AI in 2027: Prove the Productivity, Don’t Just Promise It

As 2026 draws to a close, the AI conversation is shifting from possibility to accountability. Engineering teams have spent the year experimenting with copilots, coding agents and AI-assisted workflows. The question for 2027 is not whether these tools can produce impressive demonstrations. It is whether they improve the system that gets software safely into customers’ hands.

My view is straightforward: AI adoption is an input. Better outcomes are the result we need to prove.

That means ending the year with an honest review, choosing a small number of measurable bets for the next one, and being willing to stop work that does not deliver.

The productivity story is more complicated than the demos suggest

It is tempting to measure AI success by licences purchased, lines of code generated, prompts sent or developer enthusiasm. These numbers may tell us something about adoption, but they do not tell us whether delivery has improved.

DORA’s 2024 research highlighted this tension. Its analysis associated a 25% increase in AI adoption with improvements in documentation quality (+7.5%), code quality (+3.4%) and code-review speed (+3.1%). At the same time, it estimated declines in delivery throughput (-1.5%) and delivery stability (-7.2%). These are associations from that research, not universal causal effects, but the pattern is worth taking seriously: local gains can coexist with system-level costs.

A separate METR randomized study published in 2025 examined 16 experienced open-source developers completing 246 real tasks in repositories they knew well. With the AI tools tested in that study, developers took 19% longer on average, despite expecting AI to make them faster. The result is specific to that study’s participants, tasks and tools; it should not be treated as a verdict on every developer or today’s tools. It does show why confidence and demos are not substitutes for measurement.

Sources: DORA 2024 report · METR’s 2025 study.

Start the year-end review with six numbers

If I were reviewing an engineering organisation’s AI investments, I would put six measures on the table. The exact definitions matter less than consistency: establish a baseline, use the same measurement window, and segment results by workflow rather than hiding everything in one average.

1. Change lead time: how long does it take for a change to move from committed work to production?
2. Deployment frequency: are we able to release useful changes more often?
3. Change failure rate: what proportion of changes cause incidents, rollbacks or urgent fixes?
4. Escaped defects: are more problems reaching users?
5. Review rework: how much generated or human-written code needs substantial correction before it is safe to merge?
6. Time to validated customer outcome: how quickly can we move from a real customer problem to evidence that the solution helped?

Pair these measures with a little qualitative evidence. Ask developers where AI removes friction and where it creates it. Examine security findings, maintenance burden and the cost of running the workflow. A shorter first draft is not a productivity gain if it creates more review, debugging or operational work later.

Set a target that can be proved or disproved

For 2027, I would be willing to test a target such as 15% less time from a well-defined engineering task to production, with no deterioration in reliability.

That is a proposed experiment, not a forecast or a claim that AI will deliver 15%. It is useful precisely because it can fail. A target without a baseline is theatre; a target without guardrails encourages teams to optimise the wrong thing.

Here is a practical 90-day approach:

Weeks 1–2: establish the baseline

• Choose one workflow with enough repeatable work to compare.
• Record end-to-end cycle time, review rework, defects and change failure rate.
• Agree on what counts as a successful outcome before introducing the intervention.

Weeks 3–10: change one thing

• Apply AI to the selected workflow, with clear expectations for context, testing and review.
• Keep the work comparable and record where the tool saves time or adds friction.
• Track quality and reliability alongside speed, not after the fact.

Weeks 11–12: decide based on evidence

• Compare the results with the baseline and account for differences in task complexity.
• Ask whether any improvement is repeatable, meaningful and worth the full cost.
• Scale, adjust or stop. Do not keep a pilot alive simply because the team has invested in it.

For 2027, prove, scale, stop

I would use three verbs to guide AI investment decisions.

Prove. Every initiative needs a named owner, a baseline and a measurable business or engineering outcome. Adoption and activity metrics can help explain what happened, but they are not the outcome.

Scale. Expand a workflow only when evidence shows a repeatable improvement and the guardrails remain intact. That might mean shorter lead time without higher failure rates, less time spent on repetitive service-desk work without a drop in answer quality, or faster analysis without more errors.

Stop. Retire pilots that cannot demonstrate value after a fair, agreed evaluation period. This is not an argument against experimentation; it is how an organisation makes room for better experiments. Sunk cost is not a strategy.

The real work is around the model

AI tools do not operate in isolation. Their results depend on the context they receive, the systems they can access, the quality of the tests, the review process, the security boundaries and the way teams respond when something goes wrong.

That is why engineering leadership matters. The task is not simply to make individual developers faster. It is to redesign a delivery system so that people and AI can produce useful, secure and maintainable outcomes together.

I would rather have three workflows that measurably improve delivery than 30 pilots that make a quarterly presentation look exciting. Fewer initiatives, clearer ownership and honest evaluation are not signs of low ambition. They are how ambition becomes results.

Three questions to take into 2027

• Which AI-enabled workflow has demonstrably improved an outcome this year?
• What evidence would convince us to scale it — and what evidence would make us stop?
• What are we willing to stop doing so we can invest in the workflows that work?

The next phase of AI in engineering will not be won by the organisation with the most tools or the loudest claims. It will be won by teams that learn quickly, measure honestly and improve the whole system.

My challenge for 2027: choose one workflow, define the outcome, establish the baseline and run the experiment. Then publish the result — even if it is not the result you hoped for.