The Code AI Maturity Model and What It Means For You

When software can build software, what remains the developer’s responsibility? Writing a function, reviewing a proposed change, and validating a finished product are different kinds of work. A useful maturity model needs to distinguish them—not simply count how much code an assistant generates. Ado Kukic, Sourcegraph’s director of Developer Relations, introduces the Levels of Code AI as a framework originally used internally to educate customers and guide the company’s thinking. He positions Cody as an assistant that knows the entire codebase, describing that capability as unique to Sourcegraph’s product. The framework became a starting point for discussion with the broader community at the AI Engineer Summit.

Kukic defines Code AI as software that builds software. In this 2023 presentation, he reports that 92% of developers use Code AI tools, compared with 1% a year earlier. The contemporary survey behind a similar 92% headline covered 500 U.S. developers at large employers and measured self-reported use at work or personally; it does not establish worldwide adoption or the 1% baseline. Kukic also relays Sourcegraph CEO Quinn Slack’s prediction that AI would write 99% of code within five years. That is a forecast from the talk’s historical context, not a measured result.

The framework divides six levels into three broad categories:

• Human-initiated code: humans remain the primary coders, with AI assisting their work.
• AI-initiated code: AI begins taking a proactive role in software development.
• AI-led code: AI has full autonomy over a codebase.

The progression concerns both capability and responsibility: what the assistant can produce, what starts its work, and where a human must remain involved. Kukic uses the SAE levels of vehicle automation as a recurring analogy for these changes in control.

Level 0 starts with the developer doing all the coding. Writing, testing, and debugging are human responsibilities. An IDE may offer symbol-name completion, but AI neither generates nor modifies the codebase. This is the traditional development workflow before AI assistance. In the driving analogy, the human handles acceleration, steering, braking, and everything else.

At level 1, the developer supplies intent and AI fills in code. Suggestions may be a single line or an entire block. For example, a developer writes a function signature, and the assistant infers an implementation from it. Kukic describes training on millions of lines of open-source code as the foundation for these completions: the assistant draws on broad programming knowledge, guided by what the developer is currently writing.

The corresponding driving assistance is cruise control or lane centering. These features make a task easier while still requiring the driver’s full attention. Likewise, a completion helps with implementation without taking over responsibility for the development workflow.

At level 2, the assistant gains specific context about the codebase it is working in. Broad programming knowledge can suggest a plausible implementation; repository context helps it choose an implementation that belongs in this application.

Kukic’s example is a Node.js application that already uses Axios for HTTP requests. An assistant with that context should suggest Axios, rather than introducing Fetch or SuperAgent. The distinction is not whether those alternatives can make an HTTP request. It is whether the suggestion follows the application’s existing library choice.

For a concrete JavaScript illustration, suppose the developer needs a function that retrieves a user record. A completion consistent with the Axios example could be:

import axios from "axios";

export async function getUser(baseUrl, userId) {
  const url = new URL(`/users/${encodeURIComponent(userId)}`, baseUrl);
  const response = await axios.get(url.href);
  return response.data;
}

The user endpoint gives the example a specific task; the source-grounded distinction is the choice of HTTP client. The assistant uses knowledge of the repository to narrow the implementation it proposes.

Kukic pairs this with partial driving automation: traffic-aware cruise control or automatic lane changes can perform more of the immediate work, but the human remains in control and can override the vehicle. More context improves the assistance without removing human authority.

At level 3, the input becomes a high-level requirement, and the output becomes a code-based solution. The assistant moves beyond individual snippets to complete components and integrations with other software. Kukic’s example is adding user authentication to an application: the developer requests the capability, and the assistant generates the required code.

The assistant then explains what it wrote, how the implementation works, and how it integrates with the rest of the application. This explanation matters because the developer is now evaluating a larger solution than a completion inside a function. In the driving analogy, level 3 is where the vehicle takes the primary driving role, with the human available as a fallback. If the vehicle encounters a task it cannot perform safely or adequately, it hands control back.

Level 4 changes who initiates the work. The assistant can proactively handle coding tasks without a developer supervising their execution. Kukic proposes two background workflows:

• Documentation maintenance: monitor code changes continuously and submit pull requests that keep documentation current.
• Bug fixing: monitor customer bug reports and submit pull requests addressing the reported issues.

These are proposed capabilities of the level, rather than a live demonstration of either workflow.

The developer can then review and merge the pull requests. That boundary makes the meaning of autonomy precise: the assistant independently identifies and carries out a task, while the proposed changes still pass through a human merge decision. Autonomous task execution does not, in this example, imply autonomous release.

The driving comparison is automation under specific operating conditions. Kukic points to Waymo’s driverless taxis, describing service in cities with high-quality mapping data. Within the service’s operating area and availability, a passenger hails a vehicle through an app and provides a destination; the vehicle completes the trip without further human driving input. The analogy illustrates independence within a bounded setting, rather than the ability to operate everywhere.

At level 5, the assistant handles the entire software development life cycle with minimal human guidance on code generation. The developer supplies high-level requirements and specifications. The AI designs the architecture, writes production-quality code, handles deployment, and continuously improves the codebase. Deployment and ongoing improvement are part of the level’s definition, not tasks left outside the assistant’s remit.

The developer’s remaining responsibility is to validate that the end product meets the stated requirements. That validation need not involve examining the generated code. The shift is from approving implementation changes to accepting the resulting product, while the assistant has autonomy to take code from concept to production.

Kukic completes the analogy with a level 5 vehicle that performs all driving tasks under all conditions, with humans optional. In his framing, neither a steering wheel nor a human override is necessary: the vehicle makes the decisions. This is the conceptual endpoint of the presentation’s autonomy comparison.

The six levels are offered as Sourcegraph’s working framework, open to agreement and disagreement. Kukic closes by inviting discussion at Booth G5 and encouraging attendees to install Cody in their IDE through the then-current cody.dev invitation. The framework leaves a concrete question for that discussion: as an assistant gains responsibility, should the developer be writing the implementation, reviewing its changes, or validating the product it delivers?