Agent in developer's IDE

At the earliest stage of AI-assisted development, the agent lives inside the developer's IDE - literally running as an extension or plugin within VS Code, Cursor, or JetBrains. The agent process executes on the developer's laptop, using the developer's local environment: their filesystem, their shell, their credentials, their installed tools. When a Cursor agent runs a terminal command or reads a file, it does so as the logged-in developer, with all the same permissions and access that person has.

This is the path of least resistance. There is no infrastructure to configure, no containers to build, no environments to provision. Install the plugin, connect an API key, and the agent is running. That simplicity is why this pattern is universal at L1 - it matches how developers already work, and it requires zero platform investment from the organization.

The IDE-resident agent model works well for single-file edits, code explanations, and autocomplete. Where it breaks down is when agents start taking broader autonomous actions: reading across many files, running tests, executing shell commands, installing packages. At that point, the agent's scope expands far beyond what the developer intended to hand over, and the shared-environment problem becomes acute. The agent is no longer just suggesting edits - it is acting as the developer, with the developer's full blast radius.

This pattern is not wrong for getting started. It is wrong as a permanent state. Every organization should pass through it, but treating it as the destination is a risk that compounds over time as agents become more capable and more autonomous.

• Zero-friction adoption - developers can start using AI agents immediately without waiting for platform teams to provision environments, making it the fastest path to first value
• Full toolchain access - the agent can use every tool the developer has locally: git, npm, make, Docker, cloud CLIs, proprietary internal tools that would take weeks to expose in a controlled environment
• No context gap - the agent sees exactly what the developer sees, including local configuration, uncommitted changes, and environment-specific settings that would be missing in a remote sandbox
• Reveals the real bottlenecks - running agents in the IDE first shows which tools agents actually need, which permissions matter, and what isolation boundaries would be meaningful before investing in platform infrastructure
• Developer trust starts here - developers who use agents in their own IDE build intuition for agent behavior before any organization-wide rollout, creating the internal champions who later drive adoption

1. Install a capable IDE agent - Cursor and VS Code with the Claude extension are the leading options. Cursor's agent mode (with "yolo" or auto-approve enabled) gives the most representative experience of what autonomous agent operation feels like on a real codebase.
2. Start with read-only tasks - Before letting the agent write files, use it for codebase exploration: "explain how this module works," "find all callers of this function," "summarize what this service does." Read-only tasks reveal agent capability without risk.
3. Enable write access incrementally - Move to small, bounded write tasks: fix a lint error, add a test for one function, update a dependency. Keep tasks scoped to single files or small directories where the blast radius of a mistake is minimal.
4. Audit what the agent accesses - After a few sessions, review what files the agent read, what commands it ran, and what external services it touched. This audit becomes the input for your sandboxing design at L2.
5. Document the credential exposure - List every credential the agent could theoretically access while running in your IDE: SSH keys, AWS credentials, database connection strings in .env files, cloud CLI tokens. This list is the security debt you will need to address.
6. Set a graduation criterion - Decide in advance what event triggers moving to isolated environments: first time an agent modifies a file it should not have, first time an agent runs a command with unintended side effects, or simply "after 30 days of use."

Treating laptop-resident agents as the permanent architecture. The IDE agent is a starting point, not a destination. As agents become more capable and autonomous, the shared-environment model scales from "minor inconvenience" to "serious security risk." Organizations that never graduate from IDE-resident agents are implicitly accepting that risk indefinitely.

Letting agents access cloud provider CLIs without restriction. When an agent runs in the developer's shell, it inherits the developer's AWS, GCP, or Azure credentials. An agent that reads the wrong file and discovers an IAM role with broad permissions can make cloud API calls that look entirely legitimate in audit logs. This is not theoretical - it is a known failure mode of uncontrolled IDE agents.

Confusing agent capability with agent safety. A Cursor agent that can fix a complex bug in five minutes is impressive. It is also an agent that can delete important files in five minutes if it misunderstands the task. Capability and safety are independent dimensions. IDE-resident agents max out capability (full environment access) while providing zero safety guarantees.

Not auditing agents before scaling adoption. Teams that adopt IDE agents widely without auditing what those agents do end up with a poorly understood blast radius across the whole engineering org. When something goes wrong - and eventually something will - the absence of audit data makes root cause analysis very difficult.

Missing the dependency on developer uptime. IDE-resident agents only run when the developer's machine is on and the IDE is open. Long-running agent tasks that take 30+ minutes are interrupted when the developer closes their laptop. This limitation forces developers into short, interactive sessions rather than the unattended overnight runs that become possible at higher maturity levels.