2026 Changed How We Build Software. 2027 Will Change How We Engineer.

Developers are no longer using AI exclusively to complete a function, explain an unfamiliar codebase or suggest a better implementation. They are increasingly asking agents to explore repositories, make changes across multiple files, execute tests, diagnose failures and work through tasks that previously required continuous human direction.

This is a meaningful shift in how software gets built. It also exposes a problem that will become more important as these systems improve: the ability to generate code is advancing faster than many organisations' ability to engineer reliable software delivery around it.

That is the distinction I think will define the next phase of AI-native engineering. In 2026, we saw a fundamental change in the tools available to engineers. In 2027, I expect the bigger differentiator to be how organisations design their engineering systems to take advantage of those tools.

The adoption numbers tell us this is not some distant possibility. JetBrains' 2026 Developer Ecosystem Survey found that 90% of professional developers surveyed were using AI coding agents at work at least weekly, with 68% using them daily. Stack Overflow's 2026 survey similarly found that 66% of respondents used AI coding assistants or agents in their work, with 73% of those users working with them daily.

These surveys use different samples and methodologies, but they point in the same direction. AI has moved beyond experimentation for a substantial part of the software engineering community.

What changed was not simply that models became better at writing code. The interaction model evolved. Developers increasingly work through agents that can use tools, inspect files, execute commands and iterate towards a goal. Instead of requesting a code fragment and manually integrating it, an engineer can delegate a larger unit of work and review the result.

This changes the economics of implementation. Work that previously required repeated cycles of writing, testing and correction can increasingly be delegated to an agent. Engineers can explore more approaches, automate repetitive maintenance and tackle tasks that might otherwise remain below the priority threshold.

But greater implementation capacity does not automatically translate into greater delivery capacity.

Software engineering has always involved more than writing code. Requirements must be understood, architectural decisions made, changes verified, security considered and existing behaviour preserved. As implementation becomes easier to delegate, the importance of these other activities becomes more visible.

The question is no longer simply how much code an engineer can produce. It is how much reliable, valuable change an engineering organisation can deliver.

One of the recurring mistakes in discussions about AI productivity is treating implementation speed as a proxy for engineering performance.

Imagine a team that previously spent two days implementing a feature and one day testing and reviewing it. If an AI agent reduces implementation to half a day, the team has made meaningful progress. But if the change now takes two days to review, debug and correct, the overall improvement is smaller than the coding metrics suggest.

This is a simplified example, but the underlying constraint is real. Faster production increases the amount of work that must be evaluated, integrated and maintained.

JetBrains' 2026 State of CI/CD research illustrates the challenge. Among organisations using AI in CI/CD workflows, review capacity and determining whether AI-generated changes are reliable were among the leading reported issues. AI is already being used for code review, test creation and diagnosing pipeline failures, but relatively few organisations have integrated AI directly into build execution.

The implication is important. AI does not remove the need for engineering discipline. It changes where that discipline must be applied.

The same principle applies to security, architecture and technical debt. An agent can generate a plausible implementation without fully understanding the business constraints, operational requirements or architectural intent behind it. Tests can pass while important assumptions remain wrong. A change can be locally correct and still create problems elsewhere in a system.

As implementation becomes cheaper, the cost of accepting incorrect changes becomes more significant. Organisations need stronger ways to define what good looks like, evaluate results and catch problems before they become production incidents.

This is why I expect evaluation engineering to become a foundational capability of AI-native software delivery. Tests remain essential, but the evaluation system must extend beyond whether the code compiles or a predefined test passes. It must establish whether the change satisfies the requirement, respects architectural constraints, preserves security and produces the intended outcome.

The organisations that solve this problem will be better positioned to delegate more work safely. Those that do not may find themselves generating code faster while accumulating a larger verification and maintenance burden.

The enterprise picture reinforces this distinction.

McKinsey's August 2026 State of AI survey found that 40% of respondents from organisations with annual revenues above $1 billion reported scaling AI agents, compared with 27% a year earlier. It also found that around two in ten respondents reported scaling software coding agents, rising to 31% among larger enterprises.

These figures demonstrate growing organisational commitment, but they do not establish that every deployment is delivering sustained productivity gains. Scaling a tool and transforming an operating model are different activities.

An organisation can provide thousands of engineers with AI coding agents without changing how work is specified, how architecture is communicated, how quality is measured or how knowledge is retained. In that environment, individual engineers may become more productive, but the organisation itself may not improve at the same rate.

The problem becomes more pronounced when AI agents work across multiple repositories, services and teams. They need reliable access to business context, architectural decisions, implementation conventions and previous lessons. Without that information, agents repeatedly reconstruct knowledge that already exists somewhere in the organisation.

This creates unnecessary reasoning, inconsistent decisions and avoidable rework. It also makes it harder to reproduce successful outcomes across projects.

The lesson from 2026 is that the next stage of AI adoption requires more than selecting better models and rolling out better tools. It requires us to rethink the systems through which engineering work is performed.

That is where I expect the biggest changes to emerge in 2027.

Access to capable models will remain important, but it will become less useful as a standalone source of competitive advantage. Organisations will increasingly differentiate themselves through the context, tools, constraints and feedback loops surrounding their models.

A coding agent operating with accurate architecture documentation, established engineering standards, reliable tool access and a strong evaluation process will have an advantage over the same agent operating without those foundations.

