Keen Code

One thing we've noticed with agent workflows is that reducing context size and improving context quality are often treated as the same problem when they're actually different.Have you found Keep Code's biggest win coming from compression, retrieval, or helping agents maintain a more consistent mental model of the codebase across longer sessions?

Sounds interesting, but aren’t you worried about competition? There are already many AI coding tools, and new ones appear every day.

The context-efficiency angle is what stands out to me here — lazy-loading MCP skills instead of front-loading schemas is a genuinely smart architectural choice that most CLI agents skip. Fellow solo builder launching nearby (Sensemaker, a thinking-to-writing tool), and the "built by agents, orchestrated by human" workflow you described is almost exactly how I shipped my own MVP. Curious: how did you handle the moments where the agent went off-spec mid-session? Did you find the prompt/design trail in the repo was enough to course-correct, or did you need other guardrails?

the skills-driven MCP approach is the part that caught my attention. every multi-tool agent setup I've seen just dumps the entire schema into context upfront and then wonders why performance drops off a cliff three turns in. lazy-loading only what the model actually needs at runtime feels obvious in hindsight but almost nobody does it. also respect for shipping the full prompt trail in the repo... that's genuinely useful for anyone trying to learn how agent-driven development actually works in practice. congrats on the launch and doing this solo is no joke

The "lazy-loaded Skills instead of stuffing MCP schemas into context upfront" choice is the detail that stood out to me - that's usually where multi-MCP setups quietly fall apart, the context budget gets eaten before you do any real work.As someone still figuring out how to keep agent sessions lean, I'm curious: with turn memory compacting older turns, how do you decide what's safe to drop vs keep? Do you summarize older turns or hard-truncate them? Wondering where the line is before the agent starts "forgetting" a constraint from earlier in the session.Also love that the whole prompt/design trail is in the repo - genuinely useful to learn from. Respect for building it solo. Congrats on the launch.

Context efficiency is the right constraint to optimize for in a coding agent. Most agents bloat the context window with irrelevant file chunks and then thrash on eviction decisions. We've hit this exact failure mode building multi-file reasoning features and it's where agent reliability falls apart. How does Keen Code handle context prioritization across a multi-step tool use chain when multiple files are relevant?

Building a CLI agent that manages its own context window is a genuinely hard problem. We've dealt with similar tradeoffs in long-running background jobs where keeping relevant context without blowing token budgets required careful chunking. What's your eviction strategy when the agent's working set grows mid-task: do you prioritize recency or semantic relevance?

Really cool, and respect for building it solo. The turn memory idea for keeping context lean is smart. How much context does it actually save in a long session?

Hi Product Hunt! I’m happy to share Keen Code, an open-source CLI coding agent written in Go.

I’ve been building it solo since February as a side project, and I used it as an opportunity to experiment with context efficiency and agent-driven development.

Three things make Keen Code different from other similar products:

1. Built by agents

Keen Code was built from scratch using state-of-the-art coding agents. My role was to act as the human orchestrator: writing prompts and requirements, then reviewing the designs and code produced by agents.

To keep this transparent, the repo includes an ai-interactions folder with prompts and output docs. More: https://mochow13.github.io/keen-...

2. Turn memory

To avoid filling the context window during multi-turn loops, Keen discards raw tool inputs and outputs after each turn. It keeps a distilled “turn memory” instead: a simple deterministic Go struct passed into the next turn.

More here: https://mochow13.github.io/keen-...

3. Skills-driven MCP servers

Instead of loading large MCP server schemas into context upfront, Keen abstracts MCP tools into local markdown Skills. It only retrieves the exact JSON schema when the LLM requests a specific tool at runtime.

Details: https://mochow13.github.io/keen-...

I’ve been using Keen to develop Keen itself, as well as in my other projects. I’m looking forward to questions, feedback, suggestions, and reviews. I’m committed to improving the project over the long term.

Thanks in advance!