2026-05-12 · 6 min read
The $6 Problem: Why AI Productivity Tools Are Fighting Over the Wrong Budget
By Dusty Bock
For every dollar an engineering team spends on AI tools, eighteen dollars goes to human cost. Most AI productivity tools compete for the tool dollar - roughly six percent of total engineering spend. The teams that actually change their economics are the ones that redesign their process to redeploy the other 94 percent: shifting engineers from writing code to reviewing what agents produce.
What the $6 actually is
A mid-size engineering team of eight engineers at $180,000 loaded compensation costs $1.44 million per year before a single line of code ships. Their tooling - IDE, CI/CD, AI assistant, version control - runs $50,000 to $100,000. Call it $80,000.
That is an 18:1 ratio. For every dollar in tools, eighteen dollars in human cost.
AI productivity tools are marketed almost universally against the $80,000. Thirty percent faster code generation. Two-times throughput. These numbers are measured against less than six percent of total engineering spend.
| Metric | Value |
|---|---|
| Team size | 8 engineers |
| Loaded compensation | $1.44M / year |
| Tooling spend | ~$80K / year |
| Cost ratio | 18:1 (people to tools) |
| Tool budget as % of total | ~6% |
A 20 percent improvement in speed recovers 20 cents per tool dollar. The other $5.80 in loaded cost goes untouched.
This is not a theoretical gap. This is where most AI-assisted engineering teams are right now: genuinely faster at implementation, with no structural change in how their labor budget is deployed.
The shift that actually moves the number
Here is the claim I will defend: the teams that actually change their engineering economics are not faster. They are structurally different.
Engineers who used to spend 70-80 percent of their time writing code now spend that time reviewing what agents produced. Same headcount. Completely different allocation. That is not a tool change. That is a process change - and the ROI is against the $1.44 million, not the $80,000.
The reason the reallocation is so valuable is that writing and reviewing are not interchangeable activities:
- Writing is execution - converting a known spec into working code, something AI does increasingly well
- Reviewing is judgment - catching what the spec missed, what the design didn't anticipate, what will break in production six months from now
Judgment is the one activity that still requires senior human cognition and cannot be cheaply substituted.
When 30 percent of an engineer's time shifts from writing to reviewing, you have repositioned roughly $430,000 in annual capacity for that 8-person team. That is not a productivity improvement. That is structural redeployment of your most expensive resource toward its highest-value use.
Why this doesn't happen automatically
Give engineers AI tools and they will write code faster. They will not restructure their workflows.
The constraint appears to be execution - it always has - so faster execution feels like the win:
- Requirements stay ambiguous until the PR
- Review happens after code is written, not before it
- Disagreements about scope surface during implementation, not during planning
The bottleneck stays invisible because execution still feels like the constraint.
The teams that actually shift are the ones who make the reallocation structurally inevitable. The mechanism is process design, not tooling.
The process question is specific: at which points does AI execute, and at which points does human judgment gate that execution? Most AI tools do not answer this question. They accelerate whatever process you already have. If your process is write-then-review, they make the writing faster. The $5.80 stays on the table.
What the AIDLC process actually changes
AIDLC - AI-Driven Development Lifecycle - was designed specifically around this reallocation. The pattern is explicit:
- AI proposes - drafts requirements, design, or code
- AI clarifies - elaborates based on context and constraints
- Human approves - judgment call at the gate
- AI executes - generates the artifact
- Human validates - confirms before the next phase begins
That sequence applies at every phase of the lifecycle, not just at code review.
Requirements are drafted by AI and approved by product before design begins. Design is proposed by AI and approved by engineering before implementation starts. Implementation is generated by AI and reviewed against the approved spec by engineers before it merges. Each phase has an approval gate. Nothing advances without human judgment at the right moment.
The review layer is multi-persona by design:
- Requirements get reviewed by a senior software engineer and a senior product manager simultaneously
- Design adds UX and frontend reviewers when relevant
- Implementation gets reviewed three ways - against requirements, against the design, against the unit spec
Each review persona is looking for a different class of problem.
This is not a faster version of the traditional SDLC. It is a process redesigned from the start so that the bottleneck flips. Engineers stop waiting on requirements to translate into PRs. Product stops waiting on development to catch scope problems. The constraint moves from execution back to product clarity - the one place AI cannot go alone.
That flip is the mechanism. The economics follow from it.
The opinion
Most AI tools are building against the $1. The market is real and the wins are measurable, so that is a rational place to compete.
But competing for the $1 means accepting that 94 percent of engineering cost is not your problem. It means your product improves on margin - and as AI continues to get faster and cheaper, the margin you compete on compresses further.
The teams that will define how engineering works in three years are not optimizing coding speed. They are redesigning their process so that AI owns execution and humans own judgment. Every AI capability improvement compounds on top of that structural advantage. Without it, teams are buying a faster saw in a process where the constraint is never the cutting.
AIDLC is a bet that process infrastructure is the load-bearing investment - and that teams who design their process first will outcompete teams who are still treating AI as a feature of their IDE.
Full framework: simplygoose.com/aidlc - or if your team is already running agents and the economics haven't shifted yet: simplygoose.com/implementation