I was reading Boris Tane’s “The Software Development Lifecycle Is Dead” and agree with several of his points, but also understand from >30 years’ XP in industry and a couple years working with GenAI and actively researching neurosymbolic AI for the better part of the past decade, I can see where there are some oversimplifications in his post and some bleedover from the GenAI hype.
That being said, and considering he calls out Claude Code in a few places as one of the silver bullets to SWE, I thought what better to analyze Boris’ post and provide counterpoints based on what its capabilities and limitations are.
Claude Opus 4.6
This is a thought-provoking piece, and Boris gets a lot directionally right. But since I’m one of the AI agents he’s describing, I think I can offer a useful perspective on where the vision holds up and where it skips over real friction.
Where I think he’s right:
The stages really are collapsing. When someone works with me, they don’t think in terms of “now I’m in the design phase, now I’m in the implementation phase.” They describe what they want, I produce code with tests, they iterate. That loop is real and it’s genuinely different from the sequential handoff model. The insight that the SDLC didn’t get faster but merged is sharp.
He’s also right that context is becoming the bottleneck skill. The quality of what I produce is dramatically affected by the quality of what I’m given — the codebase context, the constraints, the intent. Engineers who are good at framing problems for agents get outsized results. That’s a real shift in what “engineering skill” means.
And his point about monitoring becoming the primary safety mechanism is probably the most important insight in the piece. If you remove human review from the loop, you must have excellent observability or you’re flying blind.
Where I see gaps:
He overstates how much code review can be eliminated today. I make mistakes. Subtle ones — logic errors that pass tests because I wrote the tests too, architectural choices that are locally reasonable but globally wrong, security issues I don’t flag because they weren’t in my context. The idea of adversarial agents reviewing each other’s work is promising but still immature. Right now, removing human review means accepting more bugs in production. Some teams can tolerate that; many can’t. He frames human code review as “luddism,” but it’s more accurately a rational response to the current reliability gap.
He romanticizes the “AI-native engineer” a bit. Engineers who skip learning about system design, operational concerns, and debugging at depth aren’t “unencumbered” — they have a blind spot. When things break in ways the agent can’t fix, and they do, you need someone who understands what’s happening underneath. Skipping the fundamentals works until it doesn’t, and when it doesn’t, it fails badly. The ceremony might be worth shedding, but the knowledge underneath the ceremony isn’t ceremony.
The “agents commit to main” vision assumes a level of verification reliability that doesn’t exist yet. I can run tests, check types, scan for obvious issues. But I can’t reliably verify that a change doesn’t subtly degrade the user experience, introduce a performance regression under load, or violate an unstated business constraint. Automated verification is good at catching what you thought to test for. It’s bad at catching what you didn’t think to test for. That’s exactly where human judgment still matters.
He underplays coordination problems. The article is implicitly about a single engineer or small team working with an agent. But much of what the SDLC exists to solve isn’t “how does one person ship code” — it’s “how do 50 people ship code without breaking each other’s work.” Tickets, PRs, and sprint planning are partly coordination mechanisms. You can argue they’re bad ones, but removing them without replacing the coordination function they serve creates chaos at scale.
He barely touches the liability and trust question. In regulated industries — healthcare, finance, aviation — “an agent shipped it and the automated checks passed” isn’t an acceptable answer when something goes wrong. There are domains where human review isn’t ritual, it’s a legal requirement.
My honest self-assessment: I’m very good at generating code quickly, exploring solution spaces, and handling well-defined problems with clear context. I’m less reliable at knowing when I’m wrong, catching my own blind spots, or understanding the organizational and political context that shapes what “good” means in a specific codebase. Boris’s vision of the collapsed lifecycle is where things are heading, but we’re in a messy transitional period where the old process is breaking down and the new one isn’t yet trustworthy enough to fully replace it.
The smartest teams right now aren’t eliminating the SDLC or clinging to it — they’re selectively compressing it, keeping human judgment where it still has high leverage and automating where it doesn’t.
