Actually very similar, GitHub was also early in talking about Continuous AI. I think the biggest difference is that Continue is very focused on the use case of checks and gets a lot of the small details right that really matter because it's not built for generic non-AI CI workflows
Some of these are:
- Having a local experience to run them with Claude Code, etc.
- Making it easy to accept/reject suggested changes
- A single folder dedicated to just checks so you don't have to think about triggers
- Built-in feedback loops so you can tune your checks with feedback
- Metrics so you can easily track which have a high suggestion / merge rate
- we do! right now you can export some metrics as images, or share a link publicly to the broader dashboard. will be curious if others are interested in other formats https://imgur.com/a/7sgd81r
I think this is a good summary! And the configurable part turns out to be the main bit
One of the fundamental differences between checks and code review bots is that you trade breadth for consistency. There are two things Continue should never, ever do:
1. find a surprise bug or offer an unsolicited opinion
2. fail to catch a commit that doesn't meet your specific standards
- a _lot_ of people still use the VS Code extension and so we're still putting energy toward keeping it polished (this becomes easier with checks : ))
- our checks product is powered by an open-source CLI (we think this is important), which we recommend for jetbrains users
- the general goal is the same: we start by building tools for ourselves, share them with people in a way that avoids creating walled gardens, and aim to amplify developers (https://amplified.dev)
Continue is building an open-source AI code assistant along with a hub of models, rules, and tools. Our VS Code and JetBrains extensions are primarily written in TypeScript, but we write small amounts of Kotlin (for JetBrains), Rust (for performant codebase indexing), and Go (for easy distribution of a CLI).
We're hiring for junior, mid-level, and senior full-stack software engineers.
Some of these are:
- Having a local experience to run them with Claude Code, etc.
- Making it easy to accept/reject suggested changes
- A single folder dedicated to just checks so you don't have to think about triggers
- Built-in feedback loops so you can tune your checks with feedback
- Metrics so you can easily track which have a high suggestion / merge rate
Are you using a lot of `gh-aw`?