The thing nobody tells you about AI coding

Everyone’s got an opinion on which model is smartest. Almost nobody talks about the part that actually moves the needle: the discipline you wire around it.

Here’s the thing most people miss. The model is a commodity. Any tool can call one. What separates “I have a chatbot that writes code” from “I ship real work to production, alone” is the scaffolding — the skills, the guardrails, the muscle memory baked into the environment. The skill isn’t prompting. Any tool can prompt. The skill is building a system that turns a prompt into something tested, reviewed, and live.

I run Sigma Synapses as a solo founder. I write the code, I run production, and I talk to clients — no handoffs, no team to absorb the slack when something breaks. That only works because I spent the time making my setup do the heavy lifting. This post is about that setup, which I just open-sourced.

What I open-sourced

It’s called claude-dotfiles. It’s the actual Claude Code configuration I use day to day — not a sanitized demo. Clone it, run one command, and you get the same engine I do:

git clone https://github.com/iamnolanhu/claude-dotfiles.git
cd claude-dotfiles
./setup.sh

Or — and this is the part I’d actually recommend — don’t run anything by hand. Open Claude Code inside the folder and ask it to set the thing up for you. It reads the repo, it knows what setup.sh does, and it walks through the steps with far fewer of the copy-paste mistakes that bite people the first time. The same intelligence you’re installing can install itself. That still feels a little strange to say out loud, and it’s also just true.

Cloning and setting up claude-dotfiles

One command, or just ask Claude to do it.

A 15-plugin core installs the workflow backbone — brainstorming, test-driven development, systematic debugging, planning, multi-file feature work, code review, persistent memory, browser-driven verification. On my desktop that core grows to around 30 plugins; a leaner VPS profile runs about 20. Then there’s an onboarding layer that, if you’ve never coded, will literally walk you from “I want to build a thing” to a deployed result. You open Claude Code, say help me get started, and it routes you through plan → build → verify → review → ship, explaining every step in plain words.

I built that part for a specific reason. I kept watching people with great ideas get stuck at the terminal. The model could build their thing. They just didn’t know how to ask, or what was safe to do. So I encoded the asking.

Give it your own keys, and it stops writing and starts doing

Here’s the shift that changes everything, and it’s quieter than it sounds.

Most people use AI as an author. It writes the code, then you run the build, you commit, you open the PR, you deploy. The AI hands you a draft and you do the operating. But you can hand it the keys instead. Drop your own API tokens — GitHub, DigitalOcean, Vercel, whatever you use — into ~/.claude/.env, and Claude stops being the author and becomes the operator. It runs the build. It commits. It opens the PR. It deploys. It provisions the server. You stop being the hands and start being the one who decides.

That’s the actual unlock behind “team of one.” I’m not faster at typing than a team. I just don’t sit in the loop for the mechanical parts. The work that used to be mine — the deploy, the migration, the release — gets done by the same agent that wrote it, because it has the credentials to finish what it started.

One honest caution, said once: only hand it tokens you’re genuinely comfortable letting it use. The keys are the power, and they’re the responsibility. That’s exactly why the next part exists.

The guardrails are the point

The flashy part is the agents. The part that lets me sleep — especially once the agent has real credentials — is the guardrails:

  • Nothing is “done” until it’s actually run and shown working. No “this should work.”
  • Every working state gets committed automatically, so there’s always a point to rewind to.
  • Anything risky — spending money, deploying, deleting, touching secrets — stops and asks first.

These sound boring. They’re the whole game. A non-coder can ship with this setup because the rails won’t let the thing quietly break. I hand the agent my keys for the same reason — I’m not trusting it blindly, I’m trusting the rails. I’m not babysitting, I’m reviewing.

How this actually runs a company

At Sigma Synapses this isn’t a toy config. It’s production tooling:

  • One monorepo, isolated worktrees per workstream, so parallel features never step on each other.
  • Custom skills for the repetitive loop — /implement-feature, /fix-bug, /add-migration, /create-pr.
  • The changelog bumps itself on merge. I stopped tracking versions by hand a long time ago.
  • The design system blocks hardcoded colors before they ever land.
  • Every incident gets a postmortem, so the same bug never bills me twice.

One person, real client work shipping. Not because I’m fast at typing — because the system is, and because I let it operate, not just type.

Take it

It’s MIT licensed. Clone it, fork it, rip out what doesn’t fit. There’s a project page with more on how it fits together. If you’re non-technical and you’ve been waiting for permission to build something, this is it — open Claude Code in the folder, say help me get started, and let it set itself up. That’s a real door.

And if you’d rather have AI agents handle your customer conversations instead of building it yourself, that’s literally what I do for a living. Come say hi at sigmasynapses.com.

A ghost-in-the-shell easter egg hidden in the repo

There's a ghost in the shell. Look closely.

There’s a ghost hiding in that repo, by the way. You’ll find it if you look.

Streamline the Future.