AI Can Build It. Can Your Team Afford to Own It?

AI coding tools have changed the implementation cost but they have not eliminated the financial realities of software ownership.

Here, "cheap" means cheaper to produce, not free to understand, verify, integrate, secure, operate, maintain, or remove.

An agent can generate a service, integration, abstraction, migration, test suite, or internal tool in hours. Building becomes radically cheaper. The resulting software still has to be understood, reviewed, tested, integrated, secured, deployed, monitored, debugged, modified, upgraded, documented, migrated, and eventually decommissioned.

The goal of AI-assisted engineering should therefore not be to maximize how much software developers can produce. It should be to minimize the total effort required to deliver and sustainably own useful software.

DORA's 2025 State of AI-assisted Software Development research supports this systems view. The study surveyed nearly 5,000 technology professionals globally. Ninety percent reported using AI at work, more than 80 percent believed it increased their productivity, and the median respondent spent about two hours per day working with AI. The corrected 2025 report, v. 2025.2, frames AI primarily as an amplifier of the organization around it: it magnifies strengths in high-performing systems and exposes or intensifies weaknesses in struggling ones.

1. AI Has Made Code Cheap. Software Is Still Expensive.

Code generation is only one stage in software delivery. A production change still travels through requirements, implementation, review, testing, security, integration, deployment, support, and future modification.

DORA's 2026 analysis of AI use in the software development lifecycle makes the same systems point. Faster initial creation can shift saved time into auditing and verification. DORA also reports an association between higher AI adoption and both higher software delivery throughput and higher software delivery instability.

That does not mean AI necessarily causes instability.
It means faster generation, by itself, is not evidence of a healthier delivery system.

AI can reduce the code creation cost much faster than it reduces the cost of owning that same code. This gap creates a new engineering risk: teams now can accumulate software faster than they acquire the knowledge, review capacity, test maturity, platform capability, documentation, and operational experience required to carry it.

The distinction is between code output and engineering throughput. Output is implementation activity. Throughput is useful change that moves safely from idea to production.

A team that generates twice as much code but ships at the same rate has not doubled its engineering capacity. It has increased work in progress.

2. Developer Productivity Is Not Delivery Productivity

AI productivity is often measured locally: coding time, tasks completed, suggestions accepted, pull requests opened, or lines generated. Software delivery, however, is a coupled system.

A feature goes through planning, implementation, review, testing, integration, deployment, production, and support. Improving one stage does not guarantee that the whole system improves.

DORA's current software delivery performance framework uses five metrics. Throughput is represented by lead time change, deployment frequency, and failed deployment recovery time. Instability is represented by change fail rate and deployment rework rate.

DORA also recommends identifying the most significant bottleneck in the delivery process and using local measures, such as code-review duration or test quality, to understand what is driving system-level performance.

This leads to the Test Bottleneck:

Did AI improve the end-to-end engineering system, or did it merely move pressure to later stages?

If AI lets developers create changes twice as fast while review, CI, security, or deployment capacity remains fixed, then the organization does not become twice as fast.

Faster coding can create longer review queues, more work in progress, larger integration batches, additional deployment pressure, and greater reviewer fatigue.

The engineering question is not "How much faster did I finish coding?"

It is:

Did valuable changes reach production faster?

3. The Most Important NFR (Non-Functional Requirement) May Be Maintainability

AI can produce a functionally and statically correct implementation that is cost-wise wrong for the team expected to own it. In AI-heavy development, maintainability deserves to be treated as a first-order non-functional requirement.

The key architectural question is simple:

Who has to understand this implementation six months from now?

Evaluate conceptual complexity, abstractions, technologies introduced, dependencies, architectural consistency, debugging difficulty, testability, observability, documentation, upgrades, and reviewer availability.

Research on developer experience supports an important component of this argument. The DevEx research published in Communications of the ACM examines feedback loops, cognitive load, and flow state as important dimensions of developer experience and their relationship to developer and organizational outcomes.

The result does not establish maintainability as universally "the most important" non-functional requirement. It does support the broader point that excessive cognitive load and poor feedback conditions make effective engineering work harder.

The design principle is:

Generate at the complexity level your team can sustainably own, not at the complexity level the model can produce.

