Vogte

The deciding trait is that it does one language and refuses the rest. Specialisation buys real things here: it understands the structure of your project rather than treating it as text, and the feedback it shows you after a change is the one Go developers already read. Nothing general manages that without configuration.

The same choice is the ceiling. A template, a config file or a second language in the tree and you are back to a general tool. Pick it if your work is Go and only Go. Pick a general agent if your repositories are mixed.

The feedback loop is weaker than its placement suggests. Showing project health immediately after a patch implies verification, and the check being run detects a fixed set of suspicious patterns. A change that compiles, passes it, and breaks behaviour is indistinguishable from a correct one, and that is the most common way an agent's edit goes wrong.

What it does right is run anything at all. Most agents in this class apply a patch and stop, leaving the first signal to arrive from a human several minutes later.

1. A parsed representation preserves the relationships an embedding discards: which function calls which, what a type is composed of, where an interface is satisfied. For a task that is inherently about structure, structural retrieval is the correct instrument. 2. Compressing that representation rather than the raw source spends the window on signatures instead of bodies.

2. Restricting the design to one language is what makes this tractable, since a single grammar removes the parser abstraction most tools pay for. 4. No evaluation is published.

Single-language tooling has a hard ceiling and a real floor. The floor is that the audience it serves is genuinely underserved by general tools; the ceiling is that the audience is a fraction of a category whose competitors are funded to serve everyone. Nothing here converts either into revenue.

Moat: the language-specific parsing work, which is the sort of thing a general tool adds as a plugin once the idea proves out. Likely path: quiet personal maintenance, or the technique reappears inside a larger agent. Position: use it, expect to own it.

Partial coverage is its own problem. A tool that serves one part of the estate means two workflows, two sets of instructions and two answers whenever someone asks what we use, and the saving on the covered fraction rarely justifies that split at sixty people.

Beyond the coverage question the usual absences apply: no identity integration, no provisioning, no central record of what was run, and nothing that executes inside delivery tooling. The supplier is an individual. Not yet, though I would not object to one team using it privately.

Zero configuration when a key is already exported is the correct default, and offering a managed cloud route beside the direct one covers the people whose credentials live in an account rather than a file. Permissive licence, small Go source, forkable.

Then the gaps stack up. No documented install path, so I build from source. No MCP client, so the servers I run stay outside. No local endpoint, so a tool that parses my repository locally still ships the interesting part of it to somebody else's inference.