Code Is Getting Cheaper. The Hard Part of Software Development Is Moving Elsewhere

Key takeaways

• AI has made writing code cheaper, but enterprise releases aren’t much faster. The bottleneck has moved to specification and verification.
• Agents guess when requirements conflict. A versioned Long Spec in Git is our single source of truth: if it isn’t in the spec, it doesn’t get built.
• Agents generate around 95% of our developers’ code, yet senior engineers review every diff and remain accountable for it.
• A mobile product that once needed nine specialists can now be delivered by a pod of about 3.5 FTE that changes with each project phase.
• Models should stay replaceable. The client receives the full repository, including specs and architecture decisions, when the engagement ends.

Introduction

For years, software development was constrained by a simple economic reality: turning an idea into working code required a great deal of human time. Generative AI is changing that equation, allowing developers to produce code several times faster and agents to take on substantial implementation tasks that once occupied hours.

By that logic, enterprise software should be reaching production much faster. Except that's not necessarily what's happening.

At Miquido, we see organisations that have already invested in AI coding tools. Copilot has been rolled out, teams have experimented with Cursor and Claude Code, and developers have discovered ways to become noticeably more productive. The demonstrations are convincing, and the code really does arrive faster, yet twelve months later, the release calendar can look remarkably familiar.

The tools are working, but the bottleneck has simply moved.

This observation has changed how we think about software delivery. For decades, implementation consumed a substantial share of the effort; now AI is compressing that work, exposing the difficulty of everything surrounding it: deciding precisely what should be built, making sound architectural choices, and proving that the resulting software is reliable enough to run a business.

As Piotr Polus, our Head of Technology, explains:

The middle of the lifecycle, the code, is the part that got cheap. What's left at the two ends is a specification good enough for a machine to build from, and proof that what came out is right, maintainable and safe. An agent won't ask you at standup which requirement it should believe, it will guess. That's where the human work went.

Piotr Polus Head of Technology

What initially looked like a breakthrough in developer productivity has become a much bigger question for us: how should an entire software organisation operate when writing code is no longer its most expensive activity?

When ambiguity becomes software

Enterprise software has rarely suffered from a shortage of requirements. The problem is that those requirements tend to exist everywhere at once: Jira tickets, Figma files, workshop recordings, architecture diagrams, emails, and decisions someone remembers making during a meeting three weeks ago.

Experienced teams have traditionally managed this through informal interpretation, with developers resolving conflicting requirements, Product Owners explaining why exceptions exist, and designers clarifying interactions that never made it into a ticket. Much of software development has quietly depended on people noticing when the available information doesn't add up.

AI makes that arrangement considerably riskier. Give an agent contradictory instructions, and it may choose an interpretation and implement it without questioning the underlying assumptions. When writing code was expensive, ambiguity usually created delays and rework; now it can become functioning software before anyone has resolved the underlying question.

That is why we began treating specification as something more fundamental than project documentation.

Our Discovery process now ends with a Short Spec: a compact record of agreed features, integrations, and technical assumptions. On one of our current engagements, this document runs to just 103 lines and forms an annex to the contract, defining scope and budget. Changes remain possible, but they have to be made explicit rather than disappearing into an expanding backlog.

The Short Spec is then developed into a Long Spec containing acceptance criteria, flows, open questions, and change history. It lives as plain text in a Git repository, versioned and reviewed through pull requests. This may sound like an unusually technical place to keep product requirements, but the specification is no longer simply something developers consult; it is increasingly something machines build from.

The Long Spec sits within what we call the umbrella, a single project repository that brings together the source code, requirements, architecture decision records, and the conventions agents need to work correctly with the product. It serves as both the project's memory and the working context for AI, keeping the knowledge behind the software in one place rather than scattered across documents, tools, and conversations.

Jira can still manage tasks and Figma can still define interfaces, but the Long Spec remains the single source of truth for what gets built. Our rule is simple: if something isn't documented in the Long Spec, it doesn't get implemented.

Nor does this require months of documentation before development begins. We can start implementation when approximately 20–30% of the Long Spec is ready, allowing specification and delivery to progress together.

For enterprise leaders, the value lies in greater control over scope and spending. A signed specification establishes what the business has committed to, while a versioned record of requirements makes subsequent changes visible and easier to assess. As AI accelerates implementation, this discipline becomes increasingly important: organisations need to know not only how quickly their teams can build, but whether that speed is being applied to the right work.

The engineer who writes less code

The change in specification has been accompanied by an equally significant change in engineering.

In our current workflow, a developer translates requirements from the Long Spec into an engineering plan, guides the agent through implementation, and reviews the resulting code before approving it. Once the code is ready, the senior engineer inspects the resulting diff and decides whether it can be merged, remaining responsible for the implementation even when an agent performs much of the coding.

Across our developers, the median share of code generated by agents is currently around 95%. It's an extraordinary number, but also a misleading measure of productivity on its own, since it tells us how much code a machine produces rather than whether the architecture makes sense, the implementation reflects the business intention, or the result will remain maintainable.

In fact, one of our more surprising findings is that AI has made engineering experience more important, not less.

As Piotr puts it:

A strong engineer gets more and better. A weaker one just gets more.

Piotr Polus Head of Technology

Agents increase output without automatically improving the judgement guiding that output, which means a poor architectural decision can now be implemented with remarkable efficiency. The implications extend beyond individual developers to the composition of entire teams.

