The SDLC Didn’t Change. Where We Spend Our Time Did.
How AI agents moved the work out of development and into planning and review. Part 1 of a series.
If you drew the software development life cycle today, it would look the same as it did five years ago: plan, develop, test, deploy. The stages haven’t moved.
What has moved, and sharply, is who does the work in each stage and how long each one takes.
I’m a Director of Engineering at TestMu AI (formerly LambdaTest), where I look after our grid platforms, including HyperExecute. Over the past year I’ve watched my teams’ day-to-day work change more than it did in the previous decade. This is Part 1, about development. In Part 2, I’ll write about how AI is changing the way engineering is managed.
How it used to work
For most of my career, development was the main event.
We’d spend some time planning what a feature should look like and how it should behave. Then engineers would spend most of the cycle building it. When a change spread across several services, the complexity grew fast and the effort grew with it. Testing, release and deployment followed, but the SDLC was built around development.
How it works now
Today most of those stages are agent-driven. Development has shrunk to the shortest part of the cycle, and the time has moved upstream into planning and spec preparation.
The RFC is the new interface
An RFC used to be a document for other engineers. Now it’s also how you instruct your agent: what to build, what the expectations are and what outcome you want to see.
Once you have a well-defined spec covering what you want and how it should be built, you hand it to an agent that has access to all the repositories you work on, and it writes the code. What comes back is only as good as what you put in. A vague spec gives you vague code.
Exploring unknown code is no longer a superpower
For the past two or three years we talked a lot about the 10x or 100x engineer, someone who could find their way through an unfamiliar codebase and quickly see what a change would and wouldn’t affect.
That advantage has largely gone. Anyone can now run an agent, explore the unknown parts of a codebase and map the impact of a change. And if you build a self-improving loop around your agent, it keeps getting better the more you use it.
The hardest part is now review
Once the agent has written the code, we reach what I think is now the most challenging stage. I see two kinds of engineers here.
The first kind follows the agent blindly. The code compiles, the checks pass, and they move on without really understanding what was written.
The second kind reads the code, works to understand it and asks whether it could be better.
Get Japneet Singh Chawla’s stories in your inbox
Join Medium for free to get updates from this writer.
I’m firmly in the second group. I regularly review code written by the different agents my teams use. Agents are on their own iterative learning journey, and they do learn from their mistakes, but I still find code that needs reworking. Most of the time the root cause goes back to the spec: while generating the code, the agent made implementation decisions that didn’t match what was really intended.
If you don’t review the code, you often won’t notice those flaws.
New code vs. existing code
In a brand-new codebase this matters less. Everything is new, everything gets tested, and any flaws come up and get fixed.
In an existing codebase it’s a different story. When you’re adding a feature to code that carries years of assumptions, implementation choices can make or break other parts of the system. One quiet decision can break something three services away. That’s where careful review stops being optional.
Testing: catching up fast
Testing still needs a lot of manual effort, but that’s changing quickly, and AI agents are now a real part of it.
Full disclosure: this is a space we build in. At TestMu AI we’ve built KaneAI, an end-to-end testing agent for web and mobile, and Kane CLI, which brings it to the terminal. You describe a user journey in plain English, the agent runs it in a real browser or on a real device, checks the result, and helps you build test cases you can use to test your product end to end. It’s designed to be used by human developers and by AI coding agents.
The point isn’t any one tool. Once agents write code this fast, verification has to keep up, and that’s where testing is going.
Deployment: a human stays in the loop
Deployment is where AI has moved most slowly, and for good reason.
Most companies don’t yet have AI-driven deployment pipelines. Production is where organisations are most careful about what changes go out. Even where agents and automation are built into the pipeline, there’s still a human in the loop, and usually several people involved. I think that caution is right.
Summing up
The stage that used to take the most time in feature development, writing the code, now takes the least.
The new bottlenecks are clear thinking before the code is written and honest review after it. The engineers who do well in this era won’t be the fastest at typing or the best at digging through old code. They’ll be the ones who write the sharpest specs and still read the code.
In Part 2, I’ll look at the other side: how AI is changing the way engineering work is managed.
Which kind of engineer are you, the one who trusts the agent or the one who reads every line? I’d love to hear in the comments.
Links
