Writing code was never the job

Product Development is the discovery of value. Sadly, most of what we build won’t move the needle on value. What makes up for that is that a small number of things will matter enormously, and we’re pretty bad at telling which is which in advance. (If you’ve read much of what I’ve written about you’ll know I think the distribution of value looks a lot more like a power law than a bell curve.)

So the game isn’t about picking winners. It’s about tilting the playing field in your favour – placing more bets, making each one cheaper, finding out sooner which ones are paying off, and having the discipline to kill the ones that aren’t.

Over the last year or so, the economics of that game have shifted more than at any time I can remember. Code has become cheap. Not free, and not always good, but cheap enough that the cost of trying something has dropped by an order of magnitude. Some organisations have noticed and are reorganising around it. Many more are still treating it as a handy productivity tool – a faster way of doing the same work in the same way.

I think that’s a mistake, and it’s the kind of mistake that is hard to recover from.

A little while ago I argued that AI coding is a Golem, not a “Factory”. The short version: the factory metaphor imports the wrong mental model, one where repeatability is the goal and variance is a defect, when in Product Development variance is the whole point. The better analogy is the golem – powerful, tireless and obedient, but with no judgement of its own. It does exactly what you said, which isn’t always what you meant. That post was mostly about the nature of the tool. This one is about what the tool does to the work, and to the organisation doing it.

What actually changed

Engineers I trust tell me they barely write code by hand anymore and that’s my experience too. We now describe what they want, then steer, review and correct, while the large language models (LLMs) and agents do the typing. Writing code by hand is heading the same way as memorising phone numbers – a skill that mattered a great deal, right up until it didn’t.

For the most part, that’s a good thing. A lot of coding was drudgery: boilerplate, glue code, the tests nobody got around to writing because there was a deadline, and the documentation nobody wrote because there was another deadline. Models will happily do all of that without getting bored. They’re also a surprisingly useful sparring partner on design – frequently wrong, but often wrong in ways that make you think harder about why.

For anyone in the business of discovering value, though, the interesting part isn’t the drudgery that’s gone away. It’s what happens to the cost of a bet. A prototype that used to take a team a sprint can now come together in an afternoon. You can build three versions of something and test all of them, rather than arguing in a meeting about which one to build. You can throw work away without the sunk cost weighing quite so heavily. Cheaper bets means more bets, and more bets means more chances of finding the few that really matter.

That’s the theory, anyway.

So why doesn’t it feel faster?

Most teams I talk to are using these tools every day, and yet very few can show me that they’re learning any faster. Shipping more, perhaps. Learning faster? Rarely.

The question most people ask is “why hasn’t productivity gone up?” – which tells you something about how they’re thinking about it. That’s the factory question. It assumes the goal is throughput, and that if you speed up the machine, more value will come out the other end. But productivity was never the point. What matters is how quickly you can get from an idea to evidence: how long it takes to find out whether something is actually worth doing. That’s a property of the whole system, not of any one step in it.

When you look at the whole system, the answer isn’t hard to find. Writing code was only ever one step in a long chain: design, approvals, review, build, test, certification, release, deployment, and then the (often long) wait to see whether customers actually use the thing. If you dramatically speed up one step without touching the others, the work simply piles up in front of the next constraint. Queues grow, lead times go up, and Little’s Law is entirely indifferent to the fact that the code took four minutes to generate.

Worse, every bet sitting in one of those queues is quietly burning Cost of Delay. If you’ve ever watched a team try to “improve” by starting more work, you’ll know how this ends. AI makes starting work almost free. Unless something changes downstream, all you’ve done is create a bigger pile of half-finished bets, each of them waiting on something or someone.

That isn’t tilting the playing field. It’s the opposite.

The job was always bigger than the code

This is the uncomfortable bit, especially for engineers who are very good at writing code.

The job was never really to write code. It was to solve problems and create value. Code just happened to be the most expensive part of doing that, so it’s where we spent most of our time and, if we’re honest, where a lot of us built our professional identity. Now that the expensive part has become cheap, what’s left is the part that was always hardest: working out what’s worth building, how you’ll know whether it worked, and what it’ll take to make it safe and maintainable.

In golem terms, the job is now writing the shem – the instruction that animates the clay – and staying close enough to notice when the golem has gone past the point you meant. Every engineer now has a few of these working for them, and like any good team lead, the goal isn’t to stand over each of them all day. It’s to get better at telling them what you actually mean, so they can do more without you hovering.

That has a compounding effect if you treat it properly. When an agent gets stuck or drifts, fixing the problem this one time is the easy part. The more valuable question is why it happened, and what you can change so that it doesn’t happen again – not just for you, but for everyone else. Context files in the repository, shared prompts and skills, conventions the agents can read: these are all, in effect, a shared shem. Every improvement to it makes every golem in the organisation a little less likely to flood the house. A repeated failure should be treated as a defect in that shared specification, not as an annoyance to be worked around by whoever happens to hit it.

None of this makes expertise less valuable. If anything, it makes it more so. A golem has no judgement, which means all of the judgement has to come from you – knowing why the system is the way it is, which customers will be upset by a change, and when something is subtly wrong. You’re also accountable in a way that a model never will be. Someone still has to own the outcome, and it isn’t going to be the clay.

Fix the system, not the step

Most of us are still using AI to speed up individual tasks inside workflows that were designed around human limitations. That’s where the easy gains are, and for the most part we’ve already taken them.

