I use the Continue extension in both IntelliJ and VSCode and it's great.
Although, I'm just connecting it to my own providers and not using your hub.
So I'm more of a free-loader of the extension than a Continue customer. Anyway, thank you!
Launch HN: Continue (YC S23) – Create custom AI code assistants
51–60 of 113 posts
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#52As 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…
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…
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)
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#53Earlier quoted context omitted.
Excited to hear how it goes for you! Our Models Add-On is intended to give the same flat monthly fee as you’re accustomed to with other products. What did you mean by leaning into pooled, just making it more front-and-center?
Yep, exactly that. IMO agent workflows, MCP and tool usage bits are all promising, but the more common usage of LLMs in coding is still chat. AI extensions in editors just make it simple to supply context, and apply diffs. An addon makes it seem like an afterthought, which I'm certain you are not going for! But still making is as seamless as possible would be great. For ex, response time for Claude in Cursor is much…
This is a good callout, we'll definitely work to improve our messaging
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#54What is the accessibility status of the Continue platform? I am a totally blind developer and have found Cursor to be an absolute mess when it comes to accessibility. There are enough tools available that I'd like to know about there accessibility ahead of time if possible instead of spending a bunch of time trying all of them out only to find they are not accessible.
We have support for text-to-speech in the chat window and have also worked with developers who code entirely through voice and have been quite successful with Continue. I don't claim that we're perfect and would love to hear how we can improve if you have the chance to give it a try
What would be the best way to provide feedback? I'm not sure when I will get a chance to look at Continue, but suspect it may be after comments are closed on this thread.
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#55Earlier quoted context omitted.
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…
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
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#56Earlier quoted context omitted.
We have support for text-to-speech in the chat window and have also worked with developers who code entirely through voice and have been quite successful with Continue. I don't claim that we're perfect and would love to hear how we can improve if you have the chance to give it a try
What would be the best way to provide feedback? I'm not sure when I will get a chance to look at Continue, but suspect it may be after comments are closed on this thread.
If you want to keep in touch going forward, you're welcome to join our Discord or share a GitHub issue, we'll try to be quite responsive
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#57Earlier quoted context omitted.
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…
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 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:
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#58Earlier quoted context omitted.
> 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? A…
> 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/buildi…
Very interesting. I'd like to give "Github" mode a try. Are you able to use some local instance instead?
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#59Earlier quoted context omitted.
> 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/buildi…
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.
Re: Launch HN: Continue (YC S23) – Create custom AI code assistants
#60Very excited for this. The two painpoints I've had with LLM's lately: - Mediocre knowledge of Erlang/Elixir - Reluctance to use the new rune feature in Svelte 5 It sounds like I'd be able to point my local LLM to the official docs for Erlang, Elixir, Phoenix, and all the dependencies in my project. And same for Svelte 5.
I was actually talking to someone the other day who was building an MCP for Continue that could call the Elixir type checker / compiler (which I've heard is quite powerful). I'll need to find this and share—they were saying it made for a really powerful edit -> check -> rewrite loop in Agent mode Also might be interesting to take a look at these Phoenix rules that someone built: https://hub.continue.dev/peter-mueller…
I didn't think of that! I'd definitely be interested in an Elixir MCP. And thank you for pointing out the Phoenix/Elixir block. You'll find me lurking in the Discord.