{"slug": "the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools", "title": "The AIDEs Framework: How We Built a “Theory of Everything” for AI Development Tools", "summary": "JetBrains Research has developed the AIDEs Framework, a model for understanding AI development tools, after almost two years of AI product and market research. JetBrains estimates Anthropic's Claude Code is used by around 8.5 million coding professionals and earns roughly $7 billion in yearly revenue, and identifies agentic coding and cloud agents such as Devin as emerging trends. JetBrains reports AI is mostly used for just two development activities, brainstorming and coding, leaving much of the software development lifecycle untouched.", "body_md": "## JetBrains Research\n\nResearch is crucial for progress and innovation, which is why at JetBrains we are passionate about both scientific and market research\n\n# The AIDEs Framework: How We Built a “Theory of Everything” for AI Development Tools\n\nWe 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.\n\nAfter 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.\n\nThis 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.\n\n## **What we see on the market today**\n\nLooking through our research, three things stand out.\n\n**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.\n\n**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.\n\n**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.\n\nAnd 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.\n\n## **Before we talk about the future, let’s take a step back**\n\nThe 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..\n\nWhat has the evolution of AI in software development looked like so far?\n\n- It started with simple **full-line code completion** – AI within the scope of a single line.\n- Generative AI brought **multiline code completion** , the ability to complete whole chunks.\n- Better models and a focus on conversational flow made it reasonable to bring the whole chat into the IDE with **AI assistants** .\n- **AI code editors** , like Cursor and Windsurf, brought AI features to the entire development process, combining multiple parts into one context and flow.\n- Then came the agents, to whom we assign entire end-to-end tasks, with a distinct UI paradigm – **agentic development environments** .\n- And now those same agents are **moving to the cloud** and starting to do development work autonomously.\n\nThis 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?\n\n## **A “theory of everything” for AI development tools**\n\nIn 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**.\n\nLike 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.\n\n### **The definitions**\n\n**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.”**\n\n**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.\n\n**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.\n\n**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.\n\nThe 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.\n\n### **The assumptions**\n\nWe started with four foundational assumptions:\n\n**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.\n\n**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.\n\n**3. AIS will never fully replace humans, who will retain two key jobs: task specification and oversight.** (The article [“AI as Normal Technology”](https://knightcolumbia.org/content/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.\n\n**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.\n\n## **The three dimensions of the framework**\n\nOur framework operates in three dimensions: stages of the software creation process, levels of delegation, and organizational context of development.\n\n### **Dimension 1: Stages of the software creation process**\n\nThe 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.\n\nRegarding 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.\n\n### **Dimension 2: Levels of delegation**\n\nThis 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**:\n\n**L1 – Tool.** Delegation of very limited, scoped actions. Code completion is the canonical example: you let AI finish writing what you’ve already started.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n#### **Why *“How smart is the AI?”* is not a dimension**\n\n*“How smart is the AI?”*is not a dimension\n\nYou 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.\n\nFirst, **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.\n\nSecond – 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.\n\nEven when AI is technically capable of doing the job, it’s humans who decide how much control to let go of.\n\n### **Dimension 3: Organizational context of development**\n\nThe third dimension describes the organizational context in which development happens. We differentiate three contexts:\n\n- **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.\n- **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.\n- **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.\n\nThese 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.\n\n## **Putting it together: the map**\n\nNow, 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.\n\nIn our regular surveys on AI usage, we have a dedicated section on exactly this, which lets us build what we call **AIDEs maps**.\n\nOn 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.\n\n## **What the framework predicts**\n\nSo, we have a holistic model. We’ve mapped where we’ve been and where we are. Now we can finally look forward.\n\nOur 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.”\n\nAsk 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?\n\nWe could reflect on these questions forever. Here’s what we believe the primary direction will be.\n\n**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.\n\n**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.\n\n**Third (and potentially the most fascinating): people will stop treating AI as a tool and start treating it as an “intelligence resource.”**\n\nConsider 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*?\n\nIt’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.\n\nTo 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.\n\nWe 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.\n\n## **How to prepare** for the future\n\nExciting, and perhaps a little unsettling. So what can you personally do to prepare?\n\nFirst, 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.\n\nSo here’s the practical method – the same one used by JetBrains:\n\n**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?\n\n**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?\n\n**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.\n\nAnd 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.\n\n*Watch the full webinar recording:* *AIDEs Framework – the webinar**.*\n\n#### Subscribe to JetBrains Research blog updates", "url": "https://wpnews.pro/news/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools", "canonical_source": "https://blog.jetbrains.com/research/2026/09/aides-framework/", "published_at": "2026-09-18 13:52:30+00:00", "updated_at": "2026-09-18 14:57:16.680178+00:00", "lang": "en", "topics": ["ai-products", "ai-agents", "ai-tools", "ai-research", "developer-tools"], "entities": ["JetBrains", "JetBrains Research", "Anthropic", "Claude Code", "OpenAI", "Google", "Devin"], "alternates": {"html": "https://wpnews.pro/news/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools", "markdown": "https://wpnews.pro/news/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools.md", "text": "https://wpnews.pro/news/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools.txt", "jsonld": "https://wpnews.pro/news/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools.jsonld"}}