I Build Client Websites With AI. Here's How I Make Sure It Never Takes the Wheel.

If you have paid for a website recently, you may have wondered about it quietly, “did AI build this?”

For my own work, the honest answer is yes and no.

Yes, I use AI every day. The two client websites I launched this year, for an oil and gas services company and an online French school, were both built with Claude Code, an AI coding tool. So was my own portfolio.

But no, AI did not decide anything that mattered.

Think of a building site. AI is the fastest bricklayer you have ever seen. It can lay a wall in minutes that would take a person a day. But a bricklayer does not decide where the walls go, how deep the foundation must be, or whether the building is safe to live in. The site engineer does, with drawings, measurements and inspections. On my projects, AI is the bricklayer. I am the site engineer.

I am not the only developer who thinks this way. In Stack Overflow's 2025 Developer Survey of more than 49,000 developers, 84 percent said they use or plan to use AI tools, but more of them distrust the accuracy of AI output (46 percent) than trust it (33 percent). The survey found that the most experienced developers are the most cautious, because they have seen how often AI can be confidently wrong.

In this post, I will show you exactly how I work with AI on real client projects, the six rules that keep me in control, and the real mistakes those rules caught. If you are a business owner, you will learn the questions to ask any developer who builds with AI. If you are a developer, you can steal my process.

Why "just ask AI to build it" goes wrong

There is a popular way of working with AI where you describe what you want, accept whatever comes back, and keep going until it looks right. People call it vibe coding. For a quick experiment, it can be fun. For a business website that people depend on, it is risky, for four reasons I have seen with my own eyes.

AI is confidently wrong. In my Africa Deep Tech Challenge project, a small AI model recommended chemical fungicides for a cassava disease caused by a virus. It sounded sure of itself. It was dangerously wrong. Code works the same way. AI can write something that looks perfect and quietly does the wrong thing.

AI forgets. Claude Code's own documentation says each session begins with a fresh context window. Close it, come back tomorrow, and it does not remember the decisions you made yesterday unless they are written down somewhere it reads.

AI drifts. Give it a big task and it may change things you never asked it to touch, or decide on its own to do things in a different order.

You can't maintain what you don't understand. If something breaks six months after launch and you never understood how the website works, you are stuck. So is your client.

None of this means AI is bad. It means AI needs a system around it. Here is mine.

Rule 1: Plan before any code exists

On every project, I write the plan before a single line of code is written. The plan lives in a few simple text files that sit at the top of the project folder:

• PLAN.md is the master blueprint. Every page, every section on each page, the order we will build things in, and a numbered list of steps. My portfolio rebuild had 18 steps from start to finish.

• DESIGN-SYSTEM.md is the rulebook for how things look. The exact colours, fonts, sizes and spacing. When the AI builds a button on page eight, it looks exactly like the button on page one, because both came from the same rules.

• COPY.md holds every word. On the French school website and my portfolio, the client or I approved the words before any page was built. AI is not allowed to invent marketing copy on the fly.

• CLAUDE.md holds the standing rules. This is a special file. Claude Code reads it automatically at the start of every session, so it never "forgets" the rules, even on a fresh day.

What goes in CLAUDE.md? The rules that must never be broken, no matter which step we are on. On the GEE Expert website, one of the first rules was "teach as you build": every change had to come with an explanation of what the code does and why, so I learned Next.js properly while building a real product. On the French school website, the rules said the copy must contain no em dashes or other phrasing that reads as AI generated. On my portfolio, the hard rules included the exact line length for paragraphs and the exact spacing between sections, because those are the details that quietly get dropped under time pressure.

Think of these files as the drawings on a building site. The bricklayer can be as fast as he likes, but he builds from the drawings, not from his imagination.

Rule 2: One step at a time, with a save point after each

I never ask AI to "build the website". I ask it to do one step from the plan, and nothing else.

Here is the loop I follow for every step:

1. Write the prompt for this step only. I plan and write each prompt with Claude as my thinking partner, using the plan files.
2. Run it in Claude Code. Claude Code does the actual work in the project.
3. Read the report. Every prompt ends by asking Claude Code to report back what it changed, what it checked and what it was unsure about.
4. Review it. I go through the report, and when something matters, the code itself, before agreeing to anything.
5. Commit. I save the finished step in Git, with a clear message describing what changed.
6. Only then, write the next prompt.

