Build With Codex and Claude Code
Ship a small feature with tests, code review and a rollback plan.
Learn a disciplined AI-assisted software workflow from requirements and a small repository change to tests, review and a cautious release.
3–4 hours suggested practice · Free, written and self-paced · No certificate or video promised
Your learning outcomes
- Define an achievable feature
- Brief a coding agent safely
- Inspect code diffs and tests
- Check accessibility and quality
- Prepare release and rollback
0 of 5 activities checked
Completion checkmarks are stored only in this browser. Your answers are not uploaded.
Choose a tiny project
Small verifiable changes are the fastest way to learn engineering with agents.
Follow along
- Start with a sample project or a repository you own and can edit.
- Choose one feature: a reading-list checklist with local persistence.
- Write acceptance criteria for normal, empty and incorrect input.
- Set the scope: new branch only, no production changes, no secrets.
A concise, testable feature specification.
Copy and adapt this prompt
Act as a senior engineer helping a beginner. I want a reading-list checklist that can add an item, mark it done, and persist locally. Write a one-page specification with scope, acceptance criteria, edge cases, accessibility requirements, test cases and a list of files we should inspect before editing. Do not write code yet.A second person could decide whether the feature passes.
Remember: Avoid using a production repository or deploying on lesson one.
Inspect the codebase and plan
Before editing, understand existing conventions and where the change belongs.
Follow along
- In Codex or Claude Code, open the safe practice repository and check the active branch.
- Ask for a map of relevant components, data flow and existing tests.
- Request an implementation plan with risks and a minimal diff.
- Review proposed file edits before granting any write permission.
Repository map and file-level plan.
Copy and adapt this prompt
Inspect this practice repository in read-only mode. Find the entry point, related UI component, state handling, test setup and build command. Propose a minimal implementation plan and explain which files would change, why, and how to test. Do not modify files until I explicitly approve the plan.The proposed approach matches the project's actual stack.
Remember: AI-generated file paths and commands must be verified inside the real repository.
Build on a branch and run tests
An agent can generate code; shipping it is still a human engineering decision.
Follow along
- Create a feature branch and confirm a clean worktree.
- Implement only the approved acceptance criteria.
- Run the existing test suite and add tests for empty inputs and persistence.
- Inspect the diff for unrelated edits, dependency surprises and exposed secrets.
An inspectable patch and actual test report.
Copy and adapt this prompt
Implement the approved reading-list feature on the current feature branch only. Keep the diff minimal. Add tests for add, complete, empty-input and local-persistence behavior. Run the project's test and lint commands. Report exactly what ran, with pass/fail results and any limitations. Do not commit to main, install unknown dependencies, or deploy.Tests actually executed; their output and limitations are recorded.
Remember: A claimed successful test without tool output is not evidence.
Review UX, accessibility and security
Functional code may still be confusing, inaccessible, or unsafe.
Follow along
- Inspect the feature at phone and desktop widths.
- Use keyboard-only navigation and verify focus, labels and statuses.
- Test error, empty and refresh states using real browser behavior.
- Ask a second review pass to spot data exposure or unnecessarily complex logic.
A prioritized defect list, corrected patch and manual QA log.
Copy and adapt this prompt
Review the patch as a skeptical accessibility and security reviewer. Check focus visibility, labels, live updates, contrast, empty states, dependency changes, dangerous operations, and secret handling. List issues by severity and specific evidence. Do not claim browser tests unless they ran.No critical accessibility or security issue is knowingly left open.
Remember: Automated test passing does not substitute for real interaction testing.
Release only after approval
Finish with a deploy plan and a path back to safety.
Follow along
- Prepare a pull request with summary, screenshots, tests and unresolved risks.
- Verify deployment configuration, backups and rollback instructions.
- Request explicit approval before merging or publishing.
- After release, check the live feature and document issues for follow-up.
A release-ready review package with rollback steps.
Copy and adapt this prompt
Prepare a release checklist and PR description for this change. Include acceptance criteria, exact tests run, accessibility checks, changed files, remaining risks, release owner, rollback command or procedure, and post-release smoke tests. Do not merge or deploy.The release owner can confidently approve or reject it.
Remember: Never disclose API keys, disable guardrails or pretend a deployment happened.
Keep your work. Use it again.
Test the workflow on a second example before connecting accounts or automating. If you need feedback on a real project, bring your sanitized brief to a private working session.
All five activities checked. Revisit the quality gates on a fresh example to validate your work.
Product documentation and next steps
Tools and plan entitlements can change. Check your provider and workspace access before following interface instructions.
Existing AI Teachers resources: Agent to Outcome · All free written courses
Updated 2026-10-25. Paid group cohorts, certification, and live dates are not represented as currently available.