AIMay 2026 · 6 min read

I don't really write code anymore

Ten years of writing code, one year as a full-time founder, and the strange part is that the year I went all in on building was the year I stopped typing the code myself.

Darren MorganFull-stack engineer & founder
#01
/dont-write-code-anymore

I ship more code than I ever have, and I barely type any of it.

I've been writing code for about ten years. It was never the job, it was a tool. Internal tooling, the occasional production system, things that supported whatever business I was running at the time. I'm an operator first, an entrepreneur first. Code was always a means to a product I needed, or a product I thought other people might need too. Not a craft I was protecting.

At the end of 2024 I sold the last business and went all in on building. New SaaS, mobile apps, marketing automations, the property site. I expected the year to ship more code than any year before it, and it did. The part I didn't predict is how little of that code would come from my own keyboard.

I do not really write code anymore. I direct it, I review it, I reject the bits that took a clever turn I didn't ask for. I almost never sit down and type a function out from scratch. The strange part, the part I keep meaning to write about, is how completely fine I am with that, and how much more I'm shipping than I ever did when I was the one moving the keys.

This is a personal post, not a how-to. If you want a tutorial on prompting or a stack list, there are better posts. I want to describe what the day-to-day looks like for a founder who never wanted to be a full engineer in the first place.

How the job compressed

The plan was always to orchestrate. I'd spent the previous decade writing enough code to know what good output looks like, and that was the point. Not to become the engineer who types every line. To become the operator who can tell when an agent's diff is right and when it's quietly wrong.

For the first stretch of the year, even with that posture, I was still the bottleneck. The dashboard, the iOS app, the property site, the marketing automations: every codebase was waiting on me to either write the next thing or review it. Not because I wanted to be at the keys, but because I hadn't yet pushed the agents into the engineer role. They were still autocomplete to me.

That changed on a small operational decision. I started treating the agents as engineers, not as autocomplete. Not "Claude, help me write this function," but "Claude, here is the ticket, here is the context, ship it and I'll review the diff." Once that posture clicked, my role compressed into three things: deciding what to build, supplying context, and reviewing what came back.

That's the job now. Three things.

Inside the new job

A typical day looks closer to a CTO's calendar than an engineer's. The work isn't typing. It's directing.

I read incident reports. I argue with agents about architecture trade-offs. I read pull request diffs and reject the ones that took a clever turn I didn't ask for. I write tickets that read more like product briefs than implementation tasks. I check in on cron-driven agents that have been working overnight while I slept and decide what to ship from what they produced.

When I do open an editor, it's usually to clean up a one-line config or to make a precise change the agent kept getting wrong. The Pareto distribution has flipped: 90% of the typing is theirs, 10% is mine. The cognitive load went the other way. I'm doing more of the hard thinking and less of the typing.

What I'm worried about

Two things, honestly.

I'm getting worse at the thing I used to be good at. If I had to sit down today and write a non-trivial system from scratch, no model, no scaffolding, just me and a blank file, I'd be slower than I was three years ago. The muscle is atrophying. I'm not sure if that's a problem yet.

The other worry is about people just starting their engineering career now. The model can produce a working app from a paragraph, but the instincts I'm leaning on came from years of writing code the slow way, even when it wasn't the headline job. Knowing when a diff smells wrong, knowing when an abstraction is hiding the real problem: that knowledge came from doing the slow work badly, many times, until it stopped being slow. If you skip the slow way entirely, what do you lean on?

I don't have a clean answer to either question. I'm noticing them and watching.

What I'd tell a younger version of me

Stop optimising your typing speed. Stop perfecting your IDE shortcuts. Stop reading books about clean code structure as if the structure is the thing.

The leverage is upstream now. It's in deciding what to build. It's in writing the brief well enough that an agent can run with it. It's in reading a diff and seeing what's actually wrong with it instead of being charmed by how much got produced. Those are the muscles to build. The typing is becoming a commodity.

Eighteen months ago I'd have nodded at this. Walking out of the last business, the goal was always breadth across multiple products, not depth at the keyboard. I just didn't yet know how far upstream the leverage would move once the agents started shipping work I'd actually merge.

I'm not telling anyone to give up code. I'm telling you that the job has changed underneath you, and the operator who learned to direct AI ended up with more leverage than the engineer who learned to use it.

So: I do not really write code anymore, and I am shipping more than I ever have. Both of those things are true at once, and I'm still working out what that means for the rest of this chapter.

Keep reading

More on AI.

Newsletter · beehiiv1,240 readers

One essay, every other
Sunday.

Long-form notes on shipping AI products as a solo operator. No roundups, no affiliate links, no growth-hacks. Unsubscribe in one click.

✓ free✓ ~2 / month✓ no spam