All videosCoding agents2:12

Specs, plans and checkpoints

Those conditions let us reject an implementation that satisfies only half the request.

Links containing ?t= open the video at a specific second.

Video summary

The ideas to retain

01

A request is not yet a contract

Human requests usually express intent rather than every invariant an autonomous run needs.

02

Persistent instructions and a task spec solve different problems

Agentic repositories can carry persistent guidance in AGENTS.md, CLAUDE.md, GEMINI.md, or equivalent mechanisms.

03

A plan is a hypothesis, not the authority for the task

Current coding agents expose planning as an explicit operating mode. The official Codex Plan Mode template allows non-mutating actions to gather evidence and asks for a decision-complete…

Key moments

Jump directly to a section

  1. From a request to a test
  2. A stable rule, a specific goal
  3. Dependencies determine the order
  4. The plan can be wrong
  5. Save evidence, not just notes
  6. The task requires the whole contract
Read the reviewed transcript

This video has no narration. This transcript reproduces its visible explanatory text, not an invented voice.

From a request to a test

“Add JSON” leaves the format and the previous behaviour undefined.

The contract specifies a valid object with --json and unchanged text without it.

Those conditions let us reject an implementation that satisfies only half the request.

A stable rule, a specific goal

Repository instructions say how to work: do not change the public API without permission.

The spec defines this task: add --json without breaking the existing output.

Checking off a plan item changes neither obligation.

Dependencies determine the order

Agree on the schema first. The parser and serializer can then proceed.

The parser is ready, but the serializer is missing. The end-to-end test remains blocked.

Only when both pieces are ready can the complete test run. Finishing one substep is not enough.

The plan can be wrong

The plan assumes changing the serializer is enough.

The test shows that the parser rejects --json before it reaches the serializer.

Revise the plan to address the cause. A working hypothesis is not evidence of success.

Save evidence, not just notes

The checkpoint stores revision A, completed tests and pending decisions.

A parser edit creates B. Dependent tests now need to run again.

On resume, reconcile reality with the checkpoint. A nearby PASS does not carry over automatically.

The task requires the whole contract

Valid JSON is one condition, not the whole task.

The previous output and the permitted scope must also be preserved.

Delivery requires all mandatory conditions together. One green substep is not enough.