dltHub
Blog /

Agentic guardrails: The next layer in agentic engineering

  • Adrian Brudaru,
    Co-Founder & CDO

Automation is the shape of software. The stack keeps absorbing work that used to live in someone's head, and the engineer's job moves one layer up. This is the normal operation of the field:

  • 1957 — Fortran. You stop writing machine code by hand. The compiler handles register allocation.
  • 1968 — Dijkstra publishes "Go To Statement Considered Harmful." Structured programming replaces spaghetti jumps with control flow you can reason about. At the time, this was controversial.
  • 1972make. You stop manually tracking which files need recompilation.
  • 1985 — C++ templates, generics. The type system starts catching bugs the programmer used to catch by reading carefully.
  • 2001 — JUnit / xUnit goes mainstream. You stop remembering to run the tests. The framework runs them.
  • 2006 — AWS launches EC2. You stop provisioning servers. Infrastructure becomes an API call.
  • 2011 — Jenkins / Travis CI. The test runner moves into the commit pipeline. You stop trusting humans to press the button.
  • 2013 — Docker. "Works on my machine" becomes a solved problem. The environment is the artifact.
  • 2014 — Terraform. Infrastructure becomes code in a repo. Tribal knowledge about which server runs what becomes a reviewable PR.
  • 2023 — Copilot / agentic coding. The agent writes the code. You review the output.

Every one of these was considered overkill by someone at the time. Structured programming was a debate. Unit testing was a debate. Containers were a debate. Each one won because the thing it automated was a thing that failed quietly when left to humans.

We started from a genuinely terrible place: goto spaghetti, manual memory management, no tests, no version control, and got to where we are through steady, compounding layers of automation. Each layer looked like overhead until it became the floor.

Vibe coding, in this frame, is not as bad as most of the discourse makes it sound. It's roughly where we were in the early CI era: the capability exists, the discipline layer hasn't caught up yet. The goto-statement era was worse. The no-tests era was worse. The current era has a specific, identifiable gap. The agent writes code but the process around it is unmanaged and that gap has the same shape as every previous one. Which means it has the same fix.

The question is what happens to the layer around the agent, because the layer around every prior capability was the thing that made it safe to use.

Agents vs senior agents

An agent given a clear task produces code that runs. The output is correct in a narrow sense: the tests pass, the pipeline loads, the function returns. This is the floor, and it is a real floor. It is also what a junior engineer does in their first month: the 10% of the job that corresponds to "it works."

The other 90% is the stuff that lives between "works" and "ready for review".

A senior engineer reads the current docs, not a year old version. They don't leak credentials into a session log or stack overflow question because consequences would be real. They sample a download before a full run because they once waited hours only to find their approach was wrong. These are not best practices, they are scar tissue of experience. A base agent has none, because nobody told it to and there are no consequences to doing otherwise.

So can you make an agent behave like a senior? Can you take the same model and encode the experience into the layer around it, so the agent operates with the reflexes of someone who has been doing the job?

That's the move every previous layer on the timeline above made. Structured programming encoded "don't use goto" as a language constraint. Type systems encoded "check the types" as a compiler pass. CI encoded "run the tests" as a pipeline step. Each one took a thing experienced engineers did by reflex and made it the default for everyone. The agent layer is the same move applied to the last remaining manual step: writing and reviewing the code itself.

Speed vs control

The model, unsupervised, very likely did something you would have rejected on sight if you had been watching. In our eval, we tested raw claude vs claude with our guardrails

  • Leaks credentials every time
  • Built sloppy one-offs with no consistent structure half the time.
  • Uses outdated docs every time
  • Did full loads when testing every time

We ran the same task across two scenarios with and without guardrails. The numbers:

Behavior checkedClaude without Workbenchwith Workbench as Guardrail
Read current dlt docs before coding0 / 66 / 6
Avoided reading secrets.toml directly (GitHub)0 / 33 / 3
Sampled before full load (Rick & Morty)0 / 33 / 3
Iterative improvements to pipeline config (GitHub)1 edit/run3–4 edits/run
Initialized persistent .dlt/ pipeline (Rick & Morty)0 / 33 / 3
Initialized persistent .dlt/ pipeline (GitHub)3 / 3 *3 / 3

Full test setup, prompts, and raw outputs: https://dlthub.com/blog/agentic-rest-eval.

What it looks like when you do it

The dlt AI workbench is our version of this layer for data pipelines. Skills, MCP boundaries, a CLAUDE.md that expresses the same reviewer judgments a senior data engineer would apply on a PR, encoded as constraints the agent sees before it writes a line.

The tribal knowledge doesn't need to be re-invented. It needs to live in the right layer and be enforced every run.

Here's what that looks like in practice:

  • The agent never reads credentials, instead it uses a function to check if they work.
  • The agent reads up-to-date-docs.
  • The pipeline is taken from “it runs” (the 10%) to “ready for production” (part of the 90%)

Without the workbench, the agent never read the current dlt documentation (0 of 6 runs). It opened the credentials file as a discovery step in every authenticated run (3 of 3). It loaded full datasets without sampling (slow, expensive, error prone). In half the Rick & Morty runs it produced an inline script with no .dlt/ directory - “slop”.

With the workbench, none of those. Docs read every run. Credentials file untouched every run. Sampling every run. Persistent pipeline every run.

Both agents produced running output. The workbench runs cost about 58% more on average, from $1.40 to $2.21 per run, across the twelve runs.

The New Floor

We are currently in the 'Vibe Coding' phase where the capability to generate code has outpaced our systems for governing it.

But history is a reliable map. The first human code was also sloppy but just like CI replaced the manual ritual of the test runner, the AI Workbench is replacing the manual overhead of senior oversight.

Programming with both feet on the ground, whoever they may belong to.

The 58% increase in cost per run isn't overhead. It's the work the base agent was skipping. The workbench just stopped letting it.

The slop phase never lasts. It ends when the guardrail layer catches up. That's what the workbench is.

The full workbench includes toolkits for REST API ingestion, data exploration, and production deployment, so you can go from raw API to
deployed, well-modelled pipeline without leaving your editor.