IDE
The most intuitive home, but also the most constrained. In the editor, latency is visible and blocking. If an agent takes minutes to refactor or traverse a large repository, the developer’s flow collapses. IDE agents must be fast, they are assistants, not batch processors. Example
Issues and PRs
A stronger boundary. Work begins with human intent in an issue. The agent can draft specs, propose implementations, open PRs, and review diffs with reasoning attached. This fits existing collaboration models and preserves an audit trail. Because it is asynchronous, the agent can spend more time thinking without interrupting anyone. Example
Actions Triggered by Code Changes
Here the agent becomes infrastructure. It behaves like an adaptive test suite. Beyond traditional unit tests, it can enforce architectural constraints, validate accessibility compliance, detect stale documentation, flag risky migrations, and check API contracts. No one waits. It runs on every push and acts as an automated guardrail. Example
Monitoring and Alerting in Running System
Another high leverage layer. Instead of static thresholds, an agent in the monitoring system can correlate logs, traces, and metrics, suppress noise, cluster related failures, and suggest likely root causes. Alerts become contextual summaries rather than raw signals. This shifts the agent from code generation to operational intelligence. Example
The trajectory is a redistribution of authority. In the IDE, the agent assists. In PRs, it collaborates. In Actions, it enforces. In monitoring, it diagnoses. Each layer works best when it respects its latency budget and scope of control rather than trying to dominate the entire stack.