I Miss Writing Code

I miss writing code.

I liked taking a vague thought and gradually turning it into something that worked. Finding a small solution, realizing half the infrastructure wasn't needed, seeing the shape of a problem in a way I couldn't when I started.

I know business pays for results, and I've always thought about how to help get them. But people don't choose a profession for its outputs alone. They choose it for what their days are actually made of, for the kind of thinking it asks of them, for the part they'd keep doing if nobody were paying (at least, that's true for me, hopefully it is for you too).

It's being moved out because an agent can write the first version faster than I can. So now writing it myself looks like choosing to be slow, and the normal day becomes handing work over and reviewing what comes back. The part I liked is still allowed, but there's no room left for it in the day.

I'd like to be able to call that loss a loss without immediately sitting an interview on whether I'm adaptable enough.

None of this is entirely new — moving up in the industry has often meant writing less code. As you get promoted, more and more of your week goes to design discussions, reviews, and helping other people get things done. Move into management and coding can disappear almost entirely. For plenty of senior engineers, that shift happened years ago, as part of the role they chose.

What feels different now is who it happens to, how much choice they have, and what they get in return. That trade off would usually have come with a title, a raise, a wider remit, or more say in what gets built. Now, a similar shift can happen to people who never asked to change roles, without any promotion attached. You get the Staff engineer's calendar without the Staff engineer's title.

Some people will enjoy managing several agents, building prototypes quickly, and switching between tasks. I'm convinced that it can be interesting work. DHH is one of them: "Loved it, absolutely loved it, but I love this more" — I believe him.

Others came to this industry because they liked building things, only to discover that their day now consists of coordinating, reviewing, and bullying agents: repeating an instruction for the third time, writing DO NOT in capitals, telling it once more that the bug it says it fixed is still there, and adding another rule to the file after every mistake, knowing the next mistake will need one too.

Moving from IC into management changes what you do every day. Managing agents is different from managing people, of course, but the question of whether you enjoy the new work doesn't disappear just because your job title stayed the same.

When I'm told I can write code for pleasure in the evenings, the way someone else might enjoy knitting or building a shelf, I understand the logic. And yet I'm still sad — part of what made me choose this profession is being moved outside the workday.

Then there's the exhaustion.

When you've launched several agents they're all working in parallel. But, unfortunately, you still aren't. Each will come back with a question, a diff, a conflict, or a confident explanation of something that does not make any sense. All of it competes for the same thing: your attention.

The workday can stay eight hours long while demanding more frequent and difficult judgment calls. Less time simply doing familiar work and more switching between agents attempts at doing it for you.

In an eight-month study of one tech company, Berkeley researchers described people taking on more tasks, filling pauses with work, and running more activities in parallel while using AI. I don't know how widely that generalizes, but the pattern is familiar to me.

In this setup you don't even need a manager demanding more — you see the opportunities yourself. One more prototype. One more experiment. One more idea I could turn into something.

And then that burst of productivity becomes the baseline against which an ordinary day is judged. And people continue doing that because tech is still in a job cutting phase.

I see people leaving jobs without another one lined up. I'm tired too, and I can't honestly tell you AI is why any particular person walked out, because people leave for a dozen reasons and always have. But the shape of the day has changed for all of us, and I think AI is certainly part of it.

We're told humans get to keep the important parts: understanding the problem, exercising judgment, designing the architecture, verifying the result.

Fine.

Where does the person who can do those things come from?

They don't come bundled with the subscription.

Some understanding comes from trying to build something yourself. Not finding the answer immediately but discovering that the abstraction you built and were proud of yesterday gets in your way today. Figuring out why the test is green but the behavior is wrong. Gradually learning to recognize patterns in the problems you run into.

Writing code was a way of thinking. You didn't always sit down with a finished solution that just needed syntax. Sometimes (often for me) the solution emerged while you worked.

Getting a good result and learning to get good results are different achievements.

The habit I'd hate to lose most is the one where you stay with a problem before you have an answer. People who learned a new library with AI help did worse on a knowledge test afterwards, and in a larger randomized study taking the assistance away left them not only performing worse but giving up sooner. Neither of these is equivalent to programming across a career, and the second isn't programming at all. But that last part, the giving up, is the one I keep thinking about.

AI can also help build understanding. You can ask it to walk you through a change, compare alternatives, offer a counterexample, or even ask you questions. You can form your own hypothesis first, then compare it with the model's. An assistant can help you practice and learn when getting a finished result isn't the only goal.

But that's slower, and the hour it costs is an hour the tool is supposed to save.

Aviation already ran into this. When pilots started losing their hand-flying skills to the autopilot, the FAA told airlines to have them switch it off and fly manually by hand on real flights to keep the muscle memory — should we do that too?

Learning didn't only happen in courses or calendar slots labeled "mentoring".

It happened when you asked the person next to you what the hell this thing was doing. When you and three of your teammates ended up at the whiteboard. When an experienced engineer talked through alternatives and you heard, for the first time, how they decided which ones to pursue and which to reject.

That's the part the "ticket → agent → finished PR" route skips. The same experienced engineer still shows up, but only at the end, and only to say no. The beginner gets stuck and never finds out how someone else would have gone about it.

Asking questions in review instead of just correcting is good advice but it doesn't bring back the thinking you used to do together. Sometimes people need to work things out together before they have a finished implementation they're reluctant to throw away.

This applies to experienced engineers in unfamiliar areas too. An agent lets me show up in someone else's system with a huge PR very quickly. Its owner suddenly gets another person who needs a lot of context explained all at once — my shortcut becomes their extra work.

I don't know how the job market for junior engineers will change. I don't want to pass fear off as statistics. But if we automate all the simple work, we'll eventually have to build a deliberate path from beginner to expert. You can't remove learning from the costs and leave expertise in the revenue forecast.

That expertise has to come from somewhere, we can't keep assuming another company will train the juniors.

I'm also so fucking tired of reading.

An odd complaint in a long blog post from an author and code writer, I'm aware.

I'm tired of text that's cheaper to produce than to make sense of. A long answer instead of one verified sentence. An explanation where every claim sounds final until you ask the next question.

In I don't like LLMs, Martin Fowler described a familiar combination: he sees the technology's usefulness, but finds its overconfident fabrications and hollow apologies grating. I know the feeling: many tools can be useful and still be unpleasant to deal with every day.

Sending a message is an ask of work from the receiver, and intentional brevity and clarity is a way for the sender to remove some of that work and make things more efficient. AI has removed that burden from the sender, and made sending long, inefficient messages very, VERY easy.

Even correct writing has to be aimed at someone. What do they need to know? What decision do they need to make? What are we still unsure about that could change that decision? Considering all that information is a human contribution too. The number of characters you managed to get out of the model isn't.

PSA from this section: please read the AI's answer yourself before sending it out!

Keeping your own judgment takes a few concrete things.

Time to understand what you're doing. The right to stop a change or choose another tool. Opportunities to practice. Colleagues to think aloud with. Checks that can show how our beautiful explanation is wrong.

Take all of that away, then write "the engineer is responsible" in a document, and the responsibility doesn't disappear. You've just made it harder for the engineer to live up to it.

I want to understand the work I'm responsible for.

And sometimes I just want to write a little code. Because I fucking enjoy it.