How to use FalseGreen

Give the agent a Job it can actually finish.

Define what must be true. Keep the scope bounded. Let the coding agent choose how to get there.

FalseGreen works best when one consequential piece of software work has an agreed definition of done before implementation begins.

Start with the boundary

Bad Job. Good Job.

Bad Job

“Make our authentication system production-ready and verify it.”
  • Scope is undefined.
  • “Production-ready” is subjective.
  • Important regressions are unstated.
  • There is no objective stopping condition.
  • The coding agent can effectively invent what success means.
  • FalseGreen cannot responsibly turn “everything should be good” into universal correctness.

Good Job

“Change password-reset tokens so they expire after 30 minutes.”

Acceptance criteria

  • Expired tokens must be rejected.
  • Reused reset tokens must be rejected.
  • Existing active sessions must remain valid.
  • Existing reset links retain their previous policy.
  • Unrelated authentication behavior must not change.

That is a FalseGreen Job.

Why the good example works

A target the agent can reach—and evidence can judge.

Bounded

  • One consequential change.
  • Not the entire authentication system.
  • The scope has a meaningful edge.

Observable

  • The requirements can produce evidence.
  • There is a defensible ACCEPT condition.
  • Everyone can tell what success means.

Implementation-neutral

  • Says what must be true.
  • Avoids unnecessary implementation details.
  • Leaves the coding agent room to find the best solution.

Humans define the outcome. The coding agent retains implementation freedom. FalseGreen keeps the meaning of done fixed.

The practical rule

Write the outcome, not the patch.

Avoid

  • “Use Redis to fix this race condition.”
  • “Refactor this using pattern X.”
  • “Make this better.”
  • “Productionize this.”
  • “Verify the entire application.”
  • “Rewrite this subsystem cleanly.”

Prefer

  • “At most one allocation may succeed under concurrent requests.”
  • “Existing API behavior must remain unchanged.”
  • “The migration must preserve these invariants.”
  • “Expired credentials must always be rejected.”
  • “No unrelated behavior may change.”
  • “Files outside this subsystem should not require modification unless the agreed outcome justifies it.”

Bad

Use Redis to solve this race condition.

Better

Under concurrent requests, at most one allocation may succeed.

The second statement describes the required behavior without assuming the implementation. Genuine technical constraints can still be part of the requirement; the point is not to prescribe implementation by accident.

The Job lifecycle

What happens after you define done?

  1. 01

    Define

    • Humans agree what done means.
    • Identify scope, required behavior, important regressions, and evidence expectations.
  2. 02

    Freeze

    • FalseGreen freezes the acceptance boundary.
    • The coding agent cannot redefine success after seeing the result.
  3. 03

    Build

    • The coding agent investigates and implements.
    • It can form theories, change its approach, and choose how to solve the problem.
  4. 04

    Verify

    • FalseGreen independently verifies the exact result against the frozen definition of done.
    • Evidence—not agent confidence—determines what was established.
  5. 05

    Repair

    • Demonstrated deficiencies can go back to the coding agent.
    • The implementation may change. The target does not.
  6. 06

    Reverify

    • Same bounded Job. Same frozen definition of done.
    • New solution. Independent verification again.
  7. 07

    Result

    • ACCEPT
    • FAILED
    • INSUFFICIENT EVIDENCE

Why the loop matters

Why use the loop this way?

Less babysitting

  • Humans should not have to supervise every model decision.
  • The acceptance target exists outside the coding agent.

Better solutions

  • Independent evidence can falsify weak or overbroad theories.
  • The coding agent can repair or simplify without moving the target.

A real stopping condition

  • “The agent thinks it is done” is not the stopping rule.
  • ACCEPT means the evidence supports the frozen definition of done.

Independent result

  • The builder does not grade its own homework.
  • The result is bound to the source or artifact that was verified.

Failure becomes evidence

What happens when FalseGreen says no?

Theory A

Independent evidence falsifies it.

Theory B

A repair fixes one problem but exposes a regression.

Theory C

A narrower solution satisfies the frozen target.

ACCEPT

Evidence supports the agreed definition of done.

A failed verification is not merely a rejection. It can become evidence the coding agent uses to improve the bounded solution.

See this happen on a real Ada/SPARK compiler change →

Set a meaningful edge

How big should a FalseGreen Job be?

Large systems are fine. Large undefined Jobs are not.

Good size

  • One database migration
  • One authentication behavior
  • One billing or payment behavior
  • One infrastructure change
  • One consequential refactor
  • One compiler or runtime defect
  • One deployment or recovery path
  • One Rust / Anchor program change
  • One bounded subsystem invariant

Too broad

  • “Verify our database.”
  • “Make our platform secure.”
  • “Prove our application is correct.”
  • “Review everything the agent wrote.”
  • “Make the whole system production-ready.”

A large product can use FalseGreen. Decompose the work into bounded acceptance Jobs instead of representing the whole system as one vague universal-verification request.

Final check

Before you start a Job

  • One bounded consequential scope
  • An agreed outcome
  • Observable acceptance criteria
  • Important regressions identified
  • Important invariants identified where relevant
  • Enough implementation freedom for the coding agent
  • A result that can actually be judged
  • No hidden assumption that FalseGreen will certify the entire application

If you can answer those, you probably have a good FalseGreen Job.

One bounded consequential Job

Ready to define done?

Start a FalseGreen JobInstall FalseGreen