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

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

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.).

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

This is fair feedback—we're so early in building an ecosystem here that the prompts we've shared as starting points are relatively general. But already we've seen people start to build much more carefully-crafted and specific assistants. These are some examples that we've used internally and found to be super useful:

- https://hub.continue.dev/continuedev/playwright-e2e-test

- https://hub.continue.dev/continuedev/vscode

- https://hub.continue.dev/continuedev/service-test-prompt

Importantly, you don't have to pay to use custom assistants! You can think of hub.continue.dev like the NPM registry: it's just a medium for people to create, share, and pull the assistants they want to use. It's always possible to bring your own API key and we provide a Models Add-On mostly for convenience of not needing to keep track of API keys

Value prop of MCP is definitely early, but I would recommend giving Agent mode (https://docs.continue.dev/agent/how-to-use-it) a try if you haven't had the chance—there's something compelling about having the model take the obvious actions for you (though you can of course require approval first!)

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.

Yeah we think that MCP was a really solid building block at a lower level but ultimately a higher level abstraction is what will make customization really accessible. Being able to define rules, models, MCP servers, docs, prompts, data flow, all in one seems to be important

I wouldn't say that's free-loader behavior :) It's exactly what we want to make possible—if you have strong reason to use your own models (price, convenience, security, remaining local, or other) then Continue is built for that

Thank you! The biggest difference in our approach is the goal of allowing for custom assistants. What we've found is that most developers work in entirely different environments, whether that be IDE, tech stack, best practices, enterprise requirements, etc. The baseline features that we've come to expect from a coding assistant are amazing, but to truly meet people where they are it takes something different for everyone. Over the last two years we've seen tons of people customizing, and with hub.continue.dev we just want to make that accessible to all, and hope that people will share what they learn.

We're going to keep building at the edge of what's possible in the IDE, including focusing on Agent mode (https://docs.continue.dev/agent/how-to-use-it), next edit prediction, and much more. And we're going to keep making it easier to build custom assistants as the ecosystem grows!

FYI I'm sure you're aware, Svelte has one of the best migration guides ever [1].

It's too large to be a Cursor rule though. But, if you dump it into Google Gemini (which is phenomenal at large context windows) it will write you a solid condensed version.

[1] https://svelte.dev/docs/svelte/v5-migration-guide

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/phoenix-rules

I found that Copilot sucked for elixir.

But Cursor has been much better with suggestions for elixir codebases.

Probably still not as good as JS/Python but way way way better than Copilot.

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

I'm sorry you ran into problems repeatedly, and couldn't agree more. As much as we've aimed to innovate on customization, it does not have to be an either/or. We recognized this, heard a lot from the community, and the goal of our 1.0 was to focus ourselves very seriously on stability. Going forward we are going to continue to treat Continue as the foundational tool that we hope it can be. This has meant investment in testing, clearer contributing guidelines, and a general mindset shift to understand that AI code assistants have become fundamental to developer workflows and have to be rock solid (when something is doing work on every keystroke, it better not break!)

If you get the chance to try the 1.0, I'd love to hear whether you find it better, or if you think we can do even better—we think it's in a solid place and it'll always be improving from here.

What broke on you when using Cody? Sorry to hear about that and want to fix it for you.

Quick question, what do you mean by new pylance in cursor?

It's basically VSCode - I just ported all extensions in Cursor settings, it installed existing VSCode extensions including Pylance and it just works...

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?

Ooh +1 to both of these. We use shadcn as well :) and have been leveraging these docs: https://hub.continue.dev/vercel/shadcn-ui-docs, but there should totally be more in-depth rules for it and Firestore

I think Copilot plays an important role in the world of code assistants, and it's great that they've implemented Agent mode as well.

We'd actually love for them to take part in the standard we're building here—the more people build custom assistants together, the stronger the ecosystem can grow!

If I were to share any one reason why we continue to build Continue when there are so many other coding assistants, it really comes down to one word: choice. We hope to live in a world where developers can build custom prompts, rules, tools, etc. just like we currently build our own bash profiles, Vim shortcuts, and other personal or internal company tools. Lots of room and lots of space for many products, but we want to lead the way on allowing developer choice over models, prompts, and much, much more

Fix is released! Thanks for catching this so early

Should now be able to remix PyTorch rules for example: https://hub.continue.dev/starter/pytorch-rules/remix

Thanks for the report, we should be able to fix this in the next hour or so. A workaround would be to copy the YAML definition displayed on the page of the assistant / block you want to remix. Will keep you updated!