You're designing the AI development infrastructure that an eight-person data analytics consultancy will use on every project: Aroha Mitchell, who founded Tūhura Analytics in Auckland, wants her team to stop losing the first two days of each project to ad-hoc setup and inconsistent tooling. There is no model to train and no dataset to ship. The infrastructure is the deliverable.
The discipline skills: deciding what gets encoded and in what form -- project memory, skills, or hooks -- and at what granularity, before the first line is written; tiering the investment by how durable each piece is, from open standards down to tool-specific features; designing connectivity by deciding what NOT to connect and reasoning about the total security surface; writing decomposition guidelines that hold up when an agent fails; designing a before/after benchmark that proves each component measurably improves AI output rather than just feeling better; and packaging all of it so a new hire can use it in a week across clients that span cloud and air-gapped contexts.
The AI-direction lesson: the environment you direct AI within is itself something you design, with the same evaluation discipline you've spent the track applying to ML systems. AI builds the thing that works in one session and stops -- a memory file that looks complete but is tool-locked, untested, and confidently wrong in places. A wrong rule degrades AI worse than no rule. AI also connects everything by default and delegates everything when asked to decompose. The judgments that matter here are restraint and proof: deciding what to leave out and showing the rest earns its place.
Your Role
AI development infrastructure architect. You design the architecture, AI builds the encoded artifacts against it, and you verify the whole thing holds: portable across security contexts, proven by benchmark, usable by a junior consultant without you.
This is the thinnest scaffolding in the track. You get a problem and a short requirements list -- nothing else. The only safety line is narrow: a senior consultant reachable on-demand for whether your before/after benchmark actually proves the infrastructure helps, who won't volunteer or hand you answers. The constraints Aroha cares about are not named for you; they surface through discovery in the Slack channel, or not at all. You supply the entire architecture. AI is a tool you actively manage, and the deeper move is that you are designing the environment that will shape how an entire team directs AI after you're gone.
What's New
Last time you designed the retrieval-production-and-monitoring capstone for Carlos at Peru's national epidemiology center -- an indexing pipeline over a living corpus, multi-tenant access control, monitoring that monitors itself, all owned against a symptoms-only client with only a narrow on-demand consultant on the access-control seam. The architect's stance carries forward. The terrain inverts: in every prior project the infrastructure served the ML work and the ML system was the deliverable. Here the infrastructure is the deliverable and there is no ML system at all.
What's genuinely new: a CLAUDE.md template an entire team uses, not a single project's file. A skills library refactored from your own accumulated work for cross-platform reuse. A durability model that decides where to invest. Connectivity defined by what you choose not to connect. Decomposition guidelines robust to agent failure. And a before/after benchmark that proves each piece works -- proof as a deliverable, not an appendix.
The hard part is that the strong moves here are restraint, not maximization, and infrastructure that "feels better" is exactly the failure Aroha is paying to avoid. What looks done and what is proven are not the same thing, and the gap stays hidden until you design the test for it.
Tools
- Claude Code -- directing, and the primary tool the infrastructure targets
- A second AI tool's documentation -- a portability test surface; you check whether your infrastructure makes sense outside Claude Code
- Python -- only as the substance of the skills and hook scripts you write
- Git/GitHub -- familiar; carried forward
- A vector store, MLflow, a database, cloud storage -- not deployed here; they appear only as connection targets you reason about, including when not to connect them
- Your accumulated skills directory -- the raw material you refactor into a portable library
No tool is introduced as a setup step. Every tool choice is an architecture decision you make and justify.
Materials
You receive:
- A sparse first-contact Slack thread from Aroha -- symptoms, not a brief
current-templates/-- Tūhura's outdated, inconsistent project templates: the "before" state you audit, replace, and later benchmark against- A reference ML task with a tiny dataset, used only as the fixed workload for the before/after benchmark -- not the deliverable
- A small project skeleton with an empty
CLAUDE.mdfor you to fill - Your own accumulated
skills/directory from prior projects
The architecture, the durability tiering, the benchmark design, the connectivity and decomposition guidelines, the portability handling, and all handoff documentation are yours to produce.