AI accelerated coding. So where are the real constraints in software development?

Companies adopt AI for coding and expect a fivefold speedup. Then they spend tens of thousands of dollars a month on tokens, and delivery speed looks the same as before. Or worse.

After two years of working with AI at Pragmatic Coders, we see something different: coding itself has sped up many times over, and delivery rarely holds us back on its own anymore. More often, the constraints are requirements, business feedback, UX, decisions, and process quality.

How the software development paradigm has changed

Over the past decades, the constraint in software development shifted with every era. In the 1960s it was computing power. In the 1980s and 1990s it was distribution and the cost of fixes. Then the internet triggered Continuous Delivery, and the constraint became coding speed. The response was agile methods, code review, clean code, and TDD.

AI has changed that setup. Coding itself has sped up many times over. Software development, understood as building a product, accelerates less than coding alone, because outside writing code the rest of the work system cannot keep up. And this is where companies most often go wrong. They hear “five times faster,” bolt on tools, look at the metrics, and see the same pace as before. The team still delivers roughly as slowly. The tokens, however, keep flying.

The problem is not that AI “doesn’t work.” The issue is that everything gets thrown into one bucket. Working on greenfield, working on legacy, and rewriting a live system are three different games — and AI delivers different value in each.

Why AI in coding does not always accelerate delivery

AI delivers the most value in greenfield, less in classic legacy, and rewriting a live system can today be faster than continuing to patch old code — those are the conclusions from our practice.

Greenfield: where AI in coding has the biggest impact

In projects written from scratch, AI used well can generate code comparable to that of an average developer. “Used well” does not mean a single prompt like “ship me an app,” but more structured work with specification, architecture, and context.

Two approaches are worth naming explicitly. Spec Driven Development means precise specification comes first, and code only after that. AI-first architecture goes further: stronger decomposition, smaller modules, cleaner boundaries of business contexts. Architecture built for human maintenance over the last 20 years is not necessarily the architecture where AI works best. AI likes small, well-separated chunks of work and up-to-date context.

Legacy: why AI often does not speed up the work

In large, tangled systems, AI does not deliver the same acceleration as in greenfield. That explains most of the disappointment in mid-size and large companies. Developers “use AI,” the company pays for tokens, and throughput stays at the previous level. Because most of the work is legacy: many dependencies, weak tests, fuzzy knowledge of the system.

AI can help with refactoring, documentation, knowledge-base upkeep, and tedious automation. It can also give developers more time to understand the code. But it will not magically “untangle” a system people have struggled with for years. Working with legacy still means reducing complexity. AI is support here, not a substitute for architectural thinking.

Rewriting legacy with AI: when rewrite is back on the table

Two years ago, the idea of rewriting a medium or large application from scratch looked like a classic bad decision. Kent Beck, Uncle Bob, Martin Fowler, and a whole shelf of books said: don’t do it. The risk was enormous.

Today that is changing. With Spec Driven Development, AI-first architecture, and existing product knowledge, you can rebuild a system faster than evolving it in its old shape.

And that raises an uncomfortable question: is it still worth talking mainly about AI in legacy — or rather about which complex systems can sensibly be rewritten as a new greenfield?

Case study: rewriting Pragmatic Meet with AI in 8 weeks

Pragmatic Meet is an application for organizing events and gathering communities around them. It is a system meetup organizers actually use. Rewriting it took about eight weeks to production with roughly 70% of the old system’s functionality.

The old version was built on heavily modified open source (Mobilizon). The team developed it for over a year… until they hit a wall. Building a single feature — a pre-event survey with first and last name for reception check-in — took six or seven weeks (sic!). It still looked bad and did not work exactly as needed. At the same time, other teams in the company, working Spec Driven Development on greenfield, were shipping value at a completely different pace.

The idea came up: rewrite. From scratch technically, but with solid product knowledge. The app had users, feedback, and a clear scope of what had to work — so we knew exactly what we wanted.

