The project
Use Agent Mode to implement a small UI behavior change with a reviewed plan, focused diff and device verification.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What an IDE coding agent does
Distinguish explanation, completion and multi-step workspace work. Apply the module decision to this project. Your checkpoint: You can choose an interaction mode based on the work required.
2. Project context and instructions
Create a task brief that guides a focused implementation. Apply the module decision to this project. Your checkpoint: The expected behavior can be verified independently of the generated patch.
3. Planning and implementing with Agent Mode
Keep multi-file work coherent and reviewable. Apply the module decision to this project. Your checkpoint: The implementation stays within the acceptance criteria and necessary supporting changes.
4. Debugging with evidence
Use the agent to form and test hypotheses. Apply the module decision to this project. Your checkpoint: The fix addresses a demonstrated cause rather than a coincidental symptom.
5. Testing and reviewing generated changes
Make verification independent from the implementation narrative. Apply the module decision to this project. Your checkpoint: Your evidence remains convincing without the agent’s claim that the work is complete.
6. A repeatable issue-to-review workflow
Produce a handoff another engineer can trust. Apply the module decision to this project. Your checkpoint: A reviewer can assess the patch without reading the agent conversation.
Acceptance criteria
- Define acceptance criteria before generation
- Review every changed file and dependency
- Demonstrate a regression test or device check that would fail before the change
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.