How I Became a 5x Engineer with Claude Code

Claude Code has radically changed what it means for me to be a programmer. It’s made me much more productive. I’m able to get work done in hours that would have previously taken me days. On the surface it probably looks like I’m only about 1.5x more productive in terms of time to deliver results, but when you factor in that the quality of the code I can write in the same amount of time is now much higher because coding agents make it cheaper to put in the effort to write high quality code, it’s easily a 3x-5x increase in total productivity, assuming you agree with me that quality code is valuable.

The natural questions to ask are “how do I do it?” and “can you do it, too?”

Let’s tackle these questions in order.

The Mechanics of 5x Engineering

Arguably, the way I achieve 5x productivity at programming is pretty simple: I use Claude Code to do almost everything!

But the reality is more nuanced, because lots of people are also using Claude Code to do almost everything and aren’t seeing similar productivity gains. I’ve learned a lot about how to work effectively with Claude in the 6+ months since its release. Here’s how I do it:

• At a high level, I think of myself as pair programming with Claude. I’m the navigator and Claude is the driver, though occasionally I ask Claude to help me navigate, as during planning, and I sometimes do a little driving in the form of jumping in to change small things in code.

  • I find this model superior to other ways of trying to use coding agents. In particular, I dislike letting agents run and submit a PR. I don’t trust the changes work, even if CI passes, and the iteration time is longer. Rather than have my attention repeatedly pulled in multiple directions, I want to work on one thing at a time, get it done, and then move on to the next one, just faster than if I was coding without an LLM.

• I almost always start with a plan, as in using planning mode. I give Claude some vague instructions about what I want and let it get familiar with the code base. It will come back with something. I then iterate with it on the plan until it looks basically right.

  • The most valuable thing I have that Claude doesn’t is context—context about the business, our users, their needs, how a feature should work, and, to a lesser extent, our engineering culture (it’s able to infer a lot about this from our code!). This is the most important stuff for me to tell Claude about when it’s planning.

  • If I’m working on something big or complex, I tell Claude I want to break the work into phases because I want to stop after each phase to create a PR in a stack of PRs. This helps keep it from getting lost because it’s trying to do too much, and because I actually do create a stack of PRs, which makes life easier come review time.

  • Sometimes I’m not sure if the initial plan Claude comes up with is good, so I ask questions. Claude can be a little overeager to make new plans, but if I keep pressing, it will explain its decisions and, if I think they are bad, I can work with Claude to come up with a better plan.

  • Speaking of which, I often dislike the initial plan. Sometimes I have an idea in mind of what we should do instead, but I will often feign ignorance and ask Claude for alternatives to avoid biasing it. Sometimes it comes up with a better idea than me, but usually it either comes up with the idea I had or makes a suggestion that helps me make my own idea better (and then I tell Claude to change the plan to do that).

• Once the plan is ready, I have Claude execute it. During this part I usually go do something else while it works. This might be working on another coding task, dealing with email or other messages, or catching up on Twitter if I can’t hold the context of two complex things in my head at once.

• When Claude is done, I carefully review its work. I trust nothing. I look over the diff and make sure I understand every part of it. If anything seems weird or I don’t understand something, I ask Claude what’s up with that part of the code.

  • Claude is biased towards action, so when asking questions, I often need to remind it that I’m just asking, not telling it to do anything yet. I’ll say something like don’t make any changes yet, but why is [some part of the code] like [whatever it’s like]?

  • I also ask Claude to plan changes before making them. This helps avoid a lot of rework and waiting for it to make changes that I’m going to undo. I sometimes go as far as putting Claude back into planning mode, but usually I just do planning in normal mode by being explicit with a prompt like don’t change anything yet. look at [part of the code] and give me options for how we might [make it better in some specific way]

    • I treat this process like a mini planning session, even if Claude isn’t in plan mode. So I ask lots of questions, try to understand tradeoffs, and come to a clear conclusion on what to do next before letting Claude write more code.

  • I’ll also sometimes go in and make edits. I can’t consistently get Claude to match my style preferences even with fairly aggressive prompting in CLAUDE.md, so I’ll go in and fix it manually. These are always small changes, though. For anything that’s going to take me more than a couple minutes I get Claude to do it.

    • When I do make edits, I always make sure to tell Claude I did this. Otherwise it’s liable to undo my changes. For this reason I often try to leave style edits until the very end, after I expect to make no more edits with Claude.

  • I find it useful to commit code as I go. This effectively gives me checkpoints in case Claude goes off the rails and does something weird that’s hard to recover from. I’ve regularly been saved from manual cleanup by being able to execute a quick git checkout .

