Eight Levels of Agentic Engineering Detail AI-Assisted Programming Evolution

The rapid advancement in AI's programming capabilities often outpaces human ability to effectively utilize them. This disparity explains why efforts to boost SWE-bench scores do not always translate into improved productivity metrics for engineering teams. For instance, while the Anthropic team developed "Cowork" in 10 days, another team using the same model failed to launch a proof of concept, highlighting a gap between AI capability and practical application. This gap is expected to narrow progressively through eight distinct levels of "agentic engineering."

Two software engineers, one senior and one junior, collaborating on code in a modern office.

Individuals are likely to have surpassed the initial levels and are encouraged to pursue higher stages, as each advancement significantly amplifies output, a benefit further enhanced by improvements in AI model capabilities. The progression also underscores the importance of multi-person collaboration. An individual operating at a high level, such as Level 7, where agents prepare pull requests asynchronously, can be bottlenecked if a colleague responsible for approval remains at Level 2, manually reviewing code. Elevating team members' proficiency levels therefore benefits overall throughput.

Based on observations of AI-assisted programming practices across various teams and individuals, the following progression path has been identified, though the order is not strictly rigid.

Foundational Stages: Tab Completion to Context Engineering

The initial stages of agentic engineering, Levels 1 and 2, primarily serve as foundational steps. Level 1, "Tab Completion," marked the beginning of AI-assisted coding with tools like GitHub Copilot, where AI auto-completes code. This stage is often bypassed by newcomers and is more suited for experienced developers who establish code skeletons for AI to fill in.

Level 2, "Agent IDE," introduced AI-specific integrated development environments such as Cursor, which integrate chat functionalities with the codebase to streamline cross-file editing. However, these tools are constrained by context limitations, as models can only process visible information, which can be either insufficient or overly broad. At this stage, users often experiment with planning modes, converting ideas into structured, step-by-step plans for large language models (LLMs) before execution. This approach offers control but becomes less central in later stages.

Developer's hands typing on a mechanical keyboard, code editor showing optimized prompt engineering.

Level 3, "Context Engineering," focuses on optimizing the information density within prompts. This became critical as models gained the ability to follow instructions with precise context. The principle, "every token must fight for its place in the prompt," emphasizes reducing noisy or irrelevant information. Practically, context engineering encompasses system prompts, rule files (e.g., .cursorrules, CLAUDE.md), tool descriptions that guide model selection, and managing conversation history to prevent long-running agents from losing track. It also involves judiciously exposing tools to avoid overwhelming the model.

While the term "context engineering" is less prevalent now due to models' improved tolerance for noisier contexts and larger context windows, its principles remain relevant. It is crucial for smaller models, large token consumers like Model Context Protocols (MCPs) and image inputs, and agents connected to numerous tools, where parsing tool definitions can consume significant tokens. The focus has shifted from filtering out bad context to ensuring timely and relevant context delivery, paving the way for subsequent advancements.

Advancing Capabilities: Compounding to Harness Engineering

Level 4, "Compounding Engineering," introduces a loop of planning, delegation, evaluation, and solidification, as proposed by Kieran Klaassen. This approach aims to improve every subsequent session, moving beyond mere prototyping. The "solidify" step is crucial, as LLMs are stateless. Lessons learned, such as specific dependency removals, must be explicitly recorded, often by updating rule files like CLAUDE.md, to prevent recurring errors. However, over-reliance on rule files can be counterproductive. A more effective strategy involves creating environments where LLMs can autonomously discover useful context, such as maintaining up-to-date documentation folders, a concept further developed in Level 7. Practitioners of compounding engineering instinctively assess whether context is missing when an LLM makes an error, rather than immediately blaming the model. This intuition is foundational for Levels 5 through 8.

Abstract digital loop symbolizing planning, delegation, evaluation, and solidification in engineering.

Level 5 addresses capability limitations through "MCPs and Skills," enabling LLMs to interact with databases, APIs, CI pipelines, design systems, and tools like Playwright for browser testing or Slack for notifications. This expands the model's role from merely analyzing code to directly manipulating it. Examples include shared PR review skills that launch sub-agents for security checks, complexity analysis, prompt health validation, and linting. This automation shifts code review from a human bottleneck to an automated, skill-driven process. MCPs like Braintrust MCP allow LLMs to query evaluation logs and make modifications, while DeepWiki MCP provides agents access to open-source documentation.

The consolidation of similar skills into shared registries, as seen with Block's internal skill marketplace, streamlines development. A growing trend involves LLMs using command-line interface (CLI) tools instead of MCPs due to token efficiency. CLIs allow agents to run targeted commands, with only relevant output entering the context window, unlike MCP servers that inject full tool definitions. This is why tools like agent-browser are increasingly preferred over Playwright MCP.

Levels 3 to 5 form the bedrock for subsequent advancements. Without clean context, precise prompts, clear tool descriptions, and robust feedback loops, higher levels of automation will only exacerbate existing problems.

