Launch HN: Continue (YC S23) – Create custom AI code assistants (hub.continue.dev)

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!

Appreciate it!!

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

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.

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!

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

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

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!

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?

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

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

I was expecting more than "have a readme" tbh

On one hand, I think it would be useful to have a couple of benchmarks for super common tech stacks like Python, React, etc. that allowed comparing variants of rules to find the best ones. On the other hand, if something can be turned into a benchmark then it can probably be learned in the weights of a model.

A lot of the benefits of rules are completely unique to your situation and the definition of “better” is likely to differ between people. I think the videos above are the best way I currently have to display this.

There are potential solutions though to measure improvement, and we actually made it possible for you to obtain the necessary data. If you add a “data” block to your custom assistant you can capture all of the accept/reject, thumbs up/down, etc. data and use it to do an analysis. We definitely will be working more in that direction

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

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?

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

My main gripe with Cursor is that they put MCP usage behind a paywall and their support for the protocol is weaker than Continue's in meaningful ways[1]. Given the big community push on MCP development, I'm a bit annoyed that Cursor monetizes OSS work with a paywall...

[1]https://modelcontextprotocol.io/clients

Agreed! If there's value here, they'll definitely follow behind and have already taken their own creative steps.

One interesting note is that rather than a pivot, the hub was just a continuation of work we'd already been doing—we had a configuration file that tons of people were customizing, but it was just a bit too complicated to get started, so we decided to make that "1 click" easy with the hub

In the long run, we feel that it's not the "features" in the IDE that will separate different AI coding tools (most are a matter of building out new UI), but that the ecosystem will be one of the biggest differentiators

I guess you would be paying for pushing all of these tokens to the LLM. Also, too much irrelevant context can "confuse" the model about the task at hand

You're 100% correct, most models these days know most programming languages and will quickly learn the syntax of more niche languages.

For users that end up benefitting from rules, it's typically because of encoding "personal knowledge" or "preferences". When building small side projects from scratch, this typically matters much less: you probably want it to "just work" using the canonical tech stack. Pretty quickly though projects end up with a lot of implicit knowledge and idiosyncratic practices that are great candidates for custom rules!

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

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

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

thanks!!

Nothing built-in yet, but if you have a service that lets users pay for API keys then you can achieve this in effect. There are already some good examples:

- Models like Relace's Instant Apply (https://hub.continue.dev/relace/instant-apply)

- Codebase context services like Greptile (https://hub.continue.dev/continuedev/greptile-context)

- MCP servers for services like Exa (https://hub.continue.dev/exa/exa-mcp)

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

:D thank you!!

I hear this often (I had the same gut reaction before thinking below the surface) and will share why I think that our bet is perfectly aligned with the Bitter Lesson being true

1. The Bitter Lesson extends to test-time compute (some call this the "Bitter-er Lesson" https://yellow-apartment-148.notion.site/AI-Search-The-Bitte...), and we've bet that agentic LLMs will become a major transformation in how software is built. Agent mode (https://docs.continue.dev/agent/how-to-use-it) is here to stay. This means that models are going to take very extended action for you. It could be 1, 15, 60, or more minutes of work at a time without requiring interjection. As these trajectories become longer it becomes _more_, not less, important to give the model the correct initial conditions. This is the role of rules and prompts.

2. Cheap inference matters and the trend in frontier models (for those watching) is distillation, not increased parameter count. There's great reason to believe that we're headed toward a future where a few billion parameter model can contain all of the reasoning circuits necessary to solve difficult problems and that when combined with a massive context window will become the "engine" in every AI tool. The difficult part is obtaining that context, and if you watch the actions of people who work at companies, a large majority of their time is spent on reading, writing, sharing the right context with each other.

3. My co-founder Ty wrote a piece 2 years ago describing the path where language models automate increasing amounts of software and we use live coding interaction data to make them even better, in a positive feedback loop of automation: https://blog.continue.dev/its-time-to-collect-data-on-how-yo.... If you believe in this future, then you're going to want to collect your own data to post-train (e.g. https://arxiv.org/pdf/2502.18449v1) rather than letting another tool absorb all of the intellectual property without giving it back. They aren't going to train a model that knows the private details of every company's workflows, they will train on a distribution that helps primarily with the most basic tech stacks.

4. No matter how many parameters a foundation model has, there's no way for it to know in the weights that "We (at some particular team within some larger company) organize our unit tests into separate files for selectors, actions, and tests" (e.g. https://hub.continue.dev/continuedev/playwright-e2e-test). This is purely team knowledge and preference, and is often private data. The next thought in the chain here is "can't it just use tools to inspect the repository and find this out?". And the answer is absolutely, but that quickly gets expensive, slow, annoying. And you're going to end up writing a rule to save both money and time. Next: can't the model just write the rules for me? Again, absolutely! We're working on this. And to us the natural outcome of this is that the model writes the rules and you want to share this potentially expensive "indexing" step with your team or the world.

5. Probably the most obvious, but worth saying: advanced language models will use tools much more. Hooking up the right MCP is a non-negotiable part of getting out of the way so they can do their work.

Totally, I actually think this would make for a really great custom assistant, probably even something we'd feature on the front page: https://hub.continue.dev/explore/assistants

You could start here by adding a new block for docs: https://hub.continue.dev/new?type=block&blockType=docs

Rules are a subset of what we've allowed you to do on the Hub (and an important one). There are other building blocks, like models, MCP servers, docs, prompts, data, and more. We want to make all of this easy to customize

thanks!