The Agentic Development Environment is where the discipline becomes operational. Every other technique in the curriculum is implemented through the configuration of an ADE. The choice of which ADE to use, and how to configure it, is the first engineering decision in any agentic project.

The choice is made against the requirements of the work, not against the marketing of the products. Four questions structure it. What permissions does the agent need? What level of transparency does the work require? What other tools must compose with the agent? What cost and latency envelope can the work absorb?

Any ADE can be read as a particular combination of six concerns. The bare LLM is the foundation: the model determines a ceiling that no amount of tooling can lift. Tool augmentation is what the agent can do beyond producing text. Knowledge and memory is what persists across sessions. Learning from experience is the mechanism by which the agent improves over time within a project. Multi-agent coordination is the architecture for tasks that require more than one agent. Computer use is the capacity for the agent to operate the desktop or browser as a user would.

A practitioner reading a new ADE answers six questions: what is the model, what tools are available, what persists across sessions, how does the system learn, how do agents coordinate, and can the agent operate the screen.

Terminal and CLI-based agents expose the agent loop directly. The developer sees the model’s reasoning, the tool calls, the file diffs, and the verification gates as they happen. Transparency is the design value, and the cost is a higher learning curve. Examples: Claude Code, Codex CLI.

IDE-integrated agents embed the model in the development environment the developer already uses. The friction of context-switching collapses. The trade-off is reduced visibility into what the agent is doing under the hood. Examples: Cursor, GitHub Copilot Workspace.

Browser-based builders hide the architecture almost entirely. The developer states what they want and the platform produces a running application, often without exposing the code. Speed of creation is the design value. Examples: Lovable, v0. The choice is rarely between products; it is between categories.

Permission design determines how much damage an agent can cause if it acts incorrectly. The decision is made before the agent is invoked, not afterwards. Minimal footprint: an agent should have only the permissions required for the specific task at hand, no more. Reversibility: prefer tools that produce reversible actions over irreversible ones.

Sandboxing is the infrastructure layer that enforces the permission design. The practitioner’s responsibility is to understand the sandbox they are using, to verify that its boundaries match the project’s blast-radius requirements, and to escalate sandboxing controls when the work demands them.

CLAUDE.md and AGENTS.md are the primary mechanisms for persisting project-specific knowledge across sessions. They live in the project directory, are versioned with the code, and are read by the agent at the start of every session. A maintained lessons-learned file complements the context file. Context is also a budgeted resource: the token window is finite and the engineering task is curation.

Recent empirical research makes the design requirement concrete. Human-written context files improve agent performance by approximately 4%. LLM-generated context files decrease performance by 3% and increase token cost by over 20%. The maintenance of context files is a first-order engineering activity, not a delegation candidate.

Inference is a metered, billable operation. Token pricing varies across providers and models; frontier models are typically priced an order of magnitude higher than smaller models in the same family. Prompt caching reduces the cost of repeated context, with discounts of 80% or more typical at the time of writing.

The decision between frontier and smaller models is shaped by the task. A multi-agent workflow may use frontier models for high-stakes reasoning such as orchestration and evaluation, and smaller models for high-volume execution. The latency budget is a separate consideration: the response time acceptable for a user interaction determines the model choice more than capability does in most production systems.