As a Sr. Engineer, I completely get that my situation may be wildly different from what’s cited in the article.
Right now, I’m using AI “in the loop” rather than “as the loop”. That’s a big difference. And I’m getting my ass kicked routinely on review for dumb-ass things that I’m letting slide from AI generated output. And rightly so. Plus, models routinely lead me down sub-optimal blind alleys while dreaming up really stupid ways to fix problems. The level of (re)prompting I have to provide to suggest to get decent quality results converges on a post-grad that has encyclopedic knowledge of software engineering as it exists online, but with zero real-world experience. It’s both impressive and dangerous as a replacement for software engineering.
In the mode I describe above, I’m not losing the ability to do anything. I can see how one could surrender some coding chops or familiarity with a whole language or stack, in favor of automation. But all you have to do is not do that.
I will say that as a rapid-prototyping technology, It’s nothing short of miraculous. I’ve watched junior engineers knock together medium-weight applications, complete with browser UI/UX and decent workflow, in less than a week. This is great for showing value or putting something semi-functional in front of management and/or customers. But pivoting those prototypes into something maintainable is an utter nightmare. Depending on how beholden to AI and forever prompt-looping with “skills” and MCPs you want to be, I suppose it’s possible to just keep mashing the AI button. But at some point, you’re going to need to get inside there to fix security problems or bugs that elude this workflow. What then?
I joined a project that was forced to use some vibe coded solution that an intern cooked up – marketed as “solution for data pipelining”.
There are no tests, every semantic query calculates embeddings every time, and there is help together with so much bubble gum and “glue code” that nobody feels confident with any of the data were showing our customer.
It’s great for rapid prototyping, and then straight to the trash.
Thing is, as we all know, prototypes rarely make it to the trash bin if managers and product owners have a stake in the project. Which becomes an even bigger problem now that minimal amounts of humans are involved in producing said prototypes.
I had a meeting with a customer who proudly proclaimed they do “full-on agentic coding” at their startup, and one of their developers mentioned their entire codebase has been rewritten three times in the past week before the meeting took place. I do not have high hopes for their project ever being refactored by humans involved in anything else than light UAT before customer demo time.
(X) Doubt
As a Sr. Engineer, I completely get that my situation may be wildly different from what’s cited in the article.
Right now, I’m using AI “in the loop” rather than “as the loop”. That’s a big difference. And I’m getting my ass kicked routinely on review for dumb-ass things that I’m letting slide from AI generated output. And rightly so. Plus, models routinely lead me down sub-optimal blind alleys while dreaming up really stupid ways to fix problems. The level of (re)prompting I have to provide to suggest to get decent quality results converges on a post-grad that has encyclopedic knowledge of software engineering as it exists online, but with zero real-world experience. It’s both impressive and dangerous as a replacement for software engineering.
In the mode I describe above, I’m not losing the ability to do anything. I can see how one could surrender some coding chops or familiarity with a whole language or stack, in favor of automation. But all you have to do is not do that.
I will say that as a rapid-prototyping technology, It’s nothing short of miraculous. I’ve watched junior engineers knock together medium-weight applications, complete with browser UI/UX and decent workflow, in less than a week. This is great for showing value or putting something semi-functional in front of management and/or customers. But pivoting those prototypes into something maintainable is an utter nightmare. Depending on how beholden to AI and forever prompt-looping with “skills” and MCPs you want to be, I suppose it’s possible to just keep mashing the AI button. But at some point, you’re going to need to get inside there to fix security problems or bugs that elude this workflow. What then?
I joined a project that was forced to use some vibe coded solution that an intern cooked up – marketed as “solution for data pipelining”.
There are no tests, every semantic query calculates embeddings every time, and there is help together with so much bubble gum and “glue code” that nobody feels confident with any of the data were showing our customer.
It’s great for rapid prototyping, and then straight to the trash.
Thing is, as we all know, prototypes rarely make it to the trash bin if managers and product owners have a stake in the project. Which becomes an even bigger problem now that minimal amounts of humans are involved in producing said prototypes.
I had a meeting with a customer who proudly proclaimed they do “full-on agentic coding” at their startup, and one of their developers mentioned their entire codebase has been rewritten three times in the past week before the meeting took place. I do not have high hopes for their project ever being refactored by humans involved in anything else than light UAT before customer demo time.