Depends on what you do, and what systems you develop for I would reckon. If it's another TODO app or some kind of table + form system that's been done to death - AI can probably have a go at creating a barebones minimal viable product. Targeting code that's outside the sweet spot of the training data ("blurry" area), you'll start to stumble. I've also found agents to be useless in large code bases with distributed logic where parts are in react, web back-end, service system). Slow and unreliable for large systems. Good for small tasks and scaffolding up proof of concepts.
The front-end is usually just a thin layer on top of a database, sometimes with backend services (queues/processing). Having a bad language on the front-end actually helped. You don't want to write code because of the bad language, you write less code, less code is less bugs. You had to be invested to increase the lines of code. It's like the hard chair of programming languages. If you don't want programmers to dwell there, bring the hard chairs.
It's meant in a tongue in cheek way. Day to day I develop in C# and Typescript/React using all the latest bells and whistles. Long for the simpler times though. The time before product managers, Scrum and ticket driven development. All the tickets drive the complexity that maybe shouldn't exist. Hard to push back against feature requests when it's a one-way street.
It's funny how things have evolved. The modern tech stack is so inefficient at providing solutions that people grab and hold on to code gen as some kind of magic machine. We have gone from pragmatic, fast and stable foundation systems that could be extended by some small snippets of code (Drupal), RAD systems (Delphi, Visual Basic) where you could drop some components and some lines of code on a form to create functionality to some of the most verbose and ugly things that have ever reared its head (React, Angular, home-made REST systems - instead of SOAP). Less code is better. The code generated today using vibe coding won't be looked back upon. It's like fast fashion. Throw it in the trash.
Thanks for sharing your perspective. I don't agree that code generated by AI will be easily distinguishable from code generated by hand; I think it depends on who is authoring. Also, for what it's worth, if it achieves the business goals, is stable and performant, does it matter?
I see where you're coming from. Some code may stick, and some generated code actually looks decent. There is a lot of coffee-fueled code that will never see the light of day again as well. It's just that there has been an inflation in code. Almost like the quantity has a positive quality all on its own, when that should be a negative ("Look at this 50k code app made in 1 day"). I think the next generation of code generators should be penalized for writing verbose code. Hopefully they'll ease the burden of maintaining systems instead of adding to it. My experience is that once a code base gets a certain size, agents start to lose the big picture - and often repeats themselves. Adding similar but not quite the same code. Less code will probably help here too. Still. If it works, it works. It's the next phase after the system's first steps I worry about (extending and maintaining).
“if it achieves the business goals, is stable and performant, does it matter?”
Yes, if you want code to be maintainable over time, or to be able to evolve as a coherent foundation that lends itself to a long term direction and vision.
I'd consider that part of the business goals, personally. I also think over time we will end up with more people doing what I talked about in the post, so the code that gets generated by those workflows will become the norm and will impact long-term direction/vision.
FWIW, the vision and direction can and should still be dictated by the human engineer. That's what engineers will be doing IMO vs. coding.
