Engineering and IT
Engineers do not need convincing that Claude can write code. The useful questions are sharper: where does it accelerate a professional team without degrading review quality, and how does IT keep generated changes inside the same controls as human ones? This track answers both with Claude Code as the working surface.
Workflow patterns
Day-to-day development
The productive loop is explore, plan, implement, verify — with the plan reviewed before code gets written. A well-briefed task beats a vague one by the same margin here as everywhere else in this course:
The nightly sync job in jobs/inventory-sync retries failed batches
forever, flooding the log. Explore the job and its retry helper, then
propose a plan for capped retries with backoff before changing anything.
Constraints: no new dependencies; follow the existing logger patterns;
update the job's tests. Then implement, and run the project's own test
suite — not an ad-hoc script.
Start with small, bounded issues and review every diff. The engineer who reviews a generated change owns it exactly as if they had typed it — that framing, adopted early, prevents the quality drift teams fear.
Code review and documentation
Ask for risk-focused review against the repository's own standards: untested paths, failure modes, concurrency hazards, API-contract changes — "review this diff for what would page us at 2 a.m.," not "any comments?" Generated review is a second pair of eyes before human review, never a replacement for accountable peer review. The same grounding produces durable documentation: runbooks from real incident notes, API docs from the actual handlers, change summaries from the diff.
Legacy comprehension and onboarding
Point Claude Code at the subsystem nobody wants to touch and have it map entry points, dependencies, data flow, and operational risks. This is often the fastest documentation payback in the whole company — and the most important place for verification, because a plausible explanation of legacy behavior can be wrong in exactly the way that matters. Check the map against the code and a current maintainer before it becomes onboarding material.
MCP server development
Engineering also builds what other tracks consume: internal MCP servers exposing approved tools. Treat each tool like a public API — narrow capability, authenticated caller, validated inputs, authorization enforced server-side, consequential actions logged. The temptation is one broad query_database tool; the defensible design is get_open_orders_for_region with the guardrails in the server, not in the prompt.
Track lab
Choose one bounded task from your own systems:
- Explain and document a small subsystem
- Implement a low-risk change with tests
- Draft a runbook from approved operational sources
- Design one narrow internal MCP tool
Record the plan, changed files, checks run, unresolved risks, and the reviewer.
Security review
Treat generated code and commands as untrusted input until reviewed — the same posture as any external contribution. Protect secrets, dependency integrity, production access, customer data, and deployment controls. The line that matters most: never weaken a control to make a generated solution run. If the change needs credentials it should not have, the change is wrong, not the control.
Definition of done
The change is scoped, tested with the project's own standards, explainable by its reviewer in their own words, and owned by a qualified team member.