The effect was measured with Monthly Delivery Rate. It is a simple and brutal metric: total team time (Product Owner, DevOps, UX, developers) divided by the number of stories delivered in a month. Before the rewrite, the average was about 60 team person-hours per story. After the rewrite started, in July, it was already below 20. More than a threefold speedup. And that was for work that had already used AI before — just on legacy.

On the webinar, the team showed something even stronger: from requirement to a working feature in the app took under an hour. The next day that feature was supposed to go to production. That does not mean every feature always takes an hour. But with a good specification, agents, skills, and architecture, the “requirement → code → working thing” loop shrank to a scale almost nobody took seriously two years ago.

If you have your own legacy system and are wondering whether it can be rewritten in a similar model, we run this as a controlled experiment: system analysis, then a rewrite in six one-week iterations. After 6 sprints you assess code quality and pace. If the result is not worth the cost, we part ways. We take the startup risk. Book a conversation about rewriting legacy.

The faster you code, the more expensive bad assumptions become

Faster delivery makes mistakes more expensive, because in the same time more things appear that may need to be unwound. That is counterintuitive, which is why companies fall into the trap.

The old thinking goes like this: AI lets you build faster, so you learn faster, so mistakes are cheaper. In clock time the loop really can be shorter. But if you measure by the number of stories delivered, the picture flips. Once you shipped three stories in two weeks. Today you can ship thirty. If the product assumption was wrong, you are not unwinding three things. You are unwinding thirty.

On top of that comes opportunity cost. Those two weeks are not only rolling back a bad path, but also thirty stories you did not do because of that bad decision. The bigger the speedup, the more it hurts to go back a sprint or two.

That is why agile practices do not die in the AI era. They become more necessary — to catch wrong product assumptions earlier. If a team races ahead and does not wait for feedback loops, the complexity of unnecessary features grows by speedup times time. Then the pain is bigger than ever.

New bottlenecks in AI delivery: business, UX, decisions, process

When AI accelerates coding, the bottlenecks become business feedback, UX research, compliance, DevOps outside the team, and decision quality. Code stops being the slowest link in the chain.

Business feedback as a bottleneck in AI delivery

On Pragmatic Meet, for a while the team sent a daily list of delivered stories asking for feedback. The project sponsor replied about every ten days. Not out of ill will — they simply could not keep up; business feedback became the bottleneck.

The solution was not “code even faster,” but changing the cadence of accepting work:

• review in a weekly sprint
• a document describing the changes a day earlier
• time to click through and take notes. In the meeting itself: talk about decisions, not a three-hour demo of everything that was built.

Refinement and requirements in the AI coding era

A Product Owner cannot “produce requirements” alone at this pace. And should not. In Scrum, the Product Owner makes decisions. Requirements emerge close to the business, together with the team. When working with AI, refinement stops being a forgotten ritual and becomes the core of the sprint.

In practice, teams spend at least 20% of their time on this, and sometimes more. The reason is simple: if development is delivering a buffer for the current and next sprint, and refinement stalls, the whole system seizes up.

UX, compliance, and DevOps as constraints on AI delivery

Qualitative research does not happen on demand inside a weekly sprint. Interviews take time, and the respondent pool is often narrow. Validating hypotheses in production also takes time, especially with fewer users. You can ship fifteen stories in a week and only after two months have a repeatable signal whether the feature really works.

On top of that come things that used to “just somehow happen.” A policy blocking deployment. A lawyer you wait weeks for. DevOps outside the team answering “put it on the backlog.” A strategic decision nobody wants to make because the cost of reversing it is high. In the AI era that cost shows up more sharply. Not necessarily in developer salaries, but in how many other things you could have done in the same time. And in the fact that competitors are not waiting.

Process chaos and skills when adopting AI

Teams that used to work chaotically pay more for it today. AI does not fix a missing Definition of Done, Definition of Ready, tests, or ownership of architecture — but it does automate the pace. If the process was weak, you get faster… chaos.

Skill gaps get more expensive too. A wrong architectural decision at a high code-generation pace leaves a bigger footprint. So does a lack of strategy, decisiveness, and ownership. Decision processes that drag on for weeks become a hard delivery constraint.

