Everyone’s looking at Cursor, Claude Code, Antigravity, and friends and seeing coding tools: AI-powered IDEs that help developers ship faster. Useful. Narrow. Incremental.
That interpretation is comfortable—and wrong in the way “the internet is for academics” was wrong.
What shipped into IDEs first wasn’t “AI for code.” It was one of the first mainstream agent management interfaces: a general-purpose way for a human to supervise an AI that can take actions, use tools, and update state while you stay in control. Code was the Trojan horse. The interaction model was what rolled out.
Strip away syntax highlighting and Git integrations and you’re left with a small set of primitives:
- Context curation — selecting and shaping the information the agent should use.
- Tool access — giving the agent “hands” (filesystem, APIs, browsers, databases, CLIs).
- Human-in-the-loop control — the ability to approve, reject, and constrain actions before they happen.
- Iterative execution — the agent acts, the world changes, the agent reads the new state, you iterate.
- Persistence (sometimes) — memory, conventions, and project knowledge that accumulate over time.
That bundle is not specific to programming. It’s a pattern for any work where an AI can propose and execute steps—but you still want oversight.
The distinction matters. ChatGPT-style interaction is “generate a draft.” Agent-style interaction is “run a process.” In a developer workflow, that difference is obvious: an agent can write code, put it in the right place, run tests, and prepare a pull request—while you supervise each step. But the deeper point is the loop itself: you define the objective and constraints, the agent proposes a plan and specific actions, you approve or block the risky parts, the agent executes with tools and updates state, you review the result and iterate. This loop—not the code output—is the foundational pattern. Once you see it, “coding tool” looks like one early, lucrative use case—not the category.
So why did it land in IDEs first? Because IDEs are uniquely friendly to experimentation. Developers pay for productivity without procurement. Power users tolerate rough edges if the capability is real. Feedback is immediate—did it compile? did tests pass? Tooling is already expected: terminals, files, APIs, plugins. The IDE wasn’t the destination. It was the on-ramp.
The moment agents can reliably connect to the tools where work actually lives—documents, chat, tickets, CRM, databases—the “IDE-shaped” interface stops being the center of gravity.
Model Context Protocol (MCP) matters here. It’s positioning itself as a standard way for models to connect to external tools and data sources—like USB-C for agents. Instead of every vendor building bespoke integrations, there’s a shared interface that makes tooling more plug-and-play. An agent that can read your internal docs, pull the right context, and take limited actions across systems becomes less of a demo and more of a workflow.
But tool access turns model mistakes into real-world mistakes. Any serious deployment needs permissions, audit logs, rate limits, and clear “human must approve” gates.
I already use agent workflows for tasks that have nothing to do with shipping software. Research synthesis: ingest a pile of PDFs, extract claims, cluster themes, output an annotated memo with citations to source passages. Contract review: compare a vendor’s terms to a template, flag deviations, explain practical risk, draft redlines for the lawyer to validate. Meeting prep: pull relevant emails and prior notes, summarize open threads, draft an agenda and a one-page briefing. Competitive intelligence: monitor changes, compare to historical positioning, draft an executive summary with “what changed / why it matters / what to do.”
Same pattern every time: context, proposal, approvals, tool-backed execution, review, iterate. The fact that today’s best interfaces look like code editors is an accident of distribution, not a requirement of the workflow.
What these examples reveal is that the emerging skill isn’t “prompting.” It’s management.
“Prompt engineering” is collapsing into UI features—templates, memory, better defaults, guardrails. Every major chatbot now ships with suggested prompts and conversation history. Useful, but not a durable edge. What’s emerging instead is something broader: agent management—the ability to direct, supervise, and collaborate with agents across messy, multi-step work.
It breaks down into a few core competencies:
- Task decomposition — knowing what to delegate, what to keep, and how to sequence work.
- Context discipline — giving the agent exactly what it needs and nothing that confuses it.
- Quality calibration — judging “good enough,” spotting failure modes, tightening instructions.
- Risk control — deciding which actions require explicit approval, designing safe constraints.
- Orchestration (emerging) — coordinating multiple specialized agents and synthesizing outputs.
The analogy: this will be to knowledge work what spreadsheets eventually became to office work—not trendy, but invisible infrastructure. That transformation took decades; this one will move faster, but the pattern is the same.
Now, the honest assessment: the interaction pattern is proven, but the reliability and governance aren’t—yet. Long-running agents need babysitting and still get stuck. Evaluation is immature; it’s hard to measure “did this work?” beyond obvious tasks. Enterprise governance is early: permissions, auditability, compliance, policy. Costs matter at scale, especially when agents thrash or loop. Multi-agent handoffs are still brittle. We’re in the MS-DOS era, not the iPhone era. That doesn’t mean the trajectory is fake. It means the interface that makes this mainstream will likely look nothing like an IDE.
Which brings us to the real product opportunity: not “a better agent,” but the management layer above agents that makes them safe, cheap, and operationally useful.
- Policy and permissions — what can this agent read, write, where, and when?
- Approval workflows — which actions require human sign-off, with what evidence?
- Observability — logs, traces, and “why did it do that?” explanations.
- Evaluation and QA — regression tests for workflows, not just for code.
- Routing and specialization — selecting the right model, agent, or toolchain for the job.
- Budgets and rate limits — preventing accidental burn.
- Memory with boundaries — persistence that helps without leaking secrets.
Current IDE agents are credible prototypes of these primitives—but they’re not the end state. They’re proof that the loop works and that people will pay for it.
For knowledge workers, the mindset shift is not “AI is a tool I use.” It’s a move from writing prompts to orchestrating work, from doing every step to supervising execution, from “AI helps me” to “I manage agents.” This isn’t a clean replacement story. It’s a leverage story. Someone who can reliably direct a few agents to do real, constrained work will outproduce someone who can’t—and that gap compounds over time.
The IDE was a Trojan horse. Most people don’t recognize it yet because it’s disguised as something “for programmers.” The people learning to manage agents now—even with clunky tools—are building a skill set that will compound for the next decade.
Originally published on LinkedIn.