IDE

The IDE is where developers actually work, and that simple fact makes it one of the most strategically important surfaces in the entire API lifecycle. For years the API industry built its tooling — design editors, discovery portals, governance linters, documentation sites — as separate destinations that developers had to leave their editor to visit. But the developer’s center of gravity is the integrated development environment, and every context switch out of it is friction and lost attention. I’ve argued for over a decade that API tooling needs to come to the developer in the IDE rather than making the developer come to the tooling. The IDE is where API discovery should happen, where design should happen, where governance guidance should appear, and where the new AI assistants live. Meeting developers in the IDE is how you make API practices actually stick, because it’s the one place developers reliably are.

The vision is old, and I was sketching it as early as 2011. I wrote that year about wanting an integrated development environment for APIs — a dedicated IDE that brought together API libraries, explorers, and client SDKs in one place. The instinct was already clear: developers needed API context where they worked, not scattered across separate tools. By 2014 I was writing about expanding the layer of API discovery from within the developer’s IDE — the idea that the IDE could surface relevant APIs as you coded, so discovery became part of the development flow rather than a separate research task. Eclipse Che, which I covered in 2014, was an early cloud-IDE that pointed toward API discovery and orchestration living in the development environment. The Bing Developer Assistant for Visual Studio delivered relevant API code right in the editor with IntelliSense. These early efforts were all reaching toward the same goal: collapse the distance between the developer’s editor and the API context they need.

The cloud and platform IDEs deepened the integration, and the major vendors brought their APIs into the editor. I wrote in 2017 about Google and AWS APIs being available directly in Visual Studio and Eclipse, and about Microsoft’s connected services bringing Azure and Office APIs into Visual Studio. This was the API providers recognizing that the path to developer adoption ran through the IDE — if your API showed up where developers worked, with autocomplete and code generation and inline documentation, you removed enormous friction from integration. The IDE became a battleground for developer mindshare precisely because it’s where the work happens. An API that’s a first-class citizen in the developer’s editor has a massive adoption advantage over one that requires leaving the editor to learn and use.

The most important recent development, and the one I’m most invested in, is governance moving into the IDE. For years governance lived in the CI/CD pipeline, where it caught problems after the fact and felt like an obstacle. But the IDE is where the decisions get made, and bringing governance there changes it from enforcement to guidance. I wrote in 2024 about using the Monaco editor — the editor that powers VS Code — to govern and guide API artifact changes, running Spectral rules and inline guidance as the developer works. The APIMATIC VS Code extension I covered brought IDE-native OpenAPI validation and governance scoring right into the editor. This is the realization of the editor-as-governance-surface vision: the developer gets IntelliSense-style hints, real-time rule feedback, and inline explanations of why a pattern is discouraged, all at the moment of authorship in their actual working environment. Governance in the IDE is governance that gets followed, because it teaches at exactly the moment and place the developer can act on it.

The AI dimension is what makes the IDE matter more than ever, and it’s reshaping the whole picture. I wrote in 2025 that developers will listen when governance is injected into the IDE via AI — because the AI coding assistant now lives in the IDE, and that assistant is increasingly how developers write API code. When your governance rules, your design standards, and your API context are available to the AI assistant in the IDE, the guidance reaches developers through the tool they’re already using to write code. The CLAUDE.md and copilot-instructions files, the AI assistant that knows your API conventions, the governance surfaced as the developer types — this is the IDE as the delivery point for both human and AI-mediated guidance. I raised a genuine concern about this too: AI-injected governance risks bypassing the human communication and collaboration that governance also depends on. But the trajectory is clear — the IDE, augmented by AI, is becoming the place where API design, discovery, governance, and assistance all converge.

The throughline across fifteen years is that the IDE is the highest-leverage place to influence how developers work with APIs, because it’s the one surface developers never leave. Discovery in the IDE means developers find the right APIs without breaking flow. Design in the IDE means definitions get created with tooling support. Governance in the IDE means standards get followed because they’re present at the moment of authorship. AI in the IDE means guidance reaches developers through the assistant they’re already using. Where I keep landing is that the API industry spent too long building separate destinations and not enough time meeting developers where they already are. The mature approach brings the whole API lifecycle into the IDE — not as a replacement for the broader tooling, but as the point of contact where the developer actually experiences it. The IDE is where API practices either become part of how developers work or remain a separate thing they’re supposed to remember to do. Getting them into the IDE is how you make them real.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

References

Guidance Details

Explore more

Discover APIs