Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hub.continue.dev

Post reply on HN
Print view View original

21–30 of 113 posts

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

#21

Post by sestinj »

bhouston wrote: post #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…

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

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

#22

Post by thelastbender12 »

Congrats on the release! I've been using Cursor but somewhat annoyed with the regular IDE affordances not working quite right (absence of pylance), and would love to go back to VSCode.

I'd love it if you lean into pooled model usage, rather than it being an addon. IMO it is the biggest win for Cursor usage - a reasonable num of LLM calls per month, so I never have to do token math or fiddle with api keys. Of course, it is available as a feature already (I'm gonna try Continue) but the difference in response time b/w Cursor and Github copilot (who don't seem to care) is drastic.

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

#23

Post by paradite »

I think this is an interesting pivot, but Cursor's project level rules and custom modes will probably quickly evolve to cover all the aspects listed on your hub. (Maybe it already does)

This also allows developers to switch between projects quickly while simultaneously also switching the setup for the AI agent.

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

#24

Post by bhouston »

r_singh wrote: post #18
bhouston wrote: post #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…

> 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/building-an-agentic-code-from-...

- https://benhouston3d.com/blog/agentic-coder-automation

- https://news.ycombinator.com/item?id=43177117

- https://benhouston3d.com/blog/the-rise-of-test-theater

My findings are generally that agentic coders are relatively interchangeable and the reason they work is primarily because of the LLM's intelligence and that is a result of the training they are undergoing on agentic coding tasks. I think that both LLMs and agentic coding tools are converging quite quickly in terms of capabilities.

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

I've run into this wall as well. I am working on it right now. :) Here is a hint of the direction I am exploring:

https://benhouston3d.com/blog/ephemeral-software-in-the-era-...

But using Github as external memory is a near term solution:

https://benhouston3d.com/blog/github-mode-for-agentic-coding

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

#26

Post by bhouston »

sestinj wrote: post #21
bhouston wrote: post #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…

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…

> Does it need to be decoupled from package.json, etc.?

Knowledge packs should be decoupled from package.json just as eslint rules or commit-lint rules are. You can include them in package.json or in separate files. But including pointers to the main files in a package.json helps with discovery.

All packages across all languages should support AI friendly knowledge packages so a level of decoupling is required.

EDIT: After thinking about it I think README.md should just be written with Agentic Coders in mind. I wrote up my thoughts on that here: https://benhouston3d.com/blog/crafting-readmes-for-ai

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

#27

Post by sestinj »

orliesaurus wrote: post #19

Any benchmark vs just using Claude-Sonnet-3.5/3.7 to see if there's actual a performance gain rather than just a well defined PRD/prompt/context?

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

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

#28

Post by serjester »

I think I have trouble understanding what this is doing other than maybe some fine-tuned prompts tailored to a specific stack? I'm looking at the data science kit and I don't see why anyone would use this, much less pay for it?

I guess you guys have some MCP connections too, but this seems like such a marginal value add (how often am I really pinging these services and do I really want an agent doing that).

Regardless congrats on the launch.

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

#29

Post by atonse »

sestinj wrote: post #14
thomasfromcdnjs wrote: post #11

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

I'm of two minds. I currently use 3 MCPs regularly (Atlassian, Git, and GitHub). And I suppose if GitHub or Atlassian actually hosted first-party MCP endpoints for their services, we probably wouldn't need to self-host?

But I wouldn't want to have a third party host where, all they're doing is just running the npx/uvx command themselves and I still have to give them keys, etc.

At that point, I'd rather just host them locally.

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

#30

Post by prophesi »

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.

Post reply on HN