Once code is cheap, the constraint moves somewhere else. In the golem post I suggested the real bottleneck is the quality of the specification, and how quickly you notice when the output has drifted from the intent. I still think that’s where it ends up for most teams, but it won’t be the first constraint you hit. It might be the capacity of your continuous integration (CI) pipeline. It might be approvals, or code review. It might be the release train, a shortage of hardware test rigs, or certification. It might simply be how long it takes to get anything in front of a real customer. Whatever it is, you have to find it – and most organisations can’t, because they’ve never instrumented the flow of work well enough to see where it waits. Ask ten people where the bottleneck is and you’ll get ten different answers, all of them opinions.

So measure it. Track cycle time by stage, where work waits and for how long, and then go after the biggest queue. Sometimes that means tuning an existing step. More often than people expect, it means questioning whether the step needs to exist at all. A surprising number of our processes exist only because humans were slow and expensive at certain tasks, and that assumption no longer holds.

The economics of automation have flipped as well. The test harness nobody had time to build, the migration tooling, the instrumentation that would tell you whether anyone actually uses a feature – a lot of things that were never worth the investment now are. Re-run the numbers on those. Many of them are exactly the things that shorten the time it takes to notice drift, which is where a lot of the value is going to be.

Where to go slower, intentionally

Black swans run in both directions. Tilting the playing field isn’t only about increasing your exposure to the upside; it’s also about limiting your exposure to the downside. Most of what’s being written about AI and software development only talks about the first half of that.

In a lot of software, a failed bet is cheap – you roll it back and move on. I work in physical security: access control systems, controllers, readers, the things that decide whether a door opens or not. In the legend, the golem told to fetch water floods the house. In our world the flood is a door that opens for the wrong person, or stays shut when people need to get out. That changes the maths considerably.

You’ll hear people argue that human code review is on its way out. Maybe that’s true for some kinds of software, but it isn’t true for ours – at least not yet. I do think we need to rethink what review is for, though. It was never really about catching typos. It was about shared understanding, accountability and a second set of eyes on the risky bits, and those things matter more, not less, when the author is a golem. Human oversight is structural here, not optional. What should change is where human attention goes. Rather than reading every generated line with the same level of care, spend it on intent, on the threat model, and on what this change allows the system to do that it couldn’t do before. Then let the machines check the rest – and make them check far more of it than any human reviewer ever did.

There are three security issues that I think are under-appreciated:

• Agents are a new kind of insider. There’s a detail in the golem legend that gets less attention than the flood: whoever controls the shem controls the golem. Agents have commit access, they read untrusted input, and they tend to do whatever the text in front of them tells them to do. An issue description, a README in a dependency or a string in a log file can all carry instructions – which is, in effect, someone else writing on your golem’s forehead. Agents should be treated like any other privileged identity: least privilege, separate credentials, every action logged, and no standing access to production systems or signing keys.
• The software supply chain gets stranger. Models will occasionally suggest packages that don’t exist, and attackers have started registering those names. They’ll also reach for whatever library they saw most often in training, whether it’s still maintained or not. Your dependency policy needs teeth, and it needs to apply to agents just as much as it applies to people.
• Cheap tests change the trade-off. The conventional wisdom was to keep end-to-end tests lean, because they were expensive to write and maintain. If tests become cheap, that line should move a long way. Fuzz the protocol parsers, property-test the access decisions, and throw hostile inputs at the controller until it breaks. Good tests are also one of the best ways to write down what you actually meant, in a form the golem can’t misread.

When the downside is that lopsided, a good chunk of the speed dividend should be spent on verification. Limiting the tail is what allows you to keep placing bets.

Caution is not the same as waiting

None of what I’ve said above is an argument for waiting.

Caution and waiting are very different things, and it’s easy to confuse the two – especially in industries like ours, where being careful is a big part of the culture (and rightly so). Waiting has a Cost of Delay too. It’s just quieter than the cost of a mistake, which makes it very easy to ignore.

It’s no longer credible to argue that the nature of the work isn’t changing. It is, and it has to. The organisations that work out how to do this well are already tilting the playing field in their favour – running more experiments, learning faster, and compounding that advantage week after week. In markets with long product lifecycles, that gap doesn’t close by itself. You don’t catch up later by copying what they did, because by then they’ll have learned something else.

Guardrails are what let you go fast without betting the company. Without them, teams tend to end up in one of two places: they either move slowly out of fear, or they move quickly and get hurt. Neither is a good place to be.

This won’t happen bottom-up

An individual engineer can get very good at working with an agent on their own, and plenty already have. What they can’t do on their own is rebuild the CI pipeline, the test infrastructure, the release process or the security controls. That takes investment and organisation, and it comes with real opportunity costs – which is exactly why it rarely happens bottom-up.

That makes it a leadership problem. If you lead a product or engineering organisation, it isn’t enough to tell people to “use more AI” and then wait for the numbers to move. You need to find the constraints, fund the system-level work, and make it someone’s job to spread what works. Goodwill and enthusiasm will get you some early wins, but they won’t scale.

The flip side is that engineers now own more than they used to. Not just getting the work done, but how the work gets done: improving the process, automating what can be automated, sharing what they learn, and raising – loudly – the things they can’t fix on their own.

Get comfortable being uncomfortable

Writing code was never the job. It was just the most expensive part of it, so we mistook it for the job. Now that it’s cheap, we’re left with the parts that always mattered most: judgement about what’s worth building, the discipline to say clearly what we mean, the speed to find out whether we were right, and the care to make sure that what we ship is safe.

Getting there means changing how we work, and some of that change will be uncomfortable. Workflows we’ve relied on for years will need to be questioned. Roles will shift. Some of the things we were proud of being good at will matter less than they used to. The answer to that discomfort isn’t to wait until things settle down, because they won’t. It’s to experiment, learn quickly and adopt what works, with the guardrails in place to do that safely.

Others are already doing this. If you haven’t started yet, start now. The playing field is being tilted, and if you’re standing still, it isn’t being tilted in your favour.