{"id":5367,"date":"2026-09-20T01:40:41","date_gmt":"2026-09-20T04:40:41","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/20\/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools\/"},"modified":"2026-09-20T01:40:41","modified_gmt":"2026-09-20T04:40:41","slug":"the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/20\/the-aides-framework-how-we-built-a-theory-of-everything-for-ai-development-tools\/","title":{"rendered":"The AIDEs Framework: How We Built a \u201cTheory of Everything\u201d for AI Development Tools"},"content":{"rendered":"<div>\n<div>\n<section data-clarity-region=\"article\">\n<div>\n<h2 id=\"major-updates\">The AIDEs Framework: How We Built a \u201cTheory of Everything\u201d for AI Development Tools<\/h2>\n<figure>\n<\/figure>\n<p>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\u2019 natural first instinct is to spend ever more time chasing updates.<\/p>\n<p>After almost two years of AI product and market research at JetBrains, we\u2019ve come to a different conclusion: <strong>the speed of change is not a problem, as long as you can see the bigger picture.<\/strong> We deliberately don\u2019t try to track everything that happens. Instead, we try to understand where everything we observe comes from \u2013 and where it is ultimately going. That gives us a prism to look through, a filter that separates signal from noise. It\u2019s also what saves us from change fatigue.<\/p>\n<p>This post is about that prism. But before we get to the framework itself, let\u2019s start where the webinar started: with what we actually see on the market today. Because you can\u2019t build a useful model of the future without first building an honest model of the present.<\/p>\n<h2><strong>What we see on the market today<\/strong><\/h2>\n<p>Looking through our research, three things stand out.<\/p>\n<p><strong>First, AI is already a common part of the developer\u2019s life.<\/strong> People know about it and use it not only at home but at their companies \u2013 including the big ones, which are traditionally the slowest to adopt anything new. We no longer question whether AI in software development \u201cis a thing.\u201d It\u2019s here, and it\u2019s staying.<\/p>\n<p><strong>Second, agentic coding is gradually becoming the new normal.<\/strong> More and more developers use AI coding agents that go beyond automated code edits \u2013 they actually <em>delegate<\/em> coding to agents. This fundamentally changes the development loop from \u201ccode \u2192 validate \u2192 fix\u201d in an editor, to \u201cplan \u2192 execute \u2192 review\u201d in an agentic chat. The biggest push here came from Anthropic\u2019s 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 \u2013 with similar offerings now from OpenAI, Google, and a wave of niche players.<\/p>\n<p><strong>Third, AI agents have started moving to the cloud.<\/strong> 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 \u201cgarbage tasks\u201d, like fixing a linting error found during a CI run.<\/p>\n<p>And yet, here is the paradox: <strong>even though everybody uses AI, we can\u2019t say AI is used everywhere.<\/strong> 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.<\/p>\n<h2><strong>Before we talk about the future, let\u2019s take a step back<\/strong><\/h2>\n<p>The question everyone wants answered is: <em>what\u2019s the next big thing?<\/em> But before jumping there, let\u2019s 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..<\/p>\n<p>What has the evolution of AI in software development looked like so far?<\/p>\n<ul>\n<li>It started with simple <strong>full-line code completion<\/strong> \u2013 AI within the scope of a single line.<\/li>\n<li>Generative AI brought <strong>multiline code completion<\/strong>, the ability to complete whole chunks.<\/li>\n<li>Better models and a focus on conversational flow made it reasonable to bring the whole chat into the IDE with <strong>AI assistants<\/strong>.<\/li>\n<li><strong>AI code editors<\/strong>, like Cursor and Windsurf, brought AI features to the entire development process, combining multiple parts into one context and flow.<\/li>\n<li>Then came the agents, to whom we assign entire end-to-end tasks, with a distinct UI paradigm \u2013 <strong>agentic development environments<\/strong>.<\/li>\n<li>And now those same agents are <strong>moving to the cloud<\/strong> and starting to do development work autonomously.<\/li>\n<\/ul>\n<figure><\/figure>\n<p>This reads less like a list of features and more like a <em>trajectory<\/em>. 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?<\/p>\n<h2><strong>A \u201ctheory of everything\u201d for AI development tools<\/strong><\/h2>\n<p>In early 2025, we were asked to collect insights to evaluate our AI strategy. While working on this, we were inspired to create a \u201ctheory of everything\u201d: one that explains not only the current state of the field, but what is <em>fundamentally possible<\/em>. That\u2019s how we ultimately arrived at our own theory of everything for AI development tools. We called it the <strong>Artificial Intelligent Development Environments Framework, or the AIDEs Framework<\/strong>.<\/p>\n<p>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\u2019s remarkable how rarely it\u2019s applied to thinking about developer tools.<\/p>\n<h3><strong>The definitions<\/strong><\/h3>\n<figure><\/figure>\n<p><strong>Artificial Intelligent System (AIS)<\/strong>: Any computer system created by humans that demonstrates the traits of \u201cintelligence\u201d while helping users achieve their goals (their Jobs-To-Be-Done). The key insight: people want to <em>feel<\/em> intelligence from their tools \u2013 but that intelligence doesn\u2019t have to come from LLMs. Our IDEs were always considered \u201cintelligent,\u201d yet the core of their capabilities is built on deterministic heuristics. So the principle is: <strong>target the user experience of intelligence, not \u201cAI everywhere.\u201d<\/strong><\/p>\n<p><strong>Artificial Intelligent Development Environment (AIDE)<\/strong>: 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.<\/p>\n<p><strong>Principal and Agent:<\/strong> 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\u2019s behalf. But keep in mind that <em>both<\/em> 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 <em>human<\/em> agent.<\/p>\n<p><strong>Software Creation:<\/strong> We use this term instead of \u201csoftware development,\u201d 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.<\/p>\n<p>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.<\/p>\n<h3><strong>The assumptions<\/strong><\/h3>\n<p>We started with four foundational assumptions:<\/p>\n<p><strong>1. Whatever the future becomes, people will still have the goal of creating software.<\/strong> We don\u2019t 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.<\/p>\n<p><strong>2. The primary driver of change on the market will be the gradual delegation of software creation activities to artificial intelligent systems.<\/strong> Let\u2019s be honest \u2013 we\u2019re all a little lazy, and we\u2019d gladly hand off the work we see as routine. All of human history supports this, from the division of labor, to automation, to digitalization \u2013 all of it was, at its core, delegation. Delegation is already present on today\u2019s 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 \u2013 and the <em>rising level of delegation to AIS<\/em> will become the ultimate metric of their real capabilities and impact.<\/p>\n<p><strong>3. AIS will never fully replace humans, who will retain two key jobs: task specification and oversight.<\/strong> (The article <a href=\"https:\/\/knightcolumbia.org\/content\/ai-as-normal-technology\" target=\"_blank\" rel=\"noopener\">\u201cAI as Normal Technology\u201d<\/a> dives deeply into this subject.) AI will not \u201ckill\u201d 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 <em>junior architects<\/em> \u2013 a new category that would require rethinking not just roles, but the entire system of CS education.<\/p>\n<p><strong>4. With higher levels of delegation to AIS, personal \u201cimmersion\u201d into specific development activities will decrease.<\/strong> Simply put: if you\u2019re not the one doing the job, you\u2019ll always know less about it than if you\u2019d 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 \u201chigher level\u201d of the project. This does <em>not<\/em> mean everyone goes full \u201cvibe coding\u201d (after all, current tools don\u2019t 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 \u201closs of immersion\u201d problem is a prerequisite for elevating delegation \u2013 and this is why context abstraction and management of uncertainty matter so much in the framework.<\/p>\n<h2><strong>The three dimensions of the framework<\/strong><\/h2>\n<p>Our framework operates in three dimensions: stages of the software creation process, levels of delegation, and organizational context of development.<\/p>\n<h3><strong>Dimension 1: Stages of the software creation process<\/strong><\/h3>\n<p>The first dimension is a reworked take on the traditional software development lifecycle, focused on <em>outcomes<\/em> rather than process. We map <strong>35 high-level activities grouped into 5 activity groups<\/strong> \u2014 from \u201cIdeation and Conceptualization\u201d to \u201cDelivery, Maintenance, and Feedback Collection.\u201d Any developer will recognize these immediately, so we won\u2019t dwell on them here. Explore the interactive figure below.<\/p>\n<figure>\n<div>\n<details name=\"aides-sdlc-stages\" open=\"\">\n<summary> <span><\/span> <span>Ideation and Conceptualization<\/span> <\/summary>\n<div>\n<p>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\u2019s worth pursuing.<\/p>\n<div>\n<section>\n<p><span><\/span>Forms of deliverables<\/p>\n<ul>\n<li>Idea \/ concept \/ vision<\/li>\n<li>User story<\/li>\n<li>Product Requirement Document (PRD)<\/li>\n<li>Low fidelity proof-of-concept (PoC) or prototype<\/li>\n<\/ul>\n<\/section>\n<section>\n<p><span><\/span>Activities<\/p>\n<ul>\n<li>Brainstorming problem space (opportunities, pain points, user personas and their needs, market trends and requirements, opportunities by new technologies =&gt; WHERE we see a need for new software solution and WHY)<\/li>\n<li>Brainstorming solution space (types of software, design \/ UX \/ user flows, current technology opportunities, target platforms =&gt; HOW we could solve the original problems and WHAT might the final solution might look like)<\/li>\n<li>Low fidelity prototyping (with focus on user-facing parts or general technology exploration; including validation)<\/li>\n<li>Documenting final concepts and vision<\/li>\n<\/ul>\n<\/section><\/div>\n<\/p><\/div>\n<\/details>\n<details name=\"aides-sdlc-stages\">\n<summary> <span><\/span> <span>Planning, Design and Architecture<\/span> <\/summary>\n<div>\n<p>During this stage software creators \u201coperationalise\u201d the initial ideas and concepts into the design of \u201cengineering solution\u201d \u2013 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 (\u201cdefinition of done\u201d).<\/p>\n<div>\n<section>\n<p><span><\/span>Forms of deliverables<\/p>\n<ul>\n<li>Project plan \/ roadmap \/ backlog<\/li>\n<li>Software Requirements Specification (SRS)<\/li>\n<li>System architecture design<\/li>\n<li>UI \/ UX design<\/li>\n<li>Software components design \/ class diagrams \/ DB schemas diagrams<\/li>\n<li>Software Design Document (SDD) \/ blueprint<\/li>\n<li>Set of more focused proof-of-concepts (PoCs) or prototypes, that could be reused in the final implementation<\/li>\n<\/ul>\n<\/section>\n<section>\n<p><span><\/span>Activities<\/p>\n<ul>\n<li>Defining general solution technical requirements and acceptance criteria<\/li>\n<li>Selecting technology and tools stack<\/li>\n<li>Specifying system architecture and composition<\/li>\n<li>Breaking down implementation into specific tasks \/ features; defining requirements and acceptance criteria for each task \/ feature<\/li>\n<li>Designing UI \/ UX \/ visual elements<\/li>\n<li>Designing system components \/ data layers<\/li>\n<li>Prototyping technical solutions<\/li>\n<\/ul>\n<\/section><\/div>\n<\/p><\/div>\n<\/details>\n<details name=\"aides-sdlc-stages\">\n<summary> <span><\/span> <span>Implementation<\/span> <\/summary>\n<div>\n<p>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).<\/p>\n<div>\n<section>\n<p><span><\/span>Forms of deliverables<\/p>\n<ul>\n<li>Solution codebase as complete solution, working increment or MVP<\/li>\n<\/ul>\n<\/section>\n<section>\n<p><span><\/span>Activities<\/p>\n<ul>\n<li>Setting up the development environment (including tooling set up, VCS, dependencies, run \/ build configurations \/ scripts)<\/li>\n<li>Writing core business logic (data entities, data transformation functions, \u201cbehavioral\u201d part of UI components)<\/li>\n<li>Writing auxiliary infrastructure code (API controllers definitions, ORM mappers, utility \/ helper functions)<\/li>\n<li>Writing code for styling \/ UX<\/li>\n<li>Ad-hoc code validation (running, debugging, linting, profiling)<\/li>\n<li>Setting up persistency and external services layers<\/li>\n<li>Developing supporting tools<\/li>\n<li>Writing documentation<\/li>\n<\/ul>\n<\/section><\/div>\n<\/p><\/div>\n<\/details>\n<details name=\"aides-sdlc-stages\">\n<summary> <span><\/span> <span>Testing, Validation and Quality Assurance<\/span> <\/summary>\n<div>\n<p>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 \u2013 all critical defects are fixed, and stakeholders are confident in the product\u2019s correctness and stability.<\/p>\n<div>\n<section>\n<p><span><\/span>Forms of deliverables<\/p>\n<ul>\n<li>General confidence the codebase is working as expected<\/li>\n<li>Test summary report \/ validated test cases<\/li>\n<li>Accepted code review<\/li>\n<\/ul>\n<\/section>\n<section>\n<p><span><\/span>Activities<\/p>\n<ul>\n<li>Developing the test plan and strategy; formulating test cases<\/li>\n<li>Setting up test environment<\/li>\n<li>Writing and running auto tests (unit, integration, end-to-end, regression)<\/li>\n<li>Conducting manual testing<\/li>\n<li>Conducting performance \/ load testing<\/li>\n<li>Conducting security testing<\/li>\n<li>Conducting usability testing<\/li>\n<li>Doing code reviews<\/li>\n<\/ul>\n<\/section><\/div>\n<\/p><\/div>\n<\/details>\n<details name=\"aides-sdlc-stages\">\n<summary> <span><\/span> <span>Delivery, Maintenance, and Feedback Collection<\/span> <\/summary>\n<div>\n<p>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 \u201coperational\u201d state of the software solution, which includes maintenance (making sure the software is still available to end users) and feedback collection (for future improvements).<\/p>\n<div>\n<section>\n<p><span><\/span>Forms of deliverables<\/p>\n<ul>\n<li>Application code in web production environment<\/li>\n<li>Application executable distribution in distribution channel<\/li>\n<li>Solution codebase as a package \/ source code in distribution channel<\/li>\n<li>Collected application and performance logs, usage metrics, user data \/ feedback<\/li>\n<\/ul>\n<\/section>\n<section>\n<p><span><\/span>Activities<\/p>\n<ul>\n<li>Planning the deployment and \/ or release approach<\/li>\n<li>Writing production build configurations \/ scripts (e.g. Maven, Gradle, yarn\/npm, Docker)<\/li>\n<li>Writing production deployment configurations \/ scripts (e.g. Compose, Ansible, Terraform)<\/li>\n<li>Setting up the production hosting environment \/ distribution channels<\/li>\n<li>Creating deployment \/ release CI\/CD pipelines<\/li>\n<li>Managing cloud infrastructure (manually, via API, via Ia\u0421)<\/li>\n<li>Monitoring the software in the production environment, including setting up monitoring infrastructure (CLI logs, exceptions, usage \/ performance metrics)<\/li>\n<li>Collecting and analyzing data on user behavior and feedback, including setting up analytics \/ feedback infrastructure<\/li>\n<\/ul>\n<\/section><\/div>\n<\/p><\/div>\n<\/details><\/div>\n<\/figure>\n<p>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 <em>look<\/em> 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.<\/p>\n<h3><strong>Dimension 2: Levels of delegation<\/strong><\/h3>\n<p>This is the more novel dimension. Here we define the distribution of roles between principal and agent, along with <strong>10 attributes of delegation<\/strong> \u2013 autonomy, level of planning, proactivity, and others. Different combinations of roles and attribute values define <strong>five levels of delegation<\/strong>:<\/p>\n<p><strong>L1 \u2013 Tool.<\/strong> Delegation of very limited, scoped actions. Code completion is the canonical example: you let AI finish writing what you\u2019ve already started.<\/p>\n<p><strong>L2 \u2013 Assistant.<\/strong> Delegation of a well-defined sequence of actions \u2013 a \u201ctask\u201d with very specific boundaries. One example might be generating a unit test for a specific function. Simple, well-defined, and minimal context \u2013 but it\u2019s a task with a series of steps, not just one action. It\u2019s like having a third hand: it\u2019s doing the work, but it\u2019s still <em>your<\/em> hand.<\/p>\n<p><strong>L3 \u2013 General-purpose Executor.<\/strong> This is where focus starts shifting from the process to the <em>deliverables<\/em>. An L3 agent can execute any task, but requires expert input from the principal, who acts as a \u201cconsultant\u201d 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\u2019t trust them with decisions about <em>what<\/em> should actually be built \u2013 that requires deeper knowledge of the business domain. So we fully delegate execution, but retain task setting and review.<\/p>\n<p><strong>L4 \u2013 Supervised Executor.<\/strong> Here we move beyond the individual space to the organizational perspective, because the agent is now responsible for an entire development <em>function<\/em>, like managing the backend implementation of your full-stack web application. It is \u201csupervised\u201d because the principal\u2019s 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.<\/p>\n<p><strong>L5 \u2013 Competence Center.<\/strong> Imagine you\u2019re the CEO of a startup with an engineering team at your side. You define what the company wants to achieve, how you\u2019ll do it, what the key metrics are, and whether you\u2019re performing well. Your engineering team exists to execute your strategy and make your vision a reality. You don\u2019t care what stack they use, what API structure the app has, or whether it\u2019s hosted in Azure VMs or Docker containers on managed Kubernetes in GCP \u2013 you delegate those decisions to the team. <em>That<\/em> kind of delegation is L5.<\/p>\n<figure>\n<div id=\"aides-deleg-dash\">\n<p><span id=\"adg-select-label\">Select attribute<\/span> <\/p>\n<\/p><\/div>\n<\/figure>\n<h4><strong>Why <em>\u201cHow smart is the AI?\u201d<\/em> is not a dimension<\/strong><\/h4>\n<p>You may have noticed something conspicuously missing here: there\u2019s nothing about the raw capability of AI or how \u201csmart\u201d it can be. This omission is deliberate, for two reasons.<\/p>\n<p>First, <strong>benchmark performance does not automatically translate into real-world delegation.<\/strong> 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.<\/p>\n<p>Second \u2013 and this is the deeper point \u2013 <strong>everything we\u2019ve described is not an attribute of the agent, but an attribute of the <\/strong><strong><em>relationship<\/em><\/strong><strong> <\/strong><strong><em>between<\/em><\/strong><strong> the principal and agent.<\/strong> 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\u2019ll switch to L2, put Junie \u201con a leash,\u201d and feed it much narrower tasks. Even if the agent is <em>capable<\/em> of L3, there will be scenarios where the principal chooses to delegate less. The level of delegation is not an attribute of Junie \u2013 it\u2019s an attribute of the \u201cagentic contract\u201d between the two, and the principal is the one who sets its terms.<\/p>\n<p>Even when AI is technically capable of doing the job, it\u2019s humans who decide how much control to let go of.<\/p>\n<h3><strong>Dimension 3: Organizational context of development<\/strong><\/h3>\n<p>The third dimension describes the organizational context in which development happens. We differentiate three contexts:<\/p>\n<ul>\n<li><strong>Individual<\/strong> \u2013 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 \u2013 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.<\/li>\n<li><strong>SME<\/strong> \u2013 development within small and medium companies, startups, and highly autonomous teams inside larger enterprises (\u201cinternal startups\u201d). 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 \u2013 salaries and infrastructure dominate the cost structure.<\/li>\n<li><strong>Enterprise<\/strong> \u2013 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.<\/li>\n<\/ul>\n<p>These contexts define different constraint types and different complexity of organizational dynamics \u2013 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 \u2013 and we already see certain things becoming relevant specifically at the scale of large organizations.<\/p>\n<h2><strong>Putting it together: the map<\/strong><\/h2>\n<p>Now, remember our \u201ctimeline\u201d picture from earlier? Through the lens of the framework, it becomes obvious that the line running through it is, at its core, the <strong>level of delegation<\/strong> 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.<\/p>\n<p>In our regular surveys on AI usage, we have a dedicated section on exactly this, which lets us build what we call <strong>AIDEs maps<\/strong>.<\/p>\n<figure id=\"aides-map-chart\">\n<p><span><span><\/span>ChatGPT<\/span><span><span><\/span>Claude Code<\/span><\/p>\n<div id=\"aides-map-grid\">\n<p>Not used (0)<\/p>\n<p>Tool (1)<\/p>\n<p>Assistant (2)<\/p>\n<p>General-purpose Executor (3)<\/p>\n<p>Supervised Executor (4)<\/p>\n<p>Competence Center (5)<\/p>\n<p>Problem brainstorm<\/p>\n<p>Solution brainstorm<\/p>\n<p>Low-fi prototyping<\/p>\n<p>Concept documenting<\/p>\n<p>Requirements definition<\/p>\n<p>Tech stack selection<\/p>\n<p>System architecture<\/p>\n<p>Tasks formulation<\/p>\n<p>UI\/UX design<\/p>\n<p>System design<\/p>\n<p>Solution prototyping<\/p>\n<p>Setting up dev environment<\/p>\n<p>Coding business logic<\/p>\n<p>Coding infra code<\/p>\n<p>Coding styles \/ UX<\/p>\n<p>Code validation<\/p>\n<p>Persistency \/ external layers<\/p>\n<p>Coding tools<\/p>\n<p>Writing docs<\/p>\n<p>Planning tests \/ test cases<\/p>\n<p>Setting up test environment<\/p>\n<p>Coding \/ running autotests<\/p>\n<p>Manual testing<\/p>\n<p>Performance testing<\/p>\n<p>Security testing<\/p>\n<p>Usability testing<\/p>\n<p>Code reviews<\/p>\n<p>Planning deployment<\/p>\n<p>Coding build scripts<\/p>\n<p>Coding deployment configs<\/p>\n<p>Setting up production environment<\/p>\n<p>Creating CI\/CD pipelines<\/p>\n<p>Managing cloud<\/p>\n<p>Monitoring<\/p>\n<p>User data analysis<\/p>\n<p>Not used (0)<\/p>\n<p>Tool (1)<\/p>\n<p>Assistant (2)<\/p>\n<p>General-purpose Executor (3)<\/p>\n<p>Supervised Executor (4)<\/p>\n<p>Competence Center (5)<\/p>\n<\/div>\n<\/figure>\n<p>On a map like this, we can see where ChatGPT and Claude Code are used, at what level of delegation, where they are <em>not<\/em> used, and how they compare to each other \u2013 all at the same time. And because we collect such data regularly, we can track the dynamics over time.<\/p>\n<h2><strong>What the framework predicts<\/strong><\/h2>\n<p>So, we have a holistic model. We\u2019ve mapped where we\u2019ve been and where we are. Now we can finally look forward.<\/p>\n<p>Our data shows we are just in the middle of the map, at the <strong>L3 \u201cGeneral-purpose Executor\u201d<\/strong> level, with cloud agents only beginning to touch L4. We still see gaps across the SDLC, so there\u2019s plenty of room to grow, and the <em>next<\/em> stage of evolution is easy to imagine just by looking at the map. But the framework describes fundamental forces, a formal model of reality \u2013 which means we can go further and start imagining the more distant future at its \u201cfinal stage.\u201d<\/p>\n<p>Ask yourself: what does the <strong>L5 \u201cCompetence Center\u201d<\/strong> 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 <em>competence<\/em>? 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 <em>experience<\/em> of creating software feel like?<\/p>\n<p>We could reflect on these questions forever. Here\u2019s what we believe the primary direction will be.<\/p>\n<p><strong>First: the rise of abstraction.<\/strong> Developers will think less about the code itself and more about actual solution engineering \u2013 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 \u201chow to build\u201d to \u201cwhat to build and why\u201d. The good news is that this isn\u2019t new for developers. It\u2019ll just become the core of the work.<\/p>\n<p><strong>Second: vertical integration of AI in all parts of the software development lifecycle.<\/strong> 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\u2019t simply mean \u201cAI becomes part of a big development platform\u201d \u2013 we\u2019re headed somewhere more interesting.<\/p>\n<p><strong>Third (and potentially the most fascinating): people will stop treating AI as a tool and start treating it as an \u201cintelligence resource.\u201d<\/strong><\/p>\n<p>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 <em>raw material<\/em>?<\/p>\n<p>It\u2019s <strong>intelligence<\/strong>. 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 \u2013 one that can be treated as a <em>variable resource<\/em>, just like any raw material.<\/p>\n<p>To stick with our \u201cfurniture factory\u201d analogy: when organizations understand that AI is not just a hammer, but the <em>wood<\/em> itself, we may experience a fundamental shift in how development is done.<\/p>\n<figure><\/figure>\n<p>We might end up with something like <strong>Agentic Software Production Platforms<\/strong> \u2013 vertically integrated software production systems where AI works as an input \u201cintelligence resource,\u201d structured around the main layers of work management \u2013 <strong>intent management, execution, and governance<\/strong> \u2013 rather than around the DevOps cycle, with human developers managing the production system itself.<\/p>\n<h2><strong>How to prepare<\/strong> for the future<\/h2>\n<p>Exciting, and perhaps a little unsettling. So what can you personally do to prepare?<\/p>\n<p>First, an important caveat: I\u2019m not claiming to know exactly what type of future we\u2019re headed toward (or when exactly we\u2019ll get there). Our framework merely describes what\u2019s <em>fundamentally possible<\/em> given the key forces driving the evolution of software development. That\u2019s the honest boundary of any model. But understanding these forces <em>does<\/em> give you a decisive advantage in navigating whatever future actually unfolds.<\/p>\n<p>So here\u2019s the practical method \u2013 the same one used by JetBrains:<\/p>\n<p><strong>Examine our core assumptions.<\/strong> Does AI really expand the opportunities for delegating development work? Can it act as an \u201cintelligence resource\u201d? Is it possible to ultimately have \u201chybrid\u201d teams of human developers and AI coworkers? Is something else going on entirely?<\/p>\n<p><strong>Build your model \u2013 then commit to it.<\/strong> Build your own model of reality (or borrow our AIDEs Framework), accept it, and start asking questions <em>within its conceptual boundaries<\/em>: What will my responsibilities as a developer look like? Which skills will become more relevant? If the future is about \u201cmanagement of delegation,\u201d 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 <em>junior architect<\/em> roles? Which of those skills do I already have? Which do I need to develop? Am I ready to change?<\/p>\n<p><strong>Observe and validate.<\/strong> Watch the world and test your model and assumptions against it. Change doesn\u2019t happen overnight \u2013 it\u2019s a continuous process, and there will always be friction and inertia. A model you never validate is just an opinion.<\/p>\n<p>And if you\u2019re an engineering leader, your objective is considerably harder: you\u2019ll need to rethink how the development process itself is structured, and how AI as an \u201cintelligence resource\u201d should be embedded into processes where intelligence is already present as a human capability. That deserves a dedicated discussion of its own \u2013 and we at JetBrains already have our own vision. Stay tuned.<\/p>\n<hr>\n<p><em>Watch the full webinar recording: <\/em><a href=\"https:\/\/www.youtube.com\/watch?v=OfIB-qvrK7A\" target=\"_blank\" rel=\"noopener\"><em>AIDEs Framework \u2013 the webinar<\/em><\/a><em>.<\/em><\/p>\n<\/p><\/div>\n<p> <a href=\"#\"><\/a> <\/section>\n<div>\n<p><h2>Discover more<\/h2>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n<p>Fuente: <a href=\"https:\/\/blog.jetbrains.com\/research\/2026\/09\/aides-framework\/\">Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The AIDEs Framework: How We Built a \u201cTheory of Everything\u201d 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\u2019 natural first instinct is to spend ever more time chasing updates. After almost two years [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":5366,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"webixso_pending_account_ids":""},"categories":[46],"tags":[],"class_list":["post-5367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-jetbrain"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/5367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=5367"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/5367\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/5366"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=5367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=5367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=5367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}