The AIDEs Framework: How We Built a “Theory of Everything” for AI Development Tools

We are living in genuinely interesting times. AI is disrupting software development at a pace where new models, tools, and practices appear almost daily. Many teams’ natural first instinct is to spend ever more time chasing updates.

After almost two years of AI product and market research at JetBrains, we’ve come to a different conclusion: the speed of change is not a problem, as long as you can see the bigger picture. We deliberately don’t try to track everything that happens. Instead, we try to understand where everything we observe comes from – and where it is ultimately going. That gives us a prism to look through, a filter that separates signal from noise. It’s also what saves us from change fatigue.

This post is about that prism. But before we get to the framework itself, let’s start where the webinar started: with what we actually see on the market today. Because you can’t build a useful model of the future without first building an honest model of the present.

What we see on the market today

Looking through our research, three things stand out.

First, AI is already a common part of the developer’s life. People know about it and use it not only at home but at their companies – including the big ones, which are traditionally the slowest to adopt anything new. We no longer question whether AI in software development “is a thing.” It’s here, and it’s staying.

Second, agentic coding is gradually becoming the new normal. More and more developers use AI coding agents that go beyond automated code edits – they actually delegate coding to agents. This fundamentally changes the development loop from “code → validate → fix” in an editor, to “plan → execute → review” in an agentic chat. The biggest push here came from Anthropic’s Claude Code, which by our estimates is used by around 8.5 million coding professionals, earns roughly $7B in yearly revenue, and is broadly considered the best AI coding tool across all categories. Its release also kicked off the race of IDE-agnostic CLI coding agents – with similar offerings now from OpenAI, Google, and a wave of niche players.

Third, AI agents have started moving to the cloud. Tools like Devin have existed for a while, but only now is this trend starting to actually mean something. With more capable models, more powerful agents, and developers better aware of what AI can and cannot do, developers are making a more conscious decision to delegate work to cloud agents, which are more autonomous by design. They still have heavy limitations, but they can already handle simple, low-effort “garbage tasks”, like fixing a linting error found during a CI run.

And yet, here is the paradox: even though everybody uses AI, we can’t say AI is used everywhere. In reality, AI is mostly used for just two main development activities: brainstorming and coding. But development is more than just coding. Many parts of the software development lifecycle remain largely untouched, creating enormous room for further adoption. AI use is growing steadily, but unevenly.

Before we talk about the future, let’s take a step back

The question everyone wants answered is: what’s the next big thing? But before jumping there, let’s take a small step back and look at the past. We have to build a proper model of reality first, and only then look at the future through it..

What has the evolution of AI in software development looked like so far?

It started with simple full-line code completion – AI within the scope of a single line.

Generative AI brought multiline code completion, the ability to complete whole chunks.

Better models and a focus on conversational flow made it reasonable to bring the whole chat into the IDE with AI assistants.

AI code editors, like Cursor and Windsurf, brought AI features to the entire development process, combining multiple parts into one context and flow.

Then came the agents, to whom we assign entire end-to-end tasks, with a distinct UI paradigm – agentic development environments.

And now those same agents are moving to the cloud and starting to do development work autonomously.

This reads less like a list of features and more like a trajectory. We can draw a line through these points and ask ourselves: what does this line actually mean? Why did all these embodiments of AI in developer tools show up in this particular order? And if we extend the line into the future, where does it lead?

A “theory of everything” for AI development tools

In early 2025, we were asked to collect insights to evaluate our AI strategy. While working on this, we were inspired to create a “theory of everything”: one that explains not only the current state of the field, but what is fundamentally possible. That’s how we ultimately arrived at our own theory of everything for AI development tools. We called it the Artificial Intelligent Development Environments Framework, or the AIDEs Framework.

Like any piece of theory, we started with definitions and assumptions. Definitions let us abstract away from current jargon and narrowed thinking; assumptions draw boundaries around the problem, making it possible to reason about it systematically. This is standard practice in any rigorous discipline, and it’s remarkable how rarely it’s applied to thinking about developer tools.

The definitions

Artificial Intelligent System (AIS): Any computer system created by humans that demonstrates the traits of “intelligence” while helping users achieve their goals (their Jobs-To-Be-Done). The key insight: people want to feel intelligence from their tools – but that intelligence doesn’t have to come from LLMs. Our IDEs were always considered “intelligent,” yet the core of their capabilities is built on deterministic heuristics. So the principle is: target the user experience of intelligence, not “AI everywhere.”

Artificial Intelligent Development Environment (AIDE): Simply put, an AIS for creating software. There is a huge set of tools used to create software, applied at particular stages of the process and at specific levels of work delegation. In other words: there is a big world outside of IDEs, full of opportunities we might not have considered yet.

