Cheap to send, expensive to receive: what email taught me about AI coding agents

In 1989 I got my first internet email address. It was on UCL's main computing service at the time, a GEC4000 system called Euclid¹ which is also deeply memorable to me for other reasons.

I remember the feeling more clearly than the address itself: I could type a message to someone on the other side of the world, press a key, and it would just arrive. No stamp, no queue at the post office, no waiting three weeks for a reply. The set of people who had email was small enough that having an address at all felt like membership of a club, and most messages that arrived were worth reading, because sending one took enough deliberate effort that nobody did it idly.

It was, and I want to be clear about this before I say anything else, a wonderful feeling.

Then spam happened...

It didn't stay wonderful in quite the same way, and the reason is economic rather than technical. Sending an email costs the sender almost nothing. Reading one costs the recipient attention, which is the one resource nobody has ever worked out how to scale. Once sending at scale became effectively free, anyone with something to sell could send a million messages on the off-chance that a handful of recipients would bite. The cost of the whole exercise landed on the millions of people who had to open, assess, and delete the other 999,990 copies of the message.

Nobody designed that outcome. It fell directly out of the economics: when producing is cheap and consuming is expensive, the channel fills until the consumer's capacity is the limit. The bottleneck doesn't disappear; it moves to whatever is still expensive and, in this example, stops being the sender's problem and becomes someone else's.

Of course, this has nothing to do with email specifically, and nothing to do with bad intentions either, which is the part I've been chewing on lately.

The same economics, without the bad actors

I write code several times faster with AI coding agents than I did without them.

My colleagues can absorb the changes in their applications at the same speed they always did.

You can see where this is going, because it's the email story with the labels changed. And it isn't just code. A prototype, a proposal, a rewritten process, a whole website: anything I can now produce in a weekend that would once have taken a month has got cheaper on only one side of the exchange. Producing the thing is much faster and easier. Understanding it, fitting it into the overall picture, and working out what it means for their own plans still costs everyone else what it always did, and there is suddenly much more of it to go around. My cost collapsed; theirs didn't. The channel between us has exactly the shape email had in 1995. I recently looked at my own usage data, and the asymmetry is embarrassingly literal. The median time the machine spends waiting for me to reply is under ninety seconds, and I am often operating multiple sessions at once. Nothing on the production side is the bottleneck. Attention has always been the bottleneck.

The example I keep coming back to, lightly disguised to protect the guilty (me): a website was annoying me, so I spent a weekend rebuilding it from scratch on a different stack. It was faster, cleaner, easier to change, and I was pleased with it. And then it sat there. The people it landed on didn't have a spare week to go through it, satisfy themselves it was right, and confirm that the things that they cared about had survived the move. The building was cheap. The believing-in-it was expensive, and there was no way to automate that part with more agents.

The cost of exploring alternatives has collapsed too, and this one cuts both ways. A recent disagreement about approach on my team produced not two options on a whiteboard but two complete, working implementations. As exploration, this was genuinely valuable: the decision got settled by evidence rather than eloquence, and the losing option taught us things a sketch never could. Conversely, if team members are reviewing multiple versions of the same thing, that probably isn't a good use of their attention. It helps if your colleagues are clear about when you're building to explore, and when you're building to ship.

One distinction matters enormously, though, and I want to make it explicitly because the comparison is unfair without it. Spam came from bad actors exploiting an asymmetry for profit. AI exuberance comes from good actors, people genuinely trying to help, whose cost of production has suddenly collapsed underneath them. I wasn't trying to bury anyone when I got over-enthusiastic with the agents. I was being productive². That's what makes this failure mode so sneaky: every individual contribution is well-intentioned, most of them are individually fine, and the damage only shows up in the aggregate, as a queue.

What breaks

None of what follows is about quality, by the way. Keep every engineering discipline you have; I do: tests, strict linting and type checking, small steps, and careful attention to what ships. The uncomfortable part is that the queue forms anyway, because even good work has to be understood by someone, and fitted into their work and life. Discipline makes the work safe to absorb. It doesn't make it free to absorb.

