AI Automation Lab

Overview

AI Automation Lab is where I design, test, and refine the workflows that let AI agents help build software without turning the codebase into a pile of clever guesses. It’s less about any single model and more about the operating procedure around it: scoped tasks, constraints, validation, and human review.

The throughline is simple and load-bearing: AI is acceleration, not architecture. The agent moves fast; I stay responsible for whether the system makes sense. I’ve written about the philosophy in AI-assisted development without losing the architecture — this page is about the practical lab behind it.

Why this lab exists

AI can move quickly. Speed without structure just relocates the work to cleanup later. The lab exists to make the fast path also the maintainable path:

• Architecture still matters — maybe more, because output arrives faster than you can eyeball it.
• Repeatable workflows reduce risk and make progress inspectable.
• Good prompts encode expectations, constraints, and acceptance criteria — they read like operating procedures, not magic spells.

The workflow problem

Working with agents has real failure modes, and pretending otherwise is how you get burned. Left unconstrained, an agent can:

• Overbuild — solve problems you didn’t ask it to.
• Blur scope — quietly expand the change until review gets hard.
• Generate plausible-but-wrong code that looks right and isn’t.
• Drift when context is inconsistent between steps.
• Make large messes from large tasks — blast radius scales with prompt size.

None of this is an argument against AI. It’s an argument for slicing and validation as the structure that keeps the speed worth having.

Slice-based development

The single biggest lever is scope. Work gets broken into small, well-defined slices, each handled end to end before the next begins:

1. Each slice has explicit acceptance criteria up front.
2. The agent executes one slice at a time.
3. Validation runs before any commit.
4. A clean slice gets committed and opened as a PR.
5. No proceeding to the next slice without review.

This very site is built that way — scope boundaries keep each step small enough to actually inspect. (The public version of that process lives in the repo’s slice-workflow notes; private repo specifics stay private.)

Architecture guardrails

Constraints are a feature. The ones that make agent work safe here:

• File-size limits — small files are easier for both humans and models to reason about, and a bad change is obvious in review.
• Clear component boundaries and data-driven components.
• Content collections for structured content instead of ad-hoc markup.
• No unnecessary dependencies; no client-side framework islands unless a slice truly justifies one.
• Static output compatibility preserved as a hard line.
• Docs treated as part of the architecture, not an afterthought.

These same instincts show up in my other builds — the validate-before-mutate discipline in NexusPort and the operate-the-consequences mindset from the private cloud lab.

Validation loops

Generated code is a proposal, not a fact — so the loop has to close on it. At a high level, each slice is checked by:

• Type/content checking (astro check) and a full production build.
• Rendered-output checks against the built site, not just the source.
• Internal link sweeps and metadata checks.
• A commit only after validation passes, with scope kept tight.

There’s also an execution-safety pattern baked in: all build tooling runs inside a hardened container, never directly on the host. Automation should reduce risk, not quietly introduce it.

If it isn’t validated, it isn’t done — it’s just plausible.

Human review and taste

This is the part that doesn’t get delegated. Models are good at patterns; people are good at taste:

• Style, product direction, security posture, and architecture boundaries are human-owned.
• Review is where overconfidence gets caught — the plausible-but-wrong slice dies here.
• Judgment is what turns generated output into a system someone can maintain.

The agent is a very fast, very eager collaborator. It still needs direction, and it still needs someone deciding what “good” means.

How I keep AI work reviewable

Everything above rolls up to one rule: a reviewer should never have to trust the agent — they should be able to check it. In practice that means every change arrives with the same four things:

• A small slice — one narrow goal per branch, so the diff tells a single story instead of ten.
• Acceptance criteria written first — “done” is a checklist agreed before the agent starts, not a feeling at the end.
• Validation already run — check and build pass and the rendered output has been looked at before anything is committed.
• A human pass on architecture and behavior — I read the diff for boundaries and intent, then actually run it and watch what it does.

If any one of those is missing, the work isn’t ready for review — it’s just a draft the agent feels good about.

What a good slice looks like

The slice is the unit of trust here, so it’s worth being concrete about what a good one actually contains:

• One narrow goal — a single behavior or change, describable in a sentence with no “and” in it.
• Known files and areas — the slice names where it expects to work, so an edit somewhere unexpected is a red flag, not a shrug.
• No broad rewrites — sweeping refactors are their own deliberate slices, never a free rider on a feature change.
• It passes check and build — type/content checks and a full production build are green, and the rendered page is inspected, not assumed.
• A clean commit and PR summary — the commit is scoped to just that slice, and the PR says what changed, how it was validated, and what was deliberately left out.

A slice that can’t be described this tightly is usually two slices wearing a trench coat.

Safety defaults

Speed is only worth it if the failure modes stay bounded. The non-negotiables the lab runs on:

• Docker-first execution — build tooling (check, build, the dev server) runs inside a hardened container, never directly on the host. The agent gets a sandbox, not the keys to the machine.
• No secrets in prompts — credentials never go into a prompt, a commit, or the repo. Public, build-time config (PUBLIC_*) is treated as public, because it is.
• No production access by default — the workflow operates on source and local builds; touching anything live is a separate, explicit, human-initiated step, not something an agent reaches for on its own.
• No silent destructive actions — nothing irreversible happens quietly. Risky operations are dry-run first, logged, and surfaced for a human, so there’s always a panic button within reach.

What the receipts add up to

The whole lab points at a single claim, and it’s deliberately not the hype one:

• The value isn’t “AI writes code.” Code is cheap now. The value is the architecture it fits into, the constraints it runs under, the validation it has to pass, and the review it can’t skip.
• I can use AI hard without giving up engineering judgment. The agent accelerates the typing; I still own the boundaries, the tradeoffs, and the call on whether a thing is actually any good.

That’s the whole lab in one line: let the agent move fast inside a fence I built, and keep the judgment human.

What I learned

• Prompts work best when they look like engineering specs, not wishes.
• Constraints are a feature — they make the output reviewable.
• Small slices beat giant prompts, every time.
• Validation is the trust boundary between “generated” and “accepted.”
• Documentation keeps the next agent from starting at zero.
• AI makes architecture more important, not less.

What’s next

Honest, directional next steps:

• Reusable slice templates and sharper agent checklists.
• Better rendered-output audit scripts.
• More project-specific steering docs.
• Safer automation around PR creation.
• Deeper, cleaner integration with development environments.
• Public, agent-friendly architecture examples that don’t expose private prompts.

If you’re building your own AI-assisted workflows — or want to compare notes on keeping agents on a leash — let’s talk or see the broader work.

Related writing

The companion essay, AI-Assisted Development Without Losing the Architecture, is the practical version of this lab’s philosophy. Building Weird Ideas Into Real Systems explains the broader pattern: scope the chaos, validate the work, and keep the fun alive.