This is an article that's so ahead of its time that it's likely to be ignored. The TL;DR is that true agentic development doesn't improve the software dev lifecycle, it throws huge chunks of it in the trash.
When your context environment and constraints are properly designed, many planning, testing, and review stages can simply be skipped. It's remarkable but true.
> Requirements used to be handed down. A PM writes a PRD, engineers estimate it, and the spec gets frozen before a line of code is written. That made sense when building was expensive. When every feature took weeks, you had to decide upfront what to build.
In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist.
> Design used to be something you did before writing code. You’d whiteboard the architecture, debate trade-offs, draw boxes and arrows, then go implement it.
Again, I've never seen this. Usually it'd be a senior engineer who spun up a project, implemented a proof of concept, and then mid and junior staff would be onboard and work within the project's design patterns, occasionally refactoring the design if it outgrew its original footprint.
I don't necessarily disagree with the agent workflow, but we should compare it to what actually proceeded it, not some imagined dummy process that never really existed. It weakens, not strengthens, the piece.
Note: I'm sure you experienced these, but have you considered that you're an edge case? I've equally considered that perhaps I've just been extraordinary fortunate in my career.
The requirements aka intents, where do they come from? Today, there are PMs interacting with customers, analyzing data, reading the regulation, connecting insights/demand with business strategy to come up with requirements. This is now all done by the engineer who out of the blue just has the right intent to instruct the agent to code? Please explain me like I’m five.
None of this is true today. Maybe it becomes true, but I don't know what planet this guy is on where he doesn't have to worry about version control and gets perfect code from the agent everytime so no need to check and not a single person types code
I agree that sdlc is changing, but dead? Come on
The poles at the ai hype scale are taking on religious qualities with these grand proclamations and imagined reality
Yeah no chance. Quite the opposite. This framework makes the process more robust. AI is just an accelerator of what is. I work at a company without mature SDLC process and it’s chaotic and leads to sub standard outcomes. We are actually looking to adopt this SDLC process soon because of it.
My mental model on LLMs and agents is that they are force multipliers.
43 years in software development: I have not seen the SDLC that this guy claims is predominant.
What has ALWAYS happened is that teams of people come together and muddle through. We use concepts from the classic “SDLC” to discuss our processes, but we never followed it. We did have milestones, yes, which is simply incremental development.
When “Agile” appeared, the world was already pretty agile. It introduced a new vocabulary and some new values. But it didn’t fundamentally change the process— which is exactly why it was so widely “adopted.” A truly different paradigm would have been ignored.
DevOps represented a real phase shift in some respects, and agentic development does take that further.
But it’s always been people muddling through, and you ALWAYS have learning and design and testing. I don’t care how you spin it— you cannot evade it.
Here is an article from 26 years ago that relates:
This article seems completely out of line with reality, maybe I am living on a different planet.
I have never heard of anyone following those SDLC steps rigorously and sequentially. Things tend to be much more intertwined, combined, and iterative than this suggests.
Even if agents were writing the code, someone would still need to identify what actually needs to be done - requirements don'y magically pop out of nowhere.
He doesn't know a single person(!?) still writing code by hand? Even the most hardcore believers in coding agents that I know still review and revise code by hand. Even the sota models spit out garbage if not carefully guided and reviewed (and even then quality is still behind an experienced human engineer for anything non-trivial).
This all seems so far from the reality I live in...
This author plays fast and loose by comparing the broad, long-term overview of a waterfall project with a dumbed-down close-up of an iterative methodology. Just because you put a bunch of opinions, or at best naive (and wrong) interpretations into clean diagrams doesn't make them right.
There's no such thing as "AI-native engineers"; it's still developers who use AI and non-developers who use AI. Why you'd want to be in second group is beyond me.
I don't belong to both "AI has replaced engineers" and "AI will never replace engineers" camps. But for now, AI is far from replacing SWEs and development processes, especially for complex software (that has many complicated specifics, such as deployment, migration, specification, code conventions, domain knowledge etc).
Yes, nowadays AI is really powerful, our company even encourages us to use it for generating some code / documentation or reviewing your own code / documentation. In recent years several IDEs are integrating it. But it's not a panacea and has its limitations. Still, it has to be supervised, the generated code should still be reviewed and corrected. You should view AI as more like an "IDE autocompletion on steroids". You need to understand the difference between a vibe coder and a normal developer who enhances his productivity by AI.
Currently AI hasn't enough autonomy for fully replacing SWEs and development processes (yet). Full stop. The article might become correct in 20 years I guess.
There was nothing stopping everyone from using continuous delivery today, yet many companies still rely on long cycles, manual testing and handovers. The problem isn't the tooling, it's the people.
Oh my goodness, most of the people with that title don't know what it is. I hate to say it because I spent like 10 years of my life in reliability, but it's largely an industry of cargo culting around two books and a bunch of memetic blog posts postured as learned architecture. The best performing teams end up ditching much of this and crafting their own strategy based on their own problems and their own engineers and leaders perspectives of them.
I'd reply to the rest of this piece in much the same strategy. The things the author is clinging to are only gone if you, as the reader, accept that there is only one true way to do them. That doesn't mean there aren't new problems or old-problems-made-new, it simply means we need to put our thinking caps on and adapt. It is increasingly apparent that a playbook, memes, and copying other people/companies strategies will not get you far in our new future.
> If everything passes, it ships, automatically. If something fails, the agent fixes it. A human only gets involved when the system genuinely doesn’t know what to do.
This right here, he conveniently skipped elaborating how will a human fix a system he hasn’t genuinely built but just prompted.
Writing code by hand helps you build a mind-map that is helpful while debugging. Without it, a human needs to go through all of the complex code.
This is not efficiency, but delaying the heavy lifting to a later date, because system fail and they fail often (nowadays).
And based on how its phrased, it looks like AI has written this article.
24 comments
[ 2.6 ms ] story [ 40.3 ms ] threadWhen your context environment and constraints are properly designed, many planning, testing, and review stages can simply be skipped. It's remarkable but true.
> Requirements used to be handed down. A PM writes a PRD, engineers estimate it, and the spec gets frozen before a line of code is written. That made sense when building was expensive. When every feature took weeks, you had to decide upfront what to build.
In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist.
> Design used to be something you did before writing code. You’d whiteboard the architecture, debate trade-offs, draw boxes and arrows, then go implement it.
Again, I've never seen this. Usually it'd be a senior engineer who spun up a project, implemented a proof of concept, and then mid and junior staff would be onboard and work within the project's design patterns, occasionally refactoring the design if it outgrew its original footprint.
I don't necessarily disagree with the agent workflow, but we should compare it to what actually proceeded it, not some imagined dummy process that never really existed. It weakens, not strengthens, the piece.
Note: I'm sure you experienced these, but have you considered that you're an edge case? I've equally considered that perhaps I've just been extraordinary fortunate in my career.
None of this is true today. Maybe it becomes true, but I don't know what planet this guy is on where he doesn't have to worry about version control and gets perfect code from the agent everytime so no need to check and not a single person types code
I agree that sdlc is changing, but dead? Come on
The poles at the ai hype scale are taking on religious qualities with these grand proclamations and imagined reality
My mental model on LLMs and agents is that they are force multipliers.
What has ALWAYS happened is that teams of people come together and muddle through. We use concepts from the classic “SDLC” to discuss our processes, but we never followed it. We did have milestones, yes, which is simply incremental development.
When “Agile” appeared, the world was already pretty agile. It introduced a new vocabulary and some new values. But it didn’t fundamentally change the process— which is exactly why it was so widely “adopted.” A truly different paradigm would have been ignored.
DevOps represented a real phase shift in some respects, and agentic development does take that further.
But it’s always been people muddling through, and you ALWAYS have learning and design and testing. I don’t care how you spin it— you cannot evade it.
Here is an article from 26 years ago that relates:
https://www.satisfice.us/articles/reframing_requirements.pdf
Does anyone actually work like this? Have they ever?
At the least it misses all the feedback loops between the stages. Even the actual waterfall model isn’t as linear as the one given as an example.
Everything in this article seems fucking insane to me.
put up against waterfall, which no-one ever did anyway
I have never heard of anyone following those SDLC steps rigorously and sequentially. Things tend to be much more intertwined, combined, and iterative than this suggests.
Even if agents were writing the code, someone would still need to identify what actually needs to be done - requirements don'y magically pop out of nowhere.
He doesn't know a single person(!?) still writing code by hand? Even the most hardcore believers in coding agents that I know still review and revise code by hand. Even the sota models spit out garbage if not carefully guided and reviewed (and even then quality is still behind an experienced human engineer for anything non-trivial).
This all seems so far from the reality I live in...
There's no such thing as "AI-native engineers"; it's still developers who use AI and non-developers who use AI. Why you'd want to be in second group is beyond me.
Yet another rehash of the smoke and mirrors bullshit I've been hearing every 5 years or so for the last 40+ years.
Yes, nowadays AI is really powerful, our company even encourages us to use it for generating some code / documentation or reviewing your own code / documentation. In recent years several IDEs are integrating it. But it's not a panacea and has its limitations. Still, it has to be supervised, the generated code should still be reviewed and corrected. You should view AI as more like an "IDE autocompletion on steroids". You need to understand the difference between a vibe coder and a normal developer who enhances his productivity by AI.
Currently AI hasn't enough autonomy for fully replacing SWEs and development processes (yet). Full stop. The article might become correct in 20 years I guess.
Oh my goodness, most of the people with that title don't know what it is. I hate to say it because I spent like 10 years of my life in reliability, but it's largely an industry of cargo culting around two books and a bunch of memetic blog posts postured as learned architecture. The best performing teams end up ditching much of this and crafting their own strategy based on their own problems and their own engineers and leaders perspectives of them.
I'd reply to the rest of this piece in much the same strategy. The things the author is clinging to are only gone if you, as the reader, accept that there is only one true way to do them. That doesn't mean there aren't new problems or old-problems-made-new, it simply means we need to put our thinking caps on and adapt. It is increasingly apparent that a playbook, memes, and copying other people/companies strategies will not get you far in our new future.
No this is not an anti-ai message.
This right here, he conveniently skipped elaborating how will a human fix a system he hasn’t genuinely built but just prompted. Writing code by hand helps you build a mind-map that is helpful while debugging. Without it, a human needs to go through all of the complex code. This is not efficiency, but delaying the heavy lifting to a later date, because system fail and they fail often (nowadays).
And based on how its phrased, it looks like AI has written this article.