The software development environment is shifting from IDEs (Integrated Development Environments) to AOCs (Agent Orchestration Clients). This isn't just a story about tool replacement, but about the very nature of development changing. This article explores why this shift is happening, the reasons behind it, and what it demands from developers.
1. Definition
First, let's clarify the two terms.
IDE is an environment where people directly write code. Editors, compilers, debuggers, and test runners are integrated into a single screen, with the code editing window at its center. Every keystroke by a person becomes part of the final product. VS Code, IntelliJ, Vim, and Emacs all fall into this category.
AOC is an environment where people orchestrate agents. The interface centers around communication with agents, a work queue, and result review screens. A person's keystrokes don't directly become the result. Instead, they break down tasks, assign them to appropriate agents, review results, and route them to the next step. The code editing window serves as a result review tool on the periphery.
The key difference between the two environments lies in the position of the person. In an IDE, the person is the author. In an AOC, the person is the orchestrator. (AOC is a term I coined while developing tunaFlow to make it sound more credible. There isn't yet a standardized term for this concept, so industry pioneers may express it differently, and that would be equally valid.)
2. Ongoing Trend
This change is not a prediction but a current reality, evident in various tools.
Cursor started from an IDE but has been moving towards AOC with each update. Cursor 1.x added Copilot-like autocompletion to VS Code. Cursor 2.x introduced Composer, enabling multi-file editing as a single work unit. Cursor 3.x added Background Agents for asynchronous tasks. With each step, the proportion of direct human editing decreases while agent workload increases.
Claude Code, Codex, Gemini CLI, and other terminal-based AI tools are designed from the outset with an AOC approach. In a terminal interface, users provide instructions, and agents read, edit, execute, and test files. Humans spend little time in code editing windows, primarily focusing on review. While each tool is developed by different companies (Anthropic, OpenAI, Google), their interface paradigms are remarkably similar. This convergence itself indicates the direction of the trend.
Cognition's Devin goes further. Users only provide task instructions and receive results. Agents autonomously make decisions during the process, with human intervention limited to result review.
Open-source tools like Cline, Aider, and OpenInterpreter follow a similar path. Their interfaces are centered around agent dialogue rather than code editing windows.
The direction is consistent. While competition exists between tools, there's no disagreement on the overall trend.
3. Karpathy's Software 3.0 Context
To understand this shift in a broader context, Andrej Karpathy's software classification is helpful.
Software 1.0 is the era of humans directly writing code using languages like C, Python, and Java, entering commands line by line. This paradigm has persisted from the 1950s to the present.
Software 2.0 is the era where neural network weights are programs themselves. Humans don't write code but provide data and define objectives. Learned weights perform the tasks. Tesla's self-driving system replacing hand-written C++ code with a neural network is a prime example.
Software 3.0 is the era of programming LLMs using natural language. Programming languages become English (or any natural language). Humans provide goals, examples, tools, and context in natural language, and the LLM performs the calculations.
IDEs are interfaces for Software 1.0, optimized for environments where humans directly write code. AOCs are interfaces for Software 3.0, optimized for environments where humans instruct agents using natural language.
Currently, all three eras coexist. Developers often use 1.0 (direct code modification), 2.0 (model training), and 3.0 (agent instructions) within the same project. However, over time, the proportion of 3.0 will increase.
4. Reasons for Change
The consistent direction of this shift is driven by structural reasons.
Efficiency differences are significant. Agents can generate code at a speed 10 times faster than humans typing code, even for simple CRUD tasks. In areas like boilerplate generation, standard patterns, and general business logic, agents already outperform humans in terms of speed.
Consistency and quality are also evolving. Humans make mistakes when tired. It's common to struggle to understand code written days earlier. Maintaining consistent conventions across large codebases is a burden for humans. In a codebase with 100 contributors, it's typical to find 100 different styles.
Agents aren't perfect in terms of consistency either. LLMs are inherently non-deterministic and can produce different outputs for the same prompt. However, agents don't experience fatigue, consistently check defined conventions, and can handle larger context ranges than humans. While enforcing consistency isn't automatic, it's cheaper with agents compared to ensuring 100 developers follow the same convention.
Scale is a crucial factor. The number of files a single person can work on simultaneously is limited. Agents can modify dozens of files concurrently within a single task. In multi-agent environments, multiple agents perform tasks in parallel, effectively increasing the workload a developer can handle in an hour by 10 to 100 times.
Cost structures are changing rapidly. By Korean standards, the average senior developer salary ranges from 70 million to 85 million won depending on the field, with some big tech companies paying higher. Agent operation costs are at least one order of magnitude lower than that. When comparing unit costs per task, the difference is even greater. As market competition operates, work shifts to the lower-cost side. The areas where human intervention is necessary shrink, and those areas are reorganized in a direction where their value increases.
The collaboration structure itself changes. When five people work on a project, communication costs scale with the square of the number of nodes. When five agents work on a project, communication is explicit, recordable, and conflict resolution is decisive. Human teams require meetings, but agent teams suffice with logs.
These five things operate simultaneously. Any one of them alone would be sufficient to create the flow, but all five point in the same direction.
5. The Reconstruction of Developer Identity
What this flow requires from developers is not tool replacement, but identity reconstruction.
The existing identity was that of a code writer. The ability to write code well was a developer's core competency. The value lay in memorizing algorithms, learning syntax, and accumulating debugging knowledge.
The new identity is that of an orchestrator. The ability to write code well is needed only at the review stage. More important abilities are: the ability to properly decompose tasks, the ability to judge which agent is suited for which task, the ability to quickly validate results, and the ability to optimize workflows.
The problem is that identity transition is harder than tool transition. Telling a senior developer who has been writing code for 10 years, "Now don't write code directly," is not simply a job change. It's a fundamental question about where one's value lies.
A fork point emerges between efficiency and pride here. Embracing efficiency quickly allows you to establish yourself quickly in the new environment. Clinging to pride means falling behind the market flow. This is a decision that gets made within 1-2 years.
What's interesting is that junior developers transition faster than seniors. This is because their code-writer identity is not deep-rooted. Since they've been using AI tools from the start, the orchestrator identity comes naturally. A paradoxical situation emerges where juniors adapt to new tools first while seniors hold on to pride.
6. Specific Changes in AOC Interface
The screen layout in an AOC environment is configured differently from an IDE. Hypothetically, it looks like this:
Typical IDE screen layout:
AOC screen layout is different:
Agent conversation/instruction area (30-40%)
Task queue/status monitoring (20-30%)
Result diff review (20-30%)
Code editor (10-20%, for review)
The code editor doesn't disappear. It remains for review and fine-tuning purposes. However, agent orchestration takes up the main interface space.
What this change in screen layout means is a change in work units. In IDE, work units are files, functions, lines. In AOC, work units are tasks, workflows, agent combinations. You work at larger levels of abstraction.
As work units grow larger, the human time unit changes too. In IDE, people work in minute units. Five minutes to write one function, one hour to implement one module. In AOC, people work in hour units or task units. From issuing one task instruction to receiving results takes 30 minutes to several hours, and during that time other tasks are undertaken.
This changes the developer's daily rhythm itself. You shift from the pattern of continuously sitting at a keyboard to throwing tasks and moving on to other work, reviewing results, and issuing the next task instruction.
7. The Inevitability of Multi-Agent Systems
There are structural reasons why AOC doesn't stop at single-agent but progresses to multi-agent.
LLMs are trained with different reward functions, so they produce different results for the same task. Claude is analytical and cautious. GPT is execution-focused and quickly grasps user intent. Gemini is divergent and presents multiple angles. If you rely on one model, that model's bias is directly reflected in the results.
The solution is to operate multiple models in different roles. One for idea divergence, one for critical validation, one for implementation. Each model operates in its strength area, and other models cross-validate the results. This is the basic structure of a multi-agent environment.
In the open-source realm, this pattern is being established first. Indie developers launch multiple LLM CLIs simultaneously for their work and use different models by task stage. Searching "agent orchestrator" on GitHub yields dozens of tools. Tools like RuFlo, myclaude, ZenFlow, bernstein, clideck, agent-kanban, ai-maestro, and tunaFlow combine Claude Code, Codex, and Gemini CLI in different ways to construct multi-agent workflows. OpenAI has directly entered the orchestration category through its own Codex App. This category is called AOC because such workflows are hard to absorb as feature additions to a single IDE. Big tech tools are ultimately converging in this direction, and the category itself is developing simultaneously in both indie and big tech spaces.
8. New Distribution of Capabilities
In the AOC era, value is redistributed. Some capabilities disappear and new ones become important.
Capabilities decreasing in value:
Mastery of specific language syntax
Memorization of standard patterns
Speed in writing boilerplate
Simple debugging
Memorizing library APIs
Agents excel at these capabilities. Even if people spend time developing them, their market value decreases.
Capabilities increasing in value:
Ability to decompose tasks into appropriate units
Ability to judge which agent suits which task
Ability to quickly validate accuracy and quality of results
Ability to detect subtle errors in agent results
Ability to design entire workflows
Ability to decide tradeoffs between cost and quality
Ability to integrate domain knowledge with AI tools
Humans excel at these capabilities compared to agents. And because few people do them well, they have high market value.
Particularly important is the last item: the ability to integrate domain knowledge with AI tools. General AI tools don't know the domain. The ability for someone who knows the domain to appropriately leverage AI tools to solve domain problems becomes the core of value. The same pattern operates across all domains: medicine, law, finance, manufacturing, education, and more.
9. Tool Differentiation Pattern
It's likely that AOC will differentiate into multiple categories rather than remaining a single form.
Coding AOC: Claude Code, Cursor 4.0 generation, Cognition Devin Document Work AOC: Cowork, Claude in Excel Design AOC: Figma + AI Integration Sales/CRM AOC: Clay-like tools Law AOC: Harvey-like tools Research AOC: Parallel Web Systems + tool combinations
Separate agent orchestration environments are developing for each domain. This is a pattern that repeats at the service level as well, with the MoE (Mixture of Experts) architecture working at the model level.
The era is coming when one user will use different AOCs for each task. Cursor for coding, Cowork for documents, Clay for sales. The days of one tool handling everything are over.
This clarifies the position of indie developers. Indie tools fill the gaps between the diversified AOCs developed by Big Tech or the small markets that Big Tech doesn't prioritize. Areas such as Korean language user priority, local first, maniac workflows, and special domains are indie territories.
10. Timeline
Here's an estimate of the flow's speed:
What's already happening:
Within a year:
Cursor 4.0 generation multi-agent support
Stronger autonomous mode for Claude Code
Most junior/mid-level AOC conversion
Weakening resistance from some seniors
Within 2-3 years:
Conversion of a majority of seniors
Significant decrease in direct coding proportion
Full-scale differentiation of domain-specific AOCs
Visualization of the gap between those who persevere with pride and those who follow efficiency
Within 5 years:
AOC becomes standard interface
IDE relegated to review tool periphery
Domain + AOC integrated personnel become market mainstream
Code writer identity becomes a niche area
This timeline is estimated based on the premise that the direction of the flow is clear, and the exact timing may vary. However, it is highly likely that the big picture will be determined within 5 years.
11. Costs of Acceptance and Rejection
In the face of this change, developers have three options:
First, embrace it quickly. Learn new tools, redesign your workflow, and redefine your identity as an orchestrator. Short-term costs include learning time and discomfort with identity reconstruction. Long-term benefits include securing market position and the ability to respond quickly to tool changes.
Second, adopt it slowly. Use some tools as assistants while keeping IDEs as the foundation. Short-term stability is secured. However, it becomes difficult to keep up as the market moves rapidly.
Third, reject it. "AI is not real development," "Code written by myself is the real thing." Pride is maintained. However, there's no way to prevent a decline in market value.
The cost of acceptance is short-term learning. The cost of rejection is long-term market position. While it may feel like short-term costs are greater due to human cognitive bias, the long-term costs are actually larger.
The most dangerous position is the second one. Without clearly accepting or rejecting it, time passes while remaining in a state of limbo. Ultimately, acceptance becomes inevitable, but the cost of late adoption will have to be paid in full.
Conclusion
The transition from IDE to AOC is not just a tool replacement but a fundamental change in the act of development itself. The position of humans shifts from code writers to orchestrators. This change operates simultaneously on five fronts: efficiency, consistency, scale, cost, and collaboration structure.
Big Tech tools, indie tools, and open-source tools are all moving in the same direction. Category definitions emerge first in the indie space, with Big Tech entering the same categories 6 to 12 months later. However, the categories themselves are already defined.
This change requires developers to redefine their identities. In an era when the ability to write good code was at the center of value, the ability to orchestrate agents well becomes the new center of value. Whether you embrace this transition quickly or slowly will determine your market position in the next 5 years.
The code editor won't disappear. It will just be pushed to the periphery of the screen. Agent dialogue windows and work queues will take its place. The change from IDE to AOC is a surface signal of a deeper transformation: the redefinition of the relationship between humans and computers.
Whether you welcome this change or fear it, the flow continues. It's up to each individual to decide where they want to position themselves within that flow.
