01 · Briefing · what happened

Does AI actually make software teams faster? This week said three different things

Information Technology 2 min 7 sources

GM tripled its code output with AI agents, Amazon blew a coding budget by 860%, and Oracle banned AI code outright. The split reveals what the bottleneck really is.

3x

GM's merged code changes

after redesigning the workflow, not just adding agents

860%

over budget

Amazon's $1.8M menial coding task on Claude

15%

of engineers' time

is actually spent writing code, GM says

$1T+

committed to AI infrastructure

$745bn more expected in 2026 alone

At a glance

GM's self-driving unit tripled its merged code changes using AI agents.
But the gain came only after redesigning the whole workflow, not from adding a coding chatbot.
Amazon accidentally ran a menial coding task 860% over budget - $1.8 million on Claude.
Oracle banned AI-generated code from OpenJDK, citing the flood it creates for human reviewers.
The common thread: coding was only ever 15% of the job; coordination is the real bottleneck.
The $1 trillion AI bet rests on whether agents speed the other 85%.

Forces in play

Faith in agents High

$1T+ committed, GM's 3x result, Meta shipping more apps

Coordination cost Building

review load, integration, the 85% agents don't touch

Institutional caution Building

Oracle bans AI code from OpenJDK over review burden

Cost blowups Building

Amazon's 860% overrun on one task

In play General Motors — tripled output by redesigning its workflow around agents Amazon — blew a menial coding task 860% over budget Oracle / OpenJDK — banned AI-generated code, citing reviewer burden Big tech broadly — spending $1T+ betting agents multiply output

Full briefing

The trillion-dollar bet on AI rests on one question: does it actually make the people who build software faster? This week produced three sharp, contradictory answers.

General Motors’ self-driving division says it now ships roughly three times as many code changes, with faster releases and fewer defects [1]. But the gain came only after GM rebuilt its whole engineering workflow around AI agents - not from bolting a coding assistant onto the old process. A chatbot that writes code, GM’s Rashed Haq said, still leaves “a lot of inefficiency built into that process” [1]. His engineers, it turns out, spend just 15% of their time writing code. The rest goes to triaging, testing, reviewing, and deciding what to build [1].

Amazon shows the other edge. Internal metrics revealed the company accidentally ran up $1.8 million on a single menial coding task using Claude [2]. That was 860% over budget - one internal description called it “catastrophically expensive” [2]. Throwing the agent at the job, without restructuring the job, made it worse.

And Oracle, steward of OpenJDK - the open-source Java that underpins much of the world’s critical software - this week banned AI-generated code from contributions outright [3]. Its reason was not the code’s quality but the burden downstream. “Plausible-looking but incorrect code” floods human reviewers, and reviewing is already the choke point [3].

The pattern beneath all three is old. Writing code was never the slow part. The slow part is everyone agreeing, integrating, and checking each other’s work. A tool that speeds the typing can quietly bury the reviewers. One set of studies found 74% of workers now ask an AI instead of a colleague, changing who talks to whom on a team [4]. Meta, meanwhile, says AI is making it easier to build new apps, and more are coming [5].

That assumption - more code, faster, equals more done - is what the money is riding on. Big tech has now committed more than $1 trillion to AI infrastructure, with another $745 billion expected in 2026 alone [6]. Microsoft’s profit rose 31% even as it poured more into the buildout [7]. Whether any of it pays back turns on the unglamorous 85% - the coordinating, not the coding.

02 · Lesson · why it matters

Why adding more hands can make a project slower

The slow part of building software was never the typing - so speeding up the typing can bury the part that was actually slow.

How it works

A slow software project is short of output
You add hands - more people, or now AI agents
But writing code was never the slow part - it's about 15% of the work
Coordinating, integrating, and reviewing grow faster than the extra hands help
So output rises less than expected - or falls
The fix is redesigning how work is divided, not just adding agents

The twist

The bottleneck was never the typing - so a tool that speeds the typing can pile work onto the real bottleneck, the coordinating.

Where you've seen this

Group projects

adding a fifth member means the other four stop to bring them up to speed

A kitchen at rush

cram in more cooks and they collide - orders come out slower, not faster

