Launch HN: Continue (YC S23) – Create custom AI code assistants
11–20 of 113 posts
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#12Is the idea here that the assistant is going to be better at handling specific libraries and languages that you give it documentation for?
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#13Basically knowledge packs could be specified in each npm package.json or similar.
And we should view a knowledge pack as just a cache in a way. Because agents these days are capable of discovering that knowledge themselves, via web browsing and running tests, it is just costly to do so on every agent run or for every library they don't know.
I sort of view specialized agents as akin to micro services, great if you have perfect domain decomposition, but likely to introduce artificial barriers and become inconvenient as the problem domain shifts from the original decomposition design.
I guess I should write this up as blogpost or something similar.
EDIT: Newly written blog post here: https://benhouston3d.com/blog/crafting-readmes-for-ai
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#14Do you run the mcp servers in the cloud, or just download them to be installed in vscode?
I certainly feel that running them locally isn't the end state, curious if others have started to feel pains there yet?
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#15Congrats on the launch! I think this is totally the right next level abstraction for AI-assisted coding. Don’t generate everything from scratch but make it easy to plug in the tools you care about and make the generation way more accurate. Way to go!
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#16As someone who has done a lot of work with agentic coding I am not sure specialized agents are the best solution. I think standardizing knowledge packs would be better that any agent can read to understand a domain or library is more useful. In particular this allows for an agent to know multiple domains at the same time. Basically knowledge packs could be specified in each npm package.json or similar. And we should…
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
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#17Is the idea here that the assistant is going to be better at handling specific libraries and languages that you give it documentation for?
And in some cases not just "better", but if you hook up custom tools then your assistant can do entirely new things!
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#18As someone who has done a lot of work with agentic coding I am not sure specialized agents are the best solution. I think standardizing knowledge packs would be better that any agent can read to understand a domain or library is more useful. In particular this allows for an agent to know multiple domains at the same time. Basically knowledge packs could be specified in each npm package.json or similar. And we should…
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?