Everyone sells AI-accelerated delivery now. What comes after?

In April, my colleague Vratislav Kalenda wrote that the developer's role has evolved from writing code line by line into guiding the development process as an architect of intent. He was right. Six months later, that sentence describes the industry default: every serious vendor now sells AI-accelerated software delivery, where a developer defines what should be built, and agents build it.

We've spent those six months putting this approach into practice on real projects for real clients, and we've found where it stops working: The code holds up well, but the people behind the work are the ones who don't, and clients end up paying the price even if it doesn't show up on any invoice.

So we are changing how we deliver. Our new approach uses an agentic SDLC that rests on three main pillars: a cross-functional team, working software built early, and an agentic pipeline. Here's why we made that decision, what we're doing differently and what it means for our clients. 

Where AI-accelerated delivery plateaus

Nobody decides to overload a team. It happens gradually, one sensible step at a time. First, AI helps developers write code faster, then agents start running in parallel and handling tests. Eventually, sprint plans are built around that increased productivity. Each step makes sense on its own. The sum is a pace our own developers describe as unsustainable.

When we asked them how the new way of working felt, the same answer kept coming back in different words: "I can do five times more, but I can't handle it cognitively." From the client's side, the problem shows up in four places.

• The bottleneck moves. On our recent agentic projects, development tasks have routinely taken just a few hours and matched our most optimistic estimates. What we underestimated, though, was product and design capacity. Speeding up code simply moves the queue to those teams.
  
  

• Review becomes the job. More generated code means more code a human has to read and vouch for. Developers who joined the profession to build things now spend their days reviewing. And with so much code to review, attention wears thin, and quality drops with it.
  
  

• Pressure compounds. If AI makes everyone faster, expectations rise too. Teams try to keep up, but burnout arrives a few months later in the form of turnover, lost context and slower delivery. The client pays for the consequences, even if they don't appear on the invoice.
  
  

• Faster isn't the same as better. An AI-accelerated team can build the wrong thing faster than ever. And if you get the architecture wrong at the start, AI will just help you build technical debt at record speed.
  
  

"I can do five times more, but I can't handle it cognitively."

These challenges show why simply giving one developer more AI agents can only take you so far. Here's what we changed instead.

Why AI software development needs shared expertise 

Let's go back to the article mentioned at the beginning. It describes how developers are moving from writing code to becoming architects of intent. Based on our experience so far, we’d change the word architect. A single person holding all the context for a product, while also steering a fleet of agents, is precisely the overload described above.

It also assumes one person is skilled at product, design, engineering, QA and every specialist role a real product needs. Almost nobody is, and nobody should have to be.

On projects using the new approach, intent belongs to a continuous discovery unit: product, design and engineering working together from the first day to the last, making decisions together rather than passing a spec from one team to the next. This approach grew out of the product trio idea, but it isn't fixed at three people. Specialists in solution architecture, AI engineering and QA architecture join when the problem needs them. A project manager holds it all together.

Depth still matters. It just doesn't have to live in one heroic generalist. With Applifting full of specialists, there's almost always someone who has solved the oddly specific problem before.

What the client gets: Fewer misunderstandings, and decisions made together by people who understand the business, the users and the technology.

Using working software to discover what to build 

The second word we'd question is intent, at least when it's treated as something you write down once and hand to a machine. Spec-driven development with agents is still a waterfall process, just in a faster trench coat. Real intent is discovered as you go: you build working software early and use it to find out what the problem actually is.

"Spec-driven development with agents is still a waterfall process, just in a faster trench coat."

A recent example. A prospective client expected a proposal three weeks after our first meeting (their stakeholders were on summer holidays). Instead, they got a working, engineered solution rather than a deck. Building it surfaced integration issues we would otherwise have discovered months into the project. That gave us a much clearer plan: one month working with their stakeholders to figure out how the product could create value for everyone and how to fit it into their processes, followed by one month to integrate.

What the client gets: Risks identified in weeks, before the budget is committed, not after it's spent.

Automating software delivery with AI agents 