Principal and Agent: Terms borrowed from economics and sociology to describe the relationship between two parties in a delegation. The principal is the party whose interests or objectives are being served, while the agent is the party entrusted to act on the principal’s behalf. But keep in mind that both the principal and the agent can be either a human or an AIS. That means we can consider scenarios where an AI principal delegates work to an AI agent, and even where an AI principal delegates work to a human agent.

Software Creation: We use this term instead of “software development,” as the latter might suggest that software is mostly about writing code. In reality, software creation involves many different roles. These roles can be understood as relationships of delegation: a product team may delegate implementation to software engineers, frontend developers may delegate UI design to UX designers, and so on.

The direction of delegation depends on your perspective. A software engineer may see a UX designer as someone they depend on for a particular activity, but from the perspective of the broader product team, both may simply be contributors to a larger process. In this sense, organizational responsibility is relative to the level and perspective from which you view the work. Adding AI does not fundamentally change this structure; it introduces another kind of actor that can participate in these relationships.

The assumptions

We started with four foundational assumptions:

1. Whatever the future becomes, people will still have the goal of creating software. We don’t believe demand for software will decrease or that humanity will find a completely different technology to replace it. On the contrary, digitalization will continue to be the primary driver of both productivity gains and personal evolution, so demand for software will actually increase. And at least in the mid-term, the basic principles of software development will remain the same.

2. The primary driver of change on the market will be the gradual delegation of software creation activities to artificial intelligent systems. Let’s be honest – we’re all a little lazy, and we’d gladly hand off the work we see as routine. All of human history supports this, from the division of labor, to automation, to digitalization – all of it was, at its core, delegation. Delegation is already present on today’s market. At higher levels, humans delegate to other humans (the most comprehensive IT solutions are still created collaboratively), and at lower levels we delegate to artificial systems through process automation. As AISs develop further, they will become essential actors in the division of labor itself – and the rising level of delegation to AIS will become the ultimate metric of their real capabilities and impact.

3. AIS will never fully replace humans, who will retain two key jobs: task specification and oversight. (The article “AI as Normal Technology” dives deeply into this subject.) AI will not “kill” the developer profession, but it will transform what the profession means. Today, high-level task specification and oversight among developer roles is typically done by architects, a senior grade earned over years. In the future, we might see the emergence of junior architects – a new category that would require rethinking not just roles, but the entire system of CS education.

4. With higher levels of delegation to AIS, personal “immersion” into specific development activities will decrease. Simply put: if you’re not the one doing the job, you’ll always know less about it than if you’d done it yourself. This is exactly what happens between human principals and human agents today. As developers delegate activities with lower added value (like code authoring) and focus on higher-value ones (like requirements formulation), their awareness shifts to a “higher level” of the project. This does not mean everyone goes full “vibe coding” (after all, current tools don’t offer solutions for high-level context communication and management). Future developers should be aware of their projects the way development leads are aware of the projects their teams deliver. Solving this “loss of immersion” problem is a prerequisite for elevating delegation – and this is why context abstraction and management of uncertainty matter so much in the framework.

The three dimensions of the framework

Our framework operates in three dimensions: stages of the software creation process, levels of delegation, and organizational context of development.

Dimension 1: Stages of the software creation process

The first dimension is a reworked take on the traditional software development lifecycle, focused on outcomes rather than process. We map 35 high-level activities grouped into 5 activity groups — from “Ideation and Conceptualization” to “Delivery, Maintenance, and Feedback Collection.” Any developer will recognize these immediately, so we won’t dwell on them here. Explore the interactive figure below.

Ideation and Conceptualization During this stage software creators ideate on original problem and potential solution, explore and come up with vision and high level concepts of what they want to create, identify a valuable opportunity and decide whether it’s worth pursuing.

Forms of deliverables

Idea / concept / vision

User story

Product Requirement Document (PRD)

Low fidelity proof-of-concept (PoC) or prototype

Activities

Brainstorming problem space (opportunities, pain points, user personas and their needs, market trends and requirements, opportunities by new technologies => WHERE we see a need for new software solution and WHY)

Brainstorming solution space (types of software, design / UX / user flows, current technology opportunities, target platforms => HOW we could solve the original problems and WHAT might the final solution might look like)

Low fidelity prototyping (with focus on user-facing parts or general technology exploration; including validation)

Documenting final concepts and vision

Planning, Design and Architecture During this stage software creators “operationalise” the initial ideas and concepts into the design of “engineering solution” – a more specific definition of what should be done from the perspective of system and software engineering. After this stage the developer (who will write code) should understand well what should be done, how it should be done and what are the acceptance criteria (“definition of done”).

