AI for developers

Open My Learning →

1. 01 · AI guide

   Choose a surface and understand its commands ↗

   Separate an application's built-in controls from prompts and optional integrations.

   Put it to work

   Write down the application and surface you use. Verify one documented control in your own account; record unavailable features rather than guessing.

   Keep as evidence: A short list of available controls, with the application, surface, and documentation link.

2. 02 · Worked workflow

   Give the assistant a usable handoff ↗

   Describe the outcome, relevant files, constraints, and acceptance checks before asking for a change.

   Put it to work

   Pick a small issue in a repository you own. Write a handoff that names the permitted files and the command that will demonstrate success.

   Keep as evidence: A task brief another developer can follow without the conversation history.

   Practice in the browser

   Fix a priority bug →

3. 03 · AI guide

   Explore a coding tool deliberately ↗

   Identify which controls belong to the CLI and which depend on a different Codex surface.

   Put it to work

   Compare the guide's stated surface with your installed tool. Use only a documented command that is available there and record what it changes.

   Keep as evidence: One verified control and a note explaining its scope.

4. 04 · Worked workflow

   Close the verification loop ↗

   Treat generated changes as a hypothesis that needs a diff, checks, and review.

   Put it to work

   Make one bounded change. Inspect the diff, run the stated checks, and record one remaining uncertainty before accepting it.

   Keep as evidence: A small diff, check output, and a concise review note.

   Practice in the browser

   Review a logging change →Design retry tests →Automate release evidence →

5. 05 · Book chapter

   Understand the execution boundary ↗

   Connect approval to an exact action rather than a vague intention.

   Put it to work

   Describe an automated action using its target, arguments, identity, and expiry. Change one field and explain why the original approval should no longer cover it.

   Keep as evidence: An approval record and a worked example of an action it does not authorize.

Pause and check

Can you explain the boundary?

Choose an answer for every scenario, then check your reasoning. Progress is saved only in this browser.

1. A documented Codex CLI command is absent from another assistant's web menu. What should your guide say?

Treat the command as universal State the application and surface and check their documentation Invent a similar slash command

Explanation and further reading

A command belongs to a particular application and surface. A natural-language request can express an intent without being a built-in command.

Revisit the guide or chapter →

2. An assistant's patch passes the priority workshop. What evidence should you retain before accepting it?

Only the final green count The initial failure and diff and final checks plus remaining uncertainty The assistant's confidence score

Explanation and further reading

Tests check the stated contract. Reviewing the diff and recording what remains untested makes the change inspectable without overstating its coverage.

Revisit the guide or chapter →

3. An approved action changes its target resource before execution. Which response preserves the authorization boundary?

Reuse the old approval because the intent sounds similar Let the worker decide without a record Re-evaluate authorization against the exact changed action

Explanation and further reading

Approval must be bound to the exact action and its scope. A different target is a different action even when the original goal is unchanged.

Revisit the guide or chapter →

4. An assistant cannot reproduce an issue from a long conversation. What should the handoff contain?

The conversation length and confidence score The intended result, relevant files, constraints, and acceptance command Only a request to make the code better

Explanation and further reading

A reusable handoff makes the work inspectable outside the original conversation. Name the result and the evidence that will demonstrate it.

Revisit the guide or chapter →

5. A small fix appears to require editing an unrelated deployment policy. What is the useful next step?

Expand the edit silently Remove the acceptance test Explain the dependency and reassess the permitted scope

Explanation and further reading

An unexpected dependency changes the task boundary. Make that change explicit before proceeding with a broader modification.

Revisit the guide or chapter →

6. A priority sorter returns the right order but changes the caller's array. Has it satisfied the workshop contract?

Yes, because the visible order is right No, input ownership is part of the contract Only if the assistant says mutation is faster

Explanation and further reading

The priority exercise checks both ordering and preservation of the input. A correct output alone does not demonstrate the complete contract.

Revisit the guide or chapter →

7. A logging patch spreads the whole request into an event. Which review question is most useful?

Which fields are explicitly permitted by the event contract? Does the event contain as many fields as possible? Can the error message include the token for debugging?

Explanation and further reading

A field allowlist keeps future request properties outside the log by default. Useful evidence should not include arbitrary request data.

Revisit the guide or chapter →

8. A retry test sleeps for real seconds and sometimes fails on a busy machine. How can it become more deterministic?

Increase every delay indefinitely Inject the clock and waiting function and assert their calls Ignore timing assertions

Explanation and further reading

The retry workshop controls time through injected collaborators. It can inspect the intended delay sequence without relying on the wall clock.

Revisit the guide or chapter →

9. Your code matches the reference solution. What does that establish?

A production security certification That every possible input has been tested A useful comparison against a teaching example, with coverage limits still present

Explanation and further reading

A reference solution explains the exercise contract. Neither matching it nor passing its finite tests proves correctness for every deployment.

Revisit the guide or chapter →

10. The same files produce release manifests in different orders. Which change helps reproducibility?

Sort normalized entries deterministically before serializing Add a random identifier to every build Use whichever filesystem order arrives first

Explanation and further reading

A content-derived manifest needs stable ordering as well as stable values. The automation exercise checks equivalent inputs in different arrival orders.

Revisit the guide or chapter →

Your checklist is saved only on this device. Keep your own evidence alongside each exercise. Follow new guides →