Codalotl v0.11.0: gpt 5.2-based agent for Go codebases

Community
1

Any Go devs here?

I made an agent for Go codebases based on the 5.2 line: codalotl. Again, it’s a purpose-built agent for Go codebases. But when applied to Go codebases, it is 42% cheaper and 55% faster than codex (using the same underlying model), with similar success rates. See benchmark for details.

See some screenshots of it in operation.

Right now it only supports OpenAI models, since 5.2 is head-and-shoulders above other models (e.g., Opus) right now, according to my testing. You need your own API keys.

What makes it different

  • Automatically runs gofmt and lints in the same tool call as applying a patch. Cuts down on back-and-forth tool calls a lot. Also removes failed tests/build checks, sometimes only seen later in CI.

  • Automatically sends package context to LLM. This includes: list of files, function/identifier signatures, list of packages that use the current package, test/build/lint status. This small bundle of context replaces several tool calls that agents typically make to start a session. See example.

  • Uses package mode: this is the big one. See below.

Package Mode

In Package Mode, the agent is isolated to work in a single package: directly reading and writing files and listing directories are limited to this package. In exchange for this limitation, the agent gets confidence to work in the current package without analysis-paralysis of working in a large codebase. As long as you, the human developer, set the correct package, this is a very large benefit.

That being said, the agent DOES have levers to work in a multi-package environment:

  • It can read the public API (e.g., its godoc) of any other package in the module. This is often much more token efficient than using grep and directly reading various files throughout a codebase.

  • If the public API is poorly commented, it can spawn a subagent to answer questions about upstream packages (e.g., “how does func Foo work when xyz”).

  • It can spawn subagents to implement changes either upstream or downstream. Examples:

  • Change a used package so that it has xyz feature, that we need.

  • Change packages that use the current package to use a new API that was just implemented (in the future, this will be parallelized).

  • In both of these examples, the subagent uses a separate context window, so the main agent’s context is protected from getting watered down.

  • It can run the overall project tests.

You can manually give the agent context outside its package by using @ to mention specific files or directories. The agent will be able to directly read them, even if outside the package.

Caveats

  • This is not a vibe coding agent. It is a poor fit for that use-case.

  • Examine the benchmark scenarios to see if the type of prompts tested align with how you use LLMs. Also note the benchmark results are a bit noisy.

  • Only OpenAI models are supported; you must bring your own key. In my tests, OpenAI handily beat other LLMs, so I haven’t prioritized implementing others (but I have no horse in this race - when others pull ahead, I will add support for them).

  • While codalotl is usable and effective (I’ve replaced ~most of my Go coding with it), there’s a number of UX issues and missing features. E.g.: copy support poor; no session switching support yet; no skills. I’ll address these over time.

I am associated with NO company or startup. I have nothing to sell you. I just think this agent is, in a few important ways, better than current state-of-the-art agents for Go development, and wanted to share.

If anyone gives it a shot, I am more than willing to implement fixes and feature requests.

Cheers.

2 Likes