Writing down what I reject

I build my iOS prototypes with AI coding agents. They write most of the code. My part is closer to that of a demanding client.

The closest thing I had done before was site management, where I introduced standard procedures, checklists and inspection sign-offs across several client sites. Directing AI agents has needed the same habits: write the standard down, then inspect the work against it.

Two things kept going wrong. The agents had no taste they could defend, so they fell back on generic choices. And they brought back mistakes I had already corrected, because nothing carried my corrections from one session to the next.

So I started writing my rejections down. The first entry is about a capsule-shaped control placed inside another capsule, a detail that makes an interface look machine-made at a glance. It is recorded in my own Spanish, exactly as I said it: “el error básico de diseño que no me gusta, que es pill en pill… y lo acabas de hacer”. Roughly: the basic design mistake I don’t like, a pill inside a pill, and you’ve just done it.

There are now thirty-seven of these vetoes, and every agent reads them before it starts. Each one keeps my exact words, because a paraphrase drifts a little every time someone rewrites it. Under the words sits the rule in one sentence that can be tested, with a link to the reasoning. Some are about design, like no more than three tabs. Some are about process: “no quiero que hagas build en testflight hasta que te lo diga” means no agent sends a build to testers until I ask for one. A recent entry came from a screen that looked finished while some of its buttons weren’t wired up. Since then, a screen that looks right still fails review if a button does nothing.

Where a rule can be checked by a script, it is. I don’t trust a check until I’ve watched it fail, so the mistake is planted first and removed only after the check has caught it.

One rule is about the rules themselves. Every “never” has to state the failure it prevents or the way to get an exception. If it can’t, it is written as “prefer” instead. A strict rule that nobody explains gets worked around quietly, and the workaround turns into the next mistake.

The vetoes encode my taste for my own projects. They aren’t universal, and they change when I learn something. Still, an agent now starts each session knowing what I’ve already said no to.