In a way, it is two AI tools checking each other, with me in the middle making the decisions.

The commit after every step is my favourite part. A commit is a save point, like in a video game. If the next step goes wrong, I can go back to the last good version in seconds. On my portfolio, that meant a recovery point roughly every twenty minutes of work. In Nigeria, where power can go off at any moment, that is not a small thing. The worst a sudden power cut could cost me was one step.

Small steps also make mistakes small. If the AI gets something wrong in a step that touched one section, the damage is limited to one section, and it is obvious where to look.

Rule 3: Every prompt asks for a report and sets a test

A vague prompt gets a vague result. My prompts are specific about three things: what to look at first, what "done" means, and what to tell me afterwards.

Here is a shortened version of the prompt I used when speeding up the GEE Expert website:

STEP 1. Diagnose before changing anything.


Find the homepage hero image. Report its file path, file size in KB, pixel dimensions and format, and the exact element that renders it. Tell me what you found before you edit.

STEP 6. Verify.


Run a production build. Confirm it succeeds and that no existing page has visually changed. Do not deploy.

Report back: the hero image before and after in KB, every
accessibility fix, and anything you could not do or were unsure about.

Notice three habits in there.

Diagnose before changing. The AI has to look and tell me what it found before it is allowed to touch anything. Many bad fixes come from confidently fixing the wrong problem.

A clear finish line. Each step has a test it must pass, which developers call acceptance criteria. For the image pipeline on my portfolio, the test was: "Confirm AVIF is smaller than WebP at every size. If it is not, stop, because something is misconfigured."

Ask what it was unsure about. This line matters more than it looks. It gives the AI permission to admit doubt instead of covering it up. Some of the most useful things Claude Code ever told me came from that one question.

I also learned to include decision rules, in the form "if this happens, do that, otherwise do this, and continue". On the GEE build, the AI sometimes stopped to ask questions I could have answered in advance, and each stop cost time. On my portfolio, I wrote the answers into the prompt. I only asked it to stop where the decision genuinely belonged to me.

Rule 4: Measure, don't trust

The most important rule. Whenever AI says something is done, I check the result myself, with numbers or with my own eyes. Here are real mistakes that this rule caught.

The image files that came out bigger. On the GEE Expert website, I asked for lighter, modern versions of every image. The first run produced AVIF files that were larger than the WebP files at every size, which is backwards. Because I asked for the actual file sizes in the report, the problem showed up immediately. One setting was wrong. We fixed it, and the main image on phones went from 287KB to 24KB. Had I trusted "done", every visitor would have downloaded the heavier file. I told the full story in my post on image optimisation.

The careful check I didn't ask for. During that same GEE Expert work, Claude Code opened all 202 generated image files to confirm their real sizes matched their names. It also refused to claim the pages looked unchanged, because it had no earlier screenshots to compare against. That is the behaviour you want: proof where it can measure, and honesty where it can't.

The links that previewed the wrong page. On the French school website, every page was telling WhatsApp and social media that it was the home page. So a shared link to the pricing page showed the home page preview. Nobody would ever report that bug. I only caught it by checking the live site's code directly, instead of trusting that it was fine. Embarrassingly, my own old portfolio had a similar fault from the day it launched: its preview address pointed to a placeholder, so every link I shared showed a broken preview card.

The setting I checked with the raw code. When we moved the French school website to its real domain, I didn't just look at the site in my browser, which can show an old saved copy. I fetched the raw code of the live page and confirmed the important settings pointed to the real domain.

The lesson in all four: AI is very good at doing work. It is your job to prove the work is right.

Rule 5: People make the judgment calls

AI can write code. It cannot decide what is true about your business, what your client actually wants, or which trade off is worth making. Those decisions stay with people.

Here is what that looked like in practice:

• The client chose the brand. Elizabeth, the founder of the French school, picked her logo direction and favicon from the options we prepared. AI helped make the options. People chose.

