learntodriveai.dev/Web Development/Designing AI Infrastructure as the Deliverable
Web Development·Project 18·6 units

Designing AI Infrastructure as the Deliverable

**Track:** Web Dev

§ Brief

You're designing the AI development environment for Groundswell Urban, a 28-person Toronto nonprofit building open-data tools for municipal green-infrastructure planning across 14 Ontario and Quebec partner cities. Six engineers — two of them contractors on six-month rotations — work three parallel development tracks against a platform that already runs.

The discipline skills: designing a project-memory layer without bloating context; writing path-scoped rules for tracks with different risk profiles; capturing recurring workflows as portable skills; designing hooks that fail closed against a regulated partner API; scoping MCP connectivity per track and refusing connections that don't earn their security cost; planning a context lifecycle triggered by events rather than the calendar; verifying the design works on day one for a new contractor and survives a tool change.

The AI-direction lesson: at the capstone, four columns of AI judgment merge into one. Every infrastructure decision crosses several at once — what to encode permanently, what to leave to per-session direction, when to delegate, when to connect, what should remain human reasoning. AI leans toward over-capture in memory, over-connection in MCP, over-specification in skills, and over-delegation of the architectural calls back to you. The register is supervisory at architectural scale: not directing AI per task, designing the environment AI will work in for the next several quarters.

Your Role

You're the AI infrastructure architect for a single engagement. Sarah Desrosiers, Director of Digital Programs, sends a voice memo with symptoms and priorities. The platform team keeps shipping. Your deliverable is the infrastructure itself — memory, skills, hooks, MCP connectivity, a lifecycle plan, and a handover packet.

The scaffolding has transferred to you. No brief names the architecture; you supply it. No work breakdown is handed down; you write one. No verification posture is provided; you design the scenarios.

The relationship with AI becomes durable rather than per-session. What was direction in earlier projects — constraint specification, scope discipline, verification expectations — becomes memory, rules, hooks, and skills that direct AI automatically before any contractor opens their first session. AI drafts the individual files; you hold the coherence across them.

What's New

Last time you inherited a three-year-old undocumented platform from a developer leaving in four weeks, curated her stale project memory, and fixed three known symptoms with the smallest surgical changes. The directing skill was restraint against AI's rewrite instinct.

This project is the opposite kind of work.

No platform to inherit and no production code to write. Groundswell already has both. The engagement's load-bearing artifact is the infrastructure itself.

Capstone judgment is integrated, not column-by-column. Connecting a database server scoped to one track is a connectivity decision, a context-cost decision, a delegation decision, and a memory decision at once. You make one assessment, not four.

Portability and maintenance are verified by scenario. You open your own infrastructure in a different AI agent and watch what transfers. You give it to a fresh AI session as if it were a new contractor on day one. If either scenario breaks down, the gap is in your design.

Tools

  • Claude Code as the primary environment the infrastructure is designed for, plus a second AI agent (Codex CLI, Cursor, or another MCP-aware tool) used briefly in Unit 5 for the portability scenario.
  • The CLAUDE.md / AGENTS.md pair as the project-memory layer — AGENTS.md as the durable cross-tool layer, CLAUDE.md as the Claude-Code-specific layer on top.
  • Path-scoped rule files for the three development tracks (public dashboard, municipal API, internal research pipeline).
  • SKILL.md format skills capturing daily workflows — partner report generation, municipal-API endpoint scaffolding, data-residency review.
  • Hooks at three boundaries — pre-commit, pre-merge to the municipal-API branch, pre-deploy on partner-facing surfaces. Fail-closed by design.
  • MCP server configuration scoped per development track, with refused connections documented.
  • The Groundswell platform as the operating context — Node.js and TypeScript, PostgreSQL with PostGIS, a Next.js public dashboard, internal data pipelines, the partner-facing API. You don't change it; the infrastructure has to serve it.
  • Git and GitHub for the infrastructure repository, with its own commit conventions.

Materials

  • Sarah's voice memo transcript (sarah-voice-memo.md) — four and a half minutes from her bike. She names the symptoms and three priorities. The three development tracks, the residency boundary, and the contractor-rotation cadence surface only when you ask.
  • The Groundswell platform reference (references/groundswell-platform.md) — stack, tracks, partner integration shape, residency surface, and an explicit out-of-scope list.
  • The AI infrastructure capstone reference set under references/ — pattern guides for CLAUDE.md / AGENTS.md, path-scoped rules, skill patterns and robustness, hook patterns (fail-closed semantics), MCP selective connectivity, context lifecycle, and the portability scenario.
  • Templates for the engagement-architecture document, the engagement-decisions log, the day-one and portability scenario worksheets, and the handover packet (orientation, operations, decisions, verification, lifecycle, glossary) — organised by the operations the next contractor will perform.
  • Infrastructure directory scaffolds under infrastructure-scaffolds/ — empty directories for memory/, skills/, hooks/, mcp/, and lifecycle/, each with a placeholder README. You copy this tree into your working repository as infrastructure/ at the start of Unit 2; the actual files are your deliverables.
  • Sample data under sample-data/ — a partner record and quarter context for the partner-report skill, an endpoint spec for the endpoint-scaffold skill, and two change specs for the residency-review skill (one clear crossing, one ambiguous case the skill must escalate).

No brief. No work breakdown. No platform to inherit. The voice memo is the input. The engagement architecture is your first deliverable. The four-layer infrastructure plus the lifecycle plan plus the handover packet is what you ship.