Stage 06 / 30 minutes / Pairs or individual
Execute from the specifications
Use a coding agent to implement the accepted plan while preserving human control over scope, deviations and evidence.
- Output
- Build evidence and deviation log
- Support
- Checkpoint coaching
- Continue when
- All readiness checks pass
Repository for this lesson jhipster/jhipster-sample-app-react at 8c9d248 . All source links, commands and observations refer to this pinned revision.
Orient
Why this stage matters
Explain why execute from the specifications affects confidence in the build.
You can name the decision this stage supports and the risk created by skipping it.
This ties the stage to the lab’s central question: Does the evidence show that posting an operation and changing its account balance form one safe, reviewable outcome?
The agent can produce code quickly, but the team remains responsible for the contract, the diff and the meaning of test results. Discoveries must change an artifact before they change product behavior.
Inputs
Use repository sources and accepted artifacts
Identify the accepted evidence and artifacts required for this stage.
You can explain why each source is relevant and exclude material that does not affect the work.
These sources establish what the repository does when operation and balance records can be changed independently. Later claims and tests must trace back to this evidence.
Audited change and test specifications
These define the accepted behavior and evidence.
Implementation plan
Follow the approved order and stop conditions from stage 5.
Pinned repository
Work only from jhipster/jhipster-sample-app-react at source revision 8c9d248 and the prepared lab branch.
Repository verification
Use ./mvnw verify, ./npmw test and only the Cypress command accepted in the implementation plan.
Worked example
Request one planned increment and inspect the result
Study one worked example and identify the judgment behind each step.
You can reproduce the reasoning without copying the example’s conclusion.
The example models one part of the operation-and-balance problem. You apply the same reasoning to the remaining paths and produce evidence another engineer can review.
- Give the agent the claim, test specification, planned files and stop condition.
- Inspect the diff before running the focused test.
- Record a discovered assumption and pause the implementation.
A useful agent request points to accepted artifacts and a bounded step. It does not ask the agent to invent missing product behavior.
The worked example shows one request, diff review and deviation entry.
Decide
Stop when the repository reveals a new decision
Separate repository facts from decisions that require human authority.
Each question has an accepted answer or remains blocked with a named owner.
The repository cannot decide credit, debit, retry, ownership or mutation policy. Those decisions define what balance consistency means and what can be judged safe to ship.
- Does the diff implement only the selected claims?
- Did the agent introduce a product decision or new dependency?
- Do the tests observe the state named in the test specification?
- Does a discovery require a specification change?
- What evidence is strong enough to continue to the next increment?
Use the agent
Use the agent on this repository
Use the coding agent to support execute from the specifications while retaining control of decisions and evidence.
You verified each response before continuing and carried only accepted findings into the artifact.
Bounded prompts help investigate and build the balance change while human checks prevent unsupported agent output from entering the evidence chain.
These are task patterns for the pinned JHipster source, not answer scripts. Replace every bracketed field with accepted repository work. Open every cited path at the pinned revision and review each response before continuing. If you cannot supply a field, return to the earlier artifact.
Decide before prompting
- Select one approved plan increment.
- Set its files, test command and stop condition.
Add the focused test
A failing test demonstrates the gap before implementation changes it.
Implement the test portion of plan step [ID] only. Use claims [IDs] and these test-spec rows: [paste]. Change only [files]. Run [command]. Stop after reporting the expected failure and full command result.Read the test and confirm that it fails for the specified reason.
Make the smallest code change
A narrow change keeps the implementation comparable with its claim and test.
Implement the code portion of plan step [ID] only. Change only [files]. Make the smallest change required for the focused test. Do not add dependencies or extend product behavior. Run [focused command] and stop.Read the diff before accepting the passing result. Look for behavior outside the claim.
Run the increment checks
The focused test is necessary, but nearby regressions may require broader evidence.
Run the verification commands listed for plan step [ID]. Do not edit files. Return each exact command, exit status and relevant output. Distinguish new failures from recorded baseline failures.Confirm that the commands ran and that output was not summarized past a material failure.
Record deviations
Unexpected changes must become visible before another increment begins.
Compare the completed increment with plan step [ID]. List changed files, command results, assumptions and deviations. Cite the claim and test row satisfied by each change. Do not begin the next step.Accept, reverse or send every deviation back for a specification or plan decision.
Create
Produce the build evidence and deviation log for this repository
Create a reviewable build evidence and deviation log from accepted inputs.
The artifact contains every required field and stays within its stated limit.
This artifact records the evidence or decision the next stage needs to move the operation-and-balance change toward a supported release judgment.
- Run the focused test before changing behavior and record the result.
- Ask the coding agent to complete one planned increment.
- Inspect the diff against the claim, test specification and exclusions.
- Run the focused test and record the exact command and result.
- Repeat by increment. Stop when a discovery exceeds the accepted specification.
One entry for each increment and deviation.
- Plan step
- Agent request
- Files changed
- Diff decision
- Command
- Result
- Deviation
- Disposition
Challenge
Try to disprove the repository-backed work
Find a material weakness before the artifact controls later work.
Each challenge has evidence, an impact and a recorded response.
The challenge tests whether a partial write, duplicate effect, unauthorized operation or unsupported claim could survive the proposed artifact.
Select one changed behavior and verify that the claim, test, diff and recorded command result agree. If you are working alone, take a five-minute break before this review.
Required responseThe builders revise the code or artifact before starting another increment.
Revise
Use repository evidence before continuing
Resolve findings and make an explicit decision about readiness.
Every readiness check passes, or the work returns to the section that must change.
The gate prevents unresolved balance-consistency risks from flowing into code or supporting a stronger shipping claim than the evidence allows.
Ready to continue when
- Focused checks pass and their results are recorded.
- Success and failure leave the operation and balance consistent.
- Every deviation has an accepted disposition.
- The diff contains no unrelated generated-code changes.
If a check fails
- Revert or separate an unrelated change.
- Return to the affected artifact when a discovery changes behavior or evidence.
- Reduce the increment when the diff is too large to review against one claim.
Transfer
Apply the practice to your work
Map this practice to a real codebase, role and delivery decision in your work.
You can name the equivalent artifact, evidence, owner and next use in your team.
The lab succeeds when you can use the same evidence chain to judge an AI-assisted change in a production codebase, beyond this sample’s operation-and-balance problem.
- Name the artifacts you would include in an agent request on your team.
- Define one checkpoint at which a person must inspect the diff before the agent continues.
Record your answer. The lab is complete only when you can name the equivalent practice, artifact and evidence in your work.