keen-code: A Go Coding Agent

keen-code is mochow13's open-source terminal coding agent, written mainly in Go and shared as a Show HN project. It deals with the same daily problem as OpenAI Codex, OpenAI's coding agent, and other terminal agents: how much agent harness do you need before coding help becomes noisy or hard to trust? The useful takeaway is simple: a small agent can still be serious if it makes context, tool boundaries, and review artifacts visible. For readers building Codex CLI workflows, keen-code is worth studying less as a replacement and more as a compact design specimen.

A coding agent is a command-line or editor-connected program that reads code context, plans changes, edits files, runs tools, and asks for human approval at important boundaries. keen-code's README describes it as a terminal-based AI coding agent like Claude Code, Anthropic's coding agent, or Codex CLI, but lighter and more opinionated. As of August 2026, the repository was MIT licensed, had 57 GitHub stars, and listed topics around agentic AI, coding assistants, MCP, and multi-agent orchestration.

Look at the harness, not just the model

The interesting part of keen-code is not that it calls a model. Lots of projects do that now.

The interesting part is the harness: providers, skills, MCP servers, subagents, automatic compaction, and a minimal terminal UI. That is the part every serious Codex CLI workflow eventually has to confront. You need somewhere to put durable instructions, somewhere to connect external systems, and somewhere to keep the agent from narrating itself into a fog.

keen-code is explicit about being opinionated. The README says it avoids features that are not needed by a regular software engineer and tries to keep the agent harness simple. That matters because the trap in agent tools is usually not missing features. It is a pile of features that makes every session feel like operating a tiny distributed system.

A concrete Codex parallel is AGENTS.md. In OpenAI Codex, AGENTS.md gives the agent repository instructions: how to test, where not to edit, which conventions matter, and what counts as done. keen-code has its own skills and context machinery, but the lesson travels well: put stable repo knowledge in files, not in a heroic prompt you rewrite every morning.

Example AGENTS.md boundary for a small Go repo:

# AGENTS.md

- Make the smallest code change that satisfies the task.
- Run go test ./... before handing back a code change.
- Do not edit generated files under internal/gen/.
- For database changes, stop and ask before creating or changing migrations.
- Summarize only changed files, tests run, and remaining risk.

That last line is not decoration. It is a pressure valve for agent fatigue.

Why Hacker News cared about another coding agent

The predictable reaction was fatigue. One commenter effectively asked whether the world needed another coding agent at all. That is a fair question.

The better answer is that keen-code is interesting because it is self-referential without being hand-wavy. The author says it was engineered using coding agents and agentic IDEs, and the repository keeps prompts and output docs as markdown files in a .ai-interactions directory. That turns the project into a record of how agent-assisted engineering actually happened, not just a demo of the finished binary.

That record is useful for Codex users because the failure mode of agentic coding is often hidden labor. The agent writes code, then the human spends twenty minutes reconstructing why. Saving prompts, outputs, and decisions gives you a review trail that is easier to scan than a raw chat transcript.

There is a trap, though. Do not mistake a saved conversation for proof. A saved agent interaction is a receipt, not a test. The real verification loop still needs commands, diffs, and human review.

A good Codex CLI verification loop stays boring:

git status --short
git diff -- src tests
go test ./...
git diff --stat

The point is not that every repo uses Go. The point is that the agent should return to the same small loop every time: inspect the working tree, review the focused diff, run the relevant test command, then summarize risk.

Take the output-fatigue complaint seriously

The sharpest objection in the discussion was not about model quality. It was about volume.

Developers running several agents a day are getting tired of reading walls of plan text, progress text, alternative text, and recap text. Some people already use custom prompts to reduce this, but the complaint is deeper: many agents do not expose enough control over how much they say and when.

This is where keen-code's minimalism becomes more than taste. A small terminal UI has fewer places to hide verbosity. If the agent cannot explain its work in a compact handoff, the session feels heavy no matter how clever the toolchain is.

