The unit of optimisation for AI-enabled engineering should be the software delivery lifecycle, not the individual developer. A team can generate code faster and still deliver no faster if requirements are unclear, architecture decisions wait for review, environments are unstable, tests are late, security is bolted on or releases remain manual.
This is why “we have Copilot licences” is not an AI engineering strategy. It is a tool deployment.
Start with flow, not keystrokes
Software delivery is a chain of knowledge transformations. Business intent becomes requirements. Requirements become architecture and design. Design becomes code and configuration. Code becomes tested behaviour. Tested behaviour becomes a deployable change. The change becomes an operational service with telemetry and feedback.
AI can assist at every transition. The highest value comes from reducing the delay and information loss between stages.
Discovery: use AI to compress evidence, not replace stakeholder judgement
AI can summarise workshops, compare process documents, extract candidate rules from legacy systems, identify conflicting requirements and draft backlog structures. This is valuable when every output remains traceable to source evidence.
The failure mode is producing polished requirements before the team has resolved the underlying business ambiguity. Faster documentation of an unresolved process is still unresolved analysis.
Architecture: turn decisions into reusable context
Architectural context is often trapped in diagrams, meeting notes and a few experienced people. AI can help retrieve standards, compare options, draft architecture decision records, analyse dependency implications and review code against known patterns.
But the organisation needs a governed architecture knowledge base. If an engineering assistant is grounded on obsolete patterns or contradictory documentation, it can accelerate inconsistency.
Build: code generation needs an engineering envelope
AI-generated code should enter the same or stronger controls as human-generated code. Style, dependency policy, secrets handling, static analysis, unit tests, peer review and provenance still matter. NIST’s Secure Software Development Framework is useful precisely because it is outcome-based: AI changes how software is produced, not the need to protect the integrity of the software lifecycle.
I would also make the repository the unit of governed context. Developers should not have to manually paste sensitive code into arbitrary tools. Enterprise-approved assistants should operate through controlled integrations, identity and policy.
Testing is where AI can shift the economics
Many teams underinvest in test design because it is time-consuming and occurs under schedule pressure. AI can generate candidate unit tests, boundary cases, data combinations, regression packs and even explain failures. The opportunity is not to maximise the number of tests. It is to improve the speed with which the team can create meaningful coverage.
AI-generated tests need evaluation too. A test that simply mirrors an implementation can reinforce the same defect. High-value test generation should be informed by acceptance criteria, domain rules, historical defects and risk.
Release: automate evidence preparation
Change approval often involves assembling evidence from multiple systems: test results, code quality, security scan, deployment plan, rollback steps and release notes. Much of this is ideal for automation and AI-assisted summarisation because the source artefacts are structured and the approval remains human.
Measure system throughput
Useful engineering metrics include lead time from ready requirement to production, review waiting time, escaped defects, deployment frequency, recovery time, test coverage quality, rework and time spent understanding legacy components. These expose whether AI is improving delivery flow rather than simply increasing generated output.
A redesigned AI-enabled SDLC
- Discover: evidence synthesis, rule extraction, ambiguity detection.
- Prioritise: value, dependency and risk analysis.
- Design: architecture retrieval, option analysis, ADR drafting.
- Engineer: governed code assistance, refactoring and documentation.
- Verify: test generation, security checks and evidence synthesis.
- Release: deployment automation, release notes and control evidence.
- Operate: incident summarisation, log analysis and feedback into backlog.
The goal is not an AI developer. It is a software delivery system in which people spend less time reconstructing context and more time making engineering decisions.
The control point shifts from production to verification
When AI accelerates code generation, the bottleneck moves. A team can produce more candidate code than it can safely understand, review and release. That makes architecture constraints, automated testing, secure coding standards, dependency control and observability more important—not less. The organisation must increase its capacity to verify change at roughly the same pace that it increases its capacity to generate change.
This is why “developer productivity” measured as lines of code or pull requests is a poor AI metric. I would look at lead time from accepted requirement to production, escaped defects, review cycle time, rollback rate, test effectiveness, vulnerability remediation and the percentage of generated change that survives review without substantial rework.
Give AI context deliberately
Generic coding assistants know programming languages; they do not automatically know the architecture of the organisation. Useful engineering agents need controlled access to coding standards, architecture decisions, API contracts, data schemas, test conventions, deployment patterns and relevant repository context. That knowledge base should be curated. Feeding every document and repository into a model creates noise and may create security exposure without improving decisions.
Modernisation is an especially strong use case
In legacy modernisation, AI can help map unfamiliar code, propose tests around existing behaviour, translate scripts, document interfaces and compare duplicated implementations. The productivity gain is greatest when these outputs feed a disciplined engineering workflow rather than bypass it. I would use agents to create a first-pass understanding and candidate change, then require deterministic builds, tests, static analysis, security scanning and human technical review before acceptance.
The end state is not a team that types faster. It is an SDLC in which more of the low-value search, translation and boilerplate work is automated while engineers spend more time on design, risk, performance and business behaviour.
