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

以下正文同步自 JetBrains Blog，版权归原站所有，已转换为易读排版。

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 an

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。