For Codex CLI users, the practical move is to make concise handoff part of the repo instruction, not a preference buried in a prompt. You can combine that with scoped context on Codex CLI workflows: durable repo rules in AGENTS.md, task-specific instructions in the prompt, and external tools behind tight MCP boundaries.

A useful handoff format is only four lines:

Changed: pkg/parser/token.go, pkg/parser/token_test.go
Verified: go test ./pkg/parser
Risk: tokenizer edge cases around escaped unicode
Next: review diff around parseQuotedString before merge

That is enough to restart your own brain without rereading the agent's whole monologue.

Try keen-code when the repo is small enough to understand

The safest way to evaluate keen-code is with a repo where you already know the shape of the code. Pick a small bug, a missing test, or a refactor that touches one package. Do not begin with auth, billing, migrations, or infrastructure credentials.

This is also the right way to compare it with Codex CLI. Run the same task in both, keep the prompts nearly identical, and judge the artifacts: diff quality, test behavior, compactness of the handoff, and whether the tool asked before crossing a boundary.

A tiny experiment might be: add tests for a parser edge case, update one implementation file, run the package test, and produce a four-line handoff. If you want another current example of developers wrapping coding agents in smaller interfaces, Mirafold Wraps Coding Agents in Browser UI is a useful contrast.

The trap is evaluating the agent on a task you cannot review. That makes the demo feel magical and the result less useful. A coding agent earns trust fastest when the human can say, yes, I understand this diff.

Copy this safe-trial checklist

Use this checklist for a one-hour keen-code trial, or for a Codex CLI comparison run. Keep it intentionally small.

A simple MCP boundary note is often enough for the first run:

MCP boundary

- GitHub access is read-only for issue and PR context.
- No writes to GitHub, Slack, databases, or package registries.
- Ask before reading private docs outside this repository.

That gives the agent room to gather context without turning the experiment into a permissions audit.

Common questions

• Is keen-code just another Codex CLI clone?

  No. keen-code is a separate open-source terminal coding agent written mainly in Go, with its own opinions about minimal UI, providers, skills, MCP, subagents, and compaction. The README compares it to Codex CLI and Claude Code, but the project is more interesting as a small agent harness you can inspect.

• How should I compare keen-code with Codex CLI?

  Compare them on one known task, not on a vague feeling of intelligence. Use the same repo, same prompt, same allowed files, and same verification command. Then judge the diff, the test result, and the handoff. The citable artifact is the final patch plus the commands actually run.

• Can keen-code reduce agent output fatigue?

  It might help, but minimal UI does not automatically mean minimal output. The stronger pattern is to require a compact handoff and make that instruction durable. In Codex, that belongs in AGENTS.md; in any agent, it should be close to the repo and checked during review.

• Should I enable MCP on the first run?

  Usually no. Start without MCP or with read-only context access, then add tools when the task clearly needs them. MCP is powerful because it connects the agent to systems like GitHub, docs, databases, or issue trackers. That same power makes boundaries important from the first experiment.

• Is the .ai-interactions idea worth copying?

  Yes, selectively. Saving prompts and output docs can make agent-assisted work easier to audit, especially when a patch has a surprising design choice. Do not save raw noise forever. Keep the prompt, the final handoff, and any decision notes that explain why the diff looks the way it does.

Best ways to use this research

• Best for: Developers evaluating small agent harnesses, especially Codex users who want to understand what belongs in the CLI, what belongs in AGENTS.md, and what belongs behind MCP.
• Best first artifact: A four-line handoff plus a focused git diff. That tells you more about daily usability than a polished demo task.
• Best comparison angle: Compare keen-code with Codex CLI on output control, verification loops, and permission boundaries, not only on whether the agent completes the task.
• Best Codex takeaway: Treat verbosity as a repo-level interface problem. Put concise summary rules, test commands, and no-edit zones where the codex agent can reliably find them.

Further reading

• OpenAI Developers — AGENTS.md guide
• OpenAI Developers — Codex quickstart
• keen-code — source

Next step

Try keen-code or Codex CLI on one small issue you can personally review. If the result is hard to summarize in four lines, fix the workflow before you increase the agent's permissions.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.