Rethinking the Software Development Cycle in the Age of Agents

Written By: Zeeshan Abbasi

Every software team runs some version of the same relay race. A product manager defines what needs to exist and why. A business analyst translates that intent into requirements: the detailed “what” that other humans can build against. A technical lead breaks that down into an architecture and a plan. The development team writes the code. QA tests it, finds what’s broken, and sends it back. The cycle repeats until QA signs off, the BA confirms the requirements were met, and the PM and stakeholders give the final nod before it ships to the world.

It works. It’s also slow. The slowness comes from how many times the baton gets passed, and how much gets lost or reinterpreted at each handoff. A requirement written by a BA gets reinterpreted by a tech lead, reinterpreted again by a developer, and by the time QA finds the gap, you’re three translations removed from the original intent.

The merge is already happening, just not in one direction

Right now, different teams are attacking this problem from different angles, mostly without coordinating with each other. Some are pointing AI at QA: automated test generation, automated regression suites, agents that find bugs faster than a human tester working through a checklist. Others are focused upstream, using tools like Cursor to help developers write and ship code faster, without touching QA or requirements at all. Both are real progress. Neither, on its own, shrinks the cycle. It just makes one leg of the relay faster while the baton-passing stays as slow as ever.

The real shrinking happens when you stop optimizing individual roles and start asking a harder question: which of these handoffs can be removed entirely?

What I learned by trying to remove the middle

My own path here started, like a lot of teams, with QA. Automating testing seemed like the obvious first move: clear inputs, clear pass/fail outputs, an easy place for AI to add value without much risk. And it worked, up to a point.

But it exposed a deeper problem fast. If the requirements feeding into that automated QA were still loosely written, ambiguous, human-interpreted documents, the AI was faithfully testing against the wrong thing. Garbage in, faster garbage out. So the next instinct was to push AI upstream too, having it generate or tighten the BA’s requirements. That helped, but introduced a new failure mode: now AI-interpreted requirements were feeding AI-driven QA, and errors on both ends were compounding instead of canceling out. Nobody was left holding the thread end to end.

The fix was being deliberate about where humans stay in the loop. We landed on a principle: the input and the output stay human-owned. A person defines the requirement. A person confirms the result meets it. Everything in between — architecture decisions, implementation, test execution, iteration — is fair game for agents to own completely.

That principle became the rule every later stage of this had to follow.

The staged evolution: how roles get removed, one at a time

This doesn’t happen as one leap. It happens in a fairly predictable sequence, and I think most teams will recognize themselves somewhere in this progression.

It starts with isolated experimentation: the QA automation and dev-speed tooling described above, tried separately, by different teams, uncoordinated. From there, the more interesting shift happens upstream. Instead of a business owner handing a spec to a BA, who hands it to design, who eventually hands it to engineering, the spec starts going out in parallel, to the technical track and the design track at the same time. Engineers and designers then sit together against that same shared spec and conceive the product concept jointly, rather than design finishing first and throwing the result over the wall for engineering to interpret.

From there, compression starts happening layer by layer on the engineering side. Junior developers get bypassed first, their work increasingly absorbed by agents working directly off well-specified tickets. Then mid-level engineers follow the same path. What’s left is a technical lead whose job changes shape entirely. Instead of assigning work downward to be interpreted by other humans, the lead’s value becomes enrichment: taking the spec and turning it into a precise, code-aware document with direct pointers into the existing repos and the properties and fields that will be touched. An exact technical map rather than a description of intent.

That enriched document is what feeds directly into agents, which generate the code, write and run the unit tests, and integrate the result into the system: a tight, fast iteration loop with far fewer humans standing between spec and shipped code.

Design follows the same pattern on its own timeline. Tools like Figma, paired with Figma MCP, are already starting to let design output feed directly into generation, cutting the designer-to-developer handoff the same way the junior-developer handoff got cut. And through all of it, QA stays fixed as the human-anchored check on the output side. The business owner anchors the input, QA anchors the output, and everything in between is where the agents live.

This isn’t one pipeline uniformly speeding up. Every discipline — engineering, design, and soon DevOps and data — is running its own version of the same compression, on its own timeline, simultaneously.

DevOps closes the loop automatically

Once code, tests, and infrastructure-as-code live inside the same shared agent context, deployment stops being a separate, human-triggered step. CI/CD integrated directly into that loop means a change that passes its tests can move to deployment without someone manually kicking it off.

What’s made this practical, in our experience, is that agents can now read staging logs — deliberately not production — to debug issues and reverse-engineer fixes back into the infrastructure-as-code itself. And it works the other way too: agents can enrich the infrastructure code directly, proactively driving and debugging the system rather than waiting for a human to notice something’s wrong. We’ve done this in practice; it’s doable today, not a someday capability.

Scaling sideways: workspaces, not tickets

