> 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.
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.
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 :-)
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.
In waterfall, I was a young programmer in a big, disciplined, corporate environment and spent about 2/3 of my time doing documentation and meetings rather than writing code. I nearly switched careers because that wasn't what I signed up for.
In chaosland, I came in as a PM well after the company's heydey trying to sort out the mess. I wasn't there for the trips on yachts with everyone drunk. I spent my years there asking, "wtf were you guys thinking" and the answer was always, "seemed like a good idea at the time."
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
"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.
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.
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.
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.
You shouldn't wait 20 years to worry or talk about it though.
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
I feel old.
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.
My mental model on LLMs and agents is that they are force multipliers.
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 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.
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.
put up against waterfall, which no-one ever did anyway
Everything in this article seems fucking insane to me.
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.
Yet another rehash of the smoke and mirrors bullshit I've been hearing every 5 years or so for the last 40+ years.
When your context environment and constraints are properly designed, many planning, testing, and review stages can simply be skipped. It's remarkable but true.
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.
[0]: https://agilemanifesto.orgAs for agile, it was always ceremony (even says so on the tin) and can't die soon enough. A timed sprint makes no sense in an LLM environment. Just ship your damn software and stop having meetings. AI tools get us closer to XP, not agile.
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!
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.
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?