From Batch Processor to Photo Gallery, Part 3: Building with an AI Coding Assistant

Recap

In Part 2 the project grew from a batch processor into a gallery, with each addition recorded as a decision to include, reject or reshape.

The code for bip was written by an AI assistant. The engineering around the code was not left to it. That split turned out to be the most important thing we learned.

The AI writes; the process decides

An assistant can produce a lot of code very quickly. The danger is that speed makes it easy to skip the habits that make software trustworthy. So we did the opposite: we kept every habit we’d normally have, and applied them to every change.

Each change went through the same loop:

1. Build. The assistant makes the change against a specific item in the plan.
2. Static test. Before anything runs, simple automated checks look for obvious damage: a syntax check on the PHP and shell scripts, a check on the JavaScript, and a check that nothing was left unbalanced or half-edited. These checks are cheap and catch a surprising amount, including edits that had quietly removed a paragraph of documentation.
3. Dev deploy. The change goes onto a development copy and gets exercised by hand.
4. Clean dev deploy. The whole package goes onto a brand-new, empty site, exactly as a first-time user would receive it.

Why the clean deploy matters most

It’s the step people skip, and it’s the one that finds the interesting problems. On a site that’s been running for weeks, leftovers hide bugs: a folder that exists because an earlier version made it, a setting that was set by hand long ago. A clean deploy has none of that, so it tests the first-run experience the way a stranger would meet it.

Ours found a real one. A page that worked on the development copy printed a block of raw script text on a fresh install. The cause was subtle: a browser closes a script block the moment it sees a certain closing tag, even when that tag appears inside a code comment. We’d written a comment containing it. The fix was tiny and shipped as a hotfix, but nothing short of a clean deploy would have found it.

Checking the visible result, not just the code

Passing a syntax check says the code is well formed. It doesn’t say the page looks right. For anything visitors see, we also loaded the page in a real browser and looked at it, at desktop and phone widths, with both a full gallery and a nearly empty one. This is where the later refinements to the public index page came from. Seeing a real gallery on screen showed small things that no amount of reading code would have shown, such as how mixed portrait and landscape thumbnails line up. Those tweaks arrived during the release-candidate cycle, and each one went through the same loop as everything else.

Versioning as a habit

Every file touched in any change gets its version number bumped, however small the edit. That sounds fussy. In practice it means you can look at any file and know exactly which build it belongs to, and nothing gets quietly changed without a trail. The same version policy rolled up into the named release at the end, which we cover in Part 5.

What we didn’t trust the AI with

Judgement. Whether something belonged in the product, whether a risk was worth taking, whether a finding was real or a false alarm: those stayed with the human. The assistant was tireless and fast, and also happy to be wrong with total confidence. The process existed to catch that.

In short

The AI wrote the code, but build, static test, dev deploy and clean deploy decided whether it was good. The clean deploy is the one that finds what everything else misses.

Read next: The independent audit.