Forms of deliverables

Project plan / roadmap / backlog

Software Requirements Specification (SRS)

System architecture design

UI / UX design

Software components design / class diagrams / DB schemas diagrams

Software Design Document (SDD) / blueprint

Set of more focused proof-of-concepts (PoCs) or prototypes, that could be reused in the final implementation

Activities

Defining general solution technical requirements and acceptance criteria

Selecting technology and tools stack

Specifying system architecture and composition

Breaking down implementation into specific tasks / features; defining requirements and acceptance criteria for each task / feature

Designing UI / UX / visual elements

Designing system components / data layers

Prototyping technical solutions

Implementation During this stage software creators create a codebase and related artifacts that realize the design and pass initial validation. In addition any activities that are required to create and validate this codebase / artifacts are also performed here (e.g. setting up DB, working with external services and / or creating custom tools).

Forms of deliverables

Solution codebase as complete solution, working increment or MVP

Activities

Setting up the development environment (including tooling set up, VCS, dependencies, run / build configurations / scripts)

Writing core business logic (data entities, data transformation functions, “behavioral” part of UI components)

Writing auxiliary infrastructure code (API controllers definitions, ORM mappers, utility / helper functions)

Writing code for styling / UX

Ad-hoc code validation (running, debugging, linting, profiling)

Setting up persistency and external services layers

Developing supporting tools

Writing documentation

Testing, Validation and Quality Assurance During this stage the created codebase is getting verified and validated against initial requirements, acceptance criteria and quality standards. The end of this stage means the software has passed QA – all critical defects are fixed, and stakeholders are confident in the product’s correctness and stability.

Forms of deliverables

General confidence the codebase is working as expected

Test summary report / validated test cases

Accepted code review

Activities

Developing the test plan and strategy; formulating test cases

Setting up test environment

Writing and running auto tests (unit, integration, end-to-end, regression)

Conducting manual testing

Conducting performance / load testing

Conducting security testing

Conducting usability testing

Doing code reviews

Delivery, Maintenance, and Feedback Collection During this stage the created codebase is getting delivered to the end users either via deployment (web production environment) or distribution (application stores, file storages, package repositories). In addition, this stage covers the “operational” state of the software solution, which includes maintenance (making sure the software is still available to end users) and feedback collection (for future improvements).

Forms of deliverables

Application code in web production environment

Application executable distribution in distribution channel

Solution codebase as a package / source code in distribution channel

Collected application and performance logs, usage metrics, user data / feedback

Activities

Planning the deployment and / or release approach

Writing production build configurations / scripts (e.g. Maven, Gradle, yarn/npm, Docker)

Writing production deployment configurations / scripts (e.g. Compose, Ansible, Terraform)

Setting up the production hosting environment / distribution channels

Creating deployment / release CI/CD pipelines

Managing cloud infrastructure (manually, via API, via IaС)

Monitoring the software in the production environment, including setting up monitoring infrastructure (CLI logs, exceptions, usage / performance metrics)

Collecting and analyzing data on user behavior and feedback, including setting up analytics / feedback infrastructure

Regarding our methodology: The taxonomy is designed to cover all types of development involving any roles within software teams (not just developers), yet is not so granular that we lose homogeneous groups of activities. The stages look like a linear workflow, but in reality developers jump between stages and between activities within a stage. These activities can also serve as a foundation for formulating high-level developer Jobs-To-Be-Done.

Dimension 2: Levels of delegation

This is the more novel dimension. Here we define the distribution of roles between principal and agent, along with 10 attributes of delegation – autonomy, level of planning, proactivity, and others. Different combinations of roles and attribute values define five levels of delegation:

L1 – Tool. Delegation of very limited, scoped actions. Code completion is the canonical example: you let AI finish writing what you’ve already started.

L2 – Assistant. Delegation of a well-defined sequence of actions – a “task” with very specific boundaries. One example might be generating a unit test for a specific function. Simple, well-defined, and minimal context – but it’s a task with a series of steps, not just one action. It’s like having a third hand: it’s doing the work, but it’s still your hand.

L3 – General-purpose Executor. This is where focus starts shifting from the process to the deliverables. An L3 agent can execute any task, but requires expert input from the principal, who acts as a “consultant” on more complex topics. Current agentic coding sits roughly here: we believe agents like Claude Code and Codex are well capable at code writing and low-level solution engineering, but we still don’t trust them with decisions about what should actually be built – that requires deeper knowledge of the business domain. So we fully delegate execution, but retain task setting and review.

