Prompt engineering finally gets a build step

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-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 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 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 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.