AI makes implementation cheaper. Organisations will capture the benefit only if they redesign how they discover problems, make decisions, maintain context and validate what they release.
Engineering organisations still use structures designed for a period when producing code was time-consuming: detailed handovers before anybody could see a result, plans calibrated around implementation effort, and review and quality assurance (QA) practices that combined technical, product and risk checks. Adding an AI coding tool does not resolve the mismatch between cheaper implementation and an unchanged delivery process. The organisation itself has to change.
I believe organisations should evaluate each engineering practice separately: design, estimation, handovers, story slicing, code review, testing, documentation and approval gates. For each practice, raise these questions: does it still help teams make sound technical decisions, coordinate dependencies or prevent costly production failures? Or is it only compensating for implementation that used to be slow and expensive?
Certain engineering practices mainly existed to serve expensive implementation. Estimation, for example, helped teams reason about costly and uncertain implementation steps. Other practices solve problems which are still relevant in an era of cheaper implementation: feature slices reduce coordination risk; architecture helps teams make sound design decisions; documentation preserves reasoning. The delivery lifecycle still matters, but it needs to be redesigned around the constraints that remain.
My recommendation is straightforward: a CTO should start with the delivery system, not an AI-tool rollout.. The question is how the organisation should turn a customer problem into a reliable product when implementation no longer consumes the significant share of time and effort.
An AI-first engineering operating model consists of three interconnected systems: delivery, context and enablement.
- Product delivery system: how problems become reliable outcomes and production learning feeds the next decision.
- Context system: how product, engineering and operational knowledge remains trustworthy and retrievable.
- Enablement system: how team design, platforms, governance and investment support delivery.
A rollout of AI coding tools changes only one part of the product flow, that is the speed at which a team can write and modify code. Sustained value requires product flow, organisational context and team design to reinforce one another. In particular, the organisation must treat context as a production asset rather than an archive.
While building 'Shruti Shred', an agentic system that composes Hindustani raga and metal music, I had an end-to-end pipeline working within a day, which was the easy part. Later, I noticed certain musical ornaments like meend stayed within the raga and hit the correct notes, yet sounded glaringly out of tune. Another week was needed just to make that ornamentation convincing.
Implementation was no longer the constraint.
The economic factor that shifted the constraint
Engineering practices like requirement gathering and estimation helped teams plan work that was difficult to predict and expensive to change. Code review protected maintainability and system integrity. QA provided independent scrutiny where failures carried business risk. Engineering practices grew around addressing distinct constraints. Before changing any of these practices, leaders need to identify the coordination problems and business risks.
In order to study how constraints shifted because of AI, we measured gain in productivity of two teams. I will call them Team Forge and Team Nova.
Team Forge improved delivery by 1.95x per developer. The gain grew over six months as the team became better at delegating work to AI, reviewing its output and creating reusable workflows. The team's primary focus was platform migration and refactoring. With delivery increasing by 1.95x, although the number of merge requests remained stable, the size of these merge requests nearly doubled. Consequently, the review had become the bottleneck for the team whereas the testing phase had spare capacity.
On the other hand, team Nova improved their delivery by 1.3× per developer. This team was earlier in their adoption journey of AI and was building features for an LLM-based agentic product. Engineers spent more time tuning agent behaviour, designing evaluations and investigating non-deterministic failures. Its constraints were closer to product readiness and evaluation.
The two teams show why AI does not create one universal productivity gain or bottleneck. Adoption maturity, work type and the capacity of the surrounding delivery system determine both the gain and where the next constraint appears. That is the economic shift: implementation is no longer the only constraint on delivery. The organisation captures the gain only when product decisions, technical design, review, testing and operations can absorb broader and more complex work.
Product delivery system: from problem to production
Product teams have traditionally written detailed requirements before handing them to a development team and waiting for an implementation. AI coding tools shorten implementation and enable product discovery, design, review, testing and operations to absorb changes faster. The product delivery system below identifies five places where an AI-first organisation needs to work differently.
explore → decide → delegate → validate → operate and learn
Explore
test assumptions with a disposable prototype
Before AI, requirements became detailed partly to reduce rework ahead of an expensive implementation. A product manager can now create a rough prototype before committing development capacity, when the main uncertainty is the user journey. Such prototypes shorten the decision by making each interpretation of user journey testable, before we commit to one implementation. Indeed, when the uncertainty lies in technical feasibility or system design, an engineer should lead the prototype.
A prototype should remain a prototype. It has not yet gone through checks at different stages of entire software development lifecycle like design, security, data ownership, failure behaviour, performance, scalability, modularity, supportability. AI can design an interface that looks ready for release before those decisions have been made. Leaders must decide explicitly whether to discard the prototype or subject it to the full production engineering lifecycle.
Decide
the shape before implementation gathers momentum
Once the product, feature or story direction is clear, engineering has to decide which service owns the feature, where its data belongs, how failures will behave and which business rules the system must enforce. Earlier, any unanswered questions about design of these considerations used to get exposed while implementation. Now, AI can build a convincing feature before anybody challenges those underlying decisions, causing reversal of these to be expensive. Hence, these design choices need to be carefully crafted before a developer starts working on the feature or story.
Feature-level product and engineering discussion should be explicit. It should be initiated after a prototype has resolved the main product uncertainty and before a team starts implementation. The product manager brings the customer problem and intended outcome. Engineers bring the service boundaries, data constraints, failure cases and technical choices. A principal engineer should join when a decision crosses team boundaries or could make the broader system inconsistent.
Delegate
clear, deployable slices
The importance of user stories still remains because they manage coordination and release risk. Cheaper implementation allows teams to use broader vertical slices. For ordinary product work, prefer slices that can be understood, validated and deployed independently rather than splitting a feature into technical layers. When an engineer can take a coherent slice from design to production, further splitting adds coordination unless the smaller slice substantially lowers release risk.
Before delegating a slice to an AI coding agent, the team should state the customer outcome, agreed design, acceptance criteria, edge cases and assumptions that the agent is likely to misread. Keep the readiness conversation short. If any of those decisions are missing, move the task back for further design. An AI-fluent engineer gives a model the relevant product and technical context, defines its operating limits, recognises when the work is going wrong, and turns repeated tasks into reusable workflows. The person who accepts the result owns the decision to release it.
Validate
in two different ways
Code review has traditionally caught routine mistakes, enforced conventions, identified security and performance problems, checked whether the implementation matched the intended behaviour. When an AI coding agent produces a large change quickly, machine validation and human validation performing distinct jobs becomes imperative.
AI Validation should handle the first pass over repeatable checks: common correctness failures, style, gaps in tests, known security patterns, likely performance issues and deviations from repository conventions. Using the test strategy explicitly defined during the design phase, AI agents should be able to perform the review of functionality as well. The model that produced the implementation should not be the only one assessing it. An adversarial review by a separate agent/model should follow, actively looking for counterexamples, missing business rules, unsafe assumptions and failure modes.
Human Validation: Human reviewers make the product and release decisions. Does the change solve the customer problem? Does it fit the agreed technical design? Which trade-offs are being accepted? Does the test evidence justify the risk of this release?
Testing: QA becomes risk-based rather than automatically attached to every team. Developers can own routine validation where automated tests can exercise the critical behaviour and when failures are recoverable. In financial, banking or other high-risk applications, specialist QA should define critical scenarios early, challenge the test strategy and provide independent scrutiny where a defect could create regulatory exposure, financial loss or difficult-to-reverse data consequences.
Operate
learn and update the context
Production support needs to stay inside product development because an incident may expose a decision made much earlier in the feature development. An AI support agent can assemble the evidence people usually need to discover manually. Evidence assembly is the agent's job; engineers still investigate the cause and incident ownership stays with them. For critical systems, keep AI access scoped and read-only by default. For non critical systems, the agent can decide the next step for issues with documented standard operating procedures.
Closing an incident should include updating the relevant feature context, test scenarios, runbook or design decision. A repeated incident may expose several gaps and provide valuable learnings. When an incident learning stays in a ticket, the next developer and the next AI tool start from the same incomplete picture. Context debt accumulates when the organisation fails to preserve why a decision was made, causing later work to begin with the same uncertainty.
The product flow does not end at release. Prototypes, design decisions and production incidents change what a team knows about the product. When the product knowledge becomes irretrievable, the team begins new work by reconstructing earlier decisions. Feature documentation, architecture decision records (ADRs), test scenarios and runbooks must preserve those decisions and remain current. Together, those records form the context system.
Context system: the organisation's memory
The context system preserves why a feature exists, how the team designed it, how the team tests it and what production has taught the organisation. An experienced engineer carries much of this knowledge in their head. They know which customer problem the feature solves, where the system is fragile, and which earlier decision should not be undone casually. A model cannot read minds.
Treating context as organisational memory does not mean copying every document into one large knowledge base. Context must be captured across product development and maintained in a structured, retrievable form so that AI can distinguish current from obsolete information and reason effectively. Each source of truth should stay close to the product, code, or process it describes, and to the people responsible for keeping it current.
Start capturing context before a product exists
Discovery starts before there is a repository. An organisation-wide business-process audit that captures customer pain points, recurring manual work and operational friction should initiate the discovery. An AI tool can scan the audit for repeated patterns and find themes for new products. Keep early notes in a workspace that product managers and business can use comfortably. Once a team commits to an idea, place the approved problem statement and business case in the feature's engineering home.
Give every committed feature a home
For a software feature, a feature folder in the repository is recommended holding business and engineering decisions together. The folder should contain the customer problem, current process and intended outcome with scenarios, critical rules, design decisions, diagrams, test approach and operational notes. A product manager can write the first version. Developers refine it during design and implementation, with continuous monitoring by the product manager. ADRs remain useful for decisions that cut across features or repositories.
Keep context trustworthy
Documentation is not dependable by default. For AI to acquire trustworthy content to bank its operations on, each feature context needs to be owned and updated by linking it to the code or decisions it describes. Developers update feature context when business rules, design choices, test strategies or operational assumptions change, while product managers confirm that the business intent remains correct. Else, developers and AI tools will be forced to reconstruct decisions from code, tickets and memory, creating context debt and avoidable errors. The enablement system must assign ownership and capacity for keeping this context current and extending these practices across teams to ensure that the context is reliable.
Enablement system: teams, platform and economics
An AI-first organisation should not reduce headcount merely because writing code has become cheaper. Product and engineering decision-makers must remain close to each team, proven AI workflows must be reusable across teams, and leaders must decide where to reinvest the time saved.
Put judgment close to the product
Team shape and product partnership
For a bounded product area with a stable delivery platform and limited cross-team dependencies, I would start with a small, cross-functional team. Typically a product lead and three to five developers. This is a starting point rather than a prescribed team size. The team should expand or draw on specialists according to domain complexity, operational responsibility, dependencies and regulatory risk. The team must combine product thinking, engineering judgment and domain knowledge so that they can avoid building a solution that is technically plausible but unfit for the customer. Developers need enough user-experience (UX) judgment to prototype, while product managers should use prototypes to test ideas before committing engineering capacity. Regulated, safety-critical and specialist products will also need the relevant quality, security, data or domain experts.
Principal engineering and people leadership
One senior engineer should work within or regularly alongside each team. A principal engineer can support two or three teams when they share services, data boundaries or architectural standards. People growth, staffing and conflict still need an owner, whether that is an engineering manager or a principal.
Specialists
QA should be a risk-based role, not a default headcount. Developers and AI can validate product changes when automated tests cover the critical behaviour and failures are recoverable. Specialist QA is essential where failure creates regulatory, financial, safety or irreversible data exposure. Infrastructure, data and design specialists can be shared across product teams rather than embedded in every team.
Use the platform to distribute capability
Individual AI fluency does not scale when every developer has to find tools, configure connections and rebuild the same debugging process. The developer-experience platform should distribute approved connectors, context packages and workflows for building, debugging and testing. Product teams need room to adapt a workflow to their domain, improve it and publish it for other teams. Make each workflow easy to find, install, extend and govern. For critical production systems, default AI access should be scoped and read-only; production changes need a separate approval path. A platform creates organisational value when a second team can adopt a proven workflow safely without rebuilding its tools, access controls and operating knowledge.
The enablement system described above has to be in synergy with product delivery and context system to be successful.
Build capability through delivery
AI fluency cannot be created merely by providing tools or offering one-time prompt-engineering training. Teams need protected capacity to learn through real delivery. Begin with a bounded and valuable piece of work, experiment with one part of the workflow, compare the result with the previous approach and capture what worked. Experienced practitioners, internal communities and platform teams can coach teams, turn successful experiments into reusable workflows and help other teams adapt them to their own domains. Because models and tools change rapidly, these practices must be reviewed continuously. The objective is not to teach people one tool; it is to develop their ability to provide context, delegate work, evaluate evidence, recognise failure and improve the human–AI workflow.
Measure outcomes and reinvest the gain
Tool usage, suggestion-acceptance rates and the percentage of AI-generated code indicate adoption, but they do not demonstrate organisational value. Leaders should measure the complete delivery system: time spent in discovery, design, implementation, review and release; work in progress and batch size; escaped defects and recovery time; customer outcomes; and developer experience. Establish a baseline before changing the workflow, compare similar kinds of work and observe where the constraint moves as implementation becomes faster. The organisation must then decide deliberately how to use the capacity released by AI: whether to improve discovery, strengthen quality, modernise systems, increase product investment or reduce cost. Without that decision, local productivity gains may simply create larger review queues, more unfinished work or software that customers do not need.
start with one bounded value stream: one product, client engagement, service or team
For any organisation that is embarking on the AI transformation journey I would set up the three systems described above for a bounded value stream. Later, this should be scaled to the entire organisation. I will begin with following concrete steps:
- Run one real feature through the new product delivery system. Starting with the product manager prototyping, initiating feature-level product and engineering discussions, engineering teams performing system architecture design and the team delegating implementation to an AI coding agent with clear responsibilities and boundaries. Measure elapsed time at each stage to identify where constraints lie.
- Create one trusted context path for that product. Link the product brief to the feature home, repository documentation, ADRs, test strategy, runbooks and operational history. Each of these documents should have an owner and current status. Test whether another engineer can recover the decision and its constraints without reconstructing them from tickets and code.
- Package one repeated AI workflow on the developer-experience platform. Start with something a team already repeats. Make it discoverable, give it defined access controls, and let a second team use it without rebuilding the setup. If the second team cannot adopt it safely, the organisation has demonstrated individual fluency rather than organisational capability.
These three steps should show where the constraint has moved in the organisation: review capacity, test strategy, product decision-making or operational context. The results should determine the next change in team structure, platform investment, specialist support or capacity allocation.
I believe AI’s biggest advantage isn’t that it lets us build more software; it lets us rethink how we build it. CTOs can use the lower cost of implementation to improve the product decisions, context and workflows that shape every subsequent feature. Each release then leaves behind current context and reusable workflows, reducing the cost and risk of the next change. To me, that is the real compounding advantage of becoming AI-first.
