Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets
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.
Why I Stopped Trusting the Word "Done"
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.
The Solo Developer AI Agent Workflow, in Five Steps
Here is the workflow, exactly as I run it on a normal night.
Step 1 — Write a brief a stranger could follow
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.
Step 2 — Build small, in one direction
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.
Step 3 — Verify against the live system, never the report
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:
- After a push, I fetch the remote tree and confirm the exact paths are present. A helper's success message is not evidence; the remote tree is.
- After a test run, I run the full suite — library tests and integration tests — because I once watched a builder report a green suite that had only run the easy half while dozens of integration tests were failing quietly underneath.
- After a content publish, I open the live URL and read the page, including the parts I did not write. A page that renders is not a page that is correct.
Each check takes minutes. Each skipped check has cost me hours. That arithmetic is why this step is non-negotiable, even on tired nights.
Step 4 — Ship in batches, on a schedule I control
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.
Step 5 — Log it, or it never happened
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.
The Green Test Suite That Wasn't
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.
Solo Developer AI Agent Workflow: The Verification Checklist
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:
- Remote truth: is the change actually present in the live system (remote tree, live URL, published page), confirmed by fetching it fresh?
- Full suite: did the complete test set run, including integration tests, not just the convenient subset?
- Scope check: did the change touch only what the brief asked for, with nothing extra smuggled in?
- Human read: have I personally read the final version — the page, the post, the diff — at least once, end to end?
- Reversibility: if this is wrong, can I undo it in minutes? If not, it ships smaller or not at all.
- Log entry: is it written down, with the date and the link, so future me can find it?
Six checks, a few minutes each. I have never regretted running them. I have regretted skipping every single one at least once.
What the Human Gate Is Actually For
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.
The Bottom Line
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.