Building with AI · Part 6

A Builder, Not Just a Coder: Project Intake

Posted June 28, 2026

Until this month, aidd had a hidden assumption baked into every code path: every project it had ever seen was mine. Point it at a directory and it expected to find, or create, its own .aidd/ contract, its own conventions, its own gates. Fine for a personal fleet. Disqualifying for anything more. June was the month that assumption got surfaced, named, and converted into explicit machinery. It was also the month aidd's behavior toward my own repositories got the same treatment.

Ingestion is not migration

The design doc that drove the month settles the product's identity in two sentences: aidd is the builder and ingester. Spernakit is the strongest default target stack, not the only possible destination. It draws the line everything else hangs on - ingestion is not migration. Adopting an existing project means aidd learns and manages it. It analyzes the code, infers a profile, generates a feature inventory, runs audits, writes an intake report. Rewriting the project is a separate, later, explicitly-approved decision. The product promise, verbatim from the doc: not "aidd rewrites your app automatically," but "an audited, recipe-driven migration path with evidence, checkpoints, and validation."

The no-touch promise is not a prompt convention. Metadata-only runs get a write allowlist of exactly ['.aidd'], enforced by the orchestrator: it snapshots the worktree before each step and mechanically reverts any write outside the allowlist. Don't ask the model nicely. Make the violation impossible to keep.

The hole you can't design at a desk

The ingest lane got dogfooded on a real outside project the same day it was built, and the first real run found a hole in the guard within the hour. The guard watched the working tree. The agent committed a forbidden file and walked straight past a guard that only inspected uncommitted state. Catching only uncommitted writes was security theater. You cannot design that failure mode at a desk.

Same run, two more protocol gaps: runs whose entire legitimate output lived under a gitignored .aidd/ were being classified as "produced no result," and the interview step crashed on a fresh ingest instead of generating its questions file. Three findings, one hour, one honest test on a codebase the tool didn't grow up with. Being a stranger to your own tool is the cheapest security research there is. If I ever have to prove this tool in public, this is how I'll do it: make it work on things that aren't mine, and file what breaks.

Templates are config, not code

The second half of Intake generalized project creation. The old implementation was a hardcoded fresh-or-Spernakit switch. The new one is a template registry: any scaffold command can be registered, and a third-party template runs create-then-ingest - scaffold with someone else's starter, then immediately ingest whatever it produced. aidd doesn't need to understand the T3 stack or Laravel. It examines their output like any other foreign codebase.

This keeps Spernakit's privileged position honest instead of hardcoded: not "the template aidd supports," but the only template that arrives pre-contracted and pre-gated. The advisor that routes between the three lanes got one safety rule elevated above all others: a parse failure on a non-empty directory routes to ingest, never to fresh scaffold, because scaffolding over existing code is the one unrecoverable wrong default. And failed scaffolds became inspectable failure cards (view log, retry, dismiss) instead of silent half-projects on disk, per the design doc's failure-semantics rule: never a half-project the fleet doesn't know about, and never automatic deletion of a directory the user might want to inspect.

The git reset that made isolation non-negotiable

June 18, during routine verification, a dogfooded run performed a git reset against my live working tree and discarded an in-flight commit. Recovered with git merge --ff-only - commits are never truly gone - but the reaction I wrote down that night stands: an orchestrator with git powers needs the same isolation discipline we demand of its coding agents. Worktree isolation landed the very next day, and the timing was not a coincidence.

Every coding run can now execute in its own per-run git worktree on branch aidd/run-<id>. A clean run merges back (fast-forward preferred, gated on a clean live tree). A failed run gets discarded - free rollback. A conflicting merge parks as waiting_approval with its own exit code, optionally resolved by a write-guarded, merge-only AI resolver. Isolation is also what unlocks safe concurrency: multiple runs against one project, bounded by a per-project ceiling.

The same release added a cross-artifact consistency gate, complexity-tiered planning, and warn-only cost and token budgets (watch the numbers before letting them kill runs). All four share one shape, and it's the doctrine from last month's post again: put a mechanical check where a hope used to be. Healthy paranoia, encoded.

The quieter discipline

Three smaller June episodes belong here because they're what a trustworthy system is actually made of:

Killing your darlings. Penelope's Loom, an animated dashboard visualization that had won a four-way bake-off six days earlier, got deleted end to end. The bake-off answered "which visualization is best." Shipping answered "do we want one at all." Choosing the best version of something and choosing to keep it are different decisions.

Honest benchmarks. The benchmark harness learned real cost accounting, normalizing each backend's disjoint token buckets into one convention, because a backend whose cached tokens were double-counted elsewhere had been quietly winning composite scores it hadn't earned. Benchmarks are only as trustworthy as their worst normalization. (The corrected leaderboard produced my favorite pricing anecdote so far: the top composite score currently belongs to a stack costing $0.63 per suite, beating runs that cost four times more.)

The blocker-decision-implementation loop. Agents working the template hit three genuine product-decision points, the kind of ambiguity where guessing is malpractice. Instead of guessing, they filed written analyses and parked the features as waiting_approval. Two weeks later my decisions came back and got implemented in a day, including decoupling account lockout from session refresh so tripping someone's lockout can no longer kill their live sessions. That discipline is the difference between an autonomous coder and an autonomous liability.

As of today the platform surface from the design doc is substantially shipped: three-lane intake, the registry, the write guard, worktree isolation, re-intake, intake reports. aidd is a builder and an ingester, mechanically constrained, dogfooded on itself daily.

Which leaves the question I've been avoiding all month: what, exactly, is all this for? There's a commercial plan sitting in a drawer with my name on it, and every time I look at it I see a sales job where my life used to be. That conversation with myself is overdue. Soon.