Where to spend your software budget in 2027, now that AI writes much of the code

In short:

• AI made typing code cheaper, but the bottleneck moved, so company-level gains are smaller than the demos suggest.
• I think the time saved on development should go into scope, design and verification (tests, review and pipelines).
• The evidence is strongest for verification and thinnest for design, which is my prediction. Check your own numbers before you move budget.

Introduction

AI has made writing code much cheaper, so a software budget now does the most good somewhere else. I think less of a project's time should go on typing code, and more on the three things that decide whether the code is worth having: scope, design and verification.

This is an opinion piece. Where I cite evidence I link it, and where the evidence is thin I say so. I also run a software house that sells development, design and code audits, so weigh my conclusions with that in mind.

This is a prediction, and I have not measured it. AI made every step cheaper or faster, but it also produces far more output than before. When output is plentiful, the steps that decide whether it is the right output become scarce. I think those are scope, design and testing, and that the time saved on development should move into them.

How a project used to run

Most software projects, mine included, have followed the same six steps for years:

1. Scope. Decide what to build, for whom, and what "done" means.
2. Design. Turn the scope into user flows, screens and interaction.
3. Development. Build it.
4. Testing. Check that it works and keeps working.
5. Production. Release it and run it.
6. Support and new features. Fix, maintain and extend it.

Development was never most of the elapsed time. Bain & Company estimates that writing and testing code is only about 25% to 35% of the time from first idea to product launch (Bain Technology Report 2025). Bain counts testing inside that slice, so keep that in mind when comparing it with the six steps above.

What AI changed, and what it did not

The process is essentially the same six steps. What changed is the cost of each. AI can draft a scope document, generate user flows and interface options, write code, write tests and help review changes.

The gains are smaller than the demos suggest. Bain found that teams using AI coding assistants saw 10% to 15% productivity boosts, and that the time saved often isn't redirected toward higher-value work (Bain). DORA's 2025 research, based on nearly 5,000 technology professionals, describes AI as an amplifier of the strengths and weaknesses a team already has (DORA 2025). It also found that higher AI adoption is associated with more delivery throughput and more delivery instability (DORA).

Faros AI's telemetry from more than 10,000 developers points the same way. Teams with high AI adoption merged 98% more pull requests, but review time rose 91%, and the company-level result did not improve (Faros AI). Faros sells engineering analytics, so read that as a vendor's data, though it matches the independent sources above.

Typing got faster, and the bottleneck moved.

You will often see METR's 2025 finding that experienced developers were 19% slower with AI tools. METR itself now calls that finding outdated. It says speedups now seem likely, but that its newer results are unreliable because of selection effects (METR, February 2026). I don't rely on either number.

Scope: a generated scope still needs an owner

AI makes a scope document easy to produce, and most teams now generate one in minutes. A generated scope reads well whether or not it is right, and an AI coding agent will build exactly what it is told, including the parts nobody checked.

My view is that the time saved on development should go first into a scope that a person has actually read, challenged and understood: who the users are, what each feature must do and must not do, and what "done" means. AI can draft it, but someone has to own it.

The evidence is early but points the same way.

• DORA's 2025 research found that adopting AI without a user-centric focus can harm team performance, while teams with a strong user focus see their effectiveness grow (DORA).
• A 2026 paper describes WiseSpec, a system that checks and refines requirements before an agent writes code, on the premise that ambiguous, incomplete or incorrect requirements propagate errors into the implementation (WiseSpec).
• An exploratory 2026 study found that higher specification quality was associated with better code-quality indicators. It also notes that little earlier evidence linked requirements quality to outcomes, so treat this as a first signal (EPIC framework).
• A study of 33,000 agent-authored pull requests on GitHub analysed 600 that were not merged. It found rejection reasons including unwanted feature implementations and agent misalignment, as well as duplicate pull requests and a lack of reviewer engagement (Ehsani et al., MSR 2026).

Design: when building speeds up, design becomes the constraint

This is my opinion, and it rests on the thinnest data of my three points, so read it as a prediction.

When development gets faster, developers run out of designed work sooner. The pressure then lands on design, which has to deliver more flows and screens and make decisions earlier. Design was always meant to be where a product's value gets decided, and I think the time saved on development belongs there. Teams that don't strengthen design will either leave build capacity idle or build the wrong things quickly. When developers are waiting for designs or working from vague tickets, a squeezed design team is the likely reason.

