The New Model of Software Delivery

By Oliver Dore

For most of the last decade, the way we write code stayed remarkably stable. While languages and frameworks evolved, with the adoption of agentic assistants the work is now moving from writing code to directing the systems that generate it—a shift as fundamental as the Industrial Revolution, with the same effect: the work doesn’t go away, it moves to a higher level of abstraction, defined by specifying intent and verifying results rather than typing every step. It’s already underway: developers are writing less code by hand, designers are generating front-end code from Figma, and product managers are filling out their backlogs with rich requirements and acceptance criteria.

At Work & Co we’ve been creating this way ourselves—shipping client work with these tools, not just trialing them. Early on, the experience was exciting and worked well on contained tasks. But once a codebase grew complex, things drifted: tests were quietly rewritten to pass instead of the bug being fixed, shortcuts that created technical debt, the same patterns repeating. It was impressive to watch, but useless without close supervision.

Over the past 12 months it wasn’t only that the models got better (though they have). It was realizing this isn’t a faster way to just generate code—it’s an evolved way of delivering it. The teams seeing value stopped treating it as powerful autocomplete and started building real workflows around it: directing the work rather than typing it, with the structure to make that dependable.

In this new model of software delivery, the gap won’t be between teams with better tools and worse ones; after all, everyone has the same tools. It’ll be between those who learn to orchestrate well and those still trying to work faster by hand.

From autocomplete to orchestration

Progress has come in three stages, each asking more of evolving AI systems.

It started with autocomplete. The first tools finished your line, then answered questions — describe a function, get a function. Useful, but you drove every step, and the unit of work was the line, then the snippet.

Then came the agent. Tools like Claude Code, OpenAI’s Codex, and Cursor began taking a goal and acting on it directly: reading the codebase, editing files, running tests, fixing their own mistakes across many steps. The unit of work became the task—”add this feature,” not “write this line.”

The newest stage is teams and long-running work. A lead AI agent delegates to specialists working in parallel, one researching while another builds and a third writes tests—the community calls these “swarms.” Claude Code’s Dynamic Workflows go further still, holding a large goal together across multiple sessions rather than a single sitting. The unit of work becomes the project, sometimes an entire codebase migration. One engineer recently ported a codebase of around a million lines in days—the kind of work that used to be scoped in quarters.

What makes it scale

Turning a capable assistant into one you can really depend on takes three core building blocks.

Connection to real systems: Through open standards, an agent can connect to the systems where the work actually lives and try a change against the real, running product rather than guessing whether it will work. Model Context Protocol—created by Anthropic—has since been adopted across the major tools. The effect is that decisions get checked against reality instead of assumed.

Introduce memory: An agent’s attention is limited. Left alone it forgets everything between sessions.Each morning it starts over, with no memory of how your team works or why things were built the way they were. Give it a lasting memory and that changes. It holds onto your team’s unique way of working: the standards you follow, the patterns you recommend, the decisions you make and the reasoning behind them. Now it builds the way your best engineers would, rather than reinventing the approach from scratch every time and pulling the work in different directions.

Guardrails & delegation: You give the agent hard limits it cannot cross, no matter what it’s asked to do. Never delete files, never touch live customer data, always run the tests before calling something finished. These aren’t guidelines it’s trusted to remember; they’re decision firewalls built into the system, so a dangerous move isn’t just discouraged, it’s not possible. Alongside that, the routine, repetitive work gets handed to helper agents, leaving the main one free to focus on the decisions that actually matter.

Notice that none of these building blocks is the model itself. They are what a team builds around the model. Anyone can buy the same tools; the framework you create around them is harder won, and harder to replicate.

What it changes about creating digital products

Until now this has mostly been a story about software engineers. But the bigger change is who gets to build at all. When building is easy and directing is the skill, a designer can stand up a working prototype and a product manager can test an idea in something real.

We’ve always believed in prototypes over presentations—a working artifact beats a slide describing it every time. We should be honest about the limits of that, though. There’s a wide gap between a vibe-coded prototype that proves an idea and the code that runs a feature for millions of users—reliably, securely, at scale, and still working six months from now. Lowering the difficulty of creating the first doesn’t lower the bar for shipping the second.

Engineers still own critical parts like the architecture, the performance, the security, the judgement about whether something is genuinely sound.That work matters more as everything around it speeds up, not less. What’s changed is that more people can now turn an idea into working software; what hasn’t is who you trust to make that software production-grade.

But how that software gets built has changed too. A digital product is the sum of many disciplines: product management, strategy, design, engineering, writing, QA. In the past, each handed off to the next, with intent leaking at every seam. What’s different now is that those disciplines increasingly share context instead of exchanging deliverables, working inside the same loop rather than in sequence. When fewer handoffs separate the idea from the implementation, what users experience reflects a single vision instead of a series of compromises. The design, the build, and the behavior all tell the same story.

Where it still falls short

Verification has become the new bottleneck. The hard part has moved from writing code to confirming it’s right. Sonar’s 2026 State of Code survey, which polled more than 1,100 professional developers, found that 96% don’t fully trust AI-generated code, and yet only 48% always check it before it ships. That gap is a problem. The time you save writing code you can lose again checking it, if the reviewing just piles up further down the line. The teams handling it well have flipped the order. Instead of reviewing code after the fact, they write the tests first and let the agent keep working until those tests pass. People decide what “correct” means up front, and verification becomes a gate the agent has to clear, not a pile of output someone has to wade through later.

Our existing software delivery lifecycles can’t keep pace. Review, QA, approval, release, was built for products produced at human speed. When generation suddenly runs ten times faster, that pipeline is where everything collects, and the temptation is to wave things through. The cost isn’t theoretical because code that ships fast reaches users fast.

There’s also one subtler risk, which is that agentic output looks polished and reads fluently, which makes it tempting to trust it. Mistake that fluency for quality, ship without real testing, and the problems surface later in production, in front of your users.

What it all means

For any company building digital products, agentic engineering changes how work gets scoped, staffed, and priced. Once implementation is cheap, the constraint moves to specification and review. The valuable work becomes knowing what to build and judging what comes back, not the typing. The people who matter most start to look less like a coder head-down in a file and more like a tech lead running a team.

The work ahead is concrete: invest in the judgement that decides what to build and what not to build, the context and standards that make an agent yours, and the verification that keeps speed from becoming risk. The ones who learn to direct it well won’t just ship faster—they’ll build things that were out of reach before, and set the standard for everyone who follows.

About the author

Oliver Dore leads Technology at Work & Co. He works closely with clients including Apple, IKEA, Goldman Sachs, and Pfizer—from architecture through launch—on the next generation of AI-powered digital products