How I use Claude Code to ship real business systems (as a salesperson, not a career engineer)

I have worked with AI since 2024. In September 2026 I moved from no-code tools to shipping real software with Claude Code. My background is more than ten years in sales, not engineering. Within weeks I had an inventory system with 396 automated tests, a routing engine running on Bogotá’s real street map, and a robot that tests my store’s checkout before every change.

I’m not sharing that to show off. I’m sharing it because the shift wasn’t learning to code in a month. It was learning to direct an AI that codes. And that has a lot more in common with selling and managing than with writing software.

Here’s the operating model I use with Claude Code on real businesses.

1. Context before code

Claude Code is excellent at writing code. What it doesn’t know is who you are, what you sell, or what matters this quarter. If you don’t tell it, it guesses.

So the first thing I built wasn’t a client system. It was my own AI operating system: a folder of plain text files.

• Who I am and how I write, so drafts sound like me.
• My business: what Empire Essence sells, to whom, and how money comes in.
• Three quarterly priorities, with dates and numbers.
• A task queue, in order.
• A decision log: what I decided, why, and what I ruled out.

Every session starts by reading that. I never re-explain the business. And when I bring a shiny new idea, it asks which of my three priorities it serves. That filter has saved me from my biggest weakness: scattering my focus.

Takeaway: before asking AI to build anything, write it one page about your business. What you sell, the number that hurts, and what must never be touched.

2. Clear roles: I decide, agents build

I run Claude Code and Codex as a small team.

• Me: I decide what gets built, for whom and within which limits. I talk to customers. I own the outcome.
• Claude: plans, orchestrates, builds and reviews everyone else’s work.
• Subagents: for big jobs, Claude spins up several agents in parallel, each on a model matched to the difficulty. Cheaper models for research and volume work, the strongest model for the hard core.

On the routing project, one agent researched costs and sources, another built the address auditor, and the strongest model built the engine. Claude reviewed every delivery by running the tests and checking screenshots.

Takeaway: the question isn’t “which tool?” It’s “who decides and who executes?” If the AI is deciding, you have a problem.

3. Non-negotiable rules

The question I get most: aren’t you afraid the AI will do something it shouldn’t?

Yes. That’s why there are written rules that always apply:

• Nothing ships without my explicit yes. No push, no production change, no message to a client. Approving the idea is not approving the release.
• Secrets are off-limits. Keys, passwords and private config files are never read.
• Every step lands in a commit that says what changed, why, and how it was tested. That history is my portfolio.
• Every release has a written rollback before it goes out.

I learned it building a QA robot for my store: AI doesn’t need more freedom. It needs clear rules.

4. Demand evidence, not promises

An agent can say “done, it works” when it doesn’t. So I never accept “done” without proof.

• Every system ships with automated tests. Restocore has 396. The routing engine has 405, plus 86 browser tests.
• Anything risky gets an adversarial review: another agent whose only job is to break it. On Restocore, that review caught my first proposal promising features the product didn’t have yet. I built them before sending it.
• Anything visual gets screenshots on mobile and desktop before it counts as finished.

Takeaway: when someone sells you an AI system, ask how many tests it has and what happens when it fails. No answer, no system.

5. The mistakes that cost me

Building with AI isn’t magic. These were my most expensive lessons:

• The wrong source of truth. I asked an agent for a gift guide and it came back with outdated prices, because I’d pointed it at an old code branch. Now prices only come from the published version or the live site.
• Burning a week’s quota in one night. I launched three heavy jobs in parallel at maximum reasoning effort and drained a tool’s weekly limit overnight. Now effort is matched to the task.
• The most expensive setting isn’t the best one. In one test, a small model at maximum effort overthought a tiny function and cost more than a mid-size model at medium effort. Only measuring tells you.
• Made-up data. I started the routing project with invented deliveries in a sandbox. I stopped it. Without real map data and verified sources, it helps nobody.

6. Where a business should start

You don’t need to code to get value from Claude Code. You do need clarity:

1. Pick one task your team repeats every day.
2. Write down what it costs, in hours, errors or money.
3. Define “done” before you start. Otherwise you never finish.
4. Ask for a plan before code. Read it. Question what you don’t understand.
5. Require tests and look at them, even briefly.
6. Try it on your own business first. I do everything at Empire Essence before taking it anywhere else.

What this means if you’re hiring

I don’t call myself an engineer yet. I’m someone who understands how businesses make money and has learned to direct agents that build. That combination is rare: I can sit in a discovery call, find the number that matters, and come back with a tested system.

If that’s the profile your team needs, or if you have a business with a task that keeps repeating, message me on LinkedIn.