The AI Builder's Field Manual

Let me set the range honestly, because most writing about AI is either a sales pitch or a panic.

With today's tools, one careful person can build: a fast, well-designed marketing site. A store or a booking system. An internal tool your team actually uses. A content pipeline producing more long-form work than a human team could. Automated workflows that read, write, sort, and route information — with a database underneath and a custom admin interface on top, so you can run the thing yourself. I have built every item on that list, alone, in weeks rather than months. None of it required a development team.

Two years ago that list would have been dishonest. What changed is that AI stopped being an autocomplete and became a builder that can hold an entire project in view — read the code, change it, and check its own work.

Now the other half. AI will not give you the vision — it has no stake in your business and no opinion about it worth having. And it will not do judgment: it doesn't know when an answer is fluent but wrong, when a page is technically fine but off for your audience, or when a feature shouldn't exist at all. Vision and judgment stay human. Nearly everything between them can be automated.

That's the frame for the rest of this manual: AI is the best construction crew I've ever worked with — and a construction crew still needs someone who knows what the building is for.

Not a survey of everything that exists — the short list of what I open every working day, and what each piece does in plain words.

What's missing from the list is deliberate. I used page builders like Lovable and dropped them — the output is bloat you end up fighting. And I don't build on WordPress or similar legacy stacks: that's bloat you pay for forever, in plugins, updates, and hosting. The stack above is smaller, faster, and close to free to run. The honest trade-off: it needs someone who can operate it.

The tools are the smaller half. The method decides whether you end up with a system or a mess.

Vision first. I don't start building until I understand what the thing is for and what "working" would mean. This is the one step that cannot be rushed and cannot be delegated to a model — and in my experience, the step people most want to skip.

Then a written plan. What we're building, the exact stack, what I do, what you bring. Deliberately boring. The plan is what the AI executes against; without it, you're improvising — at machine speed.

Then small, verified loops. AI builds fast enough that the temptation is to let it run. I do the opposite: small steps, each one checked — does it run, does it look right, did anything break — committed to version control, then the next step. Slower per step, dramatically faster to something that actually works.

Humans exactly where judgment matters. The largest system I run this way has produced 400+ long-form articles through a 12-stage process. Machines carry the volume; humans sit at fixed gates — setting direction, checking facts and sources, approving what ships. That's not a compromise on automation. It's the thing that makes automation trustworthy.

If you're mapping your own idea onto a stack, this table is the shortest version of my advice.

I'm an AI-first builder, end to end. I am not a classic software development shop, and for some projects that difference matters.

You need a traditional developer — usually a team — when the work involves real-time systems where milliseconds matter, heavy custom backends and infrastructure, native mobile apps, or security-critical products: payment infrastructure, health data, anything where a breach is a catastrophe rather than an embarrassment. Those domains reward deep specialist experience and a slower, more defensive engineering culture. AI is useful there too — but as a tool in an expert's hands, not as the whole way of working.

When a project lands in that territory, I'll say so on the first call. I can refer people I trust, and I'm comfortable working alongside a development team — building the site, the content machinery, and the interfaces around their core. What I won't do is stretch this manual over terrain it doesn't cover.

Almost every failed AI project I've seen up close died from one of these — usually the first.

• AI output with no quality gate. Generate, publish, repeat. If nobody checks the work, the work isn't done — it's merely produced. This is where AI slop comes from, and readers can smell it.
• No version control. Building with AI and no history means one bad change with no way back. If your builder can't tell you exactly what changed yesterday, that isn't engineering.
• Renting bloated tools forever. No-code platforms get you a demo in a day, then bill you monthly for the privilege of never owning it — and buckle the moment you need something they didn't anticipate.
• Skipping the plan. AI makes starting cheap, which makes building the wrong thing cheap too — and very fast. The plan is not paperwork; it's the steering.
• Automating a process nobody understands. If no one on the team can do it manually and explain every step, automation just makes the confusion faster. Understand first, then automate.