Comment by gen220 | Hacker News Reader

Comment by gen220 | Hacker News Reader

Parent Full thread

I, too, recommend aider whenever these discussions crop up; it converted me from the "AI tools suck" side of this discussion to the "you're using the wrong tool" side.

I'd also recommend creating little `README`'s in your codebase that are mainly written with aider as the intended audience. In it, I'll explain architecture, what code makes (non-)sense to write in this directory, and so on. Has the side-effect of being helpful for humans, too.

Nowadays when I'm editing with aider, I'll include the project README (which contains a project overview + pointers to other README's), and whatever README is most relevant to the scope of my session. It's super productive.

I'm yet to find a model that beats the cost-effectiveness of Sonnet 3.7. I've tried the latest deepseek models, and while I love the price (nearly 50x cheaper?), it's just far too error-prone compared to Sonnet 3.7. It generates solid plans / architecture discussions, but, unlike Sonnet, the code it generates often confidently off-the-mark.

Have you tried Gemini 2.5? It's cheaper and scores higher on the Aider leaderboard.

I haven’t yet, I’ll give it a shot!

It's so good!

Why create READMEs and not just comments in the code?

I’d generally prefer comments in code. The README’s are relatively sparse and contain information that would be a bit too high-level for module or class-level comments. If commentary is specific to a module or class or method, the documentation belongs there. My rule of thumb is if the commentary helps you navigate and understand rules that apply to entire sets of modules rooted at `foo/`, it generally belongs in `foo/README`.

For example “this module contains logic defining routes for serving an HTTP API. We don’t write any logic that interacts directly with db models in these modules. Rather, these modules make calls to services in `/services`, which make such calls.”

It wouldn’t make sense to duplicate this comment across every router sub-module. And it’s not obvious from looking at any one module that this rule is applied across all modules, without such guidance.

These little bits of scaffolding really help narrow down the scope of the code that LLMs eventually try to write.

Comments are not easy for the LLM to refer to, ironically: https://taoofmac.com/space/blog/2025/05/13/2230

There is a better way than just READMEs: https://taoofmac.com/space/blog/2025/05/13/2230

I like this a lot! My root README ends up looking a lot like your SPEC.md, and I also have a file that’s pretty similar to your TODO.md.

My experience agrees that separating the README and the TODO is super helpful for managing context.

Reply on news.ycombinator.com