The AI Builder’s Field Manual

Most of what you read about AI is either a sales pitch or a panic attack. Here’s the plain version of what it can build today, and what it can’t.

With today’s tools, one careful person can build a fast, well-designed marketing site, a store, or a booking system. Or an internal tool your team will actually use. Or a content system that produces hundreds of long-form articles, with a person checking every one. Or automations that read, write, sort, and route information, running on a real database with an admin panel on top so you can manage them yourself.

I’ve built the sites, the content system, and the automations on that list myself, with no development team behind me.

Two years ago, that list would have been a lie. What changed is that AI went from fancy autocomplete to a builder that can keep a whole project in its head. It reads the code, edits it, and then checks its own work.

Now the other half. AI won’t hand you a vision. It has nothing riding on your business and no opinion of it worth hearing. It also can’t make judgment calls. It can’t tell when an answer sounds right but is wrong, when a page works fine technically but misses your audience, or when a feature shouldn’t exist at all. Vision and judgment stay with people. Nearly everything in between can be automated.

AI is the best construction crew I’ve ever worked with. But even a great crew needs someone who knows what the building is for.

This isn’t a roundup of every tool out there. It’s the short list I actually work with, and what each one does, in plain English.

Anything missing is missing on purpose. I tried AI site builders like Lovable and dropped them, because they generate bloat you then spend your time fighting. I’ve also built WordPress sites, including a WooCommerce store, and I’ve stopped. You keep paying for them forever in plugins, updates, and hosting. The stack above is leaner and faster, and it costs next to nothing to run. The catch is that it needs someone who knows how to run it.

The tools are the smaller half of the job. 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” looks like. You can’t rush this step, and you can’t hand it to a model. In my experience, it’s also the one people most want to skip.

Then a written plan. It covers what we’re building, the exact stack, what I’ll do, and what you’ll bring. It’s boring on purpose. The plan is the drawing the crew builds from, and without it you’re improvising at machine speed.

Then small, verified steps. AI builds so fast that it’s tempting to just let it rip. I do the opposite. I work in small steps and check each one (does it run, does it look right, did anything break?), then commit it to version control before I start the next. Each step takes longer, but you reach something that works much sooner.

Humans exactly where judgment matters. The biggest system I run this way is a 12-stage content process that has produced 400+ long-form articles. Machines handle the volume. People sit at fixed checkpoints, where they set the direction up front, check facts and sources, and sign off on every page before it goes live. That’s what “human-in-the-loop” means in practice, and it’s why you can trust the output.

If you’re trying to figure out what your idea should be built with, here’s my advice in its shortest form.

I build with AI from start to finish. I’m not a traditional software shop, and for some projects that difference matters.

You need a traditional developer, usually a whole team, for real-time systems where milliseconds matter, heavy custom backends and infrastructure, native mobile apps, and anything security-critical: payments, health data, anything where a breach is a catastrophe rather than an embarrassment. That work rewards deep specialist experience and a slower, more defensive engineering culture. AI still helps there, but as one tool in an expert’s hands.

If your project is in that territory, I’ll tell you on the intro call. I can point you to people I trust, and I’m happy to work alongside a dev team, building the site, the content system, and the interfaces around their core product. What I won’t do is pretend this manual covers ground it doesn’t.

When an AI project fails, it’s usually for one of these reasons, most often the first.

• Publishing AI output with no quality check. Generate, publish, repeat. If nobody checks the work, it isn’t finished, just produced. That’s where AI slop comes from, and readers can smell it.
• No version control. If you build with AI and keep no change history, one bad edit can leave you with no way back. If the person building for you can’t say exactly what changed yesterday, that isn’t engineering.
• Renting bloated tools forever. No-code platforms get you a demo in a day, then charge you every month for something you’ll never own. And they fall apart the moment you need something they didn’t plan for.
• Skipping the plan. AI makes starting cheap, so it also makes building the wrong thing cheap, and fast. The plan is how you steer.
• Automating a process nobody understands. If nobody on the team can do it by hand and explain each step, automation just speeds up the confusion. Understand it first, then automate it.