A boring design that several engineers can reason about under incident pressure may be more valuable than an elegant abstraction that only one specialist can safely modify. Bottlenecks are to be removed, not praised.

4. Team Capability Is an Architectural Constraint

Architecture discussions usually begin with workload constraints: scale, latency, reliability, security, availability, consistency, and cost.

AI makes another constraint harder to ignore:

Who has the capacity to support and maintain it?

A four-person product team and a 400-person engineering organization should not automatically make the same architectural decision.

Team knowledge, senior-review availability, bus factor, hiring difficulty, onboarding time, operational experience, and ownership boundaries are architectural inputs.

Consider Kafka, an agent can generate producers, consumers, schemas, retries, manifests, dashboards, and tests, but that does not justify Kafka when the workload does not require it, nobody understands its failure modes deeply, and the organization cannot operate it confidently.

PostgreSQL, an existing queue, or a managed service may solve the problem with less ownership burden.

The same logic applies to microservices. Five generated services can create five deployment units, API contracts, telemetry streams, failure surfaces, and on-call obligations.

This is the Ownership Test:

If the AI assistant disappeared tomorrow, could this team confidently understand, modify, troubleshoot, and operate what it created?

If the answer is no, the implementation may have exceeded the team's sustainable complexity budget.

5. AI Changes the Economics of Overengineering

Historically, unnecessary complexity came with an immediate disincentive: someone had to build it.

An internal framework that required three engineer-weeks naturally triggered discussion. AI weakens that obstacle.

An engineer can now request another abstraction, service, integration, pipeline, wrapper, or internal tool before the economic question has been seriously examined.

This is the AI Overengineering Paradox:

As implementation becomes cheaper, control about what deserves to be implemented becomes more valuable.

The paradox is not an argument against AI. It is a consequence of removing building friction.

That friction previously acted as an imperfect filter on speculative complexity.

Before AI:

"This framework will take three weeks."

The cost exposes the investment.

With AI:

"The agent built it this afternoon."

The implementation cost suddenly looks almost negligible.

But the organization still owns the API, tests, documentation, releases, compatibility requirements, upgrades, and support.

AI can remove creation friction without removing ownership obligation.

6. Measure Total Cost of Ownership, Not Coding Time

A practical way to evaluate an AI-assisted implementation is Engineering TCO:

Implementation
+ Review
+ Testing
+ Integration
+ Documentation
+ Infrastructure
+ Operations
+ Debugging
+ Security
+ Upgrades
+ Onboarding
+ Migration
+ Decommissioning
= Total Engineering Cost

AI can reduce several terms by helping with tests, documentation, migrations, diagnosis, and upgrades.

It can also increase costs by introducing more dependencies, infrastructure, abstractions, technologies, or deployment paths.

The correct economic question is not:

"How many hours did AI save while coding?"

It is:

"What impact did this decision have on the system’s lifetime cost?"

Saving four implementation hours is not automatically a win if the change creates recurring operational work.

A framework that accelerates the first release but adds years of upgrades, onboarding, and debugging may be a negative optimization.

Security belongs in this lifecycle calculation as well. NIST's Secure Software Development Framework 1.1, released as final on February 3, 2022, treats secure development as an integrated lifecycle concern rather than a final-stage check.

As of August 19, 2026, SSDF 1.2 remains an initial public draft, published December 17, 2025. NIST's AI-specific SP 800-218A community profile has been final since July 26, 2024.

Risks and Gotchas: AI makes upfront creation costs unusually visible and ongoing ownership costs unusually easy to ignore. Review decisions against the expected maintenance horizon, not only the speed of the first implementation.

7. AI Should Reduce Complexity Before It Creates More Software

Before asking:

"What can AI build for us?"

ask:

"What existing engineering friction can AI remove?"

High-leverage uses include:

• understanding legacy code;
• improving tests;
• generating and maintaining documentation;
• automating migrations;
• diagnosing failures;
• finding duplication;
• simplifying implementations;
• accelerating dependency upgrades;
• improving internal search;
• reducing operational toil.

The ordering matters.

First improve the organization's carrying capacity: feedback loops, tests, documentation, platform paths, release automation, and operational visibility.

Then spend that capacity on more product features.

