Hacker News Reader

> 2. Start with a good spec. Spend enough time on the spec. You can get AI to write most of the spec for you, if you provide a good outline.

Curious how you outline the spec, concretely. A sister markdown document? How detailed is it? etc.

> 3. Make sure you have tests from the beginning. This is the most important part. Tests (along with good specs) are how an AI agent can recurse into a good solution. TDD is back.

Ironically i've been struggling with this. For best results i've found claude to do best with a test hook, but then claude loses the ability to write tests before code works to validate bugs/assumptions, it just starts auto fixing things and can get a bit wonky.

It helps immensely to ensure it doesn't forget anything or abandon anything, but it's equally harmful at certain design/prototype stages. I've taken to having a flag where i can enable/disable the test behavior lol.

> Curious how you outline the spec, concretely. A sister markdown document? How detailed is it? etc.

Yes. I write the outline in markdown. And then get AI to flesh it out. The I generate a project structure, with stubbed API signatures. Then I keep refining until I've achieved a good level of detail - including full API signatures and database schemas.

> Ironically i've been struggling with this. For best results i've found claude to do best with a test hook, but then claude loses the ability to write tests before code works to validate bugs/assumptions, it just starts auto fixing things and can get a bit wonky.

I generate a somewhat basic prototype first. At which point I have a good spec, and a good project structure, API and db schemas. Then continuously refine the tests and code. Like I was saying, types and linting are also very helpful.

I don't even write the outline myself. I tell CC to come up with a plan, and then we iterate on that together with CC and I might also give it to Gemini for review and tell CC to apply Gemini's suggestions.

I built a tool for this exact workflow in mind but with MCP and versioning included so you can easily track and edit the files on any platform including cursor, Claude desktop etc

https://github.com/jerpint/context-llemur

What kind or projects are more suitable for this approach? Because my workflow, sans LLM agents, have been to rely on frameworks to provide a base abstraction for me to build upon. The hardest is to nail down the business domain, done over rounds of discussions with stakeholders. Coding is pretty breezy in comparison.

That's why you see such a difference in time saved using LLMs for programming across the population. If you have all the domain knowledge and the problem is generic enough it's a 100x multiplier. Otherwise your experience can easily range from 0.1x to 10x.

Playwright is such a chore with Claude but I'm afraid to live without it. Every feature seems to be about 70% of the time spent fixing it's playwright mess. It struggles with running the tests, basic data setup and cleanup, auth and just basic best practices. I have a testing guide that outlines all this but it half asses every thing ..

I will start with a basic markdown outline and then use a prompt describing more of the system in just flowing (yet coherent) thought and, crucially, I'll ask the model to "Organize the spec in such a way that an LLM can best understand it and make use of it." The result is a much more succinct document with all the important pieces.

(or -- you can write a spec that is still more fleshed out for humans, if you need to present this to managers. Then ask the LLM to write a separate spec document that is tailored for LLMs)

I wrote a tool for this, which allows you to co-create and maintain a context repository with your LLMs

https://github.com/jerpint/context-llemur

CLI for the humans, MCP for the LLMS. Whatever is in the context repository should be used by the LLM for its next steps and you are both responsible for maintaining it as tasks start getting done and the project evolves

I’ve been having good success with it so far

I have a similar flow to this, but using files which are part of the repository. For you tool; What made you choose to version it with git but also write context is not code? Wouldn't you end up with multiple versions of say your backlog, and to what benefit?

The way I see it is that context evolves somewhat orthogonally to code. But you still want to track it in similar ways. Having git under the hood makes it easy to track its evolution and undo/diff things LLMs might decide to change, but also means that tracking your todos and new feature ideas don’t pollute your codebase

> 1. Monorepos can save time

Yes they can save you some time, but at the cost of Claude's time and lots of tokens making tool calls attempting to find what it needs to find. Aider is much nicer, from the standpoint that you can add the files you need it to know about, and send it off to do its thing.

I still don't understand why Claude is more popular than Aider, which is by nearly every measure a better tool, and can use whatever LLM is more appropriate for the task at hand.

> Aider is much nicer, from the standpoint that you can add the files you need it to know about, and send it off to do its thing.

As a user, I don't want to sit there specifying about 15-30 files, then realize that I've missed some and that it ruins everything. I want to just point the tool at the codebase and tell it: "Go do X. Look at the current implementation and patterns, as well as the tests, alongside the docs. Update everything as needed along the way, here's how you run the tests..."

Indexing the whole codebase into Qdrant might also help a little.

I think it makes sense to want that, but at least for me personally I’ve had dramatically better overall results when manually managing the context in Aider than letting Claude Code try to figure out for itself what it needs.

It can be annoying, but I think it both helps me be more aware of what’s being changed (vs just seeing a big diff after a while), and lends itself to working on smaller subtasks that are more likely to work on the first try.

You get much better results in CC as well if you're able to give the relevant files as a starting point. In that regard these two tools are not all that different.

Aider does know the whole repository tree (it scans the git index). It just doesn't read the files until you tell it to. If it thinks it needs access to a file, it will prompt you to add it. I find this to be a fairly good model. Obviously it doesn't work off line though.

> Aider is much nicer, from the standpoint that you can add the files you need it to know about, and send it off to do its thing.

Use /add-dir in Claude

As an alternative to monorepos, you can add another repo to your workspace by informing it relevant code is located at XXX path on your machine. Claude will add that code to your workspace for the session.

Because it works.

Honestly, it's just this. "Claude the bar button on foo modal is broken with a failed splork". And CC hunts down foo.ts, traces that it's an API call to query.ts, pulls in the associated linked model, traces the api/slork.go and will as often as not end up with "I've found the issue!" and fix it. On a one sentence prompt. I think it's called an "Oh fuck" moment the first time you see this work. And it works remarkably reliably. [handwave caveats, stupid llms, etc]

Agreed, for CC to work well, it needs quite a bit of structure

I’ve been working on a Django project with good tests, types and documentation. CC mostly does great, even if it needs guidance from time to time

Recently also started a side project to try to run CC offline with local models. Got a decent first version running with the help of ChatGPT, then decided to switch to CC. CC has been constantly trying to avoid solving the most important issues, sidestepping errors and for almost everything just creating a new file/script with a different approach (instead of fixing or refactoring the current code)

I've also found that structure is key instead of trusting its streams of consciousness.

For unit testing, I actually pre-write some tests so it can learn what structure I'm looking for. I go as far as to write mocks and test classes that *constrain* what it can do.

With constraints, it does a much better job than if it were just starting from scratch and improvising.

There's a numerical optimization analogy to this: if you just ask a solver to optimize a complicated nonlinear (nonconvex) function, you will likely get stuck or hit a local optimum. But if you carefully constrain its search space, and guide it, you increase your chances of getting to the optimum.

LLMs are essentially large function evaluators with a huge search space. The more you can herd it (like herding a flock into the right pen), the better it will converge.

> Put external documentation inside project docs

Most projects have their documentation on their website. Do you spend time formatting it into a clean Markdown file?