Hashlogics
Tool review

Claude Code

A year of shipping on it, not a week of trying it

This website and our internal Supabase CRM are both built and maintained with Claude Code daily. Here is what that year taught us.

The short answer

Claude Code is good enough to run production work daily, provided a senior engineer reviews every diff and the codebase carries a verification suite the agent has to pass.

Skip it if nobody on the team can review a pull request the tool did not write by hand. The output is fast and mostly right, and mostly right is the dangerous half of that sentence without a reviewer who would catch the rest.

What decides this

4 things that decide this

  1. 01It writes correct code most of the time and confidently wrong code the rest of the time, so a test suite matters more with it than without it.
  2. 02Skills, which are packaged instructions the agent loads for a repeated task, cut the setup cost of a recurring job from a paragraph of context each time to one line.
  3. 03A schema or database migration is where it needs the most supervision. It will run a script before checking what environment it points at unless the repo stops it.
  4. 04It changes who reviews code more than who writes it. The senior engineer's job shifts from typing the function to reading the diff and asking what the agent missed.
What it is

A command-line agent that reads, writes and runs your codebase

Claude Code is Anthropic's coding agent, run from a terminal or an editor plugin. Point it at a task. It reads the relevant files, writes the change and runs the tests, then asks for approval on anything it is not cleared to do alone.

The part that matters commercially is not the code generation. Most models write a passable function. What Claude Code adds is the loop around that. It reads your existing patterns before writing new ones, and it can run your build and tests itself.

Where it holds up and where it does not

Strengths

  • It reads a large codebase before acting, so a change follows the patterns already in the repo instead of introducing a new one on every file.
  • Skills let us package a recurring job once, such as writing a new page block or running our page-verification checks, and reuse it with one line instead of re-explaining it.
  • It runs the verification suite itself and reports failures, which turns a review from reading code cold into checking a claim it already tested.
  • Long, multi-step jobs, like a schema migration across several files, stay coherent because it keeps the plan in view rather than losing the thread after a few edits.

Trade-offs

  • It will run a destructive command, such as a database reset script, against whatever the environment variable happens to point at unless the repo explicitly guards that path. We added a local-only check after this nearly hit a shared database.
  • Confidence does not track correctness. A wrong answer reads exactly as fluent as a right one, so skimming a diff because it looks clean is how a bug gets merged.
  • It will squash or rewrite history if asked loosely, so anything destructive to git state needs the same explicit boundary as a database command.
  • On an unfamiliar codebase with no tests, it moves fast toward the wrong place. The gain is proportional to how well the repo can prove its own correctness.
How a change gets reviewed hereLive
  1. TaskDescribed in plain language, not a spec
  2. Agent readsExisting files and patterns first
  3. Agent writesCode, migration, or config change
  4. Suite runsTests and checks, before a human looks
  5. Senior reviewsThe diff, before the result

The suite runs before the person does. That order is what makes review fast rather than skipped.

From our own use

What runs on it, and what changed because of it

This website is built with it: the Next.js and Payload CMS codebase, its page-builder blocks, its migrations and its verification scripts. Our internal Supabase CRM runs the same way. Both are maintained daily, which is the harder test for a tool like this.

The biggest shift was not speed. It was what a verification suite is for. Every check we added traces back to a mistake the agent made once. A database write with no local-only guard. A cache purge that missed one collection. A migration file with no IF NOT EXISTS clause. Each became a script the agent now has to pass, so the mistake cannot recur silently.

  • 01Write the check first for anything the agent got wrong once. It will not remember the mistake next session; the check will.
  • 02Give it a skill for any task done more than twice. A one-line trigger beats retyping the same instructions.
  • 03Treat its confidence as unrelated to its correctness. Review the diff on its own merits, not on how sure it sounds.
Questions, answered

What teams ask before committing

01Is Claude Code good enough for production, or just prototypes?

It holds up in production if your codebase has a verification suite it must pass and a senior reviews the diff. We run our own website and our internal CRM on it, both maintained daily rather than built once. Without tests or review on your side, the same speed just ships mistakes faster.

02Is Claude Code worth it for an agency, beyond a solo developer?

Yes, with a structural change to how review works. The agent narrows the gap between writing code and having a draft to review, so the bottleneck moves to the senior engineer's time reading diffs. An agency that does not restructure review around that just moves the queue somewhere else.

03Claude Code or Cursor?

Cursor is an editor with AI assistance built in. Claude Code is a standalone agent you run from a terminal or plug into an editor of your choice. Decide by whether you want the agent to run your build and tests end to end, or stay inside an editor's autocomplete-and-chat model. We use Claude Code because our verification suite needs a command runner, and an editor alone cannot be that.

04What breaks first when a team adopts it?

Database and git safety, before anything else. An agent that can run any command will eventually run a destructive one against the wrong target if nothing stops it. The fix is a guard script checked into the repo, not a reminder in a prompt. We added ours after a near miss on a shared database connection string.

05Does it replace a senior engineer?

No. It changes what a senior engineer spends time on: from typing the function to reading the diff and deciding what the agent missed. The judgment calls still come from a person who has shipped the failure mode before. What to build. Where to guard against it. How strict the tests need to be.

Written by Abdul Basit, CEO, HashlogicsVerified
Start

Let’s build the one that runs after.

We build AI agents and automation, then stay on under an agreed service level. A senior engineer reads every brief, and your call gets scheduled within 24 hours.

What happens next

  1. 01

    You send a brief or book a call

    Two minutes, whichever you prefer.

  2. 02

    A senior engineer replies within 24 hours

    Not a sales rep.

  3. 03

    Honest scoping, in writing

    And if we’re not the right fit, we say so.

Abdul Basit, CEO of Hashlogics

“I started Hashlogics because too many teams ship a demo, get paid, and disappear. We build to a standard we’d run ourselves — and we stay to keep it running.”

Abdul Basit · CEO · a direct line

Not ready to talk? Take the checklist.

12 questions to ask any AI agency before you sign. They separate a demo shop from a team that ships to production.

Get the checklist

Free · no newsletter