DORA's current platform-engineering guidance illustrates the mechanism. Its research reports widespread internal developer platform adoption and dedicated platform teams. More importantly, DORA reports that platform quality influences how effectively organizations can translate AI adoption into organizational performance.

This is not a prescription for every company to build a large platform organization.

It shows why standardized paths for testing, security, deployment, and self-service can convert individual speed into organizational flow.

A strong principle follows:

Use AI first to increase what the engineering organization can own, then use that capacity to build more.

8. Follow the Bottleneck, Not the Hype

Consider a simplified steady-state capacity model:

Planning:    10 changes/week
Coding:      10 changes/week
Review:       8 changes/week
Testing:      8 changes/week
Deployment:   8 changes/week

Now AI raises coding capacity:

Planning:    10 changes/week
Coding:      30 changes/week
Review:       8 changes/week
Testing:      8 changes/week
Deployment:   8 changes/week

In this simplified model, end-to-end throughput remains capped at roughly eight changes per week because review, testing, and deployment are still constrained at eight.

Real delivery systems are obviously more complicated. Variability, rework, parallelism, dependencies, utilization, and batch size affect actual throughput. This is a constraint model, not a general queueing theorem.

Tripling coding capacity does not automatically triple delivery capacity.

It can instead increase review queues, merge conflicts, stale work, context switching, and reviewer fatigue.

DORA's software delivery metrics guidance recommends identifying friction points and focusing improvement efforts on the most significant constraint or bottleneck. Local measures such as code-review time and test quality can then help explain the constraint.

If review is the bottleneck, use AI to improve change summaries, pre-review checks, test coverage, policy enforcement, and reviewer context.

If CI is the bottleneck, focus on test selection, parallelization, flaky-test diagnosis, environment setup, or build performance.

Performance Notes: The best place to apply AI is often not where the model produces the most impressive artifact. It is where removing friction creates the greatest improvement in the entire value stream.

9. More Generated Code Means More Review

AI can increase implementation capacity faster than human can hold their attention.

Reviewers still have finite time, domain knowledge, and cognitive bandwidth.

This makes batch size an important control. DORA's guidance on software delivery emphasizes maintaining changes at a scale humans can effectively understand and validate, and its AI research highlights the pressure that accelerated generation can create in review and verification.

A 4,000-line pull request does not become easy to review because an agent created it quickly.

AI-generated work should still arrive in human-scale units:

• narrow scope;
• incremental commits;
• explicit acceptance criteria;
• generated tests;
• concise architecture notes when required;
• a clear explanation of what changed and why.

Automated checks should run before scarce reviewer attention is consumed.

In AI-heavy workflows, verification bandwidth can become scarcer than code-generation capacity.

That is a conditional engineering observation, not a universal law.

The appropriate response is to keep changes reviewable and automate low-value verification work without pretending that automated checks eliminate the need for human judgment.

10. Don't Outsource Complexity You Will Have to Debug

AI creates a dangerous asymmetry:

A model can generate a complex structure faster than a human can build an accurate mental model of it.

This is especially risky with:

• highly generic frameworks;
• clever metaprogramming;
• custom orchestration engines;
• excessive indirection;
• unnecessary distributed systems;
• premature event-driven architectures;
• deeply nested agent workflows.

Complex requirements can justify complex systems.

The default should be:

Prefer boring, readable, locally understood technology unless additional complexity buys a measurable capability that the system actually needs.

During a production failure, generation speed is irrelevant.

The team needs to localize the fault, understand the state transitions, mitigate the failure, and make a safe change.

AI should make simple architectures easier to implement. It should not make unnecessary sophistication socially acceptable.

11. The Familiar Technology Advantage

AI lowers the cost of experimenting with unfamiliar technology.

That is valuable.

It can explain an API, scaffold a proof of concept, compare architectures, or help a developer learn a new language.

The danger begins when experimentation cost is confused with commitment cost.

A developer can assemble Rust, Kubernetes, Kafka, GraphQL, and multiple agents into a working prototype without deep expertise in any component.

The day-one success does not demonstrate a day-500 ownership.

Before committing a new technology, ask:

