GuideIntermediate
Architecture For Ai Native Systems
Learn to design systems where an AI component (an LLM) is a first-class piece, and what changes in the architecture when that piece is non-deterministic, slow, expensive, and fails in new ways. The guide's core is that an LLM is not a normal function — you can't assert its exact output, it takes hundreds of milliseconds, it costs money per call, it hallucinates, and reading user data turns it into a trust boundary — and that the architecture must contain that non-determinism with a deterministic shell: evals as a quality gate, guardrails at the boundary, latency and cost budgets, fallback when the model goes down, and a data loop that improves the system over time. You work through Mercado, which adds semantic search, a support agent, recommendations, and a product-description generator for sellers. Everything is simulated and executed in Python with the LLM represented by a deterministic stub (no real API calls): you'll measure the savings of a cheap-first model cascade, run an eval-set that catches a regression, reject an invalid output at a guardrail, watch a fallback keep the system up when the model goes down, and block a model proposal that violates policy before it touches money or state. The capstone architects a complete AI feature inside Mercado.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Free
- access
Outcomes
What you'll be able to do
- Understand an LLM's probabilistic contract and why "it's just an API call" underestimates the redesign required
- Treat latency and cost as architectural constraints: budgets, model cascades, and response caching
- Use the eval-set as a quality gate that blocks a deploy when a prompt or model change drops the score
- Build guardrails that validate the model's input and output, and understand prompt injection as a trust-boundary problem
- Design against AI-specific failure modes (hallucination, a downed model, drift) with fallback and circuit breakers
- Apply the deterministic shell pattern: the model proposes, a rules system disposes before touching money or state
- Design the data loop of an AI system: observability, user feedback, and the prompt vs. RAG vs. fine-tune decision at the architecture level
- Architect a real AI feature end to end inside an existing system, with its budget, eval gate, guardrails, fallback, and deterministic shell
Before you start
What you need to bring
It's for you if...
- Backend devs and architects who need to add an AI feature to a production system without the LLM touching money or state directly
- Devs who already wired an LLM to an API call and are now facing latency, cost, or hallucinations with no design around it
- Teams that need to justify why an AI feature is safe to ship with architectural judgment, not just demos
- Anyone who wants to understand evals, guardrails, and fallback as architecture pieces before learning to build them in depth
Requirements and materials
- Basic Python (every simulation in this guide runs in Python with a simulated LLM, no real API keys)
- Having worked on the design or construction of a backend system
- No prior experience building RAG, agents, or fine-tuning models required
Content
The syllabus, module by module
Open any of them to see its lessons.
- Module introduction: what changes when a component is non-deterministic
- The probabilistic contract
- The LLM is a component, not the system
- It's not "just an API call"
- The probabilistic core and the deterministic shell
- How much non-determinism can a feature tolerate?
- The property sheet of an AI component
- Mini-project: place an AI feature into Mercado
- 1. Module introduction: latency and cost as architecture
- 2. The LLM is slow and costs per call
- 3. The latency and cost budget
- 4. The model cascade: cheap first, escalate only if needed
- 5. Cache: many queries repeat
- 6. Async and streaming: when the user can't wait
- 7. The cost-aware request path
- 8. Project: design the budget for a Mercado AI feature
- 1. Module introduction: the eval as a fitness function
- 2. Why you can't assert a probabilistic component
- 3. The eval-set and the score
- 4. The eval as a quality gate (fitness function)
- 5. Catching regressions when the prompt or model changes
- 6. The eval in CI: a gate on the deploy
- 7. Types of eval criterion
- 8. Project: build the eval gate for a Mercado AI feature
- Module introduction: failure modes and resilience for AI
- The new failure modes of an AI component
- Hallucination as a failure mode
- The model down, slow, or rate-limited
- Fallback and graceful degradation
- The circuit breaker over the model
- Drift: the silent degradation
- Project: make a Mercado AI feature resilient
- 1. Module introduction: the data and feedback loop
- 2. The flywheel: usage becomes a better system
- 3. Observability for AI: beyond the server log
- 4. The feedback loop as a design decision
- 5. Closing the loop: the feedback becomes the eval-set
- 6. Prompt vs RAG vs fine-tune as an architectural choice
- 7. Routing the feedback signal to the right lever
- 8. Project: build the data loop for a Mercado AI feature
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!