Show HN: Gauge – Open-Source CLI to recursively improve your docs
Posted by 0x63_Problems 1 day ago
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 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
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
Comment by the1024 1 day ago
- 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
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
Comment by leon_fieldtest 16 hours ago
Comment by alexutz6 10 hours ago
Comment by kydfeng 1 day ago
Comment by esafak 1 day ago
Thanks for sharing.
Comment by choxi 1 day ago
Comment by 0x63_Problems 1 day ago
Comment by jpease 1 day ago
Comment by seanjhkwon 1 day ago
Comment by vladzoff 1 day ago
Comment by xiaoliangliang 1 day ago
Comment by emscb 1 day ago