1. Does it solve a demonstrated limitation?
2. Does someone on the team understand it deeply enough to review its use?
3. Can the team debug it without depending entirely on AI?
4. Does the delivery pipeline support it?
5. Does observability support it?
6. Can security requirements be evaluated and enforced?
7. Can new engineers learn it in a reasonable period?
8. Is the organization prepared to maintain it for the expected lifetime of the software?

AI lowers experimentation cost.

It does not necessarily lower commitment cost.

Familiar technology has option value. Existing runbooks, deployment paths, controls, monitoring, and debugging habits reduce the assumptions a team must carry.

A new technology should earn its complexity by solving a real limitation.

12. AI Changes "Build vs. Buy vs. Don't Build"

AI makes "we can build it ourselves" newly seductive.

For some capabilities, implementation cost really has fallen. But build-versus-buy was never only about implementation cost.

The decision still includes:

• maintenance;
• support;
• compliance;
• security;
• uptime;
• upgrades;
• documentation;
• integration;
• staffing;
• edge cases;
• opportunity cost.

A more useful framework has four outcomes.

Build

Build when the capability is strategically differentiating and long-term ownership is justified.

Buy

Buy when the capability is commodity infrastructure and transferring operational responsibility has more value than owning the implementation.

Use AI to Build

Use AI to build when implementation effort was the dominant constraint and the team can sustainably review, operate, secure, and evolve the result.

Don't Build

Do not build when the problem does not justify another permanent system.

The final category becomes more important as creation gets cheaper.

An internal dashboard, framework, proxy, integration, or workflow engine may be inexpensive to create and still be unnecessary to own.

The absence of implementation pain is not an evidence of strategic value.

13. A Decision Framework for Responsible AI Leverage

Before allowing AI to materially expand an implementation, run an AI Engineering Decision Test.

1. Value

Does the complexity solve an important problem?

2. Simplicity

Is there a simpler solution?

3. Team Fit

Can the current team understand and maintain it?

4. Review Capacity

Can the generated change be properly reviewed?

5. Pipeline Fit

Can CI, testing, security, and deployment absorb the output?

6. Operational Fit

Can the team monitor, debug, and support it?

7. Lifetime Cost

What recurring maintenance obligation does it introduce?

8. Reversibility

How expensive will changing or removing it be?

9. Dependency Risk

What new vendor, framework, model, or infrastructure dependency does it create?

10. Net System Improvement

Does it improve the engineering system, or only one person's implementation speed?

Functional correctness is necessary, not sufficient.

A locally efficient implementation can still be a globally expensive decision.

If the net system effect is unclear, producing more software may be premature.

Security and governance belong here too. They are not taxes applied after implementation. They are capabilities that determine whether additional engineering output can move safely through the system.

NIST's SSDF provides a lifecycle-oriented framework for incorporating secure software development practices into organizational software processes.

14. Optimize for Flow, Not Lines of Code

DORA's current five-metric model provides a better foundation for evaluating AI-assisted engineering than generation metrics alone.

Measure:

• change lead time;
• deployment frequency;
• failed deployment recovery time;
• change fail rate;
• deployment rework rate.

These measures should be interpreted in the context of the application or service being delivered rather than collapsed into a single universal productivity score.

For AI-assisted development, supplement them with indicators that reveal subsequent pressure:

• PR review time;
• PR size;
• review queue depth;
• CI duration;
• flaky-test rate;
• incidents per deployment;
• rollback frequency;
• escaped defects;
• time spent understanding generated code;
• rework caused by generated code;
• support burden;
• developer cognitive load.

Do not use AI-generated lines of code, number of prompts, percentage of code written by AI, or suggestion acceptance rate as primary measures of engineering success.

Those metrics describe activity more directly than value.

The outcome to optimize is flow:

Useful changes moving safely through the pipeline with fast feedback, manageable work in progress, and low rework.

15. Individual AI Productivity Can Be Misleading

Empirical evidence on developer-level productivity is context-sensitive.

The history of METR's research demonstrates why.

METR's July 2025 randomized controlled trial studied 16 experienced open-source developers completing 246 real tasks in mature repositories they knew well.

With early-2025 AI tools allowed, developers took 19 percent longer on average. Before the study they expected AI to reduce completion time by 24 percent, and afterward they believed it had reduced completion time by 20 percent.

METR explicitly warned that the result should not be generalized to most developers, other software-development contexts, or future tools.

