Continue 1.0
The next step towards a future where developers are amplified, not automated
Large Language Models (LLMs) are powerful, general text manipulators. To learn to use them while programming, you need to be intentional. Once you start, you won’t be able to go back to how you used to code. You will have begun a journey that all developers will be embarking on.
Similar to how we moved from assembly to higher-level programming languages, we are at the beginning of a transition where we effectively end up one abstraction level higher. This transition will rewrite the architecture underlying how software is built.
Those of us working together towards an open architecture aim to customize together and become amplified developers. Those resisting this paradigm shift or using closed architectures risk being automated over the coming decades.
With Continue 1.0, we are charting a path forward for how the open, AI-enhanced developer tools of today can evolve into an open architecture for tomorrow, so that we can ensure developers are amplified, not automated.
Today: Open tools
Open, AI-enhanced developer tools exist because they enable us to customize.
We need customization because every developer, every team, every organization is different. Each of us has our own unique skills, development practices, and environments. No one vendor or one solution will be able to give developers everything they need.
AI-enhanced developer tools will give developers superpowers, but only if they don’t require us to completely upend our existing software and workflows.
This is why so many developers are building open, AI-enhanced developer tools. They need to make it easier for themselves to use LLMs. Many of them are sharing about their experience: LLM, Aider, Tabby, Cline, Open Hands, Goose, aidev, e2b, Cody, Daytona, Sketch, and Continue. They each have their own ways of using LLMs, and their different situations lead to different requirements.
These early pioneers are not alone—every developer needs tools that can be customized to their situation. But very few people will go as far as creating and maintaining their own tools. Some developers will make customizations to open tools, while almost everyone else will just use those customizations.
Tomorrow: Open architecture
An open architecture for AI-enhanced developer tools is coming into existence because it enables us to customize together.
Customizing together means that everyone benefits from the work of all others. Up until now, customizing open, AI-enhanced developer tools has been difficult, laborious, and bespoke. But open tools have laid the ground work for an open architecture to emerge, which can make it far more playful, seamless, and shared.
So, how can the open, AI-enhanced developer tools of today evolve into an open architecture for tomorrow?
1. Define simple building blocks
AI systems made out of simple building blocks that allow for bottom-up emergence work better than complex, top-down designed AI systems. In the realm of AI-enhanced developer tools, we need building blocks that some create and everyone can combine together, but what are these simple, interoperable blocks?
With Continue 1.0, our community has helped us define seven building blocks so far: models, rules, context, docs, prompts, data, and MCP. These blocks will evolve over time, and new ones will emerge, as developers determine the customizations they want and need.
2. Align on a standard packaging format
Blocks are a great first step but alone they are not enough. Most developers want nearly complete AI-enhanced developer tools, so we need an easy way to package blocks into a full configuration. Without friction, we should be able to just grab a custom AI-enhanced developer tool and try it out. There needs to be a standard way to specify a set of blocks that go together.
With Continue 1.0, we are standardizing on config.yaml as our packaging format. Our approach to packaging configurations is through an open format that we plan to evolve over time. For example, we intend to decouple the parser for the format from our open-source IDE extensions and make it available to others.
3. Cultivate a culture of contribution
In the pursuit of their own “selfish” customizations, some developers can create value for everyone as an automatic byproduct—by making their customizations available for others to use. This is where a registry for defining, managing, and sharing blocks and configurations comes in. The open architecture needs to be designed for user contribution, so that an architecture of participation can emerge. That is, we need to make it as easy to give back as selecting “public” visibility.
With Continue 1.0, we are enabling developers to create and share custom AI code assistants at hub.continue.dev. This registry will be a place of discovery within and across organizations, which will evolve in lock step with the evolution of blocks and open AI-enhanced developer tools.
4. Make it easy to customize open tools
A standard standard packaging format for these defined blocks and a place to find them makes it easy for developers to customize any open tool that adopts this approach. Developers can understand how a particular tool works and then choose the blocks and config that works best for it. With open tools, developers maintain control of their data, so they can use it to guide their customizations and decide when they let others use it to create better building blocks.
With Continue 1.0, our open-source VS Code and JetBrains extensions can seamlessly use any config.yaml, which are easy to find on hub.continue.dev. Over time, we plan to make it easier for other open tools to adopt this approach.
The coming decades
When a new tool enters your workflow, it changes how you think. As software development is increasingly automated, we need to be able to shape AI-enhanced developer tools, so that we can shape how we think. But AI is not going to magically do everything. When it works for us, we will move toward higher levels of abstraction. When it doesn’t, we should be able to do something about it.
The role of the software engineer will increasingly involve customizing and using the AI-enhanced developer tools that write more of the code. This is only possible in a world built on an open architecture that does not place limits on what and how you customize. Try out Continue 1.0 yourself now!