L4 – Supervised Executor. Here we move beyond the individual space to the organizational perspective, because the agent is now responsible for an entire development function, like managing the backend implementation of your full-stack web application. It is “supervised” because the principal’s role narrows to approving key decisions; everything else the agent decides itself. This is also where we run out of real-world examples, except perhaps some usage patterns of vibe-coding platforms like Lovable or Replit.

L5 – Competence Center. Imagine you’re the CEO of a startup with an engineering team at your side. You define what the company wants to achieve, how you’ll do it, what the key metrics are, and whether you’re performing well. Your engineering team exists to execute your strategy and make your vision a reality. You don’t care what stack they use, what API structure the app has, or whether it’s hosted in Azure VMs or Docker containers on managed Kubernetes in GCP – you delegate those decisions to the team. That kind of delegation is L5.

Attributes View Levels of Delegation View

Select attribute

Why “How smart is the AI?” is not a dimension

You may have noticed something conspicuously missing here: there’s nothing about the raw capability of AI or how “smart” it can be. This omission is deliberate, for two reasons.

First, benchmark performance does not automatically translate into real-world delegation. AI models can achieve remarkable results on standardized tests and still struggle to earn enough trust from people to perform even relatively simple tasks autonomously. Thus we might see an AI model having top-notch benchmark results but surprisingly little economic impact. Conversely, a deterministic system that effectively orchestrates a set of less capable agents can potentially produce more useful work than a single super-smart AGI.

Second – and this is the deeper point – everything we’ve described is not an attribute of the agent, but an attribute of the relationship between the principal and agent. The level of delegation is a decision made by the principal, based on their personal perception of the agent. A developer may delegate code writing to Junie at L3 and let it execute a task end-to-end, but for more critical cases they’ll switch to L2, put Junie “on a leash,” and feed it much narrower tasks. Even if the agent is capable of L3, there will be scenarios where the principal chooses to delegate less. The level of delegation is not an attribute of Junie – it’s an attribute of the “agentic contract” between the two, and the principal is the one who sets its terms.

Even when AI is technically capable of doing the job, it’s humans who decide how much control to let go of.

Dimension 3: Organizational context of development

The third dimension describes the organizational context in which development happens. We differentiate three contexts:

Individual – development done solo or in small informal groups (hobby, education, open-source, one-person startups, freelancing). Tooling requirements are relaxed and preference-driven, stickiness is low, and budgets are limited – free options are preferred over paid ones even when the paid experience is superior. Codebase size and complexity are limited, and requirements for the final software (quality, security, reliability, process standards) can be quite low.

SME – development within small and medium companies, startups, and highly autonomous teams inside larger enterprises (“internal startups”). Production-grade commercial applications, modern technologies, teams of professionals making most decisions themselves with light coordination from tech leadership. Speed and agility are the key goals, and technology, processes, and tooling all bend to maximize them. Tooling price is rarely an issue – salaries and infrastructure dominate the cost structure.

Enterprise – development within large commercial companies. Very large projects (including large monorepos), legacy code, formalized and strict quality and process standards, and hard requirements on technologies and tooling. Often with special compliance and security needs (zero data retention, private cloud, on-premises) and expectations of enterprise CX (centralized user management and billing, dedicated support, custom integrations). Technology and purchasing decisions are centralized, with a strong focus on minimizing transactional costs.

These contexts define different constraint types and different complexity of organizational dynamics – which are later reflected in the complexity of development decisions and, ultimately, the codebase itself. We added this dimension primarily so we never forget this aspect – and we already see certain things becoming relevant specifically at the scale of large organizations.

Putting it together: the map

Now, remember our “timeline” picture from earlier? Through the lens of the framework, it becomes obvious that the line running through it is, at its core, the level of delegation dimension. But since the model is richer than a single line, we can also track how AI penetration grows across SDLC activities and how it differs across organizational contexts.

In our regular surveys on AI usage, we have a dedicated section on exactly this, which lets us build what we call AIDEs maps.

ChatGPTClaude Code

Not used (0)

Tool (1)

Assistant (2)

General-purpose Executor (3)

Supervised Executor (4)

Competence Center (5)

Problem brainstorm

Solution brainstorm

Low-fi prototyping

Concept documenting

Requirements definition

Tech stack selection

System architecture

Tasks formulation

UI/UX design

System design

Solution prototyping

Setting up dev environment

Coding business logic

Coding infra code

Coding styles / UX

Code validation

Persistency / external layers

Coding tools

Writing docs

Planning tests / test cases

Setting up test environment

Coding / running autotests

Manual testing

Performance testing

Security testing

Usability testing

Code reviews

Planning deployment

Coding build scripts

