Check + Carry Forward

Before the quiz

You have read six sessions. Before the quiz, one question to see what stuck, not as a test, but as a mirror:

Quiz

Six questions from the guide. Tap an option to see whether you were right.

Quick check

Tap an option to see whether you were right. Wrong answers are fine; they show where a reread might help.

0 of 6 answered

1. 1.A listing says “ship faster with LLMs.” What does that most likely mean?

   Type faster with tab completionOrchestration and verification, not raw typing speedReplace engineers with autonomous agentsAlways use the newest model release

2. 2.In harness → agent → orchestrator, who is the orchestrator?

   The harness (CLI and file tools)The LLM provider APIYou, coordinating focused sessions toward one outcomeAGENTS.md

3. 3.Best first agent session on an unfamiliar refactor?

   Implement and open a PR in one chatPlan only: map deps and propose a plan, no edits yetSwitch LLM providers until code looks goodPaste the whole repo into chat for context

4. 4.An agent keeps running `pnpm test` at the repo root instead of the payment package. Best first fix?

   Expand README install stepsAdd a package-scoped test rule to agent rules (e.g. AGENTS.md)Type the same correction in every new chatSwitch to a different LLM provider

5. 5.A failing test is “fixed” by changing `expect(result).toEqual({ ok: false })` to `expect(result.ok).toBeDefined()`. CI is green. What happened?

   Good fix: CI passing means behavior is correctAssertion was weakened; production behavior may still be wrongThe harness ran the wrong commandExploration spike: no verification needed

6. 6.Five engineers repeat the same agent correction in chat. What team pattern helps most?

   Everyone picks their own harnessLonger personal chat preamblesPR-reviewed agent rules + CI on the right scopeBan agent-assisted PRs

The whole story: one task, six sessions

If you only remember one thread, remember this: the same payment-helper task walked through every session so abstract words had something concrete to attach to. Below is the arc in order, read it once, then use the table when you need a reminder of where an idea lived.

The listing said AI-native, harness, orchestrator. Session 1: likely the same engineering work, new workflow words, not necessarily a different career.

The comparison was autocomplete. Session 1: closer to a junior teammate you direct and verify: not faster typing alone.

The task: refactor a payment helper, add tests, open a pull request.

One long chat produced a scary diff. Session 2: plan → implement → review in separate sessions.

Monday’s correction was forgotten by Wednesday. Session 3: agent rules, layout, and skills so the repo teaches the next session.

Green CI on a weakened test. Session 4: verification levels and phase separation: plausible is not the same as correct.

Five engineers, same standup complaint. Session 5: shared rules, evidence in review, CI floor.

Session	The essence
1, Capability shift	Expectations changed; your judgment matters more, not less
2, Stack + first session	The model proposes; the harness acts; you coordinate
3, Teach the repo	Put repeated instructions where the next session finds them
4, Verify before merge	Match checking to risk
5, Team patterns	Good habits spread when they are written down and reviewed
6, Check + carry forward	Quiz, summary, practice at your pace

The point was never “AI wrote it.” The point is clear goals, clear boundaries, written rules, honest verification, shared habits. If something in that list still feels fuzzy, return to that session’s opening question, write a fresh answer, read the session again, and compare at the closing reflection.

When you are ready: one loop to try

Reading guides and noticing in your own work are different skills. The loop below connects all six sessions on one real task. You can take a week on it or an afternoon; the order matters more than the speed.

1. Run a plan-only first session (Session 2 brief).
2. Add one line to agent rules (Session 3).
3. Implement in a second session; verify at the right ladder rung (Session 4).
4. Write the verification note you would want as a reviewer.
5. If the team repeats a correction, name it once in standup (Session 5).

Quick reference

Keep this section for later, at work, in an interview, or when a listing uses unfamiliar words again.

When job listings use new words

Listing language	In plain terms, it often means…
“AI-native engineer”	An engineer who works well with AI-assisted tools, not a different career
“AI-assisted development”	Using an AI helper as part of your normal workflow
“Ship faster with LLMs”	Working in smaller, clearer steps, and checking the result carefully
“Agent workflows”	Breaking one goal into several focused sessions
“Harness / orchestrator”	The tools that run commands, and you coordinating the work
“Strong code review”	Checking AI output carefully, more important, not less
“Cursor / Claude / Copilot”	Product choices, useful, but secondary to how you work

A short repo check (about five minutes)

Question	A practical fix
Would a fresh AI session break something on day one?	Add agent rules (e.g. AGENTS.md)
Do you repeat the same instruction in chat every week?	Put it in agent rules or a skill
Might the AI run the wrong tests?	Fix CI scope and folder layout
Might plausible but wrong code get merged?	Session 4 verification + Session 5 team norms

Before you merge a change

□ Is this a throwaway experiment or production work?
□ Was every changed file intentional?
□ Do the tests actually exercise the change?
□ Did the work follow your repo’s agent rules?
□ Did you run what matters, or confirm CI did?
□ For risky areas: did someone try to break it on purpose?

Four small habits to try

On a real task:

1. Split the work: plan, implement, review, not one long chat.
2. Write one rule down: one line in agent rules you are tired of retyping.
3. Say what you checked: in notes or the pull request, list what you ran and what you did not check yet.
4. Reuse one workflow: install a skill such as review-changes instead of rewriting instructions.

When to return

If…	Reread…
Job listings confuse you again	Session 1 opening question + reflection
You repeat the same chat instruction	Session 3
CI is green but you feel unsure	Session 4
The team moves fast and breaks things	Session 5

Come back anytime a familiar instinct returns. That is not failure; it is the same idea with more experience behind it. Guides work best when they meet you after you have tried something, not only before.