Building Solo With AI

What actually worked, and what nearly cost me

I lead design teams for a living. For this project I had no team, just me and AI. I shipped a working product, hit a legal wall, pivoted the entire audience, and rebuilt it.

That is the headline. Here is the part people skip.

AI confidently told me things that were not true, wrote a report about work it never did, and deleted real data while testing. None of that showed up as an error message. All of it looked like progress.

The difference between AI making you fast and AI making you wrong is almost entirely about what you do after it hands you something.

---

1. Split the work by what each side is good at

The setup that worked:

• Architecture, decisions, documentation, review: one AI session with full project context. It holds the whole picture and catches contradictions
• Implementation: a separate coding agent working in the repository. It does the work and does not need the strategy
• Verification, commits, deploys: back to the first session. Nothing ships without independent review
• Judgment, direction, device testing: me. Only I can decide what the product should be

The key move is that the thing writing the code is not the thing approving it. When one session both implements and verifies, "I checked it and it is fine" is worth nothing.

---

2. A passing build proves nothing

This is the single most expensive lesson.

Real bugs I shipped, each of which passed every automated check:

• A security gate that used "or" instead of "and", so any logged-in session bypassed the PIN entirely. The wall was decorative
• Accessibility settings applied to an element the video player replaces at runtime, silently wiping every setting. Every control appeared to work. None did
• Two style rules with identical priority, where the wrong one won. The theme switch flipped and nothing changed
• A menu that rendered behind the navigation bar, so its options could not be tapped

Not one of these was visible in code review. Every one was obvious within ten seconds of driving the actual running app.

The rule I now follow: if a change touches security, permissions, or anything visual, someone drives the live product and confirms the behaviour. Not the build log. The behaviour.

---

3. Verify claims about what exists, including your own

The most insidious failure is not bad code. It is confident wrong facts.

I was told a whole feature had never been built. I repeated it. I re-prioritised around it. It had been built the entire time. It just looked old, so it read as missing.

"Not redesigned" is not the same as "not built." That one conflation cost me real decisions.

The discipline that fixes it: any claim about what exists gets checked before it is said. Open the file. Query the database. Look at the deployment. Conversation history is not evidence, and neither is your own earlier statement.

---

4. Assume the report might be fiction

Once, an agent produced a detailed report. Files changed, tests run, results tabulated. None of it existed. The working directory was untouched.

I only caught it because I checked the repository instead of reading the summary.

Trust the artifact, not the account of the artifact. Files, database rows, deployment logs. Those are real. A description of work is a story about work.

---

5. Write the guard rails down, with the reason attached

An agent deleted a real profile, with its videos and history, while testing a delete function. It was following my instructions. My instructions were the problem. I had asked for behavioural verification without saying "never against real data."

Now the project has a standing instructions file the AI reads at the start of every session. The rules that stick are the ones with the incident attached:

"Never run destructive tests against production data. A real profile was destroyed this way once, do not repeat it."

"Be careful with data" gets rationalised away. "This exact thing happened" does not.

Other rules worth having:

• Never authenticate as me. No passwords, no stored credentials
• Commit nothing, deploy nothing. Leave work for review
• Preserve what works. Extend rather than rewrite
• If you could not verify something, say so plainly

---

6. Let it disagree with you

The best moment in the whole project: I gave the AI a task built on a premise. Instead of building, it went and checked, came back and said the premise was wrong, and showed me the file that proved it.

It was right. I would have wasted a day.

The same session later refused to write "passed" next to tests it could not run, and refused to click a delete button on my real account after the earlier incident.

An AI that pushes back is more valuable than one that agrees. If yours never does, your prompts are probably asking for compliance rather than judgment.

---

7. Do not overstate what the AI did

I built this. AI made it possible to move at a pace that would normally need a team, and it caught things I would have missed. It also made confident mistakes that only a human paying attention would catch.

Both things are true. "AI-built" is a worse story than the real one, which is that a designer with no engineering team shipped, hit a wall, pivoted an entire audience, and rebuilt, in weeks.

The leverage is real. The judgment still has to be yours.

---

The short version

1. Separate who builds from who verifies
2. A passing build proves nothing. Drive the real thing
3. Check claims about what exists before repeating them
4. Trust artifacts, not reports about artifacts
5. Write guard rails down, with the incident attached
6. Reward disagreement
7. Be honest about who did what

---

I am Aneil Razvi, a product design and AI experience leader. Cubby, my personal project, is a caregiver-curated video app for teens and adults with autism and intellectual disabilities.

Available for fractional design leadership and advisory work.