• While I usually go do something else while Claude works, sometimes I find it useful to sit and watch it. I especially find this useful when I have low confidence that it will do the right thing, or when I’ve seen it wasting time doing extra steps after making code changes. Then I can interrupt it and correct course or stop it early and get on to the next thing.

• I always test Claude’s changes, just like I’d test changes if I made them directly. This should be obvious, but I own the code, not Claude, so it’s up to me to test it and make sure it works.

  • That doesn’t mean I can’t ask Claude for help, in particular to write automated tests. I’ll usually give it a vague description of what I want tested and what cases I care about, and it will code them up.

  • The tests Claude produces aren’t perfect, but writing tests is tedious, and I otherwise don’t write enough of them. Claude reduces the friction enough that I produce a larger number of useful tests in my code, even if those tests don’t meet the same quality bar I set for the application code.

  • I also test the code for real. I run it in dev and staging. Claude makes mistakes all the time, and I need to be sure the code actually does what I think it does. It’s not uncommon to discover that code looks correct but does something subtly different than intended or behaves contrary to expectations I didn’t realize I had until seeing the code in action.

• I use Claude to review the code. I start a new session and ask it to review the code. Don’t tell Claude that I wrote the code with its help, because that can bias it. I just ask it to review the changes. It can look at the diffs in the commit, read more code, and spot issues the original Claude instance missed.

  • In practice I also use other automated code review tools that run as part of CI, and sometimes I skip local Claude review because of that. The point is that LLMs are great at noticing mechanical mistakes in code that humans often miss, and I rely on a fresh set of LLM eyes to catch those before they make it to production.

• I use Claude to refactor the code it produces. The initial run is usually full of code smell or exposes latent smell, and this is where a huge chunk of my productivity boost comes from. Rather than shipping more technical debt on top of existing debt, I’m able to continually pay down debt with every PR because the cost of doing refactors with Claude is dramatically lower than doing them by hand.

  • For example, code organized into the wrong directory structure? That’s a pain to fix by hand. Claude can do it in a few minutes while I get a fresh cup of coffee.

  • Sometimes I need to talk with Claude about the refactor and plan it. The process looks like this:

    • hey, this part of the code looks weird to me. what’s up with it? don’t try to fix it, just explain to me why it’s like this

    • Claude answers

    • okay, what are some options for how we could improve it

    • Claude proposes some solutions

    • let’s go with option B, but change it to include feature 2 of option C

    • or actually, i don’t like any of those, let’s do [something better] instead

  • Again, if I need more information to make a decision, I ask for it.

    • Frequently I have to explicitly ask Claude to look at docs or otherwise search the web for it to get correct information about how, for example, a library or API works. This is basically always worth the time it takes.

• Finally, I never get mad at Claude. Sometimes it’s kinda dumb or includes a change that I don’t notice until a reviewer asks me about it and then I look dumb because I didn’t know it was there, but that’s my fault. As I said, I own the code, not Claude, and that means I’m both responsible and accountable for what Claude does. I find that this mindset is critical to using Claude Code effectively.

Can You Become a 5x Engineer?

Yes. Probably. Maybe. If you use Claude like I do, the quality of the results you get will depend heavily on how good of a programmer you are.

From what I can tell talking to other people, I work well with Claude because I have a lot of programming experience—over 30 years’ worth! I’ve developed strong intuitions about what good code looks like, and have clear ideas about what patterns will and won’t work. I can steer Claude towards good solutions because I know what good solutions look like. Without this skill, I’d be lost.

Now, I earned my intuitions the hard way, by spending years writing code by hand, carrying my punch cards uphill both ways. If you’re in that situation, great, you can pair with Claude Code the way I do to good effect. If not, is there anything you can do?

I think so. You can learn by talking to Claude and asking it to explain things to you. If you have a few basic motions to ask about tradeoffs and to ask for help understanding why Claude thinks some change is a good idea, you can use it to bootstrap yourself and gain a lot of experience rapidly. This might not be a total replacement for years of experience, but it’s better than nothing, and realistically, it’s what you’re going to have to do if you’re just starting out and want to get productive enough to get and stay employed.

Because if there’s one thing you should come away from this post with, it’s not that there’s a bunch of ways to use Claude or other coding agents to increase your productivity, it’s that you must start using these tools to become more productive so that you aren’t left behind.