Code with AI

You know how to build agents. This module is about building agents that are actually sophisticated — multi-model routing, MCP integrations, and architectures that handle complex multi-step tasks.

MCPs (Model Context Protocols) let agents reach beyond the chat window — reading files, calling APIs, or interacting with other software on behalf of the user. If you haven't worked with MCPs yet, this is where you start.

Exercise: The Power Agent

Build an agent that uses at least one MCP and handles a multi-step task. Then build a simpler version of the same agent (no MCP, single model) and compare.

1. Pick a task that naturally involves multiple steps — data retrieval, processing, and output.
2. Build the full version: MCP integration, multi-model routing if appropriate, multi-step handling.
3. Build the simple version: same task, single model, no MCP.
4. Test both with the same inputs. Document the difference — in quality, speed, reliability, and failure modes.

The platform is a controlled environment. CLI-based AI tools — like Claude Code or similar tools that let you use AI from the command line — give you programmatic access, local development, and integration options the browser can't match.

This module is about learning when to use which. The platform is better for some things. CLI tools are better for others. Knowing the boundary is the skill.

Exercise: First Flight

Pick a real task and complete it using a CLI-based AI tool. Then compare the experience to doing the same task on the platform.

1. Install a CLI AI tool if you haven't already (Claude Code, GitHub Copilot CLI, or similar).
2. Pick a task you'd normally do on the platform — code generation, data transformation, document analysis.
3. Complete it using the CLI tool.
4. Compare: speed, control, iteration ease, integration with your existing workflow.

Real tools connect to real data. This module is about building integrations that survive actual use — authentication, rate limits, error handling, and the reality that external data sources are unreliable.

Exercise: The Data Bridge

Before you start, check with your IT team about what data sources at your organization are approved for external use — integration work can involve data flows that haven't been explicitly reviewed yet.

Pick something concrete to connect to: organizational data exports, a public API, a document store like Google Drive or SharePoint, or an email integration. Then:

1. Build a working connection using Claude Code or your preferred tool. Handle authentication.
2. Test with real data. Verify what it retrieves. Verify what it can't retrieve.
3. Document: what connects, how it authenticates, what data it can access, what fails, and what the rate limits are.

This is the module where everything comes together. Scope a real project, build a working prototype, and use AI as your coding partner throughout.

Exercise: The Project

Build a working prototype that solves an actual problem at your organization. AI is your development partner — not just for generating code, but for architecture decisions, debugging, testing, and documentation.

Pick a real problem: a manual reporting process that could be a pipeline, a spreadsheet workflow that should be an app, two systems that should talk to each other but don't. Scope it tight — a prototype that does one thing well is worth more than an ambitious project that's half-finished. You can expand it in Module 5.

A prototype that works on your machine is not the same as something others can use reliably. This module is about the gap between "it works" and "it works for other people, in production, when things go wrong."

Exercise: The Stress Test

Take your prototype from Module 4 and break it systematically.

1. Identify the 3 most likely failure modes. Start with the obvious ones: empty or malformed input, API timeouts, expired authentication tokens, data that doesn't match the expected schema, very large inputs. Pick the ones most likely to affect your specific project.
2. Reproduce each failure. If you can't trigger it on demand, you can't fix it reliably.
3. Fix each one. Handle errors gracefully — the user should see a useful message, not a stack trace.
4. Verify the fixes. Run the same failure scenario again.
5. Write a "known limitations" doc. What still breaks? What would you need to fix next? What should users know?

The final module. Document what you built, think about what deployment would look like, and create a case study that teaches others what you learned.

Exercise: The Case Study

Write a case study covering:

1. What you built — the problem, the solution, the technical approach.
2. Why — what organizational need it addresses, who uses it, what impact it has.
3. How AI helped — where AI accelerated the work, where it didn't, what you'd use AI for again and what you'd do manually.
4. What you'd do differently — architecture decisions, tool choices, scope decisions, anything you'd change knowing what you know now.

This doesn't need to be polished marketing material. Technical honesty is more useful than a clean narrative. Include the parts that didn't work.