The pressure part is supported. In the 2026 AI in Design report, a survey of more than 900 designers, 73% said expectations for their work were rising: 45% pointed to faster turnaround times and 37% to higher expected output volume. The report also says engineering teams accelerated output more dramatically with AI than designers did, so each designer is asked to cover more surface area. Of respondents, 19% said their company had reduced headcount while expecting the same or more output, 65% said they now do more PM and engineering work, and 40% said PMs and engineers do more design work. The signal on staffing is mixed: 28% of design leaders plan to grow their teams, 10% expect to reduce them, and 32% expect flat headcount with higher output expectations (AI in Design 2026, teams).

Practitioners are reaching the same conclusion, though what follows is commentary and vendor data, not independent measurement:

• Atlassian argues that implementation is becoming a commodity, and that the scarce resource is now knowing what is worth building (Atlassian, January 2026). Atlassian sells product-discovery software, so treat that as a vendor's view.
• One commentator reports that the traditional ratio of one product manager to eight engineers now behaves more like one to twenty, because each engineer ships more (VentureBeat). That is an opinion piece, so the ratio is an estimate, not a measurement.
• A survey of nearly 250 product professionals found AI use clustered around summarising feedback and generating research outputs, with far fewer people using it for upstream work on customer problems and roadmaps (Forbes, on ProductPlan's 2026 survey).
• On A/B testing, Optimizely's analysis of 47,000 agent interactions across 900 companies found that teams using agents across the experimentation lifecycle ran 78.7% more experiments, with win rates up 9.3% (Optimizely). Optimizely sells these tools, so treat that as vendor data.

To my knowledge, no one has published a measurement of how much of a project's total time now goes into design, or of teams deliberately moving time there. That part remains my prediction.

Verification: tests, review and pipelines

AI has made tests cheap to write, which most developers never enjoyed doing.

Agents now write test code at scale in open-source projects. A March 2026 study of 2,232 test-related commits from the AIDev dataset looked at how often agents add tests and what they do for coverage (Yoshimoto et al.). More integration and end-to-end tests are now affordable.

The catch is that coverage does not measure quality. One 2025 paper reports an LLM-generated suite with 100% line and branch coverage and a 4% mutation score on a single example from a Java benchmark, and calls coverage a weak indicator of fault detection (Wang et al.). Mutation testing, which changes the code on purpose and checks that a test fails, is a stricter check than coverage. A 2026 ISSTA study of 11 LLMs on Java code found that the picture depends on context. Coverage and mutation score are informative for comparing models when the code under test is bug-free, but coverage is not a reliable sign of bug-finding ability when the code may already contain bugs, and suites with more tests did not necessarily kill more mutants (ISSTA 2026).

I have seen this with my own eyes, including in audits: in the projects I looked at, quite a few tests were simply there and had never been checked, so they satisfy a coverage number and give no protection.

The research is mixed. One 2026 preprint found Claude-written Python tests no weaker than human-written ones from Django and Pandas (preprint). A static analysis of about 200,000 test files found that agents covered more edge-case inputs than humans but carried a higher risk of flakiness (study). Either way, generated tests need checking.

The strongest data is on review and pipelines. In Faros AI's 2025 telemetry from more than 10,000 developers, high-AI teams merged 98% more pull requests, but review time rose 91%, pull requests grew 154% larger and bug counts rose 9%. Its 2026 report, covering 22,000 developers, found bugs per developer up 54%, incidents per pull request up 242.7% and 31.3% more pull requests merged with no review at all (Faros AI). Faros says both reports are observational. LinearB's analysis of 8.1 million pull requests found that AI pull requests wait 4.6 times longer before review, and that 32.7% of them merge within 30 days against 84.4% of unassisted ones (LinearB). Bain's 2026 Global Technology Report, a survey of nearly 300 technology leaders, found developers completing about 21% more tasks while time spent reviewing rose 91%. A Bain partner summarised it as the bottleneck moving from writing code to trusting it, and the report recommends building automated testing, security checks and policy controls into AI-assisted workflows (CIO Dive on Bain). DORA's analysis of 1,110 comments from Google engineers found that time saved writing code is often re-spent auditing it (DORA). Faros and LinearB are vendors, so their numbers are telemetry from their own customers.

Verification covers who reads the tests, how long changes wait for review, and whether automated checks stop bad changes early.

What this means for your budget

AI affected every step of the process, but the freed development time does not disappear. It goes into new projects, and into existing ones, where it puts pressure on whatever the developers wait for, such as scope and design. If a project's total time stays fixed, I think it should be split differently from before. The table shows direction only. I have not measured the split, and to my knowledge no study has.

There is some support for the idea that freed capacity turns into more work. Faros's 2026 report, covering 22,000 developers, found task throughput per developer up 34% and epics completed up 66% between each organisation's lowest and highest AI-adoption periods (Faros AI). That is vendor telemetry, and it shows more output, not where the time went.

On staffing, my guess is that the mix of people shifts toward design, product thinking and verification, and away from typing code. A simple swap of developers for designers is not visible in hiring data yet. Indeed Hiring Lab reports that US software-development job postings rose almost 15% between late February 2025 and mid-2026, while remaining about 27.5% below their pre-pandemic level. It also found that 71% of the increase between May 2025 and May 2026 came from senior roles, and says this is in line with earlier Stanford research on the disproportionate impact of AI on entry-level jobs (Indeed Hiring Lab).

To my knowledge, there is no comparable posting data for designers. The nearest evidence says that senior developers who can review and judge AI work are in demand, and that early-career developers are squeezed. I expect the mix to shift, possibly toward more designers and fewer developers, but that is a prediction. The data neither shows it nor contradicts it.

Where I may be wrong

• The tools will keep improving. If AI gets better at scope, design and testing too, the case for shifting time shrinks. Bain notes that companies pairing AI with an end-to-end rethink of the lifecycle report 25% to 30% gains, which supports changing the whole process but also suggests every step may eventually benefit (Bain).
• Much of the evidence is association, not proof. DORA's findings are statistical associations from surveys, and Faros reports telemetry from its own customers. Higher instability may reflect teams that have not yet adapted their process, which would make it temporary.
• To my knowledge, nobody has measured the time split by phase. The studies show where bottlenecks are, not how teams should reallocate. My budget table is therefore a judgement.
• My position. I run a software house that sells development, design and code audits. That gives me the supplier's view of these steps, so check the evidence I link and weigh my view as one perspective.

What to do on Monday

Six changes a CTO or owner can make without a reorganisation:

1. Name an owner for scope on every project, and require acceptance criteria that a test could check.
2. Have someone who knows the business read any AI-generated scope before building starts.
3. Keep design capacity ahead of build capacity. Check whether developers wait for designs or work from vague tickets, and protect time for discovery and UX.
4. Ask for a stronger signal than a coverage percentage. Have a person read a sample of AI-written tests each sprint, and consider mutation testing for the code that matters most.
5. Measure review, not just output. Track how long pull requests wait, how large they are and what share merge without review, and budget review time as real work.
6. Track hours per phase for one quarter (scope, design, development, testing and review), so that you have your own numbers instead of borrowing mine.

Frequently asked questions

How is AI changing the software development process?

The process is still the same six steps: scope, design, development, testing, production, and support. What changed is the cost of each step. The evidence I have seen suggests the bottleneck has moved from writing code to scope, design and verification, and that company-level gains are smaller than individual ones.

Will AI replace software developers?

Not in the data I have seen. US software-development job postings rose almost 15% between February 2025 and mid-2026, though they remain about 27.5% below their pre-pandemic level, and most of the increase was in senior roles (Indeed Hiring Lab). That data covers the US only, and early-career developers appear to be squeezed.

Can you trust AI-generated tests?

Not on a coverage percentage alone. One 2025 paper shows an LLM-generated suite with 100% line and branch coverage and a 4% mutation score on a single example (MutGen paper), and a 2026 ISSTA study found that coverage stops being a reliable sign of bug-finding ability when the code under test may already contain bugs (ISSTA 2026 study). Have a person read a sample of the tests, and check the important code with mutation testing.

Where should you spend a software budget in 2027?

My view is more on scope, design and verification, and less on typing code. That is an opinion, not a measured result, and I recommend tracking hours per phase on your own projects before changing anything.

About the author

Piotr Żarów is CEO at Dev and Deliver, a Kraków-based software house working with senior React, Next.js, Node and NestJS engineers. This article is his opinion on where project time should go now that AI writes much of the code.

Planning your 2027 software budget, or unsure whether scope, design and testing are getting enough time on your projects? We are a Kraków-based software house working with senior React, Next.js, Node and NestJS engineers. Get in touch and tell us what you are building.

Read more about our AI code audit, product and UX/UI design and modernisation and migration services.