Hacker News Reader

> As someone who has done a lot of work with agentic coding

Can you please share what are your favourite tools and for what exactly? Would be helpful

I've been using Cline a lot with the PLAN + ACT modes and Cursor for the Inline Edits but I've noticed that for anything much larger than Claude 3.7's context window things get less reliable and it's not worth it anymore.

Have you found a way to share knowledge packs? Any conventions? How do you manage chat histories / old tasks and do you create documentation from it for future work?

> Can you please share what are your favourite tools and for what exactly? Would be helpful

I wrote my own open source one here: https://github.com/drivecore/mycoder. Covered on hacker news here: https://news.ycombinator.com/item?id=43177117

I've also studied coding with it and wrote a lot about my findings here:

- https://benhouston3d.com/blog/lean-into-agentic-coding-mista...

- https://benhouston3d.com/blog/building-an-agentic-code-from-...

- https://benhouston3d.com/blog/agentic-coder-automation

- https://news.ycombinator.com/item?id=43177117

- https://benhouston3d.com/blog/the-rise-of-test-theater

My findings are generally that agentic coders are relatively interchangeable and the reason they work is primarily because of the LLM's intelligence and that is a result of the training they are undergoing on agentic coding tasks. I think that both LLMs and agentic coding tools are converging quite quickly in terms of capabilities.

> Have you found a way to share knowledge packs? Any conventions? How do you manage chat histories / old tasks and do you create documentation from it for future work?

I've run into this wall as well. I am working on it right now. :) Here is a hint of the direction I am exploring:

https://benhouston3d.com/blog/ephemeral-software-in-the-era-...

But using Github as external memory is a near term solution:

https://benhouston3d.com/blog/github-mode-for-agentic-coding

Thanks so much for sharing your work. Your blog posts are _far_ more interesting and helpful than most of what I'm seeing about agentic coding.

I'm particularly fascinated by those last two links, along with your latest post about READMEs. It makes me wonder about a visual specification editor that provides GitHub-like task chronology around the spec, with the code as a secondary artefact (in contrast to GitHub, where code is primary).

Thanks for the positive feedback! If you can share them please do!

BTW I'm working on ideas to make code a secondary artifact right now, sort of v2 of mycoder.

Very interesting. I'd like to give "Github" mode a try. Are you able to use some local instance instead?

It can, but Claude 3.7 is the best model for it right now. Using other models with mycoder right now is just an exercise in frustration. I will fix that eventually.

What I meant to ask is, instead of pushing your code to Github, is it possible to use a local self hosted instance of a similar tool like GitLab or Bitbucket?

It is just a prompt change if there is a cli tool for GitLab or Bitbucket. I just tell Claude to use the gh cli tool and to use it as external memory to track tasks and to submit PRs.

I see, so it depends on a cli tool being available. I will check what other options are available out there.

It would be great to run local models at the same level one day. I am sure that Claude is making your wallet feel quite light :)

It costs about a $1 to implement a major feature, so no the cost is marginal compared to my salary.

That's not bad. Btw your docs are really good. Will be checking out the Discord.

> The recent productivity has been so high, it has the effect of making my previous efforts seem sort of pedestrian

Fantastic!

Agentic task-offloading is already here; it is just unevenly distributed.

Are you using aider in your mycoder?

Mycoder is open source and an independent project. The story of building mycoder from scratch is here:

https://benhouston3d.com/blog/building-an-agentic-code-from-...

On another note, this rang true to me:

> Basically knowledge packs should be specified in each npm package.json or similar.

Our YAML-based file format for assistants (https://docs.continue.dev/reference) is hoping to do just this by allowing you "import knowledge packs".

Does it need to be decoupled from package.json, etc.? One of the most interesting reasons we decided not to go that route was it can be cumbersome for all of your many dependencies to taken into account at once. Another is the question of how the ecosystem will evolve. I definitely think that each package author should take the time to encode the rules and best practices of using their library, however it might be difficult for community to help out if this is gated by getting in a pull request.

At the same time, one of the soon-to-be-released features we are working on is the ability to auto-generate or suggest rules (based on package.json, etc.).

> Does it need to be decoupled from package.json, etc.?

Knowledge packs should be decoupled from package.json just as eslint rules or commit-lint rules are. You can include them in package.json or in separate files. But including pointers to the main files in a package.json helps with discovery.

All packages across all languages should support AI friendly knowledge packages so a level of decoupling is required.

EDIT: After thinking about it I think README.md should just be written with Agentic Coders in mind. I wrote up my thoughts on that here: https://benhouston3d.com/blog/crafting-readmes-for-ai

how are "knowledge packs" different than just the package's README ? (if present and well written, it should be as usable to devs as to an LLM, if not, maybe consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package)

I'd say rules are quite similar to a README, just tailored to LLMs, which often benefit from slightly different information than a human would. One way to think about the difference is that we as developers have the chance to build up memory/context over time, whereas LLMs are "memoryless" so you want to efficiently load all of the necessary high-level understanding.

> consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package

This is something we're looking to ship soon

I agree with you on the READMEs. In response to his suggestion that I write a blog post on the idea of knowledge packages, I just spend the last 30 minutes aligning on your suggestion by coincidence. Written up here:

https://benhouston3d.com/blog/crafting-readmes-for-ai

wow that was fast—some gems in there

We think about this a lot, and I think there are merits to the viewpoint. If I were to write a rule that said "make sure all code you write uses best practices", it should already be obvious enough to a good language model that this is always the case. It's "common knowledge". In some cases today there might be "common knowledge" that is a bit more rare, and the language model doesn't quite know this. I might agree that this could be obviated as well.

A situation to think about: if I were to write a rule that said "I am using Tailwind CSS for styling", then this is actually information that can't be just known. It's not "common knowledge", but instead "preference" or "personal knowledge". I do think it's a fair response to say "can't it just read my package.json"? Probably this works in a handful of cases, but I've come to find that even so there are a few benefits to custom rules that I expect to hold true regardless of LLM progress: - It's more efficient to read a rule than to call a tool to read package.json on every request - Especially in large enterprise codebases, the majority of knowledge is highly implicit (oftentimes in detrimental ways, but so the world works)

But yeah this is a majorly important and interesting question in my mind. What types of customization will last, and which won't? A blog post would be amazing

I was expecting more than "have a readme" tbh