https://boristane.com/blog/the-software-development-lifecycle-is-dead/

[utterances-bot]

The Software Development Lifecycle Is Dead | Boris Tane

AI agents didn't make the SDLC faster. They killed it. All that's left is context.

https://boristane.com/blog/the-software-development-lifecycle-is-dead/

[1kevinson]

Hmmm, a really high-quality article and very poignant at the same time. I generally agree with everything you've described here, but now I'm wondering.

What's left of the software engineer job?

If a Java engineer needs to learn a new programming language today, for example Rust, what learning cycle would you recommend? The traditional way, i.e. reading the official documentation for days? Or just giving the AI some context and following everything the AI asks them to do?
How do you see the rise in developer skills today?

[boristane]

@1kevinson

Everything that isn't typing code. Typing on a keyboard was never the hard part.

The job shifts from "person who writes code" to "person who knows what to build and why." Taste. Judgment. Knowing when the agent is confidently wrong.

On learning Rust: start building something real with an agent immediately. But when it generates something you don't understand, stop and ask it why. Agent as tutor, not typist. You'll learn in days instead of weeks.

On skills: the ceiling is going up. Engineers who memorized Stack Overflow answers are in trouble. Engineers who can decompose ambiguous problems and feed agents the right context are more powerful than ever.

The new skill isn't writing code. It's context engineering.

[christoz]

My fear is that we are building black boxes that no one actually understands. We are hollowing out our engineering culture; if a team can't explain the 'why' behind a codebase because they've outsourced the thinking to a bot, we shouldn't consider ourselves engineers anymore. Speed won't matter if our skills rot away.
​We need to keep the SDLC. It certainly needs to adapt to new tools, but it must remain the foundation of our work.

[charity]

I love the shit out of this post, though I prefer "outcome engineering" to "context engineering"... the context is the how, the outcome is the point. 😉 o16g.com

[AA6YQ]

re "The model has seen more systems, more architectures, more patterns than any individual engineer. When you describe a problem, the agent doesn’t just implement your design, it suggests architectures that are often superior to what you’d have come up with on your own. "

1. There's no guarantee that the model has seen architectures relevant to the opportunity you've identified.

2. "Often" is not "always"

3. Novel opportunities often require novel architectures.

4. Architecture can be a primary source of differentiation in multiple important dimensions.

[dannwaneri]

The monitoring section is the most honest part of this.

Every other safeguard absorbed or eliminated Monitoring is what's left. that's right. but most observability platforms were built for humans to investigate. when the agent that shipped the code is also the agent investigating the anomaly, you need the audit trail to be trustworthy.

AWS's Kiro tool brought down AWS for 13 hours in December. engineers "allowed" the changes. accountability chain looked intact. the observability layer didn't catch it in time.

the tight loop works when the feedback is reliable. the question is who verifies the verifier.

[ghgabr]

For anyone for which it isn't clear: this is insanity, and a bunch of bulls*it.

AI magically testing, reviewing and monitoring itself. What could go wrong? Everything.
If you use this method to "develop" software, it's extremely likely to be affected by wild defects (either from the get-go or in an update), beyond anything that a human developer could conceivably leave.

A lot of software is relied upon for important things; defects can result in physical harm, and you're going to be responsible for it if you ship software this way.

And the author works at Cloudflare... we're in for so much trouble.

[muzzlol]

I agree with the monitoring part and most of the blog. the preface is very weak and misguided imo.
"> I spent a lot of time speaking with engineers who started their career after Cursor launched..."
as someone in this bucket, that's just their lack of exposure to production systems that's speaking. of course, it should still be heavily dealt with my ai, but you'll have to learn about the lifecycle to a large extent in order to ship real systems

[JoshuaWellbrock]

Spot on, Boris. The traditional SDLC was built for a manual world, and trying to apply it to AI-augmented development is like putting a speed limiter on a jet engine. It’s an anchor, not a stabilizer.

However, I’m also looking at the comment regarding the 'Who verifies the verifier?' problem, and it hits the nail on the head. The AWS Kiro outage is the perfect cautionary tale: when the loop is too tight and the 'human in the loop' is just rubber-stamping machine-scale changes, accountability becomes theater.