• I caught the AI drifting from the plan. During the GEE website build, Claude Code suggested building the service page template before the navigation bar and footer, which went against the order in PLAN.md. I noticed and corrected it. The plan exists precisely so I can see drift.

• I caught what was missing. One prompt for the GEE website About page left out the team photo the client wanted. I spotted the gap before it went live, and the prompt was revised and run again.

• I read the words. On the GEE website, I noticed the copy was full of em dashes, one of the most common signs of AI generated text, and asked for a site wide pass to make it sound human.

• I weighed the trade offs. On GEE website, the image pipeline was set to run on every deployment. The risk: if the image tool failed on the hosting company's computers, the whole deployment would fail. The alternative: run it on my own computer and save the results with the code, accepting that I must remember to run it for new images. I chose the second option, because a forgotten image is a small problem and a failed deployment is a big one. AI laid out the options. I made the call.

• I own the mistakes too. The main image at the top of the GEE website was generated with AI, and it is the weakest decision on that site. The tool did exactly what it was asked. The decision to ask was mine, and so is the responsibility. Since then, my rule is real photos of real work, lightly edited, and nothing more.

When something goes wrong on a project, "the AI did it" is never an acceptable answer. If I can't take responsibility for a decision, I shouldn't let AI make it.

Rule 6: Understand every line, and keep the keys

This rule has two halves.

Understand it. I never ship code I could not explain. That is why "teach as you build" was written into the rules on GEE Expert. Every time Claude Code made a change, it had to explain what the code does and how the pieces connect. My standard is simple: if a senior engineer asked me why any line is there, I should be able to defend it. If I can't, I go back and learn it before moving on. It makes every project slower at the start, and much faster forever after, because I actually know my own codebase.

Keep the keys. AI should never control the things that can hurt you most. For me, that means two things.

First, deployment. My portfolio and the GEE Expert website are deliberately not set to publish automatically every time code is saved to GitHub. I deploy them myself, with a command, when I am ready. Pushing code and publishing a website are two separate decisions, and I want a human making the second one. On my portfolio, the plan even said to confirm that the new version was actually live before touching the domain settings.

Second, ownership. On the French school project, the live website runs on a hosting account in the founder's own name, not mine. Her domain is hers. When I handed over, she received a written document explaining what she owns and how everything works. A client should never be trapped by their developer, and certainly not by their developer's AI tools.

That is what control really means. Not doing everything by hand, but making sure that every important decision, every key and every password stays with the right human.

Seven questions to ask any developer who builds with AI

If you are hiring someone to build your website or app, AI will almost certainly be involved. That is fine. What matters is whether they are in control of it. Ask these questions:

1. "Can I see your plan before you start building?" A good developer can show you, in writing, what will be built and in what order.
2. "How do you check that the AI's work is correct?" Listen for specific answers: tests, measurements, reviews, real devices. "It usually works" is not an answer.
3. "If I point at any part of my website, can you explain how it works?" If they can't explain it, they can't fix it when it breaks.
4. "How do you undo a mistake?" You want to hear about version control and save points, not "we'll figure it out".
5. "Who will own my domain, hosting and code?" The answer should be you, in your own name.
6. "Will you use real photos and real words from my business?" AI generated images and invented claims can quietly damage your credibility.
7. "What will I receive when the project ends?" A handover document that explains your accounts, your website and how to make simple changes is a sign of a developer who expects you to be independent.

The fastest bricklayer still needs an engineer

AI has changed how I work completely. Things that would have taken me weeks now take days. I built an offline AI system for farmers in a field I had never worked in, and I learned Next.js properly while building real client websites. None of that would have been possible for me a few years ago.

But speed is only valuable when it is pointed in the right direction. The plan points it. The small steps keep the mistakes small. The reports and tests catch the errors. The human judgment decides what is true and what matters. And understanding every line means I can stand behind my work long after the AI has closed its window.

So, did AI build my websites? AI laid the bricks. I drew the plans, checked every wall and signed off on the building. And I would happily walk any client through every room.

If you want a website built quickly with modern tools, but by someone who stays in full control and can explain every decision, send me an email at hello@chukwumaukaha.com or a message on WhatsApp. And if you are a developer who wants to compare notes on working with AI, my inbox is open to you too.