There Are No Best Practices For This Yet

The models you use were trained on decades of work done the hard way.

Ours.

Part one of the Stella series. Every screen is a live capture.

The gap nobody names

There are no best practices for agent-assisted development yet.

Not for what an agent may do to your repository. Not for who owns the work when it stops halfway. Not for what an unattended run owes you when it fails at three in the morning.

Nobody has written them down, because almost nobody has been here long enough to lose anything.

Four things that went wrong this month

Before any rule, the failures that produced it. All four are from a single month of real work.

A health check went green over an empty screen. The container was running. The load balancer agreed. The task reported HEALTHY. The cockpit served one line of text: Cannot GET /probes/workspace-shell/.

A clone landed on the wrong branch and reported success. The manifest named the branch. A function rebuilt its arguments as a five-key allowlist and branch was not one of them. Every deployment cloned the default branch — which held none of the work — and logged imported successfully.

A running machine was reported stopped. The portal resolved instances by looking up a service name. Finding none, it returned STOPPED for a machine that was running, healthy, and fully loaded.

A reaper measured runtime and called it idle. It stopped every task in the cluster at thirty minutes, mid-work, and told them they were idle.

Every one of those passed every test we had.

What they have in common

A step that cannot verify its own result reports success anyway.

That is the single pattern behind all four, and it is the thing agent development makes expensive. A human notices a blank screen. An automated pipeline files it under green and moves on.

The rules that came out of it

Everything hangs on one question, asked at the moment of action:

Will a person’s position be found here?

Not is somebody watching. A ghost sitting idle before its developer signs in will be stood in. A replicant is a seat you may step into after your laptop dies. Both are occupied.

If nobody will ever stand in it, the checkout has no history worth preserving and only its output matters. Reset it, own it, and log what was destroyed — because there was no witness.

From that:

• Never cross a branch boundary carrying uncommitted work. git checkout -B does not refuse when local changes do not conflict; it carries them, and the next reset --hard destroys them.
• Return a developer to where you found them. The mission branch is recoverable by name. A developer’s context is not.
• Log what you destroyed, not merely that you destroyed something.
• Never be the only place the work exists.

What Stella runs on

She is not a model with a personality. She is deterministic code that cannot guess, skills you can read and rewrite, and models that are first-class citizens — chosen, routed, limited, retried, monitored and costed like anything else in production.

Every prompt is a file. A hundred and sixteen of them, versioned and readable, none buried in code where you cannot reach it. Each one carries what it has cost.

And it audits itself. The template above is flagged for using 17,550 input tokens against a 4,000 target, priced at four cents a call, and offered a fix. That is a platform telling you its own prompt is too expensive.

None of that is a prompt.

Two ways to build, and they are not the same

Elsewhere, vibe coding means a prompt, a folder of code, and a hosting problem that is now yours.

This is not that.

Vibe here is the controlled path. You compose from capabilities, the scope is bounded before anything starts, and what comes out the other end is deployed rather than downloaded.

Six backends. Four databases. Five front ends. A hundred and twenty stacks before a single capability is added on top.

Then you choose how the work is done. Full rigor, where smart prompts guide each phase, a teacher builds the curriculum and a preacher enforces the gates. That is the part no model brings with it.

What is actually behind it

Not a template picker. Thirteen capability packages, each one a real pattern with its own reference implementation:

capability-database-postgresql · mysql · sqlite
spawn-crud            schema-driven CRUD from any database with foreign keys
sv-data-modeler       the model behind the schema
sv-ingestion-engine   documents in
sv-rag-companion      questions answered from them
sv-document-generator documents out
sv-workflow-engine    the process between
sv-compliance-engine  the posture around it
sv-ui-axioms          how it should look
sv-docker-compose     how it runs locally
sv-fleet-deploy       how it reaches production

Spawn CRUD is the one that surprises people. Point it at any database that has foreign keys and a published data dictionary, and it translates that into a working admin application. The schema is the specification. Nobody writes the forms.

Fleet Deploy is where it stops being a demo. A probe.json manifest, a deploy script, CloudFormation or Terraform for the infrastructure, S3 and CloudFront in front. The output of a Vibe is not a folder of code you now have to host. Fleet supports it as a deployed thing, with the database choice made deliberately rather than defaulted — local Postgres for development, RDS when it needs to be real.

An epic is the other path, and it is a different thing entirely. Vibe starts from a known composition and stays inside it. An epic starts from a description of a business, produces phases and work units and the questions nobody has answered yet, and coordinates several repositories at once. Vibe is bounded on purpose. An epic is bounded by what the work turns out to need.

Where the drama actually is

Several repositories, planned and built as one programme, with the controls around it.

Underneath, real GitHub. Each phase cut from the one before, so the pull requests are a stack. Merge the first with --delete-branch and it closes the rest. Nobody learns that from training data. You learn it by breaking it.

And a promotion through a gate that is not a calendar and not a review: an image built from that commit must boot a machine that comes up healthy and loads its repositories at the named commits.

The honest claim

Code generation is the easy half. Everybody has it.

The hard half is what happens when it goes wrong at three in the morning and nobody is watching.

Best practices for this will emerge. In a year. Maybe two.

We needed them in March.