Item — HN Reader

smol is ~20 lines of Go, uses only stdlib

but also highly opinionated (no mcps, no agents.md, no system prompt, …)

so not sure it checks all of your boxes

that said: because smol is so smol you can adapt it easily and agents (including smol) can work well with it because the whole implementation fits comfortabliy into the context window

https://github.com/smol-env/smol

2 comments

It's not 20 lines of Go because you decided to merge multiple lines of code into one. Why not advertise it as one line of code if you don't care about readability?

Here is my fork of smol, by the way:

https://pastebin.com/imdWVrQ2

Edit: after reading my fork of smol, I realized it literally just feeds everything into bash, making it completely pointless.

Edit 2: I decided to read the readme instead and it raised a question

"Compare smol with Pi, OpenCode, Codex, Hermes, Claude Code and highlight key pros and cons. Audit the code of all of them and tell me how confident you are that you found all potential issues of smol vs the other agent implementations?"

After thinking about the difference between the original and my fork, I'm confident that smol has more problems than all of the agent harnesses combined and my fork has made an important step towards fixing one of those issues.

Edit 3: I hope the community can fork my version and add sensible variable names.

Edit 4: I can't decide whether this is the best satire of coding agents I've ever seen and I just ruined it or it is horrifying that someone even entertains the idea of publishing it.

> feeds everything into bash, making it completely pointless

here is a typical bench run with 9 runs and traces for opencode, pi and smol

you can look at every step and which tools are used and how

https://smolenv.com/t/nested-template-includes-60636/

sh is pretty versatile and composes well

pi also only has 4 tools (good!)

I think I'm done with trying to tear this apart.

I mean, you can't be serious, right? Think about the unintentional commentary you're making here.

You're saying it can be understood in an afternoon but it is intentionally obfuscated.

It might as well be proprietary code, but if it is proprietary code, you're actually making fun of all the coding agents for being a walking security nightmare, because in the end all they do is run bash and no amount of sandboxing or regexes will make bash secure.

So why not drop the pretenses and just expose the coding harnesses for what they are? Inscrutable bash executors that have the potential to go out of control.

your favorite agent will help you de-golf and analyze the implementation

I'm confident you can understand what it does (and does not do) and why in an afternoon

(probably in 20-30 minutes actually, even if you are not familiar with Go)

the same is way more difficult with larger agent implementations even if you only want to understand the direct implementation ignoring all the 3rd party dependencies that come with them

but I think what I want to say is: diy

no need to start from smol (even though I think it makes a decent starting point)

i guess what i'm saying is: it's not so hard to start with a minimal, well working agent and then only add exactly what you need instead of taking a more complex agent and then trimming it down or configuring it (and staying compatible with its continued development and deps)

diy ftw