The strategic question for CTOs will shift from which model to adopt towards how to build an engineering system that consistently turns model capability into reliable outcomes.

As agents become more capable, teams will increasingly delegate work across implementation, testing, code review, documentation and maintenance. This will create opportunities to coordinate specialised agents around a shared objective.

However, running several agents in parallel is not inherently more effective than running one. Dependencies, conflicting changes, duplicated work and inconsistent assumptions can quickly erode the benefit.

The challenge will be to coordinate work, manage shared state, preserve accountability and establish clear verification boundaries. Successful orchestration will be an engineering discipline in its own right, not simply a matter of launching more agents.

Organisations will need systematic ways to assess AI-generated work before and after it reaches production. This means combining conventional automated tests with task-specific evaluations, security checks, architectural constraints and measures of functional correctness.

Evaluation will also become a feedback mechanism. When a task fails, organisations should be able to identify whether the problem originated in the requirements, the available context, the agent's approach, the tools or the verification process.

The goal is not to eliminate human review. It is to make delegation safer and more predictable, allowing human attention to focus on the decisions that genuinely require it.

Today, valuable engineering knowledge is distributed across repositories, documentation, tickets, conversations, incident reports and individual experience. Agents often need to reconstruct that knowledge each time they start a task.

In 2027, I expect more organisations to invest in maintaining accessible, structured engineering context. This will include architecture decisions, business rules, system dependencies, operational history and the rationale behind previous changes.

The advantage will not come from storing the largest possible volume of information. It will come from making the right information available, keeping it current and ensuring agents can use it reliably.

This is also where intelligence efficiency becomes important. Repeatedly reconstructing context consumes time, tokens and engineering capacity. Persistent state allows useful knowledge to survive individual tasks and compound across them.

Lines of code, suggestions accepted and tasks completed are tempting metrics because they are easy to collect. They are also incomplete measures of engineering performance.

As AI-generated output increases, CTOs will need to pay closer attention to end-to-end cycle time, deployment frequency, escaped defects, rework, change failure rates and the cost of delivering a successful change.

These measures must be interpreted in context. Faster delivery is not valuable if reliability deteriorates, and lower implementation costs are not meaningful if maintenance costs increase.

The objective should be to understand whether AI is improving the economics and outcomes of software delivery, rather than merely accelerating one part of the process.

AI will change the distribution of effort within engineering teams. Engineers will spend more time defining problems, establishing constraints, making architectural decisions, coordinating agents and evaluating results.

That does not mean engineering fundamentals become less important. In many cases, they become more important because engineers must recognise when an apparently convincing result is incorrect, incomplete or unsafe.

Organisations will need deliberate approaches to developing these capabilities. AI adoption cannot be measured only by tool usage. It must also consider whether engineers are becoming more capable of solving complex problems with AI, and whether those capabilities are spreading across the organisation.

Policies about approved models and permitted data will remain necessary, but they are not sufficient when agents can interact with repositories, execute commands and initiate actions through connected tools.

Organisations will increasingly need technical controls that enforce permissions, constrain access, preserve audit trails and apply appropriate quality and security checks at the point where work happens.

The objective is to make the safe path the practical path. Governance should enable more capable systems to operate reliably, rather than relying exclusively on rules that engineers and agents must remember to follow.

These predictions are connected by a common idea. The competitive advantage is shifting from individual access to AI towards the collective ability to engineer effectively with it.

This is what I mean by Engineering Intelligence: the collective capability of an engineering organisation to continuously solve problems, learn from outcomes and improve through the combined intelligence of people, AI and organisational knowledge.

It is not another name for AI adoption, nor is it simply a measure of how many agents an organisation deploys. It describes the capability that emerges when engineering knowledge, evaluation, tooling and human expertise work together as a system.

The distinction matters because these capabilities can compound. A successful implementation can improve the available context. An evaluation can expose a recurring weakness. A production incident can inform future constraints. Feedback can help an engineer become better at directing and reviewing agent work.

Over time, an organisation can become better at solving problems because of what it has already learned, rather than starting from the same baseline with every new task.

That requires deliberate investment. Engineering context must be maintained. Evaluations must reflect real requirements. Productivity measures must capture outcomes. Engineers must develop the skills to direct and verify AI work. Governance must be embedded into the systems that enable it.

This is the foundation of an Intelligence Strategy. The objective is not simply to give people access to AI. It is to build an organisation whose ability to solve problems improves continuously as it uses AI.

The practical implication is that technology leaders should treat AI-native engineering as an operating model to be engineered, not a collection of tools to be deployed.

Start by establishing a reliable baseline for delivery performance. Identify where implementation, review, testing and rework consume time. Then determine where AI is improving the full delivery process and where it is simply moving the bottleneck.

Invest in the foundations that make delegation reliable: accessible engineering context, clear standards, automated verification, controlled tool access and meaningful outcome measurement. Give teams room to experiment, but ensure the organisation learns from those experiments rather than leaving every team to solve the same problems independently.

Most importantly, develop the capability of the engineers who will operate these systems. The value of AI depends not only on what a model can do, but on how effectively people define problems, provide context, assess results and improve the process.

We should expect models to become more capable throughout 2027. That progress will create new opportunities, but it will not automatically produce better engineering organisations.

The companies that benefit most will be those that learn how to turn individual AI interactions into repeatable, measurable and compounding engineering capability.

In 2026, we changed how we build software. In 2027, the more important question will be whether we have learned how to engineer the systems around it.