Are you building AI products but feeling lost in the endless noise of new frameworks, hype, and technical terms?
If you are a Software Engineer or Tech Lead and you are looking for a clear mental model to navigate the modern AI engineering stack, then this email is for you.
In today’s issue, I want to share the first part of a three-part series on the essential layers of AI engineering, based on the framework developed by author and researcher Chip Huyen. Today, we start at the very top.
Here is what else we are covering in this issue:
The Read-Only Memory: The incredible trajectory of Chip Huyen, from a small farming village in Vietnam to teaching Machine Learning at Stanford.
The Open Thread Club: Tackling presentation anxiety, and why imagining the audience naked completely fails in practice.
The Rendezvous: Key upcoming software events in Las Vegas, Madrid, and Geneva.
Before you continue, if you enjoy my work and would like to support the newsletter, I’d really appreciate it if you shared it with a fellow engineer:
💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky
Or simply forward this email to someone who might find it useful.
The Read-Only Memory
Today you learn a bit more about Chip Huyen, the author of the AI Engineering book (which I recommend without getting paid).
After high school, her three-day trip to Brunei turned into a three-year journey across Asia, Africa, and South America. To fund her travels, she wrote about the people she met and eventually published four books of stories in Vietnamese. During that time, she worked as a Bollywood extra, a casino hostess, and a street performer. Years later, after initially being rejected by Stanford, she reapplied, was admitted, and went on to teach Machine Learning Systems there.
But there is one detail about Chip that I find even more interesting in the spirit of your list.
When she shared her story at Stanford, she explained that she came from a small farming village in Vietnam, didn’t have internet at home until she reached university, and wasn’t even accepted by Stanford at first. Once there, she admitted she was afraid of public speaking because she thought her accent would make it hard for others to understand her. A public speaking course at Stanford helped her gain confidence and change that perception.
And there is a second, particularly lovely layer to this: when she started teaching Machine Learning Systems, she published the course materials and publicly asked other professionals to review the notes and provide feedback. The course eventually became the foundation for *Designing Machine Learning Systems*.
In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.
Would you like to suggest some? I hear you! 👇🏻
The Open Thread Club
On this occasion, a reader asked this:
For performing talks and presentations, does imagining people naked actually work to temper my nerves?
— Nervous Anonymous Presenter
I will confess here and now that: yes, I’ve tried this.
Only once. Why? It did not work for me.
Two tricks that actually work for me:
If I have a friend in the audience, I focus my talk on that person, and it really helps to temper.
Focus your view “into the void”. What does this mean? Avoid eye contact with people in the audience and, instead, keep your eyes in the blank spaces between the public attending to your talk. Like that, the public has the feeling you are keeping eye contact (which could be good), but you are not affected by their reactions.
Do you have any tricks? Share it!
This person is starting with making talks and presentations and asked this in the context of reading this👇🏻
In this space, we will address real dilemmas about architecture, technical friction, or leadership situations you send anonymously.
Instead of giving theoretical or dogmatic answers, I will respond honestly, sharing my own past mistakes in similar situations and the lessons I learned while trying to solve them.
You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻
The Rendezvous
The events of this week.
Are you going to re:Invent 2026 in Vegas (USA)? It will happen from November 30th to December 4th.
In Madrid (Spain), the Dev Fest 2026 will be held on November 27th.
In Geneva (Switzerland), from December 9th to 10th, the KCD Suisse Romande 2026 will run in English and French.
A radar of events about software engineering and technical leadership.
The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.
Do you own an event or summit? Drop me an email! 👇🏻
The A-Side
Today, we’re looking at the Application Development Layer (Product-First).
This is the layer where most of the user experience is built. The idea is pretty simple:
Get as much value as possible from existing foundation models using traditional software engineering, without changing the model itself.
Chip Huyen highlights three main areas here:
👉🏼 Systematic & Rigorous Evaluation
Evaluating probabilistic models is one of the hardest parts of building AI systems. A simple “looks good to me” approach doesn’t scale very far.
The goal is to move from informal vibe checks to automated and reproducible evaluation pipelines. One approach is AI-as-a-judge, where a more capable LLM evaluates the output of another model against a defined set of criteria.
If you want, I can treat this AI-as-a-judge approach in future editions. Write me in the comments!
👉🏼 Prompt Engineering & Context Management
This is where techniques like RAG (Retrieval-Augmented Generation) become useful.
Instead of expecting the model to know everything, we provide it with the relevant business context at runtime. For example, company policies or product documentation can be retrieved from a vector database and included in the prompt.
The idea is to give the model the facts it needs, when it needs them, rather than relying entirely on what it learned during training.
👉🏼 AI Interfaces & Control Logic
This is about everything around the model: how users interact with it, how we orchestrate agents, and how we constrain what the system can actually do.
That might mean using patterns such as Plan-and-Act, enforcing structured outputs with JSON schemas, or adding guardrails to deal with things like prompt injection, unsafe content, or unexpected model behaviour.
🧐 A real-world example
Imagine you’re building an enterprise customer support assistant.
You probably don’t need to train your own LLM. You can provide company policies and product information through RAG, evaluate the responses using an AI-as-a-judge approach, and constrain the output to a well-defined JSON schema that your application can safely consume.
That’s a lot of product value without touching the model weights.
☝🏼 The key takeaway
A huge amount of the practical value businesses are getting from AI today is being created in this layer.
And that’s an important point: you can build surprisingly capable AI products without ever training or fine-tuning a model.
So, what does this layer Application Layer actually look like at a glance?
Evaluation: Move beyond informal vibe checks towards automated, reproducible evaluation.
Context: Use RAG and retrieval systems to give models access to the information they need at runtime.
Control: Use guardrails, agent orchestration and structured outputs to make AI systems more predictable and useful.
But there’s a limit.
What happens when prompt engineering and RAG aren’t enough? What if you need the model to behave in a very specific way that simply doesn’t fit into the context you can provide?
That’s when we need to go one level deeper.
Next week, we’ll look at how we can adapt the “brains” of these models themselves.
As always, if you have thoughts, questions, or disagree with something I’ve written, drop me a reply or leave a comment. I read and reply to all of them.
Be safe,
Marcos


