The First Build · Session 03 · Dates TBD
Plan the feature, test the system, verify the outcome
Ship AIPhoenix, ArizonaPress → to begin
The agent is only as reliable as the evidence it can see.
A confident answer is not evidence. A diff, a passing check, a browser journey, a database row, and a clean log are.
The product is live and its core data path works. Tonight the agent gets the context and evidence it needs to change that system without guessing.
Act one
Agentic engineering is not a longer prompt. It is a loop where the agent can act, see what happened, and revise against a finish line.
The magic is not any one step. It is the feedback between them and a definition of done that prevents endless motion.
One-shot prompting
Directed agent
The human still owns scope, tradeoffs, access, and the decision that the evidence is sufficient.
| The agent | You | |
|---|---|---|
| Plan | Propose files, steps, and risks | Approve scope and tradeoffs |
| Build | Implement the agreed slice | Answer product ambiguity |
| Check | Run the test gauntlet | Choose sufficient evidence |
| Access | Use granted tools | Control secrets and authority |
| Ship | Prepare a clean change | Own the release decision |
Autonomy is scoped authority, not permission to decide what the product should become.
Exercise: give the repository memory
Create project instructions from this repository
stack + architecture summarizedcommands copied from package.jsonsecurity rules and protected files nameddefinition of done written
Write durable project instructions from facts the agent can verify: architecture, conventions, commands, risk boundaries, and what must run before a change is complete.
Do not write flattering adjectives about the codebase. Write the facts a new agent would otherwise rediscover or get wrong.
Act two
Acceptance criteria say what the user can observe. Tests and checks make enough of that promise executable for the agent to steer by.
A failing check before the change proves the check can see the behavior. A passing check afterward then means something.
| Question | Evidence | |
|---|---|---|
| Types | Do the data shapes agree? | typecheck |
| Lint | Are there known unsafe or broken patterns? | lint |
| Build | Can production compile this? | production build |
| Unit | Does the rule behave at its boundaries? | focused test |
| Browser | Can a user complete the journey? | end-to-end check |
| Data | Did the correct outcome persist? | row inspection |
No single layer proves the whole feature. Choose the smallest stack that covers the actual risk.
Live build: let failure steer
typecheck → lint → test → build → browser
focused test failed before implementationagent implemented 5-file planall automated checks passedbrowser caught missing empty state — fixed
Start with one failing criterion. Let the agent implement and rerun checks. Then use the browser as a stranger and feed the first mismatch back as evidence, not as a guess about the cause.
A browser check catches the parts a green build cannot see: focus, copy, timing, empty states, and the actual sequence of actions.
Act three
The feature crosses browser, server, data, and deployment. Verification should cross the same surfaces.
Tests check claims about code. This chain checks the outcome the product created.
Persistence is useful inside a stable contract. When the contract changes, stop and make the new decision explicitly.
The reviewed checkpoint
review diff → verify live path → commit
unplanned dependency removedpermission case and empty state verifieddatabase defaults correct; logs cleanwrote 03-agentic/verification-log.md
Read the diff for unintended scope and security changes, perform the live journey once more, then record the commands and observations that justify the checkpoint.
Save the brief, plan, tests, verification log, and reviewed diff in 03-agentic/. The hackathon starts from this operating loop.
| Before | Now | |
|---|---|---|
| Context | Re-explained in every prompt | Repository instructions |
| Scope | A feature-sized wish | Criteria and a reviewed plan |
| Failure | A reason to try another prompt | Evidence that points to the next step |
| Done | The code looks right | The user outcome is verified |
This is the reusable method: plan, act, observe, revise, and stop when the agreed evidence passes.
Failure is a clue when the loop can see it.
Next
Bring the repository, one narrow problem, and the evidence loop. The capstone ends with a live product journey, a frozen deploy, and an honest account of what the agent got wrong.
shipai.club · Free, always