Then the measurement problem became harder.

In its February 2026 developer-productivity update, METR reported follow-up data using later tools and a broader participant pool.

Raw estimates were consistent with some speedup, but METR judged the central estimate unreliable. Recruitment increasingly excluded developers who did not want to work without AI, while 30 percent to 50 percent of surveyed developers reported withholding some tasks because they did not want those tasks assigned to the AI-disallowed condition.

Concurrent agent use and other methodological issues made measurement more difficult as well.

METR's May 2026 survey of technical workers added another useful data point without resolving the question. Participants reported substantial perceived productivity gains from AI, while METR cautioned that there are reasons to be skeptical of the self-reported estimates magnitude.

Taken together, these studies do not reduce AI productivity to one universal number.

Developer experience, task selection, codebase familiarity, tool generation, workflow design, outcome definition, and measurement method all matter.

The mature question is not:

"Does AI make developers faster?"

It is:

For which developers, doing which tasks, in which codebases, under which organizational constraints does AI improve the outcome that actually matters?

16. Design AI Adoption Around the Team You Actually Have

AI strategy should fit the organization.

Small Team

A small team should bias toward:

• simple architecture;
• managed services;
• few languages;
• few deployment models;
• high automation;
• low operational burden.

AI should reduce toil and extend limited attention.

Mid-Sized Product Team

A mid-sized team can invest more in:

• repeatable development environments;
• automated tests;
• predictable CI/CD;
• architecture conventions;
• internal documentation;
• controlled agent workflows.

Large Engineering Organization

A large organization may justify:

• specialist platform teams;
• model gateways;
• AI governance;
• dedicated reliability functions;
• complex distributed infrastructure;
• specialized security and operational capabilities.

DORA's platform-engineering research provides useful context, not a universal prescription. Platform quality affects whether increased development capability translates into organizational performance.

The conclusion is:

AI architecture should fit organizational capacity just as infrastructure architecture must fit workload capacity.

Design for the skills, review capacity, operational maturity, hiring market, and maintenance horizon you actually have.

17. Give Teams a Complexity Budget

Every team has finite capacity to understand:

• languages;
• frameworks;
• services;
• databases;
• message brokers;
• cloud products;
• deployment mechanisms;
• AI models;
• agents;
• integrations.

AI can reduce the cost of understanding each item, but it does not make the total human cognitive budget infinite.

Treat every significant technology choice as spending from a Complexity Budget.

The spend is not only the dependency itself. It includes:

• the mental model;
• failure modes;
• observability;
• upgrade path;
• security implications;
• documentation;
• hiring profile;
• onboarding;
• incident knowledge.

Teams can replenish the budget by removing obsolete services, consolidating frameworks, standardizing platforms, improving documentation, automating recurring operations, and training additional owners.

AI can help with all of these activities.

But AI-generated complexity still counts as complexity.

A useful architecture review question is:

If we add this technology, what will we simplify, standardize, automate, or remove so that the total system remains understandable?

This turns complexity from an abstract complaint into a portfolio-level engineering constraint.

18. The Best AI-Generated Code May Be the Code You Delete

AI's most mature role may be as a complexity-reduction engine.

Instead of asking only what the agent can add, ask:

• Can these two services become one?
• Can this abstraction disappear?
• Is this custom framework still necessary?
• Does a stdlib, native platform, current codebase or installed dependency already solves it?
• Can platform functionality replace this custom implementation?
• Can this dependency be removed?
• Can duplicate implementations be consolidated?
• Can the agent migrate callers and delete an obsolete API?

AI can generate characterization tests, map dependencies, automate migrations, update callers, and remove dead paths.

Those uses convert generation capacity into lower long-term ownership cost.

The immature question is:

How much development can we hand to AI?

The more useful question is:

Where can AI reduce the total burden of delivering and owning software?

The best engineering organizations in the AI era will not necessarily produce the most code.

They will use AI to produce smaller and cleaner changes, faster feedback, simpler systems, better tests, clearer documentation, less toil, fewer bottlenecks, and more sustainable engineering capacity.

Use AI aggressively where it improves the engineering system.

Be conservative where it merely makes new obligations easier to create.

AI should increase what a team can sustainably own, not merely increase what it can generate.