We need new frameworks that force compliance and embed non-negotiable human gates into the process, not to slow things down, but to ensure the 'audit trail' is actually trustworthy when things go sideways.

That's why we are working on a new standard designed to handle the velocity AI brings while strictly enforcing the safety and observability layers that the industry currently lacks. We’re in the final steps of releasing a paper on our findings and the framework itself. It's time we build a process that is as smart (and as safe) as the code being shipped.
Check out our paper: https://arxiv.org/abs/2602.20684

[rgenisson]

Very interresting point of view, thanks.
When you give up on code reviews, how do you know something is "no resolvable" ?

[Vad1mo]

How to get to the right context? We have to take an iterative process: idea, plan, probe and build the context up step by step. Here again we are in the "SDLC", a fairly different one, but in a process

[ledohoanglong]

There is one step I disagree with: testing.

Testing is not just unit tests or automation. It’s about maintaining full control over the quality of the final product.

1. Business logic complexity
In banking, payments, finance, or insurance, thousands of business rules accumulate over the years. Requirements can become so complex that no one person can fully understand them all. If everything is handed to an agent, when something goes wrong, who is accountable? And will we even know what “correct” looks like?

2. UI/UX is important too
Testing is not only about logic. For customer-facing applications, UI/UX is critical. I don't see how an agent can simulate human perception or emotional response yet.

Process-wise, the “implement vs. test” tension exists for a reason. It’s a built-in mechanism to reveal mismatches and refine requirements. One side builds, the other validates against the requirement. When gaps appear, discussions follow - often involving multiple stakeholders across domains. Many times, these dialogues expose edge cases where no one is 100% right.

Sure, agent dev is here to stay. Still, "agent-does-all" approach assumes one thing: perfect requirements (both business and technical), or in new term, “context”. Bad news: perfect context doesn’t exist. Requirements are often shaped by messy realities and lengthy negotiations. We still need people to do this.

Agents can support the mechanical parts "coding, testing, deploying". We might need less manual hand. But please don't remove the process itself - it is where the much needed "context" comes from. The SDLC is still there, though in a different way.

[remy90]

only notifying a human when something genuinely novel goes wrong
How should an intelligent human that has delegated architecture strategies, code review processes & observability to agents suddenly become better than the agent at fixing problems its struggling with?

I assumed engineers would be required for architecture and code reviews. If we're all just planning and observing, perhaps most of our time should be spent in team meetings aligning on product requirements 🫠

[ChrisDBaldwin]

This proposed agentic SDLC reflects what I've experienced as a solo adventurer, but not within a team. I'd love to hear how you think this plays out in teams. The PR death will be a cultural schism. I assume the best path forward is XP or just a conversation with an agent in the loop. It probably looks like online gaming tbh.

Guardrails are a blessing when things move fast, but many rails assume flight is impossible. Agents fly above the rails, and we need likely need a new "magnetic field" to prevent any Icarus situations.

When there's better observability, asking is more. When asking is more, community grows. Great post, Boris!

[robertsapunarich]

Love this. It's cogent and audacious — cogent because it's a clear-eyed look at the current trajectory of things, and audacious because a lot of these practices still feel like sacred cows to me. Also, I want everyone who says there are no entry-level jobs anymore to read this paragraph:

I spent a lot of time speaking with engineers who started their career after Cursor launched. They don’t know what the software development lifecycle is. They don’t know what’s DevOps or what’s an SRE. Not because they’re bad engineers. Because they never needed it. They’ve never sat through sprint planning. They’ve never estimated story points. They’ve never waited three days for a PR review.

That said, the two wrinkles I could see in my crystal ball:

1. Accountability: if the agent handles everything, how do we contend with engineer accountability? Especially in the case of systems with a lot of legacy subservice dependencies, the sanity of the person holding the pager will be at risk (and their effectiveness limited) when agents don't have consistent ready access to all system components. I think you got at this in the monitoring section, and until we have solid observability for agents to work with I think this will continue to be a bottleneck.
2. Economics: A lot of the changes we're seeing (AFIU as of this writing) are predicated on the advancements of proprietary models (most people I talk with are heavy Opus users). Reliable agentic workflows lean heavily on the excellence of models served by privately held companies that can upend the cost/benefit analysis on a whim. I think quality open-source models that we can safely fall back on are going to be needed at some point.