Coding deployment configs

Setting up production environment

Creating CI/CD pipelines

Managing cloud

Monitoring

User data analysis

Not used (0)

Tool (1)

Assistant (2)

General-purpose Executor (3)

Supervised Executor (4)

Competence Center (5)

On a map like this, we can see where ChatGPT and Claude Code are used, at what level of delegation, where they are not used, and how they compare to each other – all at the same time. And because we collect such data regularly, we can track the dynamics over time.

What the framework predicts

So, we have a holistic model. We’ve mapped where we’ve been and where we are. Now we can finally look forward.

Our data shows we are just in the middle of the map, at the L3 “General-purpose Executor” level, with cloud agents only beginning to touch L4. We still see gaps across the SDLC, so there’s plenty of room to grow, and the next stage of evolution is easy to imagine just by looking at the map. But the framework describes fundamental forces, a formal model of reality – which means we can go further and start imagining the more distant future at its “final stage.”

Ask yourself: what does the L5 “Competence Center” state of the world look like, where we can delegate development to an intelligent system not merely as a set of tasks, but as a competence? What does the process of creating software look like there? Does it still live within the DevOps operational loop, or does a new flow emerge? Thinking back to our assumptions about task specification and oversight: what exactly will human developers be doing?? What will the very experience of creating software feel like?

We could reflect on these questions forever. Here’s what we believe the primary direction will be.

First: the rise of abstraction. Developers will think less about the code itself and more about actual solution engineering – architecture, composition, data and user flows, and business impact. This is remarkably similar to what happened with low-level programming: today we rarely think about how our code runs on hardware; we operate through abstractions embedded in languages and frameworks. The same will happen with code in general. The focus shifts from “how to build” to “what to build and why”. The good news is that this isn’t new for developers. It’ll just become the core of the work.

Second: vertical integration of AI in all parts of the software development lifecycle. Today AI lives primarily in our IDEs or chat applications, which limits its context span. The systems of the future will integrate AI throughout the SDLC end-to-end. But this doesn’t simply mean “AI becomes part of a big development platform” – we’re headed somewhere more interesting.

Third (and potentially the most fascinating): people will stop treating AI as a tool and start treating it as an “intelligence resource.”

Consider any production process, like making furniture. We start with raw materials and transform them into an end product. Wood planks become a table. Software creation is also a production process, and the end product is a piece of software. But what, then, is the raw material?

It’s intelligence. For a long time, we humans were the only source of it. Within organizations, intelligence was a capability inseparable from the people who possessed it. Now LLMs are introducing a second source of intelligence – one that can be treated as a variable resource, just like any raw material.

To stick with our “furniture factory” analogy: when organizations understand that AI is not just a hammer, but the wood itself, we may experience a fundamental shift in how development is done.

We might end up with something like Agentic Software Production Platforms – vertically integrated software production systems where AI works as an input “intelligence resource,” structured around the main layers of work management – intent management, execution, and governance – rather than around the DevOps cycle, with human developers managing the production system itself.

How to prepare for the future

Exciting, and perhaps a little unsettling. So what can you personally do to prepare?

First, an important caveat: I’m not claiming to know exactly what type of future we’re headed toward (or when exactly we’ll get there). Our framework merely describes what’s fundamentally possible given the key forces driving the evolution of software development. That’s the honest boundary of any model. But understanding these forces does give you a decisive advantage in navigating whatever future actually unfolds.

So here’s the practical method – the same one used by JetBrains:

Examine our core assumptions. Does AI really expand the opportunities for delegating development work? Can it act as an “intelligence resource”? Is it possible to ultimately have “hybrid” teams of human developers and AI coworkers? Is something else going on entirely?

Build your model – then commit to it. Build your own model of reality (or borrow our AIDEs Framework), accept it, and start asking questions within its conceptual boundaries: What will my responsibilities as a developer look like? Which skills will become more relevant? If the future is about “management of delegation,” will certain managerial skills become a must? And if we stay in pure engineering: will everyone become a software architect, with senior, middle, and even junior architect roles? Which of those skills do I already have? Which do I need to develop? Am I ready to change?

Observe and validate. Watch the world and test your model and assumptions against it. Change doesn’t happen overnight – it’s a continuous process, and there will always be friction and inertia. A model you never validate is just an opinion.

And if you’re an engineering leader, your objective is considerably harder: you’ll need to rethink how the development process itself is structured, and how AI as an “intelligence resource” should be embedded into processes where intelligence is already present as a human capability. That deserves a dedicated discussion of its own – and we at JetBrains already have our own vision. Stay tuned.

Watch the full webinar recording: AIDEs Framework – the webinar.