On fences and farms

At more and more companies, AI is writing a growing share of the code. Across top tech, the figure is roughly 25–30%.¹ The leading companies are higher — Google around 75%, Anthropic close to 90%.² A year ago those numbers were a fraction of what they are now.

Until recently, writing code was most of your day. That part is getting eaten.

So what’s the work becoming?

Building fences, not barns. That’s been my shorthand. But the fence turns out to be doing more than the word suggests, and the farm is half the story I didn’t get to last time.

A fence isn’t a guardrail

From a distance, it can look like one — CI/CD pipelines, automated test suites, branch protection, the obvious stuff a competent team had by the late 2010s. That’s the decoy. That’s the part that was already cheap. A real fence is the judgment that used to live inside an engineer’s head — managing the complexity of building software — now externalized into the environment.

The kind of judgment that knows to ask whether the ingredient field in your recipe app handles “half a cup” and “1/3 cup” and “a bunch of cilantro” and the other twenty edge cases users will cheerfully break the feature with. The kind that holds a payments change until someone has thought about what happens when the card declines on retry. The kind that catches a 2 a.m. failure before it cascades through the rest of the system.

Almost none of what makes software work is code. The code is the visible part; the rest is everything the person writing the code decided not to do. Until recently, that judgment lived in exactly one place: in someone’s head, at the moment of writing. If the person wasn’t there, the judgment wasn’t there. Which was a fine arrangement when the person was always there.

They’re not always there anymore.

What a team looks like now

Teams that have figured this out work differently.

Pair programming, the way it used to work, has mostly vanished. Not because people stopped caring about each other’s code, but because there’s nobody at the keyboard to pair with. The old choreography of two chairs and one keyboard is gone.

There’s a title I keep hearing: context engineer. Half joke, half business card. The job is to take everything that used to be transmitted in all-hands, one-on-ones, and 15-minute hallway conversations — architecture decisions, coding standards, the unspoken rules about what “good” means here — and put it into Markdown files.

The tribal and organizational knowledge that used to live in rooms and minds now has to live somewhere an AI can read — which means it has to live somewhere, be kept current, and be findable. If this sounds suspiciously like the docs you always meant to write, it is. The difference is that the audience is no longer human.

The best engineers on these teams aren’t writing most of the features. They’re writing the rules. The checks. The systems that read a proposed change before it reaches a user and say: this will break here, this won’t, this isn’t finished. The edge was never the code — it was our judgment. The valuable engineer isn’t the one with the most of it. It’s the one who can externalize that judgment to scale past their own attention.

What the fence makes possible

You can watch the shift happening in real time in how leaders are deciding who builds the product.

Until recently, the answer was: engineers, full stop. There were two good reasons:

1. A non-engineer in a production codebase didn’t know the context — what code was already there, why it was that way, what was about to change.
2. Letting them in gave them a misleading impression of how easy shipping actually is. That bred frustration with engineering when the thing they built didn’t work the way they’d imagined, and loaded review onto the people who could least afford the interruption.

The arguments against were genuinely good. Nobody was being precious. They were protecting the team — and the resources.

The math has changed, though, if you spend time building the fence around your farm. The fence holds the context, so newcomers don’t arrive empty-handed. It catches the unfinished work, so review doesn’t fall on the people who can least afford the interruption. Both objections weaken at once.

What you get on the other side is a farm that grows faster than anyone expected. More people planting, more rows, more variety. More of it edible.

In the old world, engineers were the farm. Everything that grew, grew through them. Every row, every seedling, every decision about what to plant where. Their attention was the soil, and it was the governor of the business.

In the new world, engineers are the farmers. The craft has moved one level up, from execution to building the environment that enables others to build. The years of learning where software breaks, the distillation of your experience and judgment, now live in the fence, and the fence is what protects the farm.