Live data from Hacker News

Launch HN: Continue (YC S23) – Create custom AI code assistants

hub.continue.dev

11–20 of 113 posts

Re: Launch HN: Continue (YC S23) – Create custom AI code assistants

#12
post #10

Is the idea here that the assistant is going to be better at handling specific libraries and languages that you give it documentation for?

I think that is a temporary problem. General purpose agents will get better in general with libraries without having to have specialized agents.

Re: Launch HN: Continue (YC S23) – Create custom AI code assistants

#13
As 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 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

#14

Do you run the mcp servers in the cloud, or just download them to be installed in vscode?

Right now they are defined as a command (typically npx, uvx, docker or another way of running code) and run as a subprocess in VS Code, which is the same starting point that tools like Claude Desktop have used. We're also going to support SSE-based servers though, which will make it possible to hook Continue up to an MCP that runs anywhere.

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

#15
post #6

Congrats 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!

What does this mean exactly? I checked the website, and it seems to have very specific assistants. I do not know if I personally could take advantage of this, unless there is going to be a "C assistant" or "OCaml assistant" (or just a "coder" one) or something.

Re: Launch HN: Continue (YC S23) – Create custom AI code assistants

#16

As 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…

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

Re: Launch HN: Continue (YC S23) – Create custom AI code assistants

#17
post #10

Is the idea here that the assistant is going to be better at handling specific libraries and languages that you give it documentation for?

Languages, libraries, internal company codebases, common tasks (e.g. writing unit tests in your style, scaffolding a CRUD backend, etc.), personal preferences, and much more. Language models are so general that I probably haven't thought of all the possibilities myself

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

#18

As 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…

> 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?

Post reply on HN