- > 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.
- Remember, Waterfall model was AFAIK originally just an example of pathologically bad managed project in a conference talk :V
- I’ve seen this at more than one company.
- 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
- 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.
- 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 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.
- 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.
- 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.
- 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.
