After the phases
A typical week
You learn fastest in short cycles of building, measuring, and adjusting. Do not spend a month on courses before you touch the system. Every week should leave the system more capable or more reliable.
Pick one capability in the first session
Pick one narrow result, such as "add trace propagation through SQS", "measure retrieval recall at 5", or "require approval before write tools". Before any agent starts, write the expected behaviour and the acceptance tests as a short spec.
Direct and check in the build sessions
Run agents in parallel, each in its own worktree, and let your spec and context files guide them. For anything architectural, ask for options and trade-offs before the agent writes code. Then check the result in this order: tests first, the riskiest parts of the diff second, and a real run third. You are training the skill of deciding what is safe to merge.
Add no features in the reliability session
Spend one session a week without adding features. Break the system, read traces, improve tests and evals, add a missing metric, simplify an interface, or reduce cost. This session keeps you from building an impressive demo that fails in production.
Record the evidence in the last session
Update the README or the architecture diagram, write a short decision record, record before and after metrics, and log any failure that should become an eval. If you had to tell an agent the same thing twice, add it to a context file or a skill.