Developers are writing less and less code. A large part of their time is now spent on keeping the agents honest, instead.
Agentic development is on the cusp of transforming the software development world more than any evolution I’ve seen previously. I’ve watched agents produce in minutes what would have taken me days, or even weeks. The problem is, there’s still a huge gap between “the agent can write code” and “the agent writes code I’d actually ship.” That gap is where the guardrails live.
The Problem With Vibe Coding
Vibe coding had a moment there, but it seems like every vibe coder is rapidly discovering the problem that every engineer saw coming: you can’t vibe code your way out of a poorly architected mess. There’s no denying that vibe coding is great to start with! You rapidly produce code, you ship huge changes several times a day, and the feature count just keeps on climbing.
Three months later, however, you wonder where it all went wrong. You’re debugging a production issue at 2am, you discover that the agent generated a function with no error handling, no edge case coverage, and a subtle bug that only manifests under load. The code looked right. The problem is that nobody verified it was right, not even the agent.
The fundamental issue isn’t that agents inherently write bad code. LLMs produce the most statistically likely code. In practice that code is… average. Not amazing, not terrible, just average. Average is fine in isolation, but it quickly becomes a problem as the system becomes more complex. Without automated feedback loops, there’s no mechanism forcing them to improve their own work. An agent left to its own devices will happily produce code that passes a superficial smell test while skipping the hard parts. How many times have you seen an agent mark something critical as “out of scope”, or “for a follow-up issue”? How many times have they just mocked something that they couldn’t quickly figure out?
Guardrails Are Feedback Loops, Not Restrictions
In real life, guardrails aren’t just for safety, they give you more information about your environment. A guardrail tells you there’s probably something dangerous on the other side: you should pay attention. It’s not prescriptive about how you respond, it’s just telling you to be aware.
You give agents guardrails for much the same reason. They don’t inherently know things about your project, so you have to give them information, preferably in a form that can evolve over time. Agents won’t pause and ask a clarifying question when something feels off. They’ll just confidently produce something and move on. We need to force them to stop and check their work.
Coverage-Driven Agent Loops
Here’s an example from my own workflow. One useful guardrail I’ve found for agentic development is test coverage. Where historically it might’ve been a vanity metric on a dashboard, now it can be used to give a real-time feedback signal that agents can act on.
I recently built lcov-coverage-check, a GitHub Action that parses coverage files, enforces ratcheting thresholds. The idea is fairly simply: it enforces a ratchet mechanism where coverage can never go down. New files must meet a minimum threshold.
How it works isn’t the most important factor, though. What it does with that information is what really makes the difference. It posts a summary report directly to the PR, which an agent can read and act on. It sees which files need more testing, and can immediately act upon it.
Principles for Effective Guardrails
Coverage is just one example; over recent months I’ve found that there’s a clear pattern to providing useful guardrails for your agents. Here are the three principles that I’ve found to be most effective:
Objective. Pass or fail. Agents are probabilistic machines, so their response to subjective feedback like “this could be cleaner” is always going to be unpredictable. The more specific a signal you can give them, the better the outcome.
Ratcheting. Quality should only move in one direction. Coding agents will always skip something they decide is too hard; you need to stop that from happening.
Composable. It’s another example of the Swiss Cheese model. No single guardrail catches everything, some things will naturally slip through. Instead, you have multiple layers: type checking catches structural errors, linting enforces style consistency, test coverage ensures behavioural verification, and integration tests validate end-to-end flows. Each layer is simple, but together, they form an effective barrier.
Your New Job Description
Every “thought leader” with a LinkedIn account and a ChatGPT subscription is continually posting about how LLMs will replace developers. Funnily enough, they’re nearly right, but for entirely the wrong reasons. The coding part of the job is probably going away, but it’s been happening for a long time already. We didn’t stop creating machine code, we created compilers that do it for us. We didn’t stop creating JavaScript, we created transpilers that do it for us.
This is just the next step in the evolution. Instead of writing code, you need to design the constraints and feedback systems that produce good code. It’s a move up the abstraction ladder, not off it.
There’s more good news! Thriving in this brave new world is pretty straightforward: you don’t need to be the person who can write the cleverest prompt. Human language is inherently messy and unpredictable; computers are entirely logic-driven and predictable. To transform the former into the latter, you need useful feedback loops.
The best agentic workflows aren’t the ones with the smartest models. They’re the ones with the best guardrails.
Leave a Reply