// about

Jason Newbury

The human-in-the-loop

If you've made it here, you've found one of the few parts of this site that's written primarily by a person. The rest is part of a working experiment: as we build things, AI handles the documentation and helps maintain this website, and given this low-risk scenario, I simply perform validation and some tweaks to ensure that it isn't AI slop.

Why This Work

These projects started as an experiment. I could see AI changing how software gets built, and reading about it wasn't enough. I needed real projects to find out where AI is genuinely useful, where it falls short, and what changes when you treat it as a collaborator rather than a tool.

These questions became the backbone of this work:

What can I automate and still verify? Not "AI magic": tasks with clear inputs, clear outputs and guardrails, where correctness is checked rather than assumed.

what I've found so farDocumentation, website copy, pipeline config, review findings: the common thread is that code can check each one. The rule that holds so far: models propose, code decides. A schema, a build check or an exact match on disk catches wrong output before it lands, and some jobs turned out to need no model at all.

Where does AI genuinely accelerate development? And where does it create new failure modes and new blind spots?

what I've found so farThe leverage is real: build the loop properly once and the next job is a prompt and a config entry. The failure modes are real too. AI rarely fails by crashing; it fails by trailing off, and it sounds finished when it isn't. So "done" is a checkable claim, and a fresh reviewer is told to refute the work, not assess it.

How do I stay in control without becoming a bottleneck? What does a safe, auditable workflow look like when multiple agents are involved?

what I've found so farGates, enforced in code rather than promised. I open and close every piece of work; the middle runs without me, with bounded retries and spend caps I set by hand. What reaches me is a decision, not a re-review: the work arrives checked, with its full trace, and nothing ships without my approval.

Fulltrace, the Data Dictionary and the CI/CD blueprint are all attempts to answer these questions in real code and real workflows.

The work isn't finished. It's a living record of how AI and humans build things together, and of making that collaboration reliable and genuinely useful.
the human-in-the-loop

What can be handed off, and what still needs me? Below is just one of the patterns I run: one piece of work, from the moment I initiate it to the moment it returns for my approval.

I open and close every cycle. The middle is delegated: planning, execution and the correction pass happen without me. Once complete, I choose to either ship or skip.

↺ how the loop gets enforced →
A loop of five steps. I hand off to plan, then execute, then review. Review branches: only if a gate fails does it reach correct, which returns to review, and the correction is taken at most once. When the review is complete, the loop returns to me. Plan, execute, review and correct all sit inside a handed-off zone; I sit outside it, and the loop both starts and ends with me. handed off only if a gate fails max 1x re-check In this pattern, nothing ships without me. Me Plan Execute Review Correct
Me Every open question, every review disposition, and the ship call. The AI never resolves an open fork on its own: it stops and asks.
Planning agent Invoked with a model route, not a model. Five layers of precedence pick it, from a UI override down to the stage default. Reasoning models by default.
Execution agent Tool-reliable models. A 429, a 5xx or a dropped connection restarts the stage on the next model in the route. A schema failure is rethrown, not papered over.
The step that decides Models propose, code decides. A deterministic verifier rejects incomplete work, and an opt-in challenger re-reads what passed and can only add caution, never clear a failure.
Fix agent Only when a gate fails. The fix stage runs its own route, Claude Sonnet 4.5 first with transport-only failover: a rejected proposal is final, so a weaker model never retries the same fix.

↺I hand off, then plan, execute and review run without me. Correction only when a gate fails. Nothing ships until the loop comes back to me.