The idea of an architect of intent can make it sound as though a developer's job ends once they've told AI what to build. It doesn't. Someone still has to judge whether the result is good, and that takes taste.

So we automated the rest. Our agentic pipeline takes a task, gathers the context, and builds a plan. Then it writes the code, tests it, runs an AI code review, opens a pull request and deploys to a development environment. Several agents also guard the integrity and quality of what gets delivered, so people aren't the only safety net. Developers, designers and product people spend their time on judgment, product decisions and the outcome itself.

"When you automate everything that's boring, the craft is all that remains."

What the client gets: Speed that doesn't hollow out quality, and a team that's proud of what it ships rather than exhausted by it.

What does this change about the price of software?

We've been running the new model on selected projects to test it out. Every project is different, so we're careful with comparisons, but two estimates are worth sharing:

• A seven-month project: the estimated cost came out about 26% lower than our estimate for the same scope under the previous AI-powered development model.
  
  

• A three-and-a-half-month project: about 29% lower, same comparison.

These are estimates, not final invoices, and we'll publish the actual figures once the projects close. 

The more important change is what the client is paying for. As Jan Hauser argued in Moving beyond hours, billing by the hour stops making sense when AI keeps changing how much work a team can get done in that time. You pay for a team's output and its ownership of the product, not for the seniority and hours of specific people.

The impact on our people is harder to put into numbers, but it's something we watch closely. Teams on these projects report less stress and more fulfilment. And when people work at a sustainable pace, they stay. That means the people who know your product best keep working on it. 

"You pay for a team's output and its ownership of the product, not for the seniority and hours of specific people."

Why the classic AI-accelerated model is still on the price list

Some clients want it, and it does deliver. Most organisations drift into it naturally, one small improvement at a time. We just think the pressure it builds up calls for a bigger change than drift will ever produce. On some projects we've already made that change, and we'll keep being honest about which model fits your project best.

Four questions to ask any AI software development partner

Whether you're choosing a vendor or looking at your own capacity, these questions separate a team that has moved beyond AI acceleration from one that has just bought more licences.

1. Who holds the product, design and tech context? Is it shared among the people who build the product day to day, or is it all left to one person writing user stories for everyone else?
   
   

2. How do you figure out what to build before building it? And how do you find out early that you're building the wrong thing?
   
   

3. Who reviews the generated code, and how much of it per person? If the honest answer is "one senior, a lot", that's your bottleneck and your quality risk.
   
   

4. Is the team's pace sustainable for the length of your project? A team that burns out in month four takes your product's context with it.

The craft is what remains

The best digital products are close to invisible. You don't notice them; things just work. Getting there was never about how quickly someone can write code, and AI hasn't changed that. It has removed the excuse for spending our best people's time on anything else.

If you'd like to see what this approach could look like on your product, send us one real problem from your backlog, and we'll talk it through.

Quick answers

What is an "architect of intent"?

It's the AI-era description of a developer who defines what software should do while AI agents write most of the code.

What comes after AI-accelerated software delivery?

At Applifting, we are moving towards a model using an agentic SDLC. A cross-functional discovery team works together to decide what to build, uses working software to test ideas early, and relies on an agentic pipeline for the routine work so people can focus on product quality.

Does AI make software development cheaper?

It can. We have already seen AI-powered development help reduce costs in practice. Our newer delivery model lowers the cost further: on two Applifting projects, the estimated cost was about 26% and 29% lower than our estimates for the same scope under the previous AI-accelerated model, with teams reporting less stress. 

What is a continuous discovery unit?

It's a cross-functional team, grown out of the product trio idea, in which product, design and engineering work together from the first day to the last and make decisions together rather than passing a spec from one team to the next. Specialists in solution architecture, AI engineering and QA architecture join when the problem needs them.

How should I evaluate an AI-era software vendor?

Ask four questions: who holds the product, design and tech context; how they figure out what to build before building it; who reviews the generated code and how much of it per person; and whether the team's pace is sustainable for the length of your project. Context held by one person, one senior reviewing most of the code, or a team that burns out mid-project are all warning signs.