Well-organized server rack in a data center, symbolizing robust engineering infrastructure.

Level 6, "Harness Engineering," focuses on constructing comprehensive environments—including tools, infrastructure, and feedback loops—that enable agents to operate reliably without direct human intervention. This involves providing agents with a complete feedback mechanism, not just an editor. OpenAI's Codex toolchain, for example, integrates Chrome DevTools and observability tools, allowing agents to query, correlate, and reason about their own output. This enables agents to reproduce bugs, record videos, implement fixes, validate changes through application manipulation, submit pull requests, respond to review feedback, and merge code, escalating to human intervention only when judgment is required.

A core concept in harness engineering is "backpressure," which refers to automated feedback mechanisms such as type systems, tests, linters, and pre-commit hooks. These mechanisms allow agents to detect and correct errors autonomously. Without backpressure, autonomous agents can become "garbage-producing machines." This principle also extends to security, where agents, their generated code, and access keys should reside in separate trust domains to mitigate risks like prompt injection attacks. Security boundaries act as backpressure, constraining what an agent can do if it malfunctions.

Two key principles guide harness engineering: designing for throughput over perfection, which means tolerating minor, non-blocking errors and performing a final quality check before release; and using constraints over instructions, where defining boundaries is more effective than providing step-by-step prompts, as agents tend to fixate on explicit lists. Another aspect of harness engineering is ensuring agents can navigate codebases freely. OpenAI's approach involves maintaining a concise AGENTS.md file as a directory to structured documentation and integrating documentation freshness into the CI process.

Advanced Autonomy: Background Agents and Agent Teams

Level 7 introduces "Background Agents," marking a shift away from planning mode as a separate human intervention step. As models become more adept at planning autonomously, planning mode is expected to diminish, provided the groundwork from Levels 3 through 6 (clean context, clear constraints, well-defined tool descriptions, and closed feedback loops) is established. For complex functions at this level, "planning" evolves into exploration, with background agents probing codebases, prototyping experiments, and understanding solution spaces asynchronously. This enables work to progress without constant human oversight.

The "Ralph loop" is a method for autonomous agent operation, where a programming CLI repeatedly runs until all items in a Product Requirements Document (PRD) are complete. However, its effectiveness is contingent on precise and comprehensive PRDs. Running multiple Ralph loops in parallel can lead to coordination challenges, transforming the user into a "middle manager" overseeing agent activities. This necessitates an orchestration agent to manage scheduling, allowing users to focus on intent rather than logistics.

Tools like Dispatch, a Claude Code skill, enable a command-center approach where a lean main session orchestrates worker agents in isolated contexts. The dispatcher handles planning, delegation, and tracking, reserving the main context window for orchestration. When a worker encounters an issue, it poses clarifying questions instead of failing silently. Dispatch runs locally, facilitating rapid development and debugging, while solutions like Ramp's Inspect offer cloud-based sandboxes for longer-running, autonomous tasks, providing scalability and reproducibility at the cost of operational complexity.

A powerful pattern at this level is using different models for different tasks, leveraging their distinct training backgrounds and "personalities." For example, assigning Opus to implementation, Gemini to exploratory research, and Codex to review can yield stronger combined outputs. Crucially, decoupling the implementer and reviewer, by using different model instances or review-specific prompts, enhances signal quality and mitigates bias. Background agents also facilitate the integration of CI and AI, enabling autonomous documentation bots, security review bots, and dependency management bots that not only flag issues but also implement fixes and run test suites.

Abstract network of glowing, interconnected spheres symbolizing coordinating AI agent teams.

Level 8, "Autonomous Agent Teams," represents the current frontier, where agents coordinate directly without a central orchestrator, claiming tasks, sharing discoveries, flagging dependencies, and resolving conflicts. Claude Code's experimental Agent Teams feature exemplifies this, with multiple instances working in parallel on a shared codebase. Anthropic used 16 parallel agents to build a C compiler, and Cursor employed hundreds of concurrent agents to build a browser and migrate its codebase.

However, challenges remain. Cursor found that a lack of hierarchy led to agents becoming unproductive, and Anthropic's agents frequently introduced regressions until CI pipelines were implemented. Multi-agent coordination is a complex problem without a definitive solution yet. While impressive for ambitious projects, models at this level are often too slow, token-intensive, and economically unfeasible for most daily tasks. Level 7 is currently seen as offering the most practical leverage, though Level 8 is anticipated to become mainstream eventually.

Looking ahead, the next evolution involves moving beyond text-only interfaces to voice-to-voice (or even thought-to-thought) interaction with programming agents. This would enable users to verbally describe changes to an application and observe their immediate implementation. While some pursue perfect one-shot generation, software development is inherently iterative, and future advancements are expected to make this iterative process significantly easier and faster, extending beyond pure text interaction.