Introduction
Most discussions about AI in software engineering focus on productivity.
People ask:
- Are developers faster?
- Are pull requests larger?
- Are tickets closed quicker?
- Are teams shipping more?
I think this framing misses the most interesting question.
The real question is:
What is the company actually buying?
Historically, engineering salaries purchased engineering capital.
A company paid engineers to leave behind assets:
- Better architecture
- Better reliability
- Better performance
- Better scalability
- Better operational knowledge
Even after the engineer left, the organization continued benefiting from the work.
The value remained.
Today, something different is emerging.
AI did not create engineering theater.
Engineering theater existed long before AI.
Politics existed.
Buzzwords existed.
Status games existed.
Worklog inflation existed.
What AI changed was the economics.
The cost of generating engineering-looking output collapsed.
The cost of generating code collapsed.
The cost of generating explanations collapsed.
The cost of generating technical narratives collapsed.
And for the first time, organizations can spend substantial amounts of money producing engineering activity while simultaneously reducing engineering capital.
That is a much more dangerous phenomenon than engineering theater.
Because the company is not merely paying for nothing.
The company is paying to make the system worse.
Stage 1 — Engineering Used To Be Expensive
Before AI, engineering theater still existed.
People still wrote:
- Inflated status reports
- Architecture documents
- Strategy presentations
- Technology roadmaps
However, there was friction.
To produce convincing technical material, a person usually needed enough experience to imitate competence.
To generate large amounts of code, somebody still had to write the code.
To create complexity, somebody still had to spend time creating it.
Bad engineering existed.
But it was relatively expensive.
The organization’s ability to generate engineering debt was naturally rate-limited by human effort.
AI changes this equation.
Now the generation of:
- Code
- Documentation
- Reviews
- RFCs
- Migration plans
- Architectural discussions
can occur almost instantly.
The cost of activity collapsed.
The cost of complexity generation collapsed.
The cost of appearing productive collapsed.
Stage 2 — The Wrong Measurement
Most organizations do not directly measure engineering capital.
They measure activity.
Examples include:
- Pull requests
- Commits
- Tickets closed
- Review comments
- Sprint velocity
- Status updates
- Documentation output
These metrics were always imperfect.
But historically they were loosely correlated with engineering effort.
Now that correlation is weakening.
AI can generate enormous quantities of engineering activity.
Yet activity and value are not the same thing.
A company can observe:
- More pull requests
- More commits
- More reviews
- More documents
- More technical discussions
and conclude that engineering productivity increased.
The problem is that none of these metrics answer the most important question:
What improved?
Did reliability improve?
Did latency improve?
Did operational burden decrease?
Did costs decrease?
Did scalability improve?
Did maintainability improve?
Did the business gain a new capability?
Without those answers, activity becomes a poor proxy for value.
Stage 3 — The Local Optimization Machine
This is where modern coding agents become interesting.
Most coding agents are remarkably effective at local reasoning.
They can understand:
- A file
- A function
- A pull request
- A ticket
- A code snippet
They can generate solutions that appear reasonable within that local context.
The problem is that production systems are not local.
A production system is a living accumulation of:
- Historical decisions
- Operational incidents
- Scaling constraints
- Business requirements
- Technical debt
- Organizational tradeoffs
Most of this context does not exist inside the repository.
As a result, AI agents naturally optimize for what they can see.
The ticket gets solved.
The file changes.
The tests pass.
The pull request looks reasonable.
The worklog sounds impressive.
Everything appears successful.
Yet the system itself may not meaningfully improve.
This is the critical distinction.
The repository accumulates change.
The business does not necessarily accumulate capability.
That is a completely different failure mode from traditional bad engineering.
Traditional bad engineering often produced little output.
AI-assisted bad engineering can produce enormous amounts of output.
The output is the problem.
AI Did Not Create Engineering Theater — It Industrialized Negative Engineering (Part 2)
Stage 4 — Negative Engineering Capital
Historically, engineering outcomes generally fell into two categories.
Positive Engineering
The engineer costs the company money.
In return, the company receives assets.
Examples:
- Better architecture
- Faster systems
- Lower cloud costs
- Higher reliability
- Better deployment pipelines
- Stronger operational tooling
The engineer leaves.
The value remains.
The organization continues collecting returns from the investment.
This is engineering capital formation.
Neutral Engineering
The engineer costs the company money.
The engineer produces activity.
Little lasting value is created.
The organization breaks even or loses a small amount.
This has always existed.
Not every engineer creates major leverage.
Not every project succeeds.
Negative Engineering
This is where things become interesting.
The engineer costs the company money.
The engineer produces:
- Commits
- Pull requests
- Documentation
- Reviews
- Status reports
- Architectural discussions
Yet the resulting system becomes:
- More complicated
- More coupled
- More fragile
- More difficult to maintain
- More difficult to understand
The company is not purchasing assets.
The company is purchasing liabilities.
The organization spends money.
The repository grows.
The maintenance burden grows.
Future engineering costs grow.
The business capability remains unchanged.
This is not low productivity.
This is negative capital formation.
The company is paying to make its future engineering harder.
Stage 5 — The Repository Changes, The Business Doesn’t
This is the part many productivity discussions miss.
A codebase can experience enormous amounts of change while the business experiences almost no improvement.
The AI era is full of examples such as:
- New wrappers
- New interfaces
- New adapters
- New abstractions
- New helper layers
- New service boundaries
- New event buses
- New dependency injections
Each individual change appears logical.
Each change can be justified.
Each change can be reviewed.
Each change can be documented.
Each change can become a pull request.
Yet many of these changes do not fundamentally alter what the business can do.
The company still cannot:
- Serve more users
- Reduce costs
- Recover faster from failures
- Scale more efficiently
- Deliver features significantly faster
The repository changes.
The dependency graph changes.
The business capability does not.
This is why commit counts and pull request counts are becoming increasingly misleading.
The organization sees movement.
The organization mistakes movement for progress.
Stage 6 — Why Seniors Are Not Immune
Many discussions frame this as a junior engineer problem.
I think that misses the point entirely.
The dangerous cases are often not juniors.
The dangerous cases are experienced engineers operating within the wrong incentive system.
A junior engineer usually lacks authority.
A senior engineer has influence.
A senior engineer understands:
- Promotion systems
- Performance reviews
- Stakeholder communication
- Technical narratives
- Organizational language
Before AI, producing these narratives required effort.
Now the narratives can be generated almost instantly.
The result is that experienced engineers can become extremely efficient at manufacturing evidence of productivity.
Not because they are incompetent.
Because the incentive structure rewards it.
The organization asks:
“What did you accomplish this quarter?”
AI makes it trivial to generate a compelling answer.
The harder question remains:
“What actually improved?”
Those are not the same question.
Stage 7 — The Diff-to-Narrative Loop
One workflow increasingly appears in many organizations.
Not only among juniors.
Among experienced engineers as well.
Step 1:
Generate code with Claude Code, Codex, Cursor, Copilot, or another coding agent.
Step 2:
Review the diff.
Step 3:
Ask another AI system to explain:
- Tradeoffs
- Architectural impact
- Technical rationale
- Discussion points
- Risks
- Review responses
Step 4:
Use those explanations in:
- Standups
- Design reviews
- Performance reviews
- Stakeholder discussions
The result is a subtle inversion.
Historically:
Understanding → Decision → Code → Explanation
Increasingly:
Code → Diff → Explanation → Discussion
The engineer is no longer necessarily explaining their reasoning.
They are explaining the reasoning generated around the artifact.
The organization may not notice the difference.
The pull request looks reasonable.
The discussion sounds intelligent.
The documentation appears complete.
The explanation is coherent.
Yet the actual understanding behind the system may be decreasing.
Stage 8 — The Audit Problem
This becomes particularly problematic for organizations that depend heavily on process verification.
Examples include:
- Compliance audits
- Quality management systems
- Security reviews
- ISO certifications
- Internal governance reviews
Historically, documentation had a production cost.
Generating convincing evidence required substantial effort.
As a result, evidence and reality tended to remain somewhat correlated.
AI weakens this relationship.
Organizations can now generate:
- Process descriptions
- Technical explanations
- Architectural justifications
- Risk analyses
- Operational narratives
at almost zero cost.
The organization becomes rich in evidence.
The relationship between the evidence and reality weakens.
This creates a difficult environment for auditors and verifiers.
The documentation looks excellent.
The engineering may not be.
The organization appears mature.
The underlying system may still be deteriorating.
Stage 9 — Why Infrastructure Teams Often Resist This Better
Not because infrastructure engineers are smarter.
Because reality is harder to negotiate with.
Infrastructure teams are constantly confronted by measurable outcomes:
- Latency
- Throughput
- Reliability
- Cost
- GPU utilization
- Query performance
- Network efficiency
The benchmark becomes the final authority.
Nobody cares how elegant the worklog sounds if:
- Latency doubled
- Costs increased
- Throughput decreased
- Reliability collapsed
Reality continuously audits the engineering.
This is one reason infrastructure-heavy environments often appear less tolerant of engineering theater.
The constraints are more visible.
The consequences are more immediate.
The narratives survive only if the numbers survive.
Stage 10 — The Further From Reality, The Easier The Theater
An observation that repeatedly appears across technical organizations is:
The further evaluation moves from reality, the easier it becomes to optimize for appearances.
Reality asks:
- Did it get faster?
- Did it get cheaper?
- Did it get more reliable?
- Did it scale?
Organizations often ask:
- How many tickets closed?
- How many pull requests merged?
- How many initiatives completed?
- How much documentation produced?
The first group measures outcomes.
The second group measures activity.
AI dramatically increases the supply of activity.
It does not automatically increase the supply of outcomes.
That distinction matters.
Stage 11 — AI Is Not The Problem
AI is an amplifier.
It amplifies good engineers.
It amplifies bad engineers.
It amplifies productive organizations.
It amplifies dysfunctional organizations.
The technology itself is not the problem.
The problem emerges when organizations fail to distinguish:
- Activity from value
- Code from capability
- Complexity from progress
- Documentation from understanding
- Output from outcomes
The tools are becoming increasingly powerful.
The measurement systems are not evolving at the same speed.
That mismatch is where the danger lies.
Stage 12 — Final Thought
The popular fear is that AI will replace engineers.
I think a more interesting question is:
What happens when AI makes it possible to generate engineering activity faster than organizations can evaluate engineering value?
At that point, the bottleneck is no longer code generation.
The bottleneck becomes judgment.
The organization must determine:
- Which changes matter
- Which changes improve capability
- Which changes reduce future costs
- Which changes create lasting assets
Without that ability, the company becomes vulnerable to a new phenomenon.
Not engineering theater.
Not low productivity.
Negative engineering.
The organization spends real money.
The engineers appear productive.
The dashboards look healthy.
The documentation looks mature.
The pull requests keep arriving.
The repository keeps growing.
Yet the company’s stock of engineering capital quietly declines.
The repository accumulates change faster than the business accumulates capability.
The organization mistakes motion for progress.
And because AI can now generate both the code and the narrative explaining the code, the illusion can persist far longer than before.
That is what makes this different from traditional engineering theater.
In the past, theater mostly produced words.
Today, theater can modify production systems.
A slide deck disappears after a meeting.
A worklog is forgotten after a quarter.
A dependency added for the wrong reason can survive for years.
The cost of generating engineering theater has collapsed.
The cost of cleaning it up has not.
And the most dangerous part is that the company is paying for it every step of the way.