Committees

double the people at the table and the decision takes more than twice as long

Disaster response

untrained volunteers can slow a crisis until someone coordinates them

The catch

Adding hands does help early, when work splits cleanly - the trap is only in a project already bound by coordination.

Full lesson

Three answers to one question

This week, three companies answered the same question and disagreed completely. General Motors said AI agents tripled the code its self-driving team ships. Amazon accidentally spent $1.8 million overrunning a small task by 860%. Oracle banned AI-written code from a project the world runs on. Same tool, opposite results. The disagreement is the interesting part, because underneath it sits a law about work that is more than sixty years old.

Nine women cannot make a baby in one month

In 1975, a software manager named Fred Brooks wrote down what he learned running a giant, late IBM project. When a software project falls behind, the instinct is to add people. Brooks found it usually makes the project later. His reason was arithmetic. Two people have one line of communication between them. Five people have ten. Ten people have forty-five. The links needed to keep everyone in sync grow much faster than the number of people. Past a point, each new hand spends more time being coordinated than it spends producing.

And some work does not divide. You can put nine women on the task, but you still cannot make a baby in one month. A late project is often behind on exactly this kind of work - the part that has to happen in sequence, or in one head.

The typing was never the slow part

Here is the piece everyone forgets. Writing code is a small slice of building software. GM measured it: its engineers spend only about 15% of their time actually writing code. The other 85% is triaging problems, running tests, reviewing each other’s work, integrating the pieces, and deciding what to build at all. A study of nearly six thousand developers years earlier found the same thing - an hour or two of coding on a good day.

So the bottleneck was never the typing. It was the coordinating. And that changes what a faster typist can do for you.

A faster typist floods the reviewer

An AI agent is, roughly, an extremely fast typist. Point it at the 15% and it does that part in seconds. But the 85% doesn’t shrink - it swells. Every block of generated code still has to be read, checked, and merged by a human who understands the whole. Oracle said this plainly when it banned AI code from OpenJDK: the problem wasn’t bad code, it was “plausible-looking but incorrect code” flooding the reviewers. Amazon’s blowup is the same shape - an agent turned loose on a job nobody had restructured, burning money on work that produced more than it resolved. You sped up the one part that was already fast, and dumped the output onto the part that was already the choke point.

What GM actually did

GM’s result looks like the exception, but read what its executive said. The tripling came not from handing engineers a coding chatbot. “If you give somebody just a chatbot which can do coding, there’s still a lot of inefficiency built into that process.” GM rebuilt the workflow around the agents - how work gets split, tested, reviewed, and merged - so the coordination cost stayed low. That is Brooks’s own prescription, unchanged in fifty years. You do not rescue a coordination-bound project by adding hands. You rescue it by restructuring the work so fewer hands need to talk to each other.

The difference between GM and Amazon was not the agent. It was whether anyone redesigned the job first.

Not the same as the shape of the org

This is a cousin of a related idea - that software ends up shaped like the group that built it. But that one is about shape: who talks to whom decides where the seams fall. Brooks’s law is about cost: adding labor to a project already bound by coordination raises the coordination bill faster than it adds output. One tells you why the parts are arranged as they are. This one tells you why throwing bodies at the arrangement rarely speeds it up.

What the whole looks like from one seat

The trap is easy to miss because the thing you can see - the typing, the lines of code, the merged changes - is the thing that’s easy to count. So we count it, and we reward it, and we buy tools to make more of it. The part that actually governs the pace - the agreeing, the integrating, the checking - is diffuse and hard to measure. It is spread across people who each see only their own corner. A trillion dollars is now riding on the guess that faster code means more done. It might. But it depends on the 85% that no dashboard shows. No single seat sees it whole - the quiet work of a lot of people keeping each other in sync. That was the bottleneck before the agents arrived, and it is the bottleneck still.

03 · Lab · your turn

Staff the Late Project

Rehearse Brooks's law by adding engineers to a late project and watching coordination overhead reverse the gains.

04 · Hope · carry this

The one part no tool has taken over is the oldest skill we have: a roomful of people quietly keeping each other in sync. The faster the machines get at the typing, the clearer it becomes that the real work was always ours.