s3anw3

Good job.

This takes me back to the NES era, where developers squeezed entire worlds into a few kilobytes of ROM. What blows my mind here is that even the NES had ~40KB of program space — and this entire boss fight, complete with sprite animation, scrolling landscape, and MIDI music, fits in 256 bytes. The NES ROM header alone is 16 bytes. Incredible work.

Update: GitHub account suspended without notice. Repo links are temporarily broken. Reinstatement request submitted.

Great tool! I've witnessed numerous cases where novice users lost critical data assets by recklessly granting proxies/AI agents excessive permissions without understanding the security implications.

Hi HN! I'm Sean, and I built ChatShell to solve two frustrations I had with AI desktop clients: most are just chat wrappers with no real agent capabilities, and they're bloated Electron apps (200-300MB+).

ChatShell is different. It's a 22MB AI agent (47MB on macOS universal) built with Tauri 2, not Electron. It ships with 9 built-in tools (Web Search, Web Fetch, Bash, File Access, etc.) that work out of the box—no MCP servers to configure, no plugins to install. Privacy-first with AES-256 encryption and local SQLite storage, no telemetry. Full MCP support (STDIO, HTTP, OAuth 2.1/PKCE) and works with 40+ AI providers including local models.

I've been dogfooding this daily. Recently I installed Vercel's agent-browser skill and it's been amazing—I can now ask it to "open my GitHub PRs and summarize what needs review" or "fill out this repetitive web form for me".

The agent capabilities + Skills extensibility is where it really shines. Current limitations: Still early stage. Would love feedback on what agent tools matter most to you, and whether the small binary size is actually important or just my personal obsession.

Happy to answer questions!

I think the tension between natural language and code is fundamentally about information compression. Code is maximally compressed intent — minimal redundancy, precise semantics. Prose is deliberately less compressed — redundant, contextual, forgiving — because human cognition benefits from that slack.

Literate programming asks you to maintain both compression levels in parallel, which has always been the problem: it's real work to keep a compressed and an uncompressed representation in sync, with no compiler to enforce consistency between them.

What's interesting about your observation is that LLMs are essentially compression/decompression engines. They're great at expanding code into prose (explaining) and condensing prose into code (implementing). The "fundamental extra labor" you describe — translating between these two levels — is exactly what they're best at.

So I agree with your conclusion: the economics have changed. The cost of maintaining both representations just dropped to near zero. Whether that makes literate programming practical at scale is still an open question, but the bottleneck was always cost, not value.

Been using ChatShell as my daily driver for non-dev tasks — research, writing, file management, web lookups. The features I rely on most are well tested through dogfooding.