Show HN: Gauge – Open-Source CLI to recursively improve your docs

Posted by 0x63_Problems 1 day ago

Counter41Comment10OpenOriginal

Hi HN, I’m Evan from Gauge. We’re open-sourcing our CLI to recursively improve your docs for coding agents. The CLI includes a local execution backend, so you don't need an account to try it. Explainer video here: https://youtu.be/zhLUlIKB1Mg

The CLI supports a hillclimbing loop:

- set up tasks for coding agents that would need your docs, like 'set up Gauge CI checks'

- run the tasks

- analyze session transcripts for friction or failures

- create variants of your docs to resolve the issues

- re-run the tasks with the doc variants injected (transparently, at the same hostname)

- repeat until you have a variant that resolves the issues

The same loop supports hillclimbing your Skills, CLI, and other agent-facing surfaces.

We started out 2 years ago building open-source developer tools (like Tach https://github.com/tach-org/tach), then pivoted to AI Search optimization, and are now focused on the intersection of the two spaces. We were already working with awesome devtool companies, and they were the first ones to ask us how to optimize for Claude Code and Codex. We realized this would be something that eventually every company needs to do. Our CLI provides primitives for docs/devrel/eng teams to measure, analyze, and improve how coding agents use their product.

The design boils down to two components: VMs and a network gateway.

The VMs are straightforward, we want the agents to be highly privileged within their environment so that they are representative of developers' coding agents. Each VM generally comes with the agent harness itself, language toolchains, and a git repository.

The network gateway is where we terminate TLS and swap in variants of your docs transparently. The gateway also handles credential replacement, so agents see placeholders and can't exfiltrate keys.

The CLI comes with a 'local' execution backend (inference is still remote). For VMs, it uses Docker containers, and the network gateway is mitmproxy running in a sidecar container for each session.

We've used the hillclimbing loop internally to find and fix coding agent issues like mistaken pricing, inaccurate product limitations, and repeated workarounds. We saw coding agents report that Gauge only supports Claude Code and Codex, traced it back to the web pages they fetched, and fixed the behavior (we support Pi, OpenCode, and Antigravity as well). For Clerk, we helped shift coding agents from their legacy 'keyless' mode to their new 'clerk init' command. They were able to validate a pre-release change to their SDK's error messages using Gauge, then saw a 3x increase in coding agents using 'clerk init' post-deploy.

Due to the 'static' nature of AI models, we've realized that closed-loop optimization techniques are now possible for essentially all software products. The same agent can be simulated over and over, meaning that a high-fidelity testing environment is all you need. Achieving the best results boils down to high-quality analysis (finding generalizable friction and objections) and paired experiments (vary only the content, measure the downstream change in behavior).

The repo is here: https://github.com/gauge-sh/gauge-cli and you can start using the CLI with: npm i -g @withgauge/cli

We also have documentation and a quickstart here: https://docs.withgauge.com/agents/guides/cli

If you point a coding agent at those pages, it should guide you through the initial setup - let us know if it doesn't! The intention is for your agent to run some sensible evaluations and find at least one point of friction you can fix.

We'd love to know from HN: Has anyone tried to DIY this locally, or built something in-house at their company? Is this an improvement? If not, what would need to change?

Comments

Comment by voakbasda 1 day ago

I have been doing this process by hand. Try to do something. Observe friction. Document how to avoid it. Rinse and repeat. It works and raises the quality going forward. Most importantly, the vast majority of my tokens are spent moving my project forward.

I would be extremely leery to use an automated hill-climbing loop, repeating the same inputs, and burning tokens on the same task over and over. That’s not going to move my project forward, and I don’t have unlimited tokens to spend.

Worse, how can I be sure that these agents will follow deterministic definitions of friction and priorities for removing it? I can imagine “write less tests” would remove a lot of friction. I see this just adding another layer, where I now would be documenting the system that writes my documentation. I learned how that is likely to turn out from playing the telephone game as a child: poorly.

Comment by 0x63_Problems 1 day ago

To clarify, this does not require the hillclimbing to be unattended, especially if you are setting up the system for the first time!

This mainly automates the process that you are doing by hand. If you have your own definition of friction and priorities, you can tell this to your agent and it will fit into the CLI loop. You can review any change that is suggested, and spot-check transcripts if you feel the need.

It's like most AI systems in that you can have it earn more autonomy over time, as you add guidance and guardrails.

Comment by loopseo 14 hours ago

Your idea of using a hillclimbing loop for improving documents is interesting. It looks like you found problems by looking at conversation records. Can you explain the measurements you use to know if a version of a document solves a problem? Also what do you do when different coding assistants give comments, about the same document?

Comment by the1024 1 day ago

This is definitely something the companies most focused on agent experience are thinking about:

- https://supabase.com/evals - https://nextjs.org/evals

What is a better analogy for how you think developer tools should think about agent experience: an RL environment (hillclimbing a task like you mention), or a test suite (to be used in CI/CD, etc) as referenced by Supabase/Vercel?

Comment by 0x63_Problems 1 day ago

Active work should mostly be hillclimbing, or at least more exploratory. The search space is very large and you typically find a lot more low-hanging friction than you'd think by just running a broad battery of sessions. And I'd pair active hillclimbing work with feature launches/product work - essentially part of releasing new things is QA-ing them against coding agent workflows.

The test suite eval style is useful and mostly a complement. You do want regression tests on critical features.

Comment by the1024 23 hours ago

The search space being large feels like a fundamentally hard and costly problem to solve for. Where do you recommend folks start given such a high number of possible scenarios?

Comment by leon_fieldtest 16 hours ago

[flagged]

Comment by alexutz6 10 hours ago

[flagged]

Comment by 1 day ago

Comment by kydfeng 1 day ago

[flagged]

Comment by esafak 1 day ago

Sorry to be pedantic, but it's iteratively. Your README even calls it Iteration.

Thanks for sharing.

Comment by choxi 1 day ago

They won’t stop until the entire information capacity of the universe is consumed by autogenerated Swagger docs

Comment by 0x63_Problems 1 day ago

Fair enough, maybe when we use it internally it would qualify?

Comment by jpease 1 day ago

But what if you use recursion for iteration?

Comment by seanjhkwon 1 day ago

[flagged]

Comment by vladzoff 1 day ago

[flagged]

Comment by xiaoliangliang 1 day ago

[flagged]

Comment by emscb 1 day ago

[dead]