The same thinning-middle logic scales sideways too, across repositories and disciplines. The unit of work stops being a single ticket owned by a single developer, and becomes a workspace: multiple agents working across multiple repositories at once, sharing context and knowledge the way a well-run team shares tribal knowledge, except nothing gets forgotten or siloed in one person’s head.

That’s what makes absorbing DevOps and data engineering realistic. Once agents share context across the whole stack, they’re not guessing at how an infrastructure config relates to the service it deploys, or how a data pipeline relates to the application logic consuming it. They authored both. A human specialist’s value was rarely just technical execution; it was remembering why something was built a certain way and what broke last time. When that memory becomes structurally part of the shared agent context instead of living in one person’s head, the need for a dedicated human to hold it drops right along with it.

The catch: agents need real context, but can’t have real access

Agents write better code and better queries when they can see realistic data and a realistic environment to work against. A query tuned on a thousand fake rows behaves nothing like the same query at production scale. But you can’t hand agents real production data either. That usually means customer PII, financial records, or whatever else compliance has nightmares about, and “the AI needed it” doesn’t survive an audit.

The answer looks like what mature engineering teams already do for human developers, taken further: anonymization pipelines that produce staging data realistic enough — in shape, scale, and distribution — that agents working against it write code that behaves correctly in production, without any of it being real. Beyond that, the fuller version is something closer to a digital twin of the infrastructure and data landscape, the same concept IoT teams have used for years to simulate and test against a live system without touching it. Give agents a high-fidelity mirror to work against, and they can reason and iterate freely while the sensitive systems stay behind a wall they never need to cross. This is a precondition for the whole vision, not a nice-to-have bolted onto it.

The compiler trust analogy

We don’t write machine code anymore. We write in high-level languages and trust a compiler to translate our intent into something a processor executes correctly, without checking its output line by line. That trust was earned over decades of compilers proving themselves reliable, edge case by edge case, until “the compiler probably introduced a bug” stopped being anyone’s first suspicion.

Generated code, and eventually full agent-driven development, is on the same trajectory. Right now, most of us review AI-generated code the way early programmers double-checked their compiler’s output: carefully, skeptically, line by line. That’s appropriate for where things stand today. But the trust curve is shaped the same way. As agents prove themselves across enough real, verified cycles, scrutiny shifts up a level, from “did the agent write this line correctly” to “did the final output meet the requirement,” the same way we stopped checking assembly output and trusted that our code compiled.

Code stops being written for humans to read

The code itself also starts to change shape. A huge amount of what we call “clean code” — the layers of abstraction, the design patterns, the human-friendly naming and structure — exists for one main reason: it makes code easier for the next person to read, understand, and safely modify. That’s always been a tradeoff against performance. Abstraction layers have a cost, and we’ve paid it willingly for decades because human comprehension mattered more than the cycles it cost.

When the primary author and primary reader of code is an agent instead of a human, that tradeoff shifts. If a human is rarely the one reading it line by line, code can optimize for something else: machine efficiency and token efficiency, cheap to generate and parse, fast to execute. A lot of the abstraction we’ve built up is a readability tax paid against raw performance, and as agents become the primary consumers of that code, there’s less reason to keep paying it.

This doesn’t mean code turns into unreadable machine noise. It means the design goal changes: fewer unnecessary layers, less abstraction for abstraction’s sake, structure that’s efficient to generate and reason about rather than structure that’s comfortable for a human skimming it in an editor. The byproduct is performance gained back, not from a clever new optimization but from no longer carrying the cost of a readability requirement that mattered less once humans stopped being the primary reader.

Focus on the product, not the product team

The part product managers should sit with: the team is going to keep shrinking. That’s the direct, structural consequence of everything above, not a risk to manage around, and it isn’t slowing down. Very soon, a single person will be able to take a product from idea to shipped reality, end to end.

Which means team size and role composition are the wrong things to be optimizing for. The right focus is the product itself: usability, user empathy, the quality of what ships, the speed to get it there, and the cost of getting it there. Not headcount, not org structure, not which roles happen to be staffed this quarter. Competitors who are still organizing around team size instead of outcomes will be slower and more expensive, and that gap will show up in the market.

For anyone building a career through this, the roles with staying power are the ones requiring judgment and decision-making that can’t be handed to AI, not yet and maybe not for a long while. The best hedge I know of is breadth: experience across multiple sectors or domains, inside your industry or outside it, rather than narrow specialization in the slice of the cycle that’s being compressed. The people who adapt in time will protect their own relevance and secure the cost, the speed, and the competitive edge for whatever they build next.

Zeeshan Abbasi is the Chief Technology Officer at Y Combinator-backed Mahaana Wealth, driving innovation across fintech, cloud architecture, blockchain, and machine learning.

Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem. 

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect policy or position of any SPIN IDG media platforms. The content is provided for informational purposes only and SPIN is not liable for or does not endorse any products, services, or opinions mentioned in the aforesaid piece.