I serve legal papers for a living. I’m out in the field most days — knocking on doors in Fresno, Clovis, Madera, driving the mountain routes. I’m not a software engineer. I never took a computer science class.

And over the last two years I’ve built the entire back office of my real process-serving business with AI — using Claude Code to write the intake, the scheduling, the invoicing, the email drafting, the reporting. Hundreds of cases run through it. People assume that means I “let the AI do it.” That’s not what working with the models actually looks like. Here’s what it really is.

1. Treat it like a sharp junior, not an oracle

The model is fast, well-read, and confident — including when it’s wrong. If you treat its answer as the truth, you’ll ship its mistakes. If you treat it like a sharp junior who needs direction and review, you’ll ship good work fast.

That mental shift is the whole game. I don’t ask it “what should I build?” I tell it what I’m building and why, and I make it show me the work. The judgment stays mine. The typing speed is its.

2. The spec is the job

Vague in, vague out. The single biggest jump in quality I ever got wasn’t a smarter model — it was me writing better specs. Before I ask for a line of code, I write down what it has to do, what counts as done, and what must never happen. (If you want the disciplined version of this, look at spec-driven development — write the spec, then let the model build to it.)

Notice none of that is code. It’s the thinking. The model writes the code; I write the constraints. The place I keep those constraints is a file the model reads every time — my CLAUDE.md. It’s the real product. A slice of mine:

3. Verify. Then verify again.

“It compiles” is not “it works.” “The AI said it’s done” is not “it’s done.” Every single thing I build, I run with real input and watch what actually happens. Done isn’t a checkbox — it’s proof. A log line. A rendered page. The real response coming back.

The model will tell you it handled the edge case. Make it prove it. Half the bugs I’ve caught were things the AI was completely sure it got right. That habit — refusing to call something done until it’s proven — is exactly what first-hand, experience-backed work looks like, in code or anywhere else.

4. Know what you keep human

This is the part people skip, and it’s the most important. The AI built the system I run my company on and it drafts my routine client emails — which I review before they go out. But the legal work is mine and only mine. I’m a Registered California Process Server, PS-124. Every service of process, every proof, every sworn declaration is from my own first-hand observation, written and signed by me. A machine doesn’t get to swear to what I saw at a door. It never will.

That line — what the machine does versus what only a human can stand behind — isn’t a limitation I’m working around. It’s the design. Know your 20% that has to stay human, protect it, and let the model take the other 80% off your plate.

I’m still the process server. I still drive the routes and knock on the doors. The models just gave a one-man operation the back office of a much bigger company — because I treated them like the power tools they are, and never once handed over the steering wheel. More of this in the rest of TECHNICALLY SPEAKING — and if you want the short version of who I am, that’s there too. (When I’m not shipping code, I’m in the woodshed with a guitar.)

FAQ

Do I need a CS degree to build software with AI?

No. I don’t have one. You need to be willing to read the work, write clear specs, and verify everything before you trust it. The judgment matters more than the credential.

Is it safe to let AI touch code that runs a real business?

Only if you stay the operator. I review what it writes, run it against real input, and keep the parts that carry legal or financial weight under human control. The model drafts; I decide and verify.