From nine specialists to a pod of 3.5 FTE

Two years ago, a mobile product of this kind might have required nine people throughout development: a project manager, designer, four developers, QA, DevOps, and an AI/ML specialist. Today, we're organising comparable work around a pod averaging approximately 3.5 full-time equivalents. The more interesting change, however, is not simply the smaller team but the fact that its composition can evolve throughout the project.

Product and design carry more responsibility early, engineers join as enough specification becomes available, and QA becomes more prominent in the second half. Throughout the engagement, the Product Owner maintains responsibility for both specifications, while the wider team draws on shared tooling for activities such as code analysis, documentation, and test preparation.

Making this model repeatable requires more than giving every employee access to an AI assistant. We're building a library of documented skills across eight domains, each with a defined purpose, input, output, and human owner. Some help structure workshop transcripts or document architecture decisions, while others are designed to respond to development events, such as a pull request opening or a story becoming ready for QA.

The library continues to evolve, with new skills developed, tested, and introduced into production as they prove reliable. We make this distinction deliberately because a promising automated workflow is not the same thing as a proven one.

A dedicated AI Core team develops shared tooling, informed by feedback from actual projects. That organisational decision came from experience: we initially expected developers equipped with AI tools to build the infrastructure they needed themselves, but found that a central team had to create shared capabilities that individual projects could then use and improve.

For enterprise clients, this changes the economics of software delivery. A smaller, adaptable team can allocate engineering capacity according to the needs of each phase rather than maintaining the same roster throughout the project. But the more consequential advantage is clearer accountability: the Product Owner controls the specification, engineers remain responsible for implementation, and quality decisions stay with experienced specialists. The result is a delivery model designed to make better use of engineering investment without sacrificing the oversight that enterprise systems require.

What happens when the code arrives too fast?

It would be convenient if the story ended with smaller teams, faster implementation, and more capable engineers, but some of our most important findings concern what we still don't know.

Technical debt is one example. If clean code can arrive several times faster, poorly structured code can too, and we don't yet know what sustained volumes of AI-generated code will mean for maintainability over three or five years. Evaluating an individual AI skill against known-good outputs tells us whether it performs a task correctly, but it cannot tell us what thousands of those implementations will eventually do to a large codebase.

Testing presents a similar paradox: generating more tests is becoming trivial, while knowing which tests actually matter remains difficult. This is one of the areas where we're concentrating the most effort.

Security creates another challenge. Agents can inspect enormous quantities of code and configuration with a consistency that's difficult to reproduce manually, yet they can also flag irrelevant issues while overlooking something that requires deeper architectural context. Our security reviews therefore remain senior-led, with experienced engineers overseeing AI-assisted analysis, evaluating findings, and taking responsibility for the final assessment.

These limitations matter particularly in enterprise environments, where the consequences of an incorrect decision can extend far beyond a failed feature.

Your software delivery process should outlive your AI tools

There is also an uncomfortable dependency in the technology itself. The models and coding tools we rely on continue to change, and their long-term economics remain uncertain. We're also exploring EU-hosted alternatives with Scaleway, recognising the growing importance of data sovereignty and technological independence. As these capabilities mature, they could give us greater flexibility in choosing where and how AI workloads are deployed.

That experience has reinforced an important principle for us: software delivery should not depend on any particular AI tool remaining at its centre. Models should be replaceable, while architecture decisions, engineering conventions, specifications, evaluation criteria, and the reasoning behind them should survive.

What should an enterprise own when code is cheap?

This brings us back to the umbrella, and to something that may ultimately matter more than the amount of code AI can generate: who owns the knowledge required to build and maintain the product.

Because the repository contains the source code alongside the specifications, architectural decisions, and the reasoning behind them, the knowledge accumulated during development remains accessible beyond the original project team. When our engagement ends, the client receives the entire repository, allowing their internal engineers or another supplier to continue developing the product without having to reconstruct how it was designed and why particular decisions were made.

We're aware that this makes us easier to leave, but we think it is one of the reasons to start.

The approach is already being tested on live enterprise engagements. We're using it during the rewrite of a mobile and web product serving millions of users. For another client, Discovery mapped roughly 40–50 integration points for a new build, delivered through a pod whose composition changes with the work.

These are ongoing projects rather than finished case studies, and they're helping us understand which parts of the process work reliably, where our assumptions need revisiting, and which capabilities still need to mature. We expect some of today's answers to be wrong, particularly when several assumptions we held only months ago have already changed.

The first phase of generative AI in software development was largely about how much code machines could produce. The next will be about whether organisations can turn that capability into a more effective way of delivering software, with clearer requirements, more adaptable teams, stronger quality controls, and less dependence on individual tools or suppliers.

For enterprise technology leaders, this changes how software delivery should be evaluated. The number of developers assigned to a project or the percentage of AI-generated code tells only part of the story. What matters is whether the organisation can translate business priorities into reliable software, maintain control over scope and spending, and retain the knowledge needed to evolve its products long after the original development team has moved on.

The competitive advantage may not belong to the organisation generating the most code with AI, but to the one that learns how to make the entire process work differently.

As Piotr puts it:

The next five years will be chaotic. Flexibility is the thing worth owning.

Piotr Polus Head of Technology

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest.You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more