The obvious casualty is scrutiny. When finished work arrives faster than the people around you can absorb it, they have two options: hold the line and become the bottleneck everyone resents, or start waving things through. Most humans, being humans, drift towards waving through, and the value of a second pair of eyes quietly evaporates while the ritual of it continues.

The subtler casualties took me longer to spot:

Shared understanding. A team's sense of its own systems is built by moving through them slowly. When change arrives faster than anyone can genuinely absorb it, the systems stop fitting in anyone's head, including, eventually, mine.
The people still learning. The traditional path to mastery is to learn by doing the medium-hard work with feedback. If the medium-hard work is now done by an agent before they get near it, and the experienced people are underwater checking agent output, where exactly does the next generation of experienced people come from?
Morale. Watching a colleague ship five times your output feels bad even when you know the machine did the typing. People who feel they can't keep pace stop feeling like contributors, whatever their actual contribution.
Architectural drift. Each individual change is locally reasonable. Nobody has time to notice that the last forty locally reasonable changes point in six different directions.

None of these appear on a dashboard. Throughput, which does appear on dashboards, goes up. That's the trap.

What helps

I don't have a complete answer. I have some things I'm doing, and some I'm trying.

Pace to the team, not to yourself. The useful measure of my output isn't what I can produce; it's what the team can absorb. Some days that means deliberately not opening the next piece of work, which is genuinely uncomfortable when the marginal cost of starting it has fallen to nearly nothing.

Hand over smaller pieces, with more of my own words attached. If my production cost has collapsed, I can afford to spend some of the saving on the receiver's behalf: tighter scope, a proper explanation of what this is and why, a note on what I'm unsure about. Cheap for me, and it moves cost back to my side of the channel, which is exactly where the asymmetry suggests it should go.

Talk before building, not after. The worst version of this dynamic is the fully-formed surprise. Agreeing the direction in a conversation first means that what eventually arrives is expected, and shaped by the people who'll have to live with it, and conversations are still reassuringly human-paced. I've gone as far as wiring this into the workflow itself: the agent isn't allowed to build anything until it has interrogated a human about the plan and heard a yes.

Keep some work AI-free on purpose. Some classes of problem are where the team's shared understanding actually gets built. Doing those together, slowly, is not inefficiency. It's maintenance of the thing that makes the fast work safe.

Use AI on the receiving side too. Agents are decent reviewers, and getting better. But this has its own social dynamics: nobody wants their carefully-considered work waved through by a machine while their colleagues are too busy to look, and a channel where machines write the code and machines review it while the humans stand back and watch is a different kind of failure, even when the code is good.

That said, we do use it, and it earns its keep. Every change is reviewed by a machine reviewer before a person looks at it. But we hold one rule on purpose: the machine never gets the last word. A person closes the work, or it isn't closed. And the best outcome has surprisingly been on the other side of the channel entirely: colleagues using agents not to produce more, but to understand faster. It's the same saving, but spent on absorption instead of additional output.

Still wonderful

Email is still wonderful, for what it's worth. I've sent several this week, each one delivered across the world for nothing, and the spam folder caught the noise without my ever seeing it. We didn't fix the asymmetry; we learned to manage it, with filters and cultural norms and a certain hard-won scepticism about unsolicited bulk anything.

AI coding agents are wonderful too, and I intend to keep being unreasonably productive with them. The challenge was never the tool. It's the asymmetry: any channel where producing is cheap and consuming is expensive will fill until the consumer is the bottleneck, whether the producers are hustlers with a mailing list or a well-meaning colleague with an agent and a full head of steam.

It's also where the email analogy finally breaks down. Spam is noise: it has no value to almost everyone who receives it, and the ideal outcome is that you never see it at all. That's why filters could win. This queue is signal. It's work the team actually wants, even when it's more than they can absorb, and you can't filter your way out of understanding something. That part stays human, which is why most of what helps looks like norms rather than filters.

Anyone who remembers 1989 can tell you what to watch for. This time we can see it coming.

I've noticed that UCL often call things Euclid, presumably because as well as being the father of geometry, he literally has "UCL" inside his name. ↩
Productive, not careless. The work was tested, reviewed by me, and shipped in good order. That's rather the point: engineering discipline travels with the work, but the cost of receiving it doesn't go away just because the work is sound. ↩