I Shipped More Last Quarter Than the Whole Year Before It

Table of contents

The thing that made me stop and think

I don’t track metrics on myself. It feels performative. But I was cleaning up old repos recently and the contrast was hard to miss: a year ago, a quarter’s worth of changelog was a handful of meaningful entries — and most of those were the unglamorous “bumped dependencies” kind. The last few months were the opposite. Features. Shipped. In production, with real users.

Same person. Same job. Same 24 hours in a day. So what changed?

Three things. And none of them involved trying harder.

Thing one: I stopped being the bottleneck

My old workflow was: think → type → debug → test → commit → repeat. Every step had my hands on it. If I was tired, progress stopped. If I was stuck on a dumb syntax error for 20 minutes, progress stopped. If I had to context-switch to a meeting, progress stopped.

The new workflow became: think → describe → review → commit. The “type” and “debug” steps moved to Claude. Not eliminated — Claude makes mistakes too — but it makes them faster. And crucially, it makes them when I’m not around. I can describe a task, step away for a meeting, come back to a working implementation that needs review.

The bottleneck used to be my hands. Now the bottleneck is my judgment. And judgment scales better than typing.

The bottleneck used to be my hands on the keyboard. Now it’s my judgment. Judgment scales better than typing.

Thing two: I shrunk the definition of “done”

This one is less about AI and more about hard-earned discipline. “Done” used to mean “all the features I dreamed up.” Every project kept growing teeth. A simple CLI tool needed a web UI. The web UI needed auth. Auth needed a database. Suddenly a weekend project was a six-week project.

Now “done” means “the smallest thing that proves the idea.” If I’m building an internal tool, the first version has exactly one happy path and zero error handling. If it’s useful, error handling comes next week when someone actually hits an error. If it’s not useful, I saved myself a week of polishing something nobody will see.

AI made this discipline easier because the cost of iteration dropped to nearly zero. I can build the ugly first version, test the idea, and either kill it or grow it. No sunk cost guilt because there wasn’t much cost to sink.

Thing three: I started treating my attention like the scarce resource it is

This was the hardest one. I used to be reactive. Slack message? Reply now. Email? Read it. Random idea for a side project? Open a new terminal.

Then I made a rule: the first two hours of my day belong to me. No Slack. No email. No meetings. Those two hours are for the hardest thinking work — the spec writing, the architecture decisions, the review of generated code where I actually need my brain fully online.

Everything else — the administrative noise, the “quick questions,” the status updates — goes into the remaining six hours. And here’s the thing: most “quick questions” answer themselves if you ignore them for two hours. Most status updates don’t need a real-time response.

What actually changed in the week

I’m not sharing this to brag. I’m sharing it because I wish someone had told me this years ago. The number of hours in my week didn’t change. What changed was where they went.

The old week was dominated by typing — writing the implementation, then debugging it, then writing the tests for it. Reviewing and specifying were the thin slivers squeezed in around that. The new week inverted it. Now the bulk of the hours go to specifying and reviewing, and the typing is the sliver. Meetings stayed about the same; they always do.

Same total hours, opposite composition. I traded typing hours for thinking hours — and thinking hours produce more output per hour, because they’re multiplied by a tool that types faster than I ever will. The one number I’ll stand behind: the weekends came back.

The part nobody talks about

Here’s the weird part: I feel less busy but I’m shipping more. That used to confuse me. Shouldn’t more output feel like more work?

Turns out the feeling of “busy” is mostly the friction of doing things yourself. When you’re the one typing every line, debugging every error, writing every test, you feel the weight of every single unit of work. When you’re orchestrating — describing, reviewing, deciding — the work feels lighter because the machine absorbs the friction.

This is the real productivity unlock. Not “do more things.” Do the right things, let tools handle the friction, and protect the hours where you actually think.

So what changed, really?

If I had to compress it: I stopped treating myself as a code production unit and started treating myself as a decision-making unit. The code is the output of decisions, not the input to them.

I used to start a feature by opening my editor. Now I start by opening a blank note and writing: “What problem does this solve? What does done look like? What are the three ways this could go wrong?” Only after I have answers does any code appear — and when it does, it’s almost always the right code on the first or second try.

The funny thing is, this was always good advice. “Think before you code.” “Plan your work.” We’ve been saying it for decades. The difference is, we now have tools that make the unthinking part so fast that you can’t afford to skip the thinking part. If you do, you just generate garbage at maximum speed.

That’s not a tool problem. That’s a process problem. And it’s the easiest thing to fix — which is the whole AI Engineering bet: stop being a code production unit, start being a decision-making one, and let the context you’ve built do the rest.