Three months ago I nearly hired a second backend developer. We had a backlog that was embarrassing — fourteen features promised to clients, two people stretched thin, and me context-switching between sales calls and pull requests like a complete idiot. Then I started actuallyusingClaude Code properly. Not just pasting functions into a chat window. I mean integrating it into the real daily flow. We cleared that backlog in six weeks. I didn't hire the second developer.
That's not a pitch. That's just what happened.
What "Properly" Actually Means
Most people I talk to at meetups are using AI coding tools the same lazy way. They paste a function, get something back, paste it into their editor, it breaks, they give up. That's not a workflow. That's desperation.
Properly — for me — means Claude Code lives inside my terminal via theClaude Code CLI, working directly on my actual repo, reading real files, not sanitised snippets. The difference is enormous. When it has full context of a 4,000-line WordPress plugin we built for a US healthcare client last year, the output is usable. When it's working blind off a 40-line paste, it's guessing.
I run it on a MacBook Pro M3. My editor is still VS Code with the usual suspects — Prettier, ESLint, GitLens. Claude Code doesn't replace any of that. It sitsalongsideit.
The Setup I Actually Use
- Claude Code CLI installed globally via npm
- A
.claudedirectory in each project root with aCLAUDE.mdfile — this is basically a brief I write for Claude about the project: stack, conventions, whatnotto touch - iTerm2 split panes: code on the left, Claude session on the right
- Git commits after every Claude-generated change, no exceptions. I've been burned.
That last point. Back in 2022 a client project — Shopify migration for a Manchester-based furniture retailer — I let three hours of AI-assisted edits accumulate without committing. The whole session got corrupted. Six hours of work gone. I now commit compulsively, almost neurotically. Claude Code or not.
The Morning Routine (This Is Boringly Specific on Purpose)
I'm in the office by 8:30. Coffee from the place on Exmouth Market. I open Notion, look at what's on the board for the day, then open my terminal.
The first thing I do with Claude Code each morning is what I've started calling a "context dump." I open the project, runclaudeand give it a paragraph of where I left off the previous day. It reads the recent git diff automatically. This takes about three minutes and means I'm not spending twenty minutes re-reading my own code to remember what I was doing. That alone is worth the subscription.
Then I work. I'm not asking Claude to write features from scratch — though sometimes I do. Mostly I'm asking it to do the things that slow me down but require zero creativity.
Things like:
- Writing PHPUnit test cases for functions I've already written
- Generating TypeScript interfaces from a JSON response I paste in
- Refactoring a 300-line component that Iknowneeds splitting but don't want to think about
- First-draft documentation for internal APIs
None of that is exciting. All of it used to eat an hour I didn't have.
Where It Actually Saves Time (With Numbers)
Seahawk has built over 12,000 sites at this point. A big chunk of that is WordPress — themes, plugins, WooCommerce customisations. There's a category of task in WordPress development that is mind-numbing but technically precise: writing custom hooks, registering REST API endpoints, building settings pages with the Settings API.
I timed it last month. Writing a WooCommerce custom shipping method class from scratch: historically takes me about 45 minutes including testing. With Claude Code doing the scaffold while I describe the business logic in plain English: 12 minutes. And the scaffold isgood— it followsWordPress coding standardsbecause I told it to in myCLAUDE.md.
That's not 10% better. That's a different category of speed.
The bigger saving is context-switching cost. When I'm mid-feature and a client pings about a bug on a completely different project, I used to either ignore the client (bad) or lose my thread entirely (also bad). Now I can ask Claude to write a detailed comment block summarising exactly where we are in the current task, switch to the bug, fix it, come back, read the comment, and pick up in about four minutes. Before, that recovery cost me twenty.
Where It Falls Apart
Honest time. And this matters more than the wins.
Claude Code is genuinely bad at anything that requires understandingwhya decision was made historically. We had a fintech project at Seahawk — a dashboard for a London-based payments startup — where a particularly gnarly bit of state management existed for a reason that predated our involvement. Some edge case in how their legacy API batched responses. Claude kept "fixing" it. Every suggestion was technically cleaner and completely wrong. It didn't know what it didn't know.
This is the failure mode nobody talks about enough. The outputlookscorrect. It passes basic review. And then it breaks in production on a Thursday evening when a user hits that edge case.
My rule now: Claude Code doesn't touch anything where the comment says "don't change this without asking Ravi." (Ravi is our lead backend dev.) Full stop.
It also struggles badly with:
- Multi-file refactors where the dependency chain is more than three levels deep
- Anything involving a third-party SDK that's less than two years old — it hallucinates method names confidently
- CSS that needs to match a designer's pixel-perfect comp (it gets close, then drives you mad with small errors)
- Performance optimisation where the bottleneck is non-obvious — it optimises the wrong thing
On point two specifically: I was integrating Resend's API into a Next.js project in January. Claude kept referencing a.send()method that doesn't exist in theResend Node SDK. Took me longer to debug Claude's confident wrongness than it would've taken to just read the docs myself. Lesson learned. For any SDK, I paste the actual README into the context window first.
The Prompt Patterns That Actually Work
I've iterated on this for months. Bad prompts get bad output. Here's what I've landed on.
Be the senior dev, not the intern.Don't ask "write me a function that does X." Ask "I need to implement X. Here's the constraint: Y. Here's what I've already ruled out: Z. What's your approach before you write anything?" Make it think first. The output after that conversation is dramatically better.
Give it a persona with stakes.I literally write: "You're a senior WordPress developer who cares deeply about not introducing security vulnerabilities. The client is a healthcare company. Prioritise sanitisation and nonce verification above everything." Does this feel silly? Yes. Does it work? Also yes.
Specify the format of the output."Give me just the function, no explanation" or "Give me the function, then a bullet list of what I should manually verify." Unstructured output wastes time.
One pattern I reach for constantly:
- Describe the goal in one sentence
- Paste the relevant existing code with a comment explaining its purpose
- State the constraint ("must be backwards compatible with PHP 7.4")
- Ask for an approach first, code second
- Review the approach, push back if needed,thenask for the code
Five steps. Sounds like overhead. Saves me fifteen minutes of bad code every time.
How It's Changed What I Delegate
This is the bit that surprised me most. Claude Code didn't just makemefaster. It changed what I hand off to junior developers.
Before, a junior dev at Seahawk would spend their first two weeks just getting familiar with our conventions and our stack. Now I hand them a project with a well-writtenCLAUDE.mdand tell them to use Claude Code to generate scaffold code, then review it against the conventions. They're contributing real work in three days instead of three weeks.
TheCLAUDE.mdfile is doing the mentoring I used to do in hourly walkthroughs. That's a meaningful shift. Not because I don't want to mentor — I do — but because now the mentoring conversations are about decisions and trade-offs, not "remember to usewp_nonce_field()in every form."
TheAnthropic model spec documentationis worth a read if you're curious about the guardrails Claude operates within — understanding them helps you work with its tendencies rather than against them.
The Founder-Specific Angle
Most articles about AI coding tools are written for developers. Fine. But there's a specific founder problem that Claude Code addresses that I haven't seen articulated well.
When you're running an agency and also shipping code, your biggest enemy isn't skill gaps. It'sre-entry cost. You get pulled into a pricing call for forty minutes, then you need to go fix a CSS regression, then you have a 1-on-1 with a team member. By the time you get back to the feature you were building, you've lost the thread so completely that starting again feels easier than picking up.
Claude Code, used properly, reduces re-entry cost dramatically. I mentioned the summary comment block trick earlier. I also use it to generate a quick "where we are" Slack message to myself with bullet points of what's done, what's next, and what's blocked. Takes ten seconds. Saves ten minutes of reconstruction.
It won't make you a better manager. It won't clear your calendar. But if you're a founder who still ships — and I think more of us should be — it removes a specific, painful tax on your coding time.
FAQ
Is Claude Code worth it if you're not a full-time developer?
Honestly, probably less so. The value compounds when you're in the tool every day and you invest time building good context files (CLAUDE.md, clear project briefs, etc.). If you're dipping in once a week, you'll spend more time re-establishing context than you save. GitHub Copilot might suit occasional users better — it's more ambient and requires less deliberate setup.
How do you handle code quality — do you just trust what it generates?
Never blindly. Every Claude-generated file goes through ESLint and our Prettier config automatically. For anything touching authentication, payments, or data handling, I do a manual line-by-line read. For utility functions and tests, I'm more relaxed. You calibrate based on risk. TheOWASP Top Tenis a useful mental checklist when reviewing AI-generated code that handles user input.
Does it work well with WordPress specifically?
Better than I expected, with caveats. It knows WordPress deeply — hooks, filters, the Settings API, WooCommerce internals. But its knowledge of newer Gutenberg block development (particularly the Interactivity API) is patchy. I always verify against theBlock Editor Handbookfor anything block-related.
What about cost?
I pay for Claude Pro, which is $20/month. At the level I use it, the time saving is somewhere between four and six hours a week. Do the maths on your own hourly rate. For me it's not a question worth asking.
---
I still write plenty of code myself. I'm not interested in becoming a prompt jockey who never touches a real function. But the founder who pretends AI coding tools haven't changed the craft is kidding themselves. The question isn't whether to use them. It's whether you're using them with enough rigour to get real value — or just enough carelessness to introduce real problems.
For me, the difference between those two things came down to treating Claude Code like a capable but junior developer. Smart. Fast. Needs a good brief. Needs review. And absolutely should not be left unsupervised near anything mission-critical.
That framing changed everything.