> 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.
> 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
30 years ago it was the norm. It really is true that the industry (standard) has shifted a lot in that time.
But I work at a place like this right now. I was hired by the new CTO to help them change this, having spent the previous 20 years actively avoiding places just like this.
Project-based planning by a roomful of not-technical people: Funding, scope, design, shape of team, deadlines, tech stacks, vendors etc. all "locked in" before any engineer is even approached, let alone asked for input.
I cannot overstate how uncanny it feels to be working here - like I have actually time travelled back to the 90s.
I’m working in the industry since 1999, spent a lot of time in regulated industries and fully agree with you, waterfall was never the process. The actual process could generate a lot of artifacts, but it was always async, not strict happens-before relationship.
Requirements handed down - never seen it in 25 years. The requirements are always fluid, by definition. At best, you get a wish list which needs to be ammended with reality. If you have completely static requirements, you don't need an engineer! You just do it. Engineering IS refining the requirements according to empirical data.
Once you have requirements that are correct (for all well-defined definitions of "correct"), the code implementation is so trival that an LLM can do it :-)
Unfortunately it started to be taken seriously, at least by academics who went on to infect an industry. I shit you not when I tell you the Software Project Management module I took at university described Agile as “Waterfall but done much faster” back in 2010/2011.
In the 30 years I've worked in software, I've seen more than one shop that worked this way. Then "eXtreme Programming" and Scrum rose up and morged into "agile", and that pretty much went away.
Same here. It’s like the author just finishes their Software Project Management module at uni, saw AI and had their mind blown without ever learning this thing called “The Agile Manifesto” exists!
At my most recent job, 2022-2025, I saw this under the guise of SAFE agile.
Previously, no, you're right. I've always worked in aggressive engineering teams with Product and Engineering closely aligned. My last company, though, was utter undisciplined chaos for decades. SAFE was an attempt to try something to corral teams together even though it basically became waterfall.
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
Title clickbait for sure, but the process has radically changed in the past 6 months due to this new generation of models.
"Perfect code from the agent everytime" isn't really what the expectation is. Bugs are always going to be shipped into production, no matter who or what is writing the code. Where SDLC is really getting compressed is in the iteration phase.
For example:
- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.
- Bugfixing is a matter now of an agent watching error logs, diagnosing traces, and immediately issuing PRs with suggested fixes, something that again would have taken hours at least and is now down to minutes (and can be a 24x7 operation, which for most businesses is a revelation).
- Engineers have the freedom to land enhancements that in the Before Times would have sat in the backlog for months and years on end because of the time commitment. That has knock-on effects of quality, features, and just overall improvements for users.
It is a very, very, very different world that we're operating in, and what used to be huge steps of the SDLC now take less time than checking your email in the mornings with your first cup of coffee.
> This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days.
Pointing the AI agentic SLoC cannon at that sounds like a way to speedrun a set of tests that completely ossify the codebase.
Careless slapping down of tests feels great and looks good in the CI at first but a good test that only tests what it needs to do and leaves flexibility for maneuver is at least as hard to write as the code to start with.
- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.
Not if you don't describe the tests before. AI will generate absolutely useless tests, and since it seems even the latest version have difficulties to generate working test doubles (which i'm _still_ surprised about, but i took 4 hour generating a dogshit test double i could have written in half the time. To me this should be a something AI should be absolutely great at, and it's not), if your test are AI-only, understanding of the underlying system will be hard.
On bugfixing I agree with your message, but disagree on the scope: bugfixing changed for some categories of bugs (most of them tbh), but some will still have you dig deep into the database or the transaction history/monitoring.
On enhancement i agree 100%, i think this is the biggest benefit of AI. Even new hires can land a few enhancement a week without any domain knowledge. Our backlog is almost empth, and only the largest enhancement are up (basically performance improvement)
Sorry i wanted to nitpick, I do that very often when i think i mostly agree with someone except on very specific points.
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.
I read it for you. Spoiler alert, remained uninteresting until the end. I agree with the notion that we will have to adapt our workflows now that coding is getting cheaper (at least for now), but the author is suggesting to forgo PRs entirely and demonises humans for being slow and some sort of bottleneck. The author is suggesting that you can let agents go crazy on your codebase and that if you don't do it you are some sort of dinosaur that doesn't accept change. It's complete nonsense in my opinion.
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.
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...
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.
I don't understand this part either. At some point we're writing software for people to use, and there has to be someone who comes up with the requirements based on what people want. AI doesn't change this fact.
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.
THIS is what makes me so mad: the best software developers are really good at evaluating new technologies, they see where they work best and where they are not a good fit. They're curious, excited, love to share but keep a healthy skepticism and really want to understand. They are balanced and look for the nuance. They've now been told by their bosses & CTOs that this is not good enough; dive in head-first without looking or find a new job (no, this is not hyperbole). That monster weight on one end of the see-saw keeps pushing me and others towards the other end to balance it, but I don't belong there and I'm not a Luddite. I want to straddle the middle and shift my weight back and forth as appropriate and the pro-AI army keeps pushing me away. It drives me bonkers.
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.
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:
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.
I would formulate it as: The software development lifecycle is inevitable, or you will not have any software. The lifecycle is just not acknowledged and thus implicit to many people. If you hack in Notepad, FTP it to your webserver, then your lifecycle lasts till you switch it all off. A simple lifecycle, but unavoidable to have one.
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.
Yes, LLMs can basically short-circuit the entire product design and development process if you want them to. You can write "Give me a goal tracking app" and pretty reliably one-shot it. Success?
I think a lot of folks would benefit from re-reading the Agile Manifesto [0]. Unfortunately in the corporate world, "Agile" became almost a perfect inversion of the original 12 principles, but in the age of AI, I think it's more relevant than ever. Back when you could only get through a handful of "user stories" per week, there was tremendous pressure on developers to prioritize the "right" ones, which led to more and more layers of planners, architects and delivery leads.
Now the feedback loop between the customer, business and developer is as tight as it always should have been.
Agreed. People aren’t ready for this, even (maybe especially) on HN.
Everyone’s hung up on how nobody really does waterfall. Or course. But a LOT of people are vibing their code and making PRs and then getting buried in code reviews. Just like the article says, you can’t keep up that way. Obviously. Only agents can review code as fast as agents write it. But I find as of recently that agents review code better than people now, just like how they write it better. Gotta lean into it!
> Requirements gathering: fluid, not dictated
> 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.
> 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
30 years ago it was the norm. It really is true that the industry (standard) has shifted a lot in that time.
But I work at a place like this right now. I was hired by the new CTO to help them change this, having spent the previous 20 years actively avoiding places just like this.
Project-based planning by a roomful of not-technical people: Funding, scope, design, shape of team, deadlines, tech stacks, vendors etc. all "locked in" before any engineer is even approached, let alone asked for input.
I cannot overstate how uncanny it feels to be working here - like I have actually time travelled back to the 90s.
I’m working in the industry since 1999, spent a lot of time in regulated industries and fully agree with you, waterfall was never the process. The actual process could generate a lot of artifacts, but it was always async, not strict happens-before relationship.
Requirements handed down - never seen it in 25 years. The requirements are always fluid, by definition. At best, you get a wish list which needs to be ammended with reality. If you have completely static requirements, you don't need an engineer! You just do it. Engineering IS refining the requirements according to empirical data.
Once you have requirements that are correct (for all well-defined definitions of "correct"), the code implementation is so trival that an LLM can do it :-)
Remember, Waterfall model was AFAIK originally just an example of pathologically bad managed project in a conference talk :V
Almost everything is a strawman
Unfortunately it started to be taken seriously, at least by academics who went on to infect an industry. I shit you not when I tell you the Software Project Management module I took at university described Agile as “Waterfall but done much faster” back in 2010/2011.
In the 30 years I've worked in software, I've seen more than one shop that worked this way. Then "eXtreme Programming" and Scrum rose up and morged into "agile", and that pretty much went away.
Same here. It’s like the author just finishes their Software Project Management module at uni, saw AI and had their mind blown without ever learning this thing called “The Agile Manifesto” exists!
I’ve seen this at more than one company.
At my most recent job, 2022-2025, I saw this under the guise of SAFE agile.
Previously, no, you're right. I've always worked in aggressive engineering teams with Product and Engineering closely aligned. My last company, though, was utter undisciplined chaos for decades. SAFE was an attempt to try something to corral teams together even though it basically became waterfall.
Honest question: Is waterfall better or worse than utter undisciplined chaos?
Wut
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
Title clickbait for sure, but the process has radically changed in the past 6 months due to this new generation of models.
"Perfect code from the agent everytime" isn't really what the expectation is. Bugs are always going to be shipped into production, no matter who or what is writing the code. Where SDLC is really getting compressed is in the iteration phase.
For example:
- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.
- Bugfixing is a matter now of an agent watching error logs, diagnosing traces, and immediately issuing PRs with suggested fixes, something that again would have taken hours at least and is now down to minutes (and can be a 24x7 operation, which for most businesses is a revelation).
- Engineers have the freedom to land enhancements that in the Before Times would have sat in the backlog for months and years on end because of the time commitment. That has knock-on effects of quality, features, and just overall improvements for users.
It is a very, very, very different world that we're operating in, and what used to be huge steps of the SDLC now take less time than checking your email in the mornings with your first cup of coffee.
> This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days.
Pointing the AI agentic SLoC cannon at that sounds like a way to speedrun a set of tests that completely ossify the codebase.
Careless slapping down of tests feels great and looks good in the CI at first but a good test that only tests what it needs to do and leaves flexibility for maneuver is at least as hard to write as the code to start with.
- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.
Not if you don't describe the tests before. AI will generate absolutely useless tests, and since it seems even the latest version have difficulties to generate working test doubles (which i'm _still_ surprised about, but i took 4 hour generating a dogshit test double i could have written in half the time. To me this should be a something AI should be absolutely great at, and it's not), if your test are AI-only, understanding of the underlying system will be hard.
On bugfixing I agree with your message, but disagree on the scope: bugfixing changed for some categories of bugs (most of them tbh), but some will still have you dig deep into the database or the transaction history/monitoring.
On enhancement i agree 100%, i think this is the biggest benefit of AI. Even new hires can land a few enhancement a week without any domain knowledge. Our backlog is almost empth, and only the largest enhancement are up (basically performance improvement)
Sorry i wanted to nitpick, I do that very often when i think i mostly agree with someone except on very specific points.
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.
>The article might become correct in 20 years I guess.
You shouldn't wait 20 years to worry or talk about it though.
Most, if not the entire article reads to me as AI-generated which just makes me uninterested in reading further.
I read it for you. Spoiler alert, remained uninteresting until the end. I agree with the notion that we will have to adapt our workflows now that coding is getting cheaper (at least for now), but the author is suggesting to forgo PRs entirely and demonises humans for being slow and some sort of bottleneck. The author is suggesting that you can let agents go crazy on your codebase and that if you don't do it you are some sort of dinosaur that doesn't accept change. It's complete nonsense in my opinion.
What is your take on the optimal usage of AI, and why would it not be N + 1? I think the article is largely correct here.
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.
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...
And he works at Cloudflare
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.
I don't understand this part either. At some point we're writing software for people to use, and there has to be someone who comes up with the requirements based on what people want. AI doesn't change this fact.
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.
The described SDLC is a recipe for rigorously and predictably building the wrong thing.
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.
it's the Capital A Agile(TM) shysters all over again
put up against waterfall, which no-one ever did anyway
I'm not anti-AI but I'm starting to feel like I live on a different planet to the pro-AI people.
Everything in this article seems fucking insane to me.
THIS is what makes me so mad: the best software developers are really good at evaluating new technologies, they see where they work best and where they are not a good fit. They're curious, excited, love to share but keep a healthy skepticism and really want to understand. They are balanced and look for the nuance. They've now been told by their bosses & CTOs that this is not good enough; dive in head-first without looking or find a new job (no, this is not hyperbole). That monster weight on one end of the see-saw keeps pushing me and others towards the other end to balance it, but I don't belong there and I'm not a Luddite. I want to straddle the middle and shift my weight back and forth as appropriate and the pro-AI army keeps pushing me away. It drives me bonkers.
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.
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:
https://www.satisfice.us/articles/reframing_requirements.pdf
Time really goes by. I read "article from 26 years ago" as: why would you post an article from the early 80s?
I feel old.
> They don’t know what’s DevOps or what’s an SRE.
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.
was writing on exactly the same topic today! https://github.com/podviaznikov/sdlc-bridge/blob/main/AGENT-...
It's not. People who say this are not good engineers, and you'll see slop come out of this. Some of these steps you need more than ever.
No this is not an anti-ai message.
Dead? What, again?
Yet another rehash of the smoke and mirrors bullshit I've been hearing every 5 years or so for the last 40+ years.
I would formulate it as: The software development lifecycle is inevitable, or you will not have any software. The lifecycle is just not acknowledged and thus implicit to many people. If you hack in Notepad, FTP it to your webserver, then your lifecycle lasts till you switch it all off. A simple lifecycle, but unavoidable to have one.
I love this article. "btw don't do PRs, they're dead! (source: me)"...alright buddy.
"And honestly? I'm jealous." Why does every article that comes out read like it was written by AI itself. 'It's not that, it's this'
Code
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.
Yes, LLMs can basically short-circuit the entire product design and development process if you want them to. You can write "Give me a goal tracking app" and pretty reliably one-shot it. Success?
I think a lot of folks would benefit from re-reading the Agile Manifesto [0]. Unfortunately in the corporate world, "Agile" became almost a perfect inversion of the original 12 principles, but in the age of AI, I think it's more relevant than ever. Back when you could only get through a handful of "user stories" per week, there was tremendous pressure on developers to prioritize the "right" ones, which led to more and more layers of planners, architects and delivery leads.
Now the feedback loop between the customer, business and developer is as tight as it always should have been.
It’s ahead of time the same way as sci fi novels writing about fusion energy sources. May happen some day, we don’t know when.
Agreed. People aren’t ready for this, even (maybe especially) on HN.
Everyone’s hung up on how nobody really does waterfall. Or course. But a LOT of people are vibing their code and making PRs and then getting buried in code reviews. Just like the article says, you can’t keep up that way. Obviously. Only agents can review code as fast as agents write it. But I find as of recently that agents review code better than people now, just like how they write it better. Gotta lean into it!
>> But I find as of recently that agents review code better than people now, just like how they write it better.
Let me guess: you're building a system that uses AI agents to replace all the PR-type tasks most of us waste their time completing?
> Only agents can review code as fast as agents write it
Which means that their writing speed is misleading, and AI or not AI you can only produce quality software at the speed that humans can review it.
It's never been hard for a computer to write gibberish very fast.