A few years ago I measured my output in lines of code. Today I measure it in decisions made, problems framed, and shipped product. The reason for that shift is simple: AI tools — Claude Code chief among them — have gotten good enough that typing the code is no longer the bottleneck. Thinking clearly about what to build, in what order, and why is.
This post is about that transition. What it looks like when AI-assisted coding stops being a novelty and becomes muscle memory, and how that frees you up to do the higher-leverage work — planning, architecture, and leading delivery.
Where I am now with AI coding
After hundreds of hours pairing with Claude Code, I’d say I’ve near-mastered the workflow. That’s a strong claim, so let me be specific about what it means:
- I can take a vague feature idea and turn it into a working, tested, reviewed change in a fraction of the time it used to take.
- I rarely fight the tools. I know what to delegate, what to verify, and what to keep in my own head.
- I trust my review process more than my keystrokes — and that has made my output both faster and more accurate.
- I treat AI hallucinations and over-eagerness as known failure modes, not surprises.
The skill isn’t prompting. The skill is framing — giving an AI agent the right scope, the right context, and the right success criteria, then reading the diff like a senior reviewer.
The real shift: from writer to director
Here’s the part that surprised me. As coding got faster, my actual job got less about coding. The bottleneck moved upstream.
These days my time goes into:
- Planning — what should we build next, and what shouldn’t we build at all?
- Architecture — how do the pieces fit together so we can move fast for the next year, not just the next sprint?
- Managing delivery — keeping work scoped, unblocking people, making sure shipped work actually solves the problem it was meant to.
- Mentoring — helping other engineers level up their own AI workflows.
The keystrokes still happen, but they happen faster, and they’re not where the value is. The value is in the decisions that frame the keystrokes.
What “planning-first” looks like in practice
A typical project for me now starts well before any code:
- Frame the problem. Not “build feature X” — but “what user pain are we actually solving, and what does success look like?”
- Sketch the shape. A short architecture doc: data flow, key components, edge cases, what we’re explicitly not doing.
- Slice the work. Break it into changes small enough that each one can be reviewed in one sitting.
- Hand off to AI for the obvious parts. Scaffolding, boilerplate, mechanical refactors — Claude Code can draft these in minutes.
- Spend my attention on the non-obvious parts. Trade-offs, edge cases, integration points, naming.
- Review every diff. Mine, the AI’s, the team’s. The review is the work now.
When you do it this way, AI doesn’t replace engineering judgement — it amplifies it. A team with clear plans and good reviewers gets superpowers. A team without them just produces more questionable code, faster.
What I tell engineers who want to make the same shift
- Don’t compete with the AI on typing speed. You’ll lose. Compete on judgement.
- Get fluent at reading diffs. This is the most underrated skill of the AI era. If you can spot a subtle bug in a 200-line patch, you’re worth ten devs who can churn out 200 lines.
- Invest in planning. A good plan turns AI from a chaos generator into a force multiplier. A bad plan turns it into a faster way to ship the wrong thing.
- Pick problems where AI can’t help much. Architecture choices, product trade-offs, organisational alignment. Those are still entirely human work — and that’s where careers grow.
- Manage scope, not lines. The most valuable thing you can do on most days is decide what not to build.
The tools, briefly
Claude Code is the one I rely on most — it sits in my repo, runs commands, edits files, uses git, and lets me operate at the level of “make this change” instead of “type this code.” Around it I keep:
- ChatGPT / Claude chat for thinking out loud and structuring plans.
- GitHub Copilot for inline completions when I’m in flow.
- A solid notes/planning system (mine is a mix of Linear and plain markdown) — because the AI workflow only works as well as the planning that feeds it.
The toolset matters less than the habits around it. Plan, scope, delegate, review, ship.
The bottom line
AI didn’t make engineers obsolete. It made typing obsolete. What’s left is the part that always mattered most — understanding the problem, designing the solution, leading the people who build it, and taking responsibility for what gets shipped.
That’s the job I want now. AI just got me here faster.