Module 1: Genai In Production Vs A Notebook
4. The boundary with AI Engineering, said out loud
Description
Lesson 3 introduced extract-shipment-manifest-fields by name, and deliberately left a question open: what does "building" that function mean, in the context of this guide? The answer matters more than it seems, because this guide and the AI Engineering ecosystem — the one that precedes this one in NIEVA's graph — could, without this lesson, end up teaching the same thing twice, under different names. This lesson exists so that doesn't happen: it fixes, with a direct quote from the ecosystem's own design, exactly where this guide's work ends and AI Engineering's begins — and it does so in lesson 4, not at the guide's close, precisely so none of the following twenty-eight lessons is tempted to cross it without noticing.
Connection to the module
Lessons 1 through 3 built the context: what's inherited, why "it works" isn't "production-ready," and what the real problem is that motivates this guide. This lesson answers the question that context leaves open: if extract-shipment-manifest-fields is going to invoke a model, who decides what it tells the model? Lesson 5, immediately after, returns to concrete ground — the real inventory of what already exists in andes-cargo-infra/ — with this boundary already installed as a reading criterion for the rest of the guide.
Analogy: the restaurant's operations manual, not the recipe book
Go back to the restaurant from lesson 2. A restaurant that works needs two completely different documents, written by two different people, with two different skill sets. The recipe book — what ingredients go in each dish, in what order, with what technique — is written by someone who knows how to cook: a chef, with years of practice in flavor, texture, presentation. The operations manual — at what temperature each ingredient is refrigerated, how many servings the kitchen can produce per hour without quality dropping, what happens if a supplier doesn't deliver on time, how much each served dish costs and how it's billed — is written by someone completely different: whoever runs the restaurant as a business. Neither role needs the other's skills to do their own job well. An excellent operations manager doesn't need to know why a wine reduction works with red meat; an excellent chef doesn't need to know how a supply contract gets negotiated. This guide is the operations manual. AI Engineering is the recipe book. The prompt that makes extract-shipment-manifest-fields extract a manifest's fields well is the recipe — and this guide uses it, minimal and honest, without pretending to write it better than it needs to be.
The quote, verbatim, from the ecosystem's design
src/paths/aws-cloud-ecosystem/STRATEGY.md, the market research behind this entire ecosystem's design, fixes this guide's position in NIEVA's full graph with a sentence worth reading slowly:
"This fits with the ecosystem's position in the graph: it comes after AI Engineering. The learner arrives already knowing how to build AI systems. Here they learn to operate them on AWS."
And, further down, in the list of underlying reasons that justify the whole ecosystem's design:
"Continuity from AI Engineering: the learner arrives already knowing how to build AI systems. It doesn't repeat fundamentals: it teaches how to operate them."
Two sentences, the same idea repeated for precision, not by oversight: building and operating are two different skills, taught by two different ecosystems, in a specific order (BACKEND → AI ENGINEERING → AWS CLOUD). The AI Engineering ecosystem — which this design assumes complete, as a prerequisite, from its first lesson — has already taught you to write an effective prompt, to design a reasoning chain, what RAG is, what an agent is, how to evaluate a response's semantic quality. This guide takes that as given. It doesn't repeat it, doesn't simplify it, doesn't re-explain it with another example. It assumes it, exactly the way it assumes you already know what a Terraform resource is.
There's a third quote, from the same document, that explains why this distinction matters so much for the market, not just for this ecosystem's pedagogical structure:
"The talent shortage in production Gen AI development is severe. Engineers who can demonstrate they build, deploy, and operate real generative AI applications — not just talk about AI — are commanding significant market premiums."
The market gap this guide exists to fill isn't "knows how to use an LLM" — AI Engineering already covers that, and the market already has plenty of signal on that skill. The gap is "knows how to operate an LLM in production, with real budget, guardrails, and observability" — a different, scarce skill, and it's exactly what these eight lessons and the seven modules that follow build.
The boundary, in a table, with the exact module where it applies
| This guide DOES build | This guide does NOT build — it's AI Engineering |
|---|---|
The infrastructure that runs extract-shipment-manifest-fields (Lambda, IAM role, permissions) — M3 | The prompt that does the extraction itself — you already know how to do that |
| Bedrock's managed guardrail, declared as code — M4 | Advanced prompt engineering, application-level guardrail techniques |
| A custom guardrail as defense in depth (PII scrubber, schema validator) — M4 | RAG, knowledge bases, embeddings, semantic retrieval |
Least-privilege IAM for bedrock:InvokeModel — M3, M5 | Agents, function calling, multi-step reasoning orchestration |
| The cost-per-token model, the custom calculator — M2, M6 | Semantic quality evaluation of a response ("is this extraction good?") |
| The security gate and cost gate, extended to the new Terraform — M5, M6 | Application-level hallucination reduction techniques |
| SLI/SLO for an AI workload: escalation, latency, block rate — M7 | Fine-tuning, training, or tuning a custom model |
| The smoke test harness — comparison structure, not the quality metric — M7 | The semantic quality metric that harness would compare against in real production |
Notice the pattern in the left column: every item is a question about how the system runs in production — who can invoke it, how much it costs, what protects it, what observes it. Every item in the right column is a question about what you tell the model and how well it responds. That's the line, and it holds without exception through the rest of this guide.
Why this guide's prompt is minimal, and why that's intentional
When extract-shipment-manifest-fields shows up with real code, in M3 and M4, the prompt it uses to extract shipmentId/originCountry/destinationCountry/carrier/weightKg from free text is going to be short, direct, and — on purpose — not a piece of polished prompt engineering. You won't see few-shot techniques, reasoning chains, or an elaborate system-message structure. This isn't carelessness: it's the same discipline that carries the whole guide. If the prompt became the focus of a lesson, this guide would, without meaning to, be rewriting AI Engineering under a different name. The point of every lesson from here on is never what the system tells the model — it's how that call runs in production: under what role, under what guardrail, with what budget, observed with what metric.
This has a practical consequence worth anticipating: whenever a lesson in this guide brushes up against the temptation to go deeper into prompting, the correct response isn't to explain it better — it's to name it, and move on. You'll see that discipline applied, out loud, several times throughout this guide, starting with M7's own lesson 5 ("What an eval in production is, and why it isn't a unit test"), which draws this same boundary for quality evaluation.
What happens if this boundary gets crossed without noticing
It's worth naming the concrete risk, not just the abstract rule. If this guide went deep into prompt engineering, it would end up teaching a weaker version of what AI Engineering already teaches thoroughly — because this ecosystem's focus, deliberately, is somewhere else. And if AI Engineering, at some point in its own curriculum, started explaining how an aws_bedrock_guardrail gets declared in Terraform, it would end up teaching a weaker version of what this guide teaches thoroughly. Neither ecosystem wins by repeating the other with less depth — each wins by being the definitive source for its own half of the problem, and pointing precisely to the other guide when a question crosses the line. It's exactly the same "inherit without repeating" principle you already saw in lesson 1, applied backward in time, toward AI Engineering, instead of toward the seven AWS guides.
Common mistakes
Expecting M3/M4 to teach you how to write a better prompt (expectation mistake). What happens: someone arrives at M4 expecting a lesson on prompting techniques to improve the extraction. How to spot it: if your question after M4 is still "how do I get the model to extract the fields better?" How to fix it: that question is, literally, AI Engineering territory — the course this design assumes complete. This guide's M4 teaches what guardrail surrounds that call, not how to improve the call itself. If the answer to that question doesn't feel obvious given what you already know from AI Engineering, that's the exact signal that prerequisite isn't solid yet for you.
Thinking "doesn't build the prompt" means "doesn't care about extraction quality" (scope mistake). What happens: someone concludes this guide doesn't care whether extract-shipment-manifest-fields works well. How to spot it: if your summary is "this guide is pure DevOps, with no concern for whether the system does what it promises." How to fix it: M4.6 (output schema validator) and M7.6 (the smoke test harness) do verify that the output has the correct shape, with real, executed code. What this guide doesn't do is evaluate that output's semantic quality — did the model correctly grasp this specific text's nuance? — which is a different question, and one that is AI Engineering territory. Correct shape (this guide) and semantic quality (AI Engineering) are two different verification layers, both necessary, neither a substitute for the other.
Confusing "the prompt is minimal" with "the prompt doesn't matter" (rushed-reading mistake). What happens: someone reads that this guide's prompt is "minimal, not polished" and concludes any vague text would work just as well. How to spot it: if your conclusion is "so it doesn't matter what I tell the model." How to fix it: minimal doesn't mean careless — it means enough for Andes Cargo's real case, without the extra depth a production case with more semantic risk would demand, and without duplicating content another ecosystem already covers thoroughly. The prompt you'll see in M3/M4 does its job; it just isn't the object of study for any lesson.
Exercises
Exercise 1 — Classify five real questions into the correct column. Without looking at this lesson's table, classify each of these five questions as "this guide" or "AI Engineering": (a) which IAM role can invoke the model?; (b) how do I structure the prompt so the model ignores hidden instructions in the input text?; (c) how much does it cost to process ten thousand manifests a month?; (d) how do I measure whether the extraction captured the correct nuance of an ambiguous text?; (e) which managed guardrail blocks sensitive information before it leaves the model?
See solution
(a) This guide — M3/M5, least-privilege IAM. (b) AI Engineering — it's a prompt engineering technique aimed at resisting prompt injection at the application level, not infrastructure (note: this guide's M4 does declare the managed guardrail that detects prompt attacks, but structuring the prompt itself to resist them is the half that belongs to AI Engineering). (c) This guide — M2/M6, the cost-per-token model. (d) AI Engineering — semantic quality evaluation, explicitly out of scope for this guide (M7.5 names it without building it). (e) This guide — M4, the managed guardrail declared as code. If you classified at least four of five correctly, you have a clear grasp of this lesson's boundary.
Exercise 2 — Explain, using this lesson's analogy, why neither ecosystem "wins" by repeating the other. A colleague asks why this guide simply doesn't include a full prompt engineering module, "since it builds the whole system anyway." Answer them using the restaurant analogy's logic.
See solution
A complete answer sounds, roughly, like this: "Because a restaurant's operations manual and its recipe book solve different problems, written by people with different skills — stuffing the recipe book into the operations manual doesn't make the restaurant run better, it just makes the manual longer and less focused on what an operations manager actually needs to solve. If this guide added a prompt engineering module, it would end up teaching a shallower version of something AI Engineering already teaches thoroughly, with more time and more examples dedicated exclusively to it. The learner comes out better prepared having two deep, well-bounded sources than one shallow source trying to cover everything."
Exercise 3 — Predict what would happen if this guide didn't fix this boundary in lesson 4. Based on how lessons 1 through 3 are written, what concrete risk does the rest of this guide run if this boundary were only declared at M8, at the close?
See solution
The concrete risk is that, without the boundary fixed early, every lesson in modules M2 through M7 that mentions extract-shipment-manifest-fields would face the natural temptation to "complete the example" by going a bit deeper into the prompt, the extraction's structure, or how to improve the response's quality — each of those small drifts, added up across seven modules, would end up turning this guide into a diluted version of an AI Engineering course, exactly the outcome this ecosystem's design exists to prevent. Fixing the boundary in lesson 4, before a single line of M3 code exists, gives every following lesson an immediate cutoff criterion: if the question is about the prompt itself, name it and link out; if it's about how it runs in production, build it.
Summary and next step
In this lesson you fixed, with direct quotes from src/paths/aws-cloud-ecosystem/STRATEGY.md, the exact boundary between this guide and the AI Engineering ecosystem: this guide operates — infrastructure, guardrails, cost, observability —; AI Engineering builds — the prompt, RAG, agents, semantic evaluation. You saw the complete table of what belongs to each side, with the exact module where it applies in this guide, and why extract-shipment-manifest-fields's prompt, when it appears with real code, is going to be deliberately minimal, not polished.
Before moving on you should be able to: cite, from memory or close to it, STRATEGY.md's central sentence about why this guide "operates, doesn't repeat fundamentals"; classify a new question about extract-shipment-manifest-fields as "this guide" or "AI Engineering" without hesitating; and explain why a minimal prompt is a design decision, not a limitation.
Lesson 5 returns to executable ground: the real inventory of what already exists in andes-cargo-infra/, with awslocal events list-rules, lambda list-functions, and iam list-roles against the inherited infrastructure — the literal starting point the following seven modules build on.
Resources
src/paths/aws-cloud-ecosystem/STRATEGY.md— the full source of this lesson's three quotes: the position in the graph, the continuity from AI Engineering, and the talent-shortage finding in production-operated Gen AI.genai-on-aws-production-guide/DISENO.md, "What this guide teaches (and what it does NOT)" section — the full, module-by-module detail of the boundary this lesson summarizes.- The AI Engineering ecosystem (NIEVA) — the complete prerequisite this guide assumes, never re-explains: prompting, function calling, RAG, agents, semantic quality evaluation.