ForthAI
Agent-native development

Best practices for an agent-native development team

Our ever-evolving development playbook for AI-native development teams — humans spec and gate-keep, while AI agents carry every feature down one path.

Lifecycle

One path for every feature

Four stages, two human decisions, zero unverified merges. The path is the process.

01Spec

Converge the contract

one page3–8 criteriabehavior only

→ a contract awaiting your approval

Human gateapprove the contract
02Build

Build against the contract

red firsttests lockedindependent review

→ a PR with a criterion-to-test table

03Verify

Verify like a first user

fresh agentmocks offevidence per criterion

→ an evidence bundle on the issue

Human gateaccept the evidence
04Ship

Ship on evidence

≤5 plain checkshuman acceptsfeature probed live

→ a squash merge, a verified deploy, a closed issue

Human judgment

Exactly two human moments

Both are short, prepared decisions — not open-ended review. Throughput is capped by human decision latency, not agent speed, so judgment is concentrated where it is irreplaceable. Roles map to lenses, and nobody rubber-stamps a lens they do not own.

agents · specyouagents · build + verifyyouagents · ship
Moment one

Approve the contract

ProductDesignTechnical readiness
Moment two

Accept the evidence

Product acceptanceTechnical acceptance
Agent-native playbook

The best practices

Each one exists to enhance development productivity and LLM token efficiency.

01

Write the contract in the product owner's own words

One page, 3–8 observable criteria, mechanically linted — no engineerese drift.

02

Spec behavior, not technical detail

Every criterion is observable in the product; ids trace from contract to test to evidence.

03

Test-driven development

Every criterion gets a failing behavior test to guide development, before implementation exists.

04

Lock the tests once they are red

The implementation bends to the tests; unlocking takes a written reason and human approval.

05

The builder is never the verifier

The verifier gets the contract and a URL — never the diff, the source, or the builder's notes.

06

Evidence over claims

One fresh artifact per criterion, checked mechanically — a reused screenshot is fabricated evidence.

07

Keep humans on product judgment

At most five plain-language checks; if an agent could execute it, it is evidence, not acceptance.

08

Enforce with hooks, not prose

Rules that live in prose get ignored — merging, test edits, and authorship are blocked by hooks.

09

A green health check is not a live feature

Deploy verification probes for the feature itself, at the route where users will see it.

10

Codify each lesson once, at the cheapest layer

A recurring surprise becomes a rule, a check, or a hook — before it costs a second incident.

Enforcement

Hard gates, named honestly

Every guarantee is classified honestly — a hard gate, a tamper-evident deterrent, or documented residual trust. What a hook cannot physically block is named as trust, never assumed.

Hard gate — blocked by an exit codeTamper-evident — leaves an audit trailResidual trust — documented, never assumed
Pull requestSquash merge
Merge gate

Merging fails until independent evidence is posted and a human has accepted it.

Test lock

After the red checkpoint, locked test files cannot be edited — including through shell redirects.

Authorship gate

Commits carrying an AI co-author trailer are rejected; accountability stays with a human.

Stop gate

An agent cannot end its turn mid-build with failing checks — it passes, or it records blocked, honestly.

Evidence freshness

Evidence captured before the verification run started is rejected outright.

Everything inside the frame is blocked by an exit code, not a code of conduct.

The hard questions

Ask us what you'd ask any AI-written codebase

If you've evaluated AI-assisted engineering before, you already have objections. Good — so did we.

Q1

Don't agents just grade their own homework?

The verifier is a fresh agent that gets only the contract and a URL — never the diff, source, or builder's notes — and uses the product like its first real user.

Q2

What stops the implementation from gaming the tests?

Tests fail first and are locked before implementation begins; unlocking takes a written reason and human approval, recorded in the pull request.

Q3

“It works” — says who?

An artifact per criterion, captured during this run. Freshness is checked mechanically; a reused screenshot counts as fabricated evidence.

Q4

Who is accountable when it breaks?

A named human. Merges require human acceptance, AI co-author trailers are rejected, and every decision leaves an audit trail.

Q5

Doesn't all this ceremony slow you down?

It removes the slowest step — humans re-reviewing everything — and concentrates judgment into two short, prepared decisions while agents carry everything in between at agent speed.

Operating health

Watch two latencies

Two numbers tell you whether the lifecycle is healthy — not a dashboard of vanity metrics.

cycle time = t·human + t·agent

Human latency

How long contracts wait for approval and evidence waits for acceptance — the ceiling on throughput.

Agent latency

How long an approved contract takes to become verified evidence.

t·agent growing? Slices are too big — split harder.

Work with us

Make your engineering team AI-native

We embed with your engineering org, find the smallest win in your backlog, and prove it in production — on your stack. Then we scale it into how your team ships: the same engineers, ten times the throughput, every merge still accountable to a human.

Deliverable · your first feature shipped through the full lifecycle, in production