Perspective_
For years, defense organizations optimized around exquisite platforms - high-cost, highly capable systems designed to deliver maximum performance. Then low-cost drones changed the economics of warfare.
Suddenly, operational outcomes that once required years of capability development and significant investment could be accomplished quickly, inexpensively, and at scale. The operating model had to evolve to govern both the exquisite platforms and the volume of lower-cost, rapidly deployable unmanned systems.
Enterprise software is approaching a similar inflection point.
AI coding agents are dramatically lowering the cost and expertise required to build software. Domain experts who once relied entirely on engineering teams can now prototype applications, automate workflows, and solve operational problems themselves. Product teams can move from idea to working capability in days rather than months.
Now, the enterprise operating model needs to evolve to govern both the exquisite software platforms and the volume of lower-cost, rapidly generated software applications.
Without a deliberate approach, AI-enabled development risks accelerating the very problems enterprises have spent decades trying to control: shadow IT, tool sprawl, inconsistent security practices, and fragmented architectures. But organizations that establish the right operating model can unlock a different outcome: faster mission execution, more responsive operations, and the ability to deliver software at the pace of need.
AI-enabled software delivery should be managed through an enterprise operating model built around three principles:
- Centralized governance, federated execution
- Risk-tiered oversight
- A self-service golden path platform
Organizations that establish this model early are better positioned to move faster and safer than those that either try to ban the tools entirely or allow unmanaged adoption across their enterprise.
Centralized Governance, Federated Execution
The enterprise must govern the risk without centralizing the work.
AI-enabled delivery requires centralized governance because the risks are shared across the enterprise: data exposure, software supply chain integrity, model approval, logging, provenance, and security controls. But execution must remain close to the mission.
This requires a different relationship between technology leaders and product teams.
The enterprise establishes the top-down control plane that provides approved tools, security controls, governance guardrails, and reusable context assets. Product teams build within these boundaries.
For agentic software development, context engineering is how enterprise standards reach the agent. Architecture guidance, testing requirements, security controls, approved tools, and mission context should be delivered as governed, machine-readable artifacts that both people and agents can consume.
That is the balance the operating model must strike. Centralized governance must not become a centralized bottleneck and federated execution must not become shadow IT. Context engineering helps make that balance practical: the enterprise governs the operating environment, while product teams retain the speed and judgment needed to solve mission-specific problems.
Risk-tiered Oversight
Not all AI-enabled software delivery use cases are the same, and they should not be governed the same way.
For example, a low-risk onboarding app for the HR team, a finance workflow that updates ERP transactions, and a real-time command-and-control application do not carry the same consequences if they fail. They can all benefit from AI-enabled delivery, but they require different levels of oversight, review, and human control. Applying the same oversight model across the board slows innovation without meaningfully improving outcomes.
This creates three broad categories of AI-enabled software delivery.
Tier 1: Low Risk / Attritable
At the low-risk end of the portfolio, organizations should empower teams to move quickly. Teams solving workflow bottlenecks, improving operational visibility, or automating manual processes should not have to wait for every requirement to be prioritized by a dev team or become a formal low-code/no-code procurement.
These are low-threat, high-impact, low-cost capabilities. Together, they represent a new attritable software layer within the enterprise: small tools that solve real problems, operate inside approved boundaries, and can be easily replaced or retired when they no longer provide value.
The analogy to attritable drones is most relevant here. Defense organizations have learned that they do not need an exquisite platform for every mission. Some missions are better served by cheaper, faster, more disposable capabilities operating within a defined envelope. Agentic software development brings that same logic to software.
Attritable does not mean unmanaged. Attritable software should still run through approved repositories, automated testing, security scanning, logging, identity controls, and deployment workflows. But the governance burden should be light enough that teams can actually use the model.
In this tier, agents may generate most of the code. Human review exists, but it is lighter and supported heavily by automated checks. The goal is to safely shrink the long tail of unmet software demand.
Tier 2: Medium Risk / Governed
Some use cases require more control. A finance team building a tool to update ERP transactions, a logistics team managing operational data, or a personnel office handling regulated data is operating in a higher-risk environment.
These applications may still be excellent candidates for agentic development, but the oversight model changes. Data access must be more tightly scoped. Integration patterns need review. Testing requirements should be explicit. Human code review should be required. Promotion from development to production should pass through defined approval gates.
In this tier, agents can still build or accelerate much of the work, but qualified humans must verify that the result meets the enterprise standard before it ships.
The difference from Tier 1 is that the cost of a defect is higher and the governance model should reflect that.
Tier 3: Mission-Critical / Human-Led
At the high-risk end of the portfolio, AI should augment software delivery but not deliver autonomously.
A real-time command-and-control application, weapons system integration, or safety-critical operational system carries consequences the enterprise cannot casually absorb. Failure may create mission impact, safety risk, compromise of sensitive information, regulatory exposure, or loss of confidence in a critical system.
In this tier, skilled engineers remain the primary authors and accountable decision-makers. AI tools can assist with research, bounded code generation, refactoring, test creation, documentation, and review. But the work should remain human-led and AI-enabled, not agent-led with human oversight as an afterthought.
Formal reviews are mandatory. Accreditation-grade evidence applies. Security, reliability, safety, and mission assurance requirements should shape the lifecycle from the beginning. This is where scarce engineering talent should be dedicated.
A Self-Service Golden Path Platform
Governance without a platform is a policy binder that nobody follows.
To ensure adherence to safe AI-enabled delivery, the approved path must also be the easiest path - otherwise, teams will route around the process. They will bring their own tools, connect to data in inconsistent ways, deploy into unapproved environments, and create the risks governance was meant to prevent.
The answer is a self-service golden path: a hardened platform that gives teams approved infrastructure, governed model access, secure development environments, and deployment workflows out of the box.
This platform should also provide approved connectors to authoritative data sources, reusable application templates, reference architectures, software supply chain controls, security scanning, evaluation gates, and provenance tracking. In an accredited environment, the enterprise must be able to answer basic questions: where did the code come from, which model or agent generated it, what data did it touch, how was it tested, who approved it, and where is it running?
The golden path makes those answers available by default.
This matters because every tier of AI-enabled delivery should build from approved enterprise patterns. They may run in segregated environments and face different accreditation requirements, but they should inherit a common enterprise foundation: approved infrastructure patterns, governed model access, deployment workflows, logging, and security controls.
The governance envelope should tighten as risk increases, but the platform baseline should remain constant.
That is how the enterprise avoids the false choice between speed and control.
Moving Forward
The line between tiers will not remain fixed.
AI-enabled software delivery will continue to absorb work that once required traditional development teams. The set of requirements an agent can safely support is larger now than it was a year ago, and it will likely be larger again next year. That means tiering cannot be a one-time policy exercise. It must become a standing governance function.
The practical path is straightforward: centralize the control plane, federate execution to product teams, scale oversight with mission risk, and build the golden path that makes compliant delivery the easiest path.
Organizations that stand up this foundation early will be able to respond to mission needs faster, deliver capability closer to the point of need, and scale AI-enabled delivery without sacrificing control. Those that skip it will likely face one of two outcomes: banning the tools and falling behind, or allowing unmanaged adoption and absorbing risks they have not accounted for.
The winners will not be the organizations that adopt every new tool fastest; they will be the ones that make safe adoption repeatable. That is how organizations turn AI-enabled software delivery into mission advantage.