Prompt engineering finally gets a build step

Google's developer blog proposed in July that system prompts should be treated like source code, composed from modules, transpiled, validated in CI, and shipped as versioned artifacts, joining Anthropic's Agent Skills and Microsoft's POML in a pattern of treating prompts as compiled artifacts. The post, written by a site reliability engineer, identifies three production failure modes—blast radius, copy-paste drift, and deferred runtime errors—and suggests using Jinja2 with StrictUndefined, a render script, and CI drift checks to build prompts. This marks the third major vendor in about a year to adopt a similar design, with Anthropic standardizing the module format and Microsoft the markup.

AI https://sourcefeed.dev/c/ai Article Prompt engineering finally gets a build step Google's transpilation pitch joins Anthropic's Agent Skills and Microsoft's POML in treating prompts as compiled, validated artifacts. Mariana Souza https://sourcefeed.dev/u/mariana souza Google's developer blog published a pitch in July that system prompts should be treated like source code: composed from modules, run through a transpiler, validated in CI, and shipped as versioned build artifacts. The author is a site reliability engineer, not a developer advocate, and the post reads like an incident retro. Its core line is blunt: "Prompts shouldn't just be edited, they should be built, validated, versioned, and deployed." On its own, that's one team's practice note. What makes it news is the pattern. This is the third major vendor in about a year to land on the same design, and they've each built a different third of it. The failure modes are real The Google post names three ways monolithic prompts die in production, and anyone running agents at scale will recognize all of them. First, blast radius: a 4,000-line instruction file where nobody can predict what a one-paragraph edit changes. Second, copy-paste drift: five teams duplicate the same safety policy into five prompts, then four of them miss the update. Third, deferred runtime errors: prompts assembled with ad-hoc string formatting fail only when a specific workflow finally exercises the broken interpolation, weeks after the bug shipped. The proposed fix is unglamorous, which is a point in its favor. Instructions get split into skill files, each owning one concern. A template layer with Jinja https://jinja.palletsprojects.com/ -style includes and macros composes them {% include "shared/safety.prompt.md" %} . A transpiler resolves the includes, rejects undefined variables and circular dependencies, and emits one deterministic final prompt. CI regenerates that artifact on every commit and fails the build if it no longer matches what's checked in, the same drift check teams already run on generated protobuf code or helm template output. None of this requires new tooling. Jinja2 with StrictUndefined , a 50-line render script, and two lines of CI get you the whole pipeline: python build prompts.py --out dist/ git diff --exit-code dist/ fail if the committed prompt drifted from its sources The underrated payoff is code review. When the compiled prompt is committed, every PR shows a diff of the exact text the model will receive. The blast radius question answers itself. Three vendors, one build system Google didn't invent this framing. DSPy https://dspy.ai/ has been arguing since 2023 that prompts are programs and hand-editing them is assembly-language work, though it goes further and generates the wording itself from declarative signatures. Microsoft's POML https://github.com/microsoft/poml attacks the format layer: HTML-like semantic tags for roles, examples, and data, a stylesheet system, and a templating engine, with a VS Code extension and SDKs for Python and Node. The most consequential piece came from Anthropic. Agent Skills https://agentskills.io/ started as a Claude feature in October 2025 and became an open specification that December: a folder, a Markdown file with YAML frontmatter, and a three-stage loading model. Agents see only skill names and descriptions at startup roughly a hundred tokens each , pull in the full instructions when a task matches, and read bundled files or scripts only during execution. VS Code, GitHub Copilot, Cursor, Gemini CLI, and Codex all adopted it within months. Put the pieces side by side and the division of labor is obvious. Anthropic standardized the module format. Microsoft standardized the markup. Google just described the compiler and the CI pipeline that should sit in front of both. Nobody is coordinating this, which is exactly why it's convincing. Three companies with different agent stacks hit the same wall and independently reinvented software engineering's oldest answer: once a text format starts carrying production traffic, it grows a build step. JavaScript got Babel; Kubernetes YAML got Helm. Prompts were never going to be the exception. There's a genuine tension between the two composition models, and the Google post resolves it the right way. Transpilation is static: everything is decided at build time. Progressive disclosure is dynamic: skills load at runtime based on the task. The post splits the difference by compiling a stable control plane identity, safety policy, tool contracts while task-specific skills stay lazily loaded. That's the correct boundary. The parts that must never vary get built and diffed; the parts that would waste context get deferred. What the compiler can't catch Now the pushback. A prompt transpiler catches structural bugs: the missing include, the typo'd variable. It cannot catch semantic regressions. The analogy to a type checker breaks down at exactly the point where it matters, because there is no static analysis for "this rewording made the agent stop escalating sev-1s." A prompt that compiles green can still behave worse than the one it replaced. So build-time validation without behavioral evals is a linter for a language nobody can parse. The build step earns its keep only when the compiled artifact feeds an eval suite, so that the same PR that shows you the text diff also shows you the pass-rate diff. Teams that adopt the transpiler and skip the evals will get tidy repositories and the same production surprises. The post's most provocative section gets this half right: agents proposing updates to their own skill files via pull requests, gated by human review. As a mechanism, it's the sane version of self-improving agents, since git history and review approvals beat opaque runtime self-modification. But the gate only works if reviewers can evaluate the change, which again means evals, not just eyeballs. Adopt it, sized to your problem My read: this is a genuine shift, not vendor content marketing, precisely because it's cheap and vendor-neutral. If you have one agent and a 200-line prompt, skip all of it; a single file you can read top to bottom is the better artifact. The moment you have two agents sharing a safety policy, or two teams editing one prompt, modularize and add the drift check. It's an afternoon of work. Write skill files against the Agent Skills spec while you're at it, since that format now travels across twenty-plus runtimes and hand-rolled equivalents don't. Prompt engineering spent three years as artisanal text editing. The tooling that ends that era looks like this: includes, a compiler, and a failing CI check. Sources & further reading 1. Building scalable AI agents with modular prompt transpilation https://developers.googleblog.com/building-scalable-ai-agents-with-modular-prompt-transpilation/ — developers.googleblog.com 2. Agent Skills specification https://agentskills.io/ — agentskills.io 3. POML: Prompt Orchestration Markup Language https://github.com/microsoft/poml — github.com 4. DSPy: Programming, not prompting, language models https://dspy.ai/ — dspy.ai Mariana Souza https://sourcefeed.dev/u/mariana souza · Senior Editor Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon. Discussion 7 ok so if prompts are compiled artifacts now, does that mean we need to start thinking about prompt dependency management the way we do with code deps? like, how do you handle when a model vendor updates their system behavior or deprecates a behavior you relied on in your compiled prompt? i'm skeptical that transpilation solves the actual problem though. most prompt drift i've seen comes from teams iterating on behavior without tracking why a change worked, not from people editing strings in prod. treating prompts as build artifacts is good discipline, but it doesn't replace having a mental model of what you're doing. feels like we're adding process overhead without fixing the reasoning gap. you're right that process doesn't replace understanding, but treating prompts as artifacts at least forces that documentation to exist somewhere. the real win isn't transpilation—it's that versioning and validation make it harder to ship behavioral changes without a paper trail. okay this is actually huge. treating prompts like real artifacts with versioning and validation feels like the obvious next step we all needed someone to actually do finally treating prompts like code instead of magic incantations. skeptical whether this actually catches the hallucination/inconsistency failures that matter, or just makes them reproducible. spent three weeks last month debugging a prompt drift issue in prod—turned out a single word change by someone on slack had cascaded through five different use cases. versioning and ci validation would've caught that in minutes. but you're right to be skeptical: the reproducibility just means you catch systematic failures faster. the random hallucinations still need guardrails elsewhere. oh man that's exactly what i'm worried about—like yeah catch the drift fast but still feels like we're building the cathedral before we know if the ground's stable