Live data from Hacker News

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

hub.continue.dev

71–80 of 113 posts

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

#71

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

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

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

#74
post #68

Earlier quoted context omitted.

What I meant to ask is, instead of pushing your code to Github, is it possible to use a local self hosted instance of a similar tool like GitLab or Bitbucket?

It is just a prompt change if there is a cli tool for GitLab or Bitbucket. I just tell Claude to use the gh cli tool and to use it as external memory to track tasks and to submit PRs.

I see, so it depends on a cli tool being available. I will check what other options are available out there.

It would be great to run local models at the same level one day. I am sure that Claude is making your wallet feel quite light :)

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

#76

Go read "The Bitter Lesson" and then ask yourself which path this startup took.

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.

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

#78

How is this customisation not equivalent to just a cursor or windsurf rules file?

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

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

#80

Is this something that could help people write code using my framework (tscircuit) more easily? I'm confused how I could add docs/recommend users to use Continue with a custom tscircuit assistant

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

Post reply on HN