We want our coding agents to be reliable and cheap. By "reliable", I mean that we get what we want out of them without a lot of fuss, and that the results (developed code) themselves are reliable, of good quality, etc. By "cheap", I mean that it should take as few tokens as possible to get those reliable results.

Often, developers think of token costs in terms of hosted models. Many of those are billed by the token, and others offer a subscription model where you have session limits to manage. However, token costs also matter for local models: the fewer tokens that need to be processed, the faster those local models can do their work. That in turn might allow those models to do that work on lesser hardware, or get the work done faster on the same hardware.

In addition, token costs affect reliability. The more tokens a coding agent needs to wade through to get at information, the more likely it is that the agent will get confused. This is especially true for lesser models (e.g., Claude Haiku compared to Claude Opus, local models compared to hosted frontier models).

So, my mindset with respect to working with coding agents is to think about guardrails and ramps.

A guardrail is some bit of the automated build process that steers coding agents to abide by project standards and expectations. Lint checks are a guardrail, as are test suites. We are used to having guardrails in projects, but with coding agents, we may tend to want more and stronger guardrails. Even junior developers can learn about standards and expectations through discussion, but coding agents will tend to need something stronger. A failed build gets the attention of a coding agent.

A ramp is some tooling that helps coding agents leverage existing tools easier, just as ramps in the real world help people for whom stairs are an issue. While a coding agent is flexible compared to traditional tools like IDEs, human developers tend to be even even more flexible. A ramp helps a coding agent in places where the existing tools are not optimized for use by agents, but instead are optimized for use by human developers or IDE-style tools.

For example, take Kover. This measures code coverage: does our test suite touch each class? Each statement? Take all branches of a particular when clause? Kover serves as a guardrail for quality, in that we can measure our code coverage and have project expectations with respect to coverage metrics. By teaching coding agents to respect Kover output and to stay above a certain threshold of coverage, agents can deliver more reliable code in a more reliable fashion.

However, Kover generates XML and HTML reports, and those reports are designed for IDE-style tools (XML) and humans (HTML). While coding agents can hack their way through such reports, they tend to do better with JSON, Markdown, or plain text. The more the report has unnecessary cruft (e.g., CSS and JavaScript for an HTML report) or high-ceremony syntax (XML), the more tokens it takes to parse. And, as discussed above, token counts directly affect costs and indirectly affect reliability.

Long-term, tools like Kover may elect to generate agent-friendly reports alongside their existing reports. In the interim, we can build a ramp to help a coding agent leverage Kover... and that is what koverGate is. It is a Gradle plugin designed to help coding agents check code coverage more cheaply and reliably, by rewriting Kover's own reports in a more agent-friendly format. I assembled koverGate after watching Claude Code dynamically generate Python to sift through Kover reports. 🤦🏼 I have been using koverGate in a couple other of my projects, with reasonable success.

I have another similar Gradle plugin in the works, to help support the use of Detekt by coding agents — there, the issue is verbosity of JSON report. I expect to formally announce its availability in a couple of weeks, though enterprising developers can probably find it by poking around Codeberg. 😉 And I have ideas for other guardrails that I will be writing about in the future.

Have you built a ramp or come up with an innovative guardrail? Tell us about it in the comments!

And, um, by the way, I am now #OpenToWork.