Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

Posted on Oct 31 • Originally published at rehmanahmad.com

I am a head teacher by day and a solo developer by night, and my solo developer AI agent workflow runs almost entirely while I am asleep or at school. AI agents draft my articles, patch my websites, and queue my content — and that sentence should terrify any solo builder, because when you are the only human in the loop, there is nobody else to catch the mistake. I learned that the hard way, more than once. The workflow below is the one I use now: agents do the building, and I do the verifying. That split is the whole system.

This is not a theory post. Every rule here exists because I broke the opposite rule and paid for it in public, in broken deploys, or in hours of quiet repair work at midnight.

The first lesson came from a deploy tool that told me everything was fine. A push helper reported "OK pushed," and I believed it. Days later, a routine check showed the remote repository did not contain the files at all — the helper had written to a wrong path, reported success, and moved on. Nothing had failed loudly. Nothing had failed at all, according to the tool. The work simply was not there.

That is the central danger of a solo developer AI agent workflow: agents report completion, not truth. A green checkmark means the step ran, not that the result landed where it should. A test command that passes can mean the tests ran, or it can mean only a comfortable subset ran. An agent that says "verified" may have verified its own output against its own assumptions, which is not verification at all.

So I changed one thing, and it changed everything: no agent verifies its own work. Verification is always a second, independent step — a different command, a different check, against the live system, not against the agent's memory of what it did. If the agent pushed a file, I check the remote tree. If the agent ran tests, I run the full suite. If the agent says a page is live, I open the live URL.

Here is the workflow, exactly as I run it on a normal night.

Before any agent touches a task, I write a short brief: the outcome in one sentence, the constraints (budget, scope, what not to touch), and the check that will prove it worked. The check matters most. "Publish the app page" is not a brief. "Publish the app page, then confirm the live URL returns the new content" is. If I cannot state the check, I am not ready to delegate the task — I am just hoping.

A good brief also names the boundaries. Mine include a hard zero-spend rule on automation: no paid service gets switched on by an agent, ever. I batch small pushes to save automation minutes, and I never let an agent start a new task to fix a failed one without me seeing the failure first.

Agents are brilliant at producing a lot of output quickly, and that is exactly the risk. A 500-line change at midnight is not progress; it is a haystack I will have to search at 1 a.m. when something breaks. So every task is scoped to the smallest change that is still useful: one page, one feature, one batch of related fixes. Big work gets cut into small, separately verifiable pieces, each with its own check.

I also keep one direction of travel per task. An agent fixing a bug does not also "improve" three nearby files. Scope creep from an agent looks like helpfulness, and it is how a clean fix turns into a broken deploy. Anything else it spots goes in the log for tomorrow, not into tonight's change.

This is the step most solo builders skip, and it is the entire article in one sentence. After the work, I verify against the real thing:

Each check takes minutes. Each skipped check has cost me hours. That arithmetic is why this step is non-negotiable, even on tired nights.

Solo shipping is a pacing problem as much as a technical one. I batch related changes into single deploys instead of firing off a deploy per fix, and I keep publishing on a schedule — a few posts a week, not a flood. Flooding helps nobody: readers cannot keep up, platforms get suspicious of bursts, and every extra publish is another chance for an unverified mistake to go live.

Scheduling also protects the human gate: work built at night gets reviewed in daylight before it goes public. Nothing in my system publishes itself straight from an agent's hands to the public internet.

Every completed task gets one line in a log: date, what shipped, where it lives. That log is how I avoid repeating topics, re-fixing fixed bugs, and re-approving work I already approved — and how I answer the only question that matters at month's end: what actually shipped? Agents forget. Logs do not.

Let me make the testing lesson concrete, because it is the one I see other solo builders repeat most. A builder on one of my projects reported a green test run and moved on. When I ran the suite independently, the picture was different: the builder had run only the library tests, while the integration tests — the ones that exercise the real user flows — were failing in large numbers. The report was honest as far as it went. It just did not go far enough.

The fix became a rule I now apply to every project: the definition of "tests pass" is written in the brief, and it means the full suite, every time, run by someone — or some step — other than the one that wrote the code. A partial run is reported as a partial run, never as a pass. If your agent tells you tests pass, ask one question: which tests? If the answer is vague, the suite has not passed yet.

The same logic applies to content. A draft that reads well is not a draft that is accurate. Links get clicked, facts get checked against the source, and every element the brief specified gets ticked off before anything is presented as finished.

Here is the checklist I run before anything ships, whether it is code, a page, or a post. Steal it wholesale — it is short on purpose:

Six checks, a few minutes each. I have never regretted running them. I have regretted skipping every single one at least once.

People hear "human in the loop" and picture a manager approving every line, which sounds like the opposite of automation. In a solo developer AI agent workflow, the human gate is narrower and more valuable than that. Agents handle volume: drafting, formatting, repetitive fixes, research, scheduling. I handle judgment: is this true, is this safe, is this mine to publish, does this match what I actually want to say?

That division is why I keep drafts as drafts until I have read them, why no post goes live on an agent's word alone, and why my publishing rule is simple: the agent proposes, I dispose. A one-word approval from me is enough to move — I do not want bureaucracy either — but that one word comes after I have looked, not before. Automation without a gate is not leverage; it is just faster mistakes.

There is a second, quieter benefit. Verifying a change teaches me what my agents did, so I can brief the next task better. Builders who fully hand off stop understanding their own systems, and then they cannot fix them when — not if — something goes wrong. The gate is how I stay the developer of my own projects instead of a bystander to them.

A solo developer AI agent workflow does not fail because the agents are bad. Mine are good — they let a teacher with a full-time job run a textbooks library, a software site, and a publishing schedule that would have been impossible alone a few years ago. You can see the results in the free Punjab textbooks library I keep at rehmanahmad.com/textbooks, and in the free, verified Windows software I publish at filecobra.com. The workflow fails when "done" stops meaning "verified."

So here is my bargain, and I recommend it to any solo builder: let agents do the building, keep the verifying for yourself, write the check into the brief before the work starts, and never accept a success message as evidence. Ship small, ship on a schedule, log everything, and keep one human gate between your agents and the public.