That's my take as well... the dev effectively takes on QA/QC and PM roles as a team working with AI for the baseline of development work. Of course, this is also a slightly different skill set and cognitive load. It also needs to completely upend how project planning happens when you are using Dev+AI in coordination.
If developers burn through thousands in AI tokens a day, does it really matter, and is it a good spend? Are the outputs actually checked for sanity, fitness, qa/qc, security etc. How much rework is coming out because of lack of validation, or too much automation in the soup.
The more I read, the more I feel that 1 dev, 1 ai agent with the dev as a gatekeeper is probably the most appropriate workflow. Where you now treat the single dev + ai as a team in terms of planning and cost analysis and you get about 1.2-1.3x the throughput compared to a traditional team of 3-5 devs with partial PM and partial QA where the Dev now needs to take on those roles too.
The output should include more/better testing, examples, demos etc... since the bus factor is now 1, but AI is expected to be able to do the heavy lift.
I'm not sure that I completely agree... my longest lived apps are the ones that were built with a KISS to the extreme mindset... make it as simple as possible and easy to replace as can be. Then it just lives forever.
My issues with using agents is actually kind of similar... pushing for simpler solutions over excess complexity... I want an image zoom control, and the AI goes down a rabbit hole of complex math, JS and CSS... Why not just wrap in a div with overflow properties set and scale the actual image size? (then it does that and uses 1/10th the code, and surprise it actually works).
The more I use AI, the more I hear about overspend and rework, the more I'm absolutely convinced that the right way to use AI in coding is as a gatekeeper... babysit it, review what it does and steer it in the right direction.
I kind of resemble the Rockstar portion mentioned... that said, I'm a massive fan and prominently defend KISS/YAGNI over most other principals... Not the there are never abstractions, but IMO, abstractions should make the rest of development easier and not just hide the common points of use/access behind painful boilerplate or interfaces.
I know of several projects I've worked on that are alive well over a decade later, and some of which I've heard feedback on even recently. Very little of it excessively negative.
It's been an uphill battle though, especially having worked in a lot of C#/.Net shops, where Enterprise Patterns are often adopted when not necessary or prudent. There's also a balance between new tooling and what's working/known already.
I'll say my biggest recent gripe with VS Code, is since they started collapsing bits in the terminal, when I type a command and hit enter, if I start typing the next command before the first command is done, the input gets mangled.
It doesn't happen in MS Terminal (new Windows Terminal) and it doesn't happen in Tabby (which is also Electron+xterm.js), so it's a recent unique to VS Code bug... and it's annoying to no end for me. I actually rely on the integrated code terminal a lot.
My work projects are on separate hardware in a separate network that doesn't allow for AI agents... for better and worse.
I have used agents for a few components externally, that I've adopted/used internally... but those were 100% code reviewed, not vibe coded. One was an intro animation using a couple SVGs and CSS. Another was an image zoom control where I needed some behaviors and not a lot extra. Both significantly tweaked by hand as well.
I'm more a proponent of working as a gatekeeper as opposed to vibe coding... Though I think a better term would be nice.
It depends... about the hardest part for me to keep track of in Rust is complex lifetimes... you can do things and organize in ways to reduce this cognitive overhead, but it may result in slightly less performant code.
The real boost to AI, is it can do a lot of things pretty easily, that you might not on your own... really thorough test suites, or even standing up a demo application just to test a single complex component. The latter I've done a few times now.
Rust itself seems to be very well supported by the coding models and is a pretty sane language to use. I cannot really comment on Go, as I've been using a lot more Rust as I have been targeting stand alone and wasm targets respectively, the latter really isn't a good structure for Go. I can say that C# is a really mixed bag, and would assume Java is similar.
Verify all email address entries before you start using it... I absolutely HATE how much garbage I get because a few people don't understand you actually have to get an email address before you start using whatever you like.
Right, maybe I worded my response a bit vaguely. Of course you need to do an opt-in and verify them.
My point was rather that if you are operating a service with human users, there is no need to deal with quoted local parts, mixed-case, non-ascii, etc. You will just run into bugs (oh, the user signed up on an iPhone and the email field was auto-capitalized and now they can't find their account?) for almost no marginal benefit.
reply