Software engineering principles are not timeless truths. They are economic optimizations.
For decades, the dominant constraint was the cost of implementing software. Writing, testing, integrating, and maintaining systems required significant time and specialized expertise. Many of the practices we now consider foundational — reuse, abstraction, shared services, centralized architecture, and specialized engineering teams — emerged because they reduced the cost of producing software.
Artificial intelligence changes that equation. Fred Brooks distinguished between accidental complexity — the effort required to implement software — and essential complexity — the inherent complexity of the business problem. AI dramatically reduces accidental complexity while leaving essential complexity largely unchanged.
Kent Beck describes this trend as Programming Deflation: implementation becomes progressively less scarce. Just as we no longer optimize applications around minimizing CPU instructions because hardware became abundant, we will increasingly stop optimizing organizations around minimizing implementation effort.
When implementation is no longer the dominant constraint, software engineering should stop optimizing for implementation efficiency. The new constraint is organizational learning velocity.
If the economics have changed, our engineering heuristics should change with them.
Treat Coordination as a First-Class Engineering Cost
For decades, reuse was considered an engineering virtue because implementation was expensive. Building something once and sharing it across the enterprise was almost always cheaper than building it many times.
AI changes that tradeoff. Generating another implementation is increasingly inexpensive. Coordinating around a shared implementation is not.
Every shared implementation introduces hidden costs: shared ownership, generalized requirements, competing priorities, synchronized releases, architectural compromise, and organizational dependencies. Those costs were justified when implementation dominated the economics. As implementation becomes cheaper, coordination increasingly becomes the larger cost.
A Practical Example
Consider a familiar enterprise scenario: four product teams each need to extract information from different document types. Historically, the obvious answer would have been to build a shared OCR platform because implementing OCR was expensive.
Today, each team may only need a single LLM call with prompts and evaluation criteria tailored to its documents and business rules. Building four independent implementations may require less effort than designing, governing, and evolving a single shared service that satisfies everyone.
The implementation is no longer the expensive part. Coordinating the shared implementation is.
This doesn’t mean reuse disappears. Enterprise capabilities such as identity, networking, security, compliance, and observability still benefit from central ownership because consistency reduces organizational risk. But business capabilities should no longer be centralized simply because they could be reused.
The question is no longer, “Can this be reused?” It is, “Does the value of a shared implementation outweigh the coordination it creates?”
Put Organizational Learning Closest to the Customer
If organizational learning velocity is the new constraint, then the teams closest to customers should own business capabilities.
Many organizations still separate customer understanding from implementation. Experience teams identify opportunities while centralized engineering organizations build reusable services and shared solutions. Every organizational handoff slows the cycle between customer insight, implementation, validation, and the next iteration.
AI removes much of the implementation friction that originally justified those handoffs. Experience teams should increasingly own the complete lifecycle of their capabilities — from understanding the business problem and implementing the solution to validating outcomes and iterating based on customer feedback. The objective is not decentralization for its own sake. It is shortening the organizational learning loop.
When AI Reasoning Belongs in the Domain
Consider a scheduling application. AI can explain why a schedule violates business constraints, recommend alternative schedules, analyze the implementation to identify unnecessary complexity, and propose changes that preserve business intent.
That intelligence is tightly coupled to the business capability and evolves with it. Extracting that reasoning into a centralized AI service introduces another organizational dependency. Every enhancement to the scheduling logic must now be generalized, prioritized, and coordinated across teams. What appears to be AI reuse is often just business logic moved further away from the domain that understands it best.
What appears to be AI reuse is often just business logic moved further away from the domain that understands it best.
Enable AI Adoption — Don’t Create Another Bottleneck
One common response to AI is to create another centralized implementation organization. While this can accelerate early adoption, it often becomes the next organizational bottleneck.
Every major technology shift has produced a new Center of Excellence. Initially these groups accelerate adoption. Eventually they become delivery bottlenecks because every initiative depends on them.
Organizations absolutely need AI expertise. They do not need every AI initiative to require AI specialists.
Ordinary Engineering, Extraordinary Outcomes
There is an important distinction between using AI and advancing AI.
Many business capabilities now require nothing more than integrating an LLM into an application, defining prompts, providing context, and validating results. These are rapidly becoming ordinary software engineering activities. Requiring a specialized AI team to participate in every implementation simply recreates the implementation bottleneck that Programming Deflation is eliminating.
Specialized expertise remains essential where it creates enterprise leverage: model evaluation, governance, security, safety, reusable patterns, cost optimization, and operational excellence. The purpose of AI specialists should be to make every engineering team more effective — not to become a mandatory dependency for every project.
Organizations should also resist rebuilding capabilities they already possess. Cloud engineering, infrastructure, networking, security, platform engineering, and developer experience teams already know how to deploy, secure, operate, integrate, and govern software at scale. AI should extend these capabilities rather than duplicate them in a new AI organization.
The goal of AI expertise should be to eliminate organizational dependencies, not create them — to make AI an ordinary part of software engineering rather than a specialized organizational dependency.
A Different Optimization
These heuristics are not replacements for sound engineering principles. They are guidance for deciding where centralization still creates leverage — and where it primarily creates coordination cost.
The organizations that succeed in the AI era will not necessarily be those that generate software most efficiently. They will be those that learn the fastest — those that reduce the time between an idea, customer validation, and the next iteration.
Before introducing another abstraction, shared service, architecture review, or centralized team, ask:
- Does this reduce the cost of coordination or increase it?
- Does this shorten the organizational learning loop or lengthen it?
- Does this enable teams or create another dependency?
- Does this automate governance or institutionalize waiting?
The answers to those questions will increasingly determine the effectiveness of software engineering in the age of AI.
Tech Canvas 