Writing code was never the job

I read a post by an engineer at a big company that went along these lines:

"Everything is made by Claude Code... People are working 12 to 13 hours a day just to press enter. Nobody is reading anything... There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore... It is so soul-sucking."

I'm sure plenty of engineers will recognise themselves in that. Most of us chose this work partly because solving problems by hand felt good, and when that part disappears it doesn't feel like losing a task - it feels like losing the job.

But reading the post closely exposed the fact that there are two complaints in it, not one. The first is that the satisfaction has gone. The second is that nobody is checking what ships, and he says himself he wouldn't mind the AI "if we were at least given the time to check out the code." Those are different problems with different answers, and the rest of this article will keep them apart.

Think of a baker who spends a whole morning on five loaves, shaping each one by hand, and a factory down the road that turns out forty thousand a day. Both make good bread, but they sell different things. The baker sells the craft - her customers pay more because it was slow and hand-made. The factory sells bread - its customers want reliable loaves on the shelf and don't care who kneaded them. Most companies that employ engineers are factories, and AI is their new production line. That's the uncomfortable truth underneath the complaint: work is paid for its result, not for the pleasure of producing it.

What is genuinely lost

What we are losing because of AI is real, and dismissing that would be both unfair and unconvincing. Flow and mastery are among the most reliable sources of satisfaction at work. The baker who shapes five loaves by hand has a better morning than someone watching a production line, and nothing about efficiency will change that. Hand-debugging is also how many engineers built their feel for how systems break, so part of what's being lost is a way of learning, not just a way of enjoying the work.

On one point the post is simply correct: a factory where nobody checks the bread coming off the line isn't focused on outcomes. It's just fast. "Nobody is reading anything" is not inherent in the factory model - it's a badly run factory. Requiring time to review what ships is not longing for the craft; it's a necessary part of the factory model that protects the outcome.

What the company is paying for

Clients and employers pay for working software, delivered on time, that solves their problem. The effort behind it is a cost to them, not the product, in the same way the factory's customers pay for the bread, not for the kneading. A team that ships ten times the output at the same quality will beat one that doesn't, so in a business setting, insisting on the slow way isn't neutral - it's a disadvantage the company can't afford. This has happened before: assembly, hand-managed memory and racking your own servers were each a craft people mourned, and each time engineers went on to build bigger things. AI is the next step on that path.

Yes, slow, hands-on coding and debugging is how you build the discernment to judge quality and spot what's wrong. But it isn't the company's job to give up productivity so you can learn it. The job is shifting from producing code to framing problems, checking output and owning what ships, and what's required of engineers is shifting with it. Discernment used to be a by-product of the work we did as we moved through the ranks. Now, it's a requirement to get in the door. If you still need to work slowly to build it, you may not yet have the skills the job now asks for, and building them is your responsibility.

Where the craft still belongs

None of this means the craft has to die. Artisan bakeries still exist because some customers pay specifically for slow, hand-made work, and the same is true of code: consulting for a client who wants something bespoke, open-source projects, personal tools, the weekend build you do because you love it. There's also a practical reason to keep doing it. If discernment is now your responsibility, deliberately coding and debugging by hand, away from the production line, is one of the best ways to keep it sharp.

The frustration in the original post comes from bringing the bakery's slow pace into the factory environment. The solution is not to give up the bakery. It's to know which environment you are operating in: be an artisan where the craft is the product or the practice, and a factory operator where the output is.

The new craft

The factory still needs people. Someone chooses the recipe, sets the quality bar and stops the line when something drifts. AI can produce output quickly, but it can't be held accountable for it, so owning the consequences of what ships becomes the most valuable thing an engineer does. The human role moves from executor to orchestrator: from making each unit to designing, governing and answering for the process that makes them.

That work has its own craft. Framing the problem and defining what "done" means decides whether fast output is useful or just fast. Getting that right takes skill, it has its own mastery and flow, and it's where the satisfaction can move to.

There's a second craft alongside it: designing the factory floor - deciding which steps AI handles, which stay with people, and where quality gets checked. An engineering manager once told me about two of her teams that got the same AI tools on the same day. One let everyone prompt their own way through tickets; output rose, and so did incidents. The other spent two weeks deciding where AI should write, where it should review, and where people should check. A month later it was shipping more, with fewer incidents. Neither team was hand-crafting code; the difference was a new craft altogether.

What this means for you

So where does that leave the engineer from the opening? People who tie their identity to the activity - writing the code, chasing the bug - will feel replaced. People who tie it to the outcome will feel promoted, because what's left of the job is the part that matters most: deciding what to build, defining what good looks like, setting up the workflow (which steps AI handles, which people handle, and where the checks go) and answering for what comes out of it. And if you love the activity for its own sake, choose the bakery deliberately - in your own time, or with clients who pay for it - rather than fighting the factory.

In practice, that means describing your role by the outcomes you own, not the tasks you do. For team leads, it means measuring results rather than visible effort, and protecting the time it takes to check what ships. In the next piece, I'll look at what that new craft actually involves and how to get good at it.

The work was always about the outcome. What's changed is the craft it takes to get there.