Published on

Prototype Features

Written by
Varun Mohan, Douglas Chen
High-tech laboratory

tl;dr We plan to explicitly call out experimental features as Prototype features so that our users and customers know where we are still actively iterating and gathering feedback on, without guarantees on what the end state looks like.

Background and Motivation

In the last few months at Codeium, we have reached the realm of “we don’t really know whether new features will definitely drive more value to our users.” We had built autocomplete and chat, state of the art proprietary code LLMs, a full codebase aware context awareness engine, integrations into over 40 IDEs, and a number of other things that we knew would drive value going in. There was no question we would build, productionize, and maintain these. But what is next?

There are a lot of demos of new features and capabilities on the internet, some of which are very flashy, but we are not convinced that they truly drive value. We have worked in this space for long enough to have some humility in the face of both the novelty and complexity of this technology and the difficulty to get widespread adoption amongst developers. So, in the ideal world, we would develop these potential features and capabilities quickly, test their effectiveness, and make this judgment call for ourselves, armed by real data.

However, while there are some things we can A/B test without our users having to learn anything new, such as new models or changes to our context awareness engine, a lot of the things we would like to test are visible to the developer, and sometimes require explicit developer interaction. These would include recent features like our GPT4 integration and Codeium Command. We have many reasons to believe that these will indeed drive value, but are they robust enough? Valuable enough? Adopted well? Cost-effective enough to serve? We don’t know until we try.

Prototype Features

Enter, Prototype features. We have a lot of ideas where AI in the software development life cycle is going and want to ship quickly to test these, and not just develop in the dark. At the same time, however, we want to be transparent to you about where we are still experimenting so that, if we make changes or completely roll back the feature, we don’t lose your trust. Prototype features are like rapid-fire MVPs when spinning up a new product, except as facets of a product (Codeium) that has other preexisting features that are well-tested and drive a lot of value.

Why use the term “Prototype” instead of the often used “Beta”? To us, “Beta” conveys the sense that we know for a fact that the feature is going to work and just needs some tweaking and tuning, while “Prototype” more accurately communicates that we have a lot of reason to believe that something will have value, but there will be work required to reach there, if we reach there at all.

Not all features will be Prototype features. There are a number of features, capabilities, and even entirely new modalities that we are either convinced will drive meaningful value, or are important to us for other reasons. Those will just be launched as normal.

What You Should Expect from Prototype Features

While in the Prototype stage, to minimize our engineering overhead, the feature will likely come to only one or two IDEs, particularly Visual Studio Code due to the ease of publishing extensions on the VSCode Marketplace and the extension auto-updating functionality of the IDE. Access will be gated behind user lists, which will be collected via waitlists posted on Discord and social media, so that we can survey and follow up with the users trying these features out. We will likely also figure out a permanent early access system so folks who like being early adopters won’t have to keep filling out waitlists, but more to come on that.

All Prototype feature announcements will be clearly marked as such, and any tags or mentions of “Prototype” will be removed once we have verified that this is something we want to continue developing, after which productionizing across IDEs and our enterprise plans will shortly follow. In these Prototype announcements, we promise that we will clearly articulate why we are building and testing the feature (the rationale behind the Prototype), why we are not sure if it would work or be adopted, and if relevant, potential directions the feature could go depending on feedback.

To be clear, there are no promises that a Prototype feature will be productionized long-term for either individuals or enterprises, or that the feature will look the same or similar to the initial release. We do not believe in shipping features for the sake of shipping features. If the features don’t drive meaningful value, we are doing you a disservice by investing a bunch of development time productionizing the feature more broadly and maintaining it indefinitely.

Conclusion

We debated for a while how we wanted to communicate our development with you, the users that expect us to keep building more and more powerful systems. We believe Prototype features will allow us to both demonstrate our speed while communicating the reality that no one has “the answers” in this space.

For all Prototype feature announcements, please click below:

Explore more

Jun 11, 2024enterprise7 min

A deeper dive into recent enterprise readiness capabilities: indexing access controls, subteam analy...

Apr 30, 2024enterprise1 min

WWT uses Codeium to accelerate their developers.

Apr 18, 2024company1 min

Codeium is the only AI code assistant in the 2024 Forbes AI 50 List.

Stay up to date on the latest Codeium & AI dev tool news

Please enter a valid email address