AI and Agile: why agile practices are needed even more

You cannot sensibly run a project with AI without agile practices. It does not have to be textbook Scrum or Kanban. But there must be short feedback loops, clear acceptance criteria, tests, CI/CD, and proximity to the business.

At Pragmatic Coders, some teams moved from two-week iterations to weekly sprints. The reason was simple: after two weeks there were so many changes that review stretched to several hours and lost its point. In a week you can close review in about 45–60 minutes if stakeholders get the change list earlier.

Daily joint work at the end of the day also appeared: quick testing of what was built today, immediate fixes, a new version every day. Feedback not once per sprint, but many times during the day.

AI forces the things the industry has declared for years. Automated tests, ideally higher-level ones too, not only unit tests. Up-to-date documentation. Thought-through architecture. Developers talking with the business. Continuous Delivery stops being a “nice practice for later” — without it, this pace simply does not work.

There is a historical paradox in this. Agile began as a movement of engineers looking for better ways to deliver value. Then it grew a shell of roles, ceremonies, and transformations. Today AI pushes the weight back onto engineering practices and product proximity — because without that, building products with AI simply does not work.

How the developer’s role changes with AI in coding

In this model, a developer spends less time typing code line by line and more time guarding requirements, architecture, and verification.

In greenfield, with good tests and architectural guardrails, classic code review of all the code is often less critical than reviewing test completeness. In banking systems, trading systems, or anywhere security, data, and money are at stake, review stays sharp. In legacy too. Because AI handles large complexity and coupling only moderately well. A developer still has to consciously decide whether a model’s proposal will break the system.

What shifts is the center of gravity. Developers spend less time in the code itself and more on assumptions, module boundaries, test quality, and decisions that will be expensive to reverse. That is still engineering work — just a different kind.

How to adopt AI in software development without burning the budget

If you are starting a project from scratch today, do not copy a 2018 process and bolt ChatGPT onto it. Stop and design the work differently: from requirements, through architecture and tests, to the business-side acceptance cadence.

A few practical takeaways from what working with AI actually looks like after two years of experience:

1. First, separate contexts and ways of working. Greenfield, legacy maintenance, and rewrite are distinct strategies.
2. Second, measure delivery, not AI activity alone. Monthly Delivery Rate, time from requirement to production, number of things unwound after bad assumptions. If tokens go up and those numbers stay flat, you are not actually accelerating.
3. Third, prepare the business to accept the work. Faster development without faster feedback only moves the cork to the other side of the table. A weekly cadence, an earlier change list, and decisions instead of endless demos help more than another IDE plugin.
4. Fourth, do not skip the basics. Tests, CI/CD, Definition of Done, refinement, ownership of architecture. AI without those will not turn a team into a modern delivery machine.
5. Fifth, treat rewrite as a real option, not a taboo. Not always. Not everywhere. If a team has been fighting one feature in an old system for weeks, and the product is well known, today it more often pays to write it anew than to keep patching legacy.

Before you add another license or another IDE plugin, it is worth checking whether the engineering foundations can even carry the new pace. The Technical Health Checklist is 60 controls across six areas: architecture, tests, CI/CD, observability, data, and security. Run it with your team. No fluff. After filling it in, you can see where AI will only speed up chaos — and where delivery actually has a chance to accelerate.

Download the Technical Health Checklist

Conclusions

AI has not made software development magically cheap and problem-free. It has made coding faster, which exposed the next constraints: quality of requirements, speed of feedback, UX, compliance, decisions, and process maturity.

Companies that buy AI as a magical promise of working “five times faster” often get the same chaos, say, “at higher resolution.” Companies that rebuild how they work around specification, architecture, tests, and short feedback loops start to see real acceleration. Sometimes threefold — and sometimes so much that the business suddenly becomes the bottleneck.

And that is the right starting point for 2026. Do not ask whether to use AI, but “where is our real constraint today, now that coding has stopped being it.”