AI-native engineering is the top of the pyramid, and it is a different discipline rather than one more rung of the same one. Everything below it changes how you write software. This changes what the software is. You are not using a model to build the product. The product uses a model, every time someone uses it.
One category sits here: AI-native software engineering. It covers model APIs, agents that take actions, retrieval over your own content (often called retrieval-augmented generation), embeddings, tool calling, memory, routing between models, evaluations, guardrails, observability, and a security surface that did not exist a few years ago.
You can work here without having climbed the rungs below. The pyramid puts it at the top because it asks the most engineering of you, not because it is where everyone else is headed.
What this rung is for
Products where a model is part of the running system. An assistant inside an application. An agent that reads a request and acts on it. Answers grounded in an organisation's own documents. A pipeline where one model drafts, another checks, and the system decides what to do with the result.
Who it suits
Engineers building product features on top of models, and teams who can name an owner for evaluation and an owner for security before the feature ships. It is usually a team building a capability into a product, rather than one person changing how they work.
How to tell you are on this rung
- Your software calls a model while it runs, not only while you write it.
- A model provider's outage is your outage.
- Someone has asked how you know the answers are good, and the answer was a demo.
The last one is common, and it is the sign that this rung's largest cost has not been paid yet.
What it costs you later
- Evaluation is ongoing work. The same input can produce different outputs, so a test that asserts an exact string does not hold. Knowing whether a change made answers better or worse needs a set of cases and a way to score them, kept current as the product changes. Without one, every release is judged on impressions.
- A dependency that moves under you. A model you rely on can change its behaviour or be withdrawn on someone else's schedule. With one provider and no fallback, their bad afternoon is yours. Decide before you need it whether the feature switches provider or degrades gracefully.
- Spend that scales with use. Each request has a price, so a popular feature is also an expensive one, and a prompt that quietly grew or a loop that retries is a bill rather than a slowdown.
- A new security surface. Content a model reads can carry instructions, and so can the description of a tool it is given. A connector runs with whatever permissions you grant it, because a protocol is not a sandbox. Be most careful with anything that can both read untrusted content and take consequential actions in the same session. The security section of MCP servers worth knowing when you build with AI goes further on tool servers.
- Explaining a wrong answer. When an answer is wrong, you need the input, what was retrieved, which model ran and what each tool returned. Without that record, a bad answer cannot be reproduced, let alone fixed.
Where it sits in the pyramid
Many people reach this rung from orchestration, because running several agents by hand teaches what an agent needs from the system around it: clear tools, scoped permissions and context it can trust. That experience transfers. The rest of the discipline, evaluation above all, has to be learned on its own terms.