At the end of August 2026 I spoke at Platzi Conf in Bogotá — a fitting moment to write down how I think about teaching AI engineering, because by then I had already recorded several courses for Platzi and run a year of hands-on workshops across Latin America: Devin meetups, Build with AI events, vibeathons, and a game-building hackathon with Platzi and Cognition.
Between all of that, a pattern became clear: developers don't struggle with AI tools because of prompting. They struggle because they're missing the engineering layer underneath. That observation shapes how I design every course.
Practice first, theory where it belongs
My courses are built around working software from the first class. Not "here's what an API key is" — here's the first call, here's the response, now let's break it on purpose.
Three examples of how that plays out in the actual curricula:
- Claude API course (16 classes, dual track): every class exists in both Python (
fastapi+anthropic) and TypeScript (@anthropic-ai/sdk), because API concepts shouldn't be hostage to your language. Students build up from first calls through multi-turn conversations, streaming chatbots, image and PDF inputs, structured JSON outputs, tool use with a real agent loop (reason → act → observe), error handling and agent security, prompt caching for cost, and the Batch API — ending with a deployable project hub. - LLM API Configuration course: students build Otro-GPT, an assistant that answers text, understands images, and speaks — integrating OpenAI, Claude, and Gemini, unifying them behind the Vercel AI SDK, adding voice with ElevenLabs, and deploying to Vercel.
- AI Tools for Developers course: organized around the development lifecycle rather than the tools — planning (Perplexity, ChatGPT, Claude; technical plans with Claude Code, Cursor, Windsurf), preparation (Warp, DeepWiki for repo analysis), building (Supabase's AI Assistant, MCP connections, editor skills), review (Devin Review, Code Rabbit), and deployment (Vercel's MCP, one-click deploys with Kilo Code).
The layer beyond prompting
The thing nobody's course taught a few years ago — because the field hadn't settled — is that building on LLMs is mostly systems engineering with a probabilistic component inside. So that's what I teach:
- Context is a budget. The
messagesarray isn't magic; it's state you manage. Students learn token accounting, context windows, and why "just paste the whole conversation" degrades before it fails. - Structured output is a contract. Asking for JSON and getting parseable JSON are different problems. I make students handle the second one — validation, retries, schema enforcement — because that's what production looks like.
- Tool use is where agents begin. A model that can call functions becomes a component that acts. I teach the agent loop explicitly — reason, act, observe — and then immediately teach the failure modes: runaway loops, tools that lie, errors swallowed silently.
- Cost and latency are product requirements. Prompt caching and batch processing aren't optimizations to mention at the end; they decide whether a feature is viable.
And underneath all of it, the unglamorous truth I repeat constantly: software engineering fundamentals are the multiplier. Agents generate code faster than you can review it; the people who thrive are the ones whose fundamentals tell them what to check. Data flow, state ownership, API boundaries, security basics (never put a provider key in the client, ever) — the AI didn't make these obsolete. It made them the job.
The failure modes I design around
I won't invent student statistics, but I can tell you the problems I deliberately build exercises to surface — the ones I hit myself and see in every workshop:
- The plausible-but-wrong API. Models hallucinate method signatures confidently, especially for fast-moving libraries. The exercise isn't "notice it's wrong" — it's "build the habit of checking against docs and running the smallest possible thing first".
- The happy-path demo. An agent builds a feature that works once, in one direction, on the author's machine. Students learn to ask: what happens on the second request? On a closed connection? With an empty file?
- The silent security hole. Generated code routinely does the obviously-convenient thing — keys in frontend bundles, unvalidated input,
INSERTpolicies open to the world. Reviewing AI output for security is a curriculum topic, not an afterthought. - The delegation cliff. There's a moment where a student stops steering and starts accepting. The lesson I try to transfer: your job shifts from writing code to specifying, reviewing, and owning the output. If you can't explain what the agent just shipped, you didn't delegate — you abdicated.
How I structure the projects
A few curriculum-design rules that have held up well:
- Every class ends with running code. Not "the final project works" — every class. It keeps feedback loops short and makes the course forkable for different starting points.
- Two stacks, same concepts. Offering the Python and TypeScript versions side by side doubles the maintenance cost but kills the "the course isn't for my stack" problem — and quietly reinforces that the concepts are the content.
- Deploy or it didn't happen. Every course ends with something live. An app that runs locally teaches APIs; an app that's deployed teaches engineering.
- Show the tool failing. Live demos where the AI gets something wrong are the most valuable minutes of a workshop — that's where students see what supervision actually looks like.
What teaching this taught me
Designing exercises that make an agent's failure modes visible forced me to understand them far better than any solo project did. And it keeps sharpening the same question: what does good human oversight of autonomous coding actually require? For a course, the answer is habits and checklists. For the industry, I suspect it's a much deeper design problem — and that's exactly the direction I want to keep pushing.
If you're building or teaching in this space, I'd love to compare notes — the field moves too fast for any of us to figure out alone.