Copilots

Copilots are where the AI wave landed most concretely in the API world, and they arrived at both ends of the pipeline at once — inside the IDE helping developers write API integrations, and increasingly inside the runtime calling APIs directly. GitHub Copilot was the opening move: an AI coding assistant that could suggest code completions, generate API call stubs, and write the boilerplate that developers had always had to grind through manually. That alone changed the daily experience of consuming APIs for millions of developers. But the more interesting and more consequential shift is what came next — copilots not just helping humans write API calls, but becoming API consumers themselves, calling APIs autonomously as part of agentic workflows. The story of copilots and APIs is really two stories running in parallel, and both of them are still unfolding.

The IDE integration story starts earlier than most people remember. I was writing in 2014 about API discovery moving into the IDE — Eclipse Che as an early example of in-editor API orchestration and discovery — because the insight was already clear that the IDE is where developers spend their time, and pulling API context into that space rather than forcing constant context-switching to documentation tabs would matter. That instinct took a decade to fully arrive, but GitHub Copilot proved it comprehensively: when the AI assistant lives where you work, it collapses the friction between knowing an API exists and being able to use it. You don’t leave the editor to look up the authentication pattern or the pagination parameters — you ask, and something answers inline. This is a profound change to API consumption, and it puts new pressure on how APIs are documented, because a copilot trained on bad or outdated documentation confidently generates bad code.

The documentation pressure is where the copilot story intersects most sharply with API design discipline. I wrote in 2024 about the shift from human-readable to machine-readable API documentation — not as a new idea, but as a newly urgent one. LLMs parse documentation, but they parse structured, consistent, machine-readable documentation far better than they parse narrative prose. An OpenAPI spec that is clean, complete, well-described, and consistently structured gives a copilot something reliable to work from. A documentation site that exists only as rendered HTML, with examples scattered across tutorials and authentication buried in a getting-started guide, produces copilot suggestions that are plausible-sounding but frequently wrong. The AI coding assistant made API definition quality a user experience problem in a way it hadn’t been before — developers started noticing directly when an API’s spec was good or bad, because it showed up immediately in whether the copilot could help them or hallucinate.

My API snacks experiment in 2024 was one way I explored this — combining APIs.json, OpenAPI definitions, Postman collections, and semantic metadata like JSON-LD into small, purpose-built packages optimized for AI-driven capability discovery and execution. The premise was that if copilots and agents are going to consume APIs effectively, the artifacts need to be structured specifically with that consumption in mind, not just with human developers in mind. Breaking OpenAI’s own monolithic OpenAPI definition into ten separate, domain-specific specs in 2024 was another angle on the same problem: a single 10,000-line OpenAPI file is useful to a human who can navigate it, but it’s harder for an LLM to reliably consume — smaller, coherent, single-purpose API definitions are better inputs for AI-assisted development, whether the AI is writing integration code or calling the API directly.

The deeper point, one I’ve made repeatedly and will keep making, is that I wrote a post in 2024 called “This Post Is Not About Artificial Intelligence” specifically to say: the thing that determines whether a copilot succeeds with your API is not the AI, it’s the API. AI effectiveness with APIs depends entirely on strong API foundations — governance discipline, good discovery, well-designed hypermedia and linked data, a coherent and well-described API landscape. A copilot pointed at a messy, undocumented, inconsistently designed API portfolio produces messy, unreliable, inconsistently generated code. Garbage in, garbage out, now at AI speed and scale. The organizations that invested in API governance and quality before the AI wave arrived have a real, measurable advantage: their copilots work better, their agents are more reliable, their developers are more productive. The organizations that skipped that work are discovering the debt compounds when the AI amplifies it.

The copilot-instructions side of this story is one of the more interesting developments I’ve tracked. Speakeasy’s agent skills work, which I wrote about in early 2026, introduced a family of files — CLAUDE.md, SKILL.md, AGENTS.md, RULES.md, and .github/copilot-instructions.md — designed to inject operational knowledge directly into AI coding assistants. The copilot-instructions.md file specifically targets GitHub Copilot, giving it context about your API, your codebase patterns, your team’s conventions, the things you always want it to know before it starts suggesting code. This is the codification of institutional knowledge in a form that AI assistants can consume — a way of answering the question “what does this AI need to know about how we work” in a structured, maintainable artifact. I wrote about governance guidance going this direction in 2026: Spectral rules, Vacuum checks, design standards — all of it flowing not just into CI/CD pipelines but into the copilot’s context, so that governance awareness is present when the developer is actually writing code, not just when the linter runs afterward.

MCP is where the two halves of the copilot story converge. I wrote in 2025 about the strategic positioning of MCP alongside HTTP, GraphQL, and event-driven patterns — specifically that MCP is additive and specialized for conversational UI and LLM use cases, not a replacement for the OpenAPI-described REST APIs that are the backbone of enterprise integration. What MCP provides is a standardized way for AI assistants and copilots to call tools and APIs as part of a conversation — the protocol layer that turns “I asked my AI assistant to do something” into “the AI assistant called the right APIs to do it.” AssemblyAI’s documentation was an early concrete example I wrote about in 2026: a developer portal that offers the option to open documentation directly in Claude, ChatGPT, Cursor, and Claude Code via MCP — a bridge between the human reading the docs and the AI assistant that will actually execute against the API. That’s the future of developer onboarding in the copilot era: meet developers where their AI assistant lives.

By 2026, copilot integration had become a recognized operational dimension for API providers. My Avalara API review explicitly listed “Reusability: Integrations, Copilot” as one of fourteen areas of modern API operations worth benchmarking — alongside authentication, documentation, governance, and the other elements that have been on the list for a decade. Copilot support isn’t a bonus feature anymore; it’s a first-class concern for any API that wants to be genuinely usable in a development environment where AI assistance is the default. The emerging standards layer supports this: robots.txt AI rules, Agent Skills, MCP, WebMCP, and UCP all forming the protocol infrastructure for how copilots and agents discover and interact with APIs at the platform level.

The honest framing I keep returning to is the one from my 2026 post: agents are just APIs, nothing has changed. A copilot calling an API is still a client making a request to an endpoint that returns a response. The authentication, the rate limits, the schema validation, the governance rules — all of it still applies. What has changed is the consumer. The consumer is now an AI assistant that doesn’t read documentation, that generates code probabilistically, that benefits enormously from clean machine-readable contracts, and that can be explicitly instructed about your API’s patterns through the new family of AI context files. The API discipline that was always worth doing — precise definitions, good schema, consistent design, strong governance, complete documentation — turns out to be exactly the discipline that makes your API work well with copilots. That’s not a coincidence. The things that make APIs clear and consistent for humans also make them clear and consistent for machines. Copilots just made the cost of skipping that discipline visible faster and more directly than it had ever been before.

References

• API Discovery Continues Its Move Into The IDE With Eclipse Che
• Voice As The Next Generation API Client
• This Post Is Not About Artificial Intelligence
• Breaking OpenAI OpenAPI Into 10 Separate OpenAPIs
• Moving API Docs From Human-Readable To Machine-Readable
• I Found A Use For The AIs
• API Snacks For AI
• HTTP APIs And GraphQL, Event-Driven, And Model Control Protocol
• Why Static Templates Make More Sense Than AI-Driven Boilerplate Code Generation
• My Avalara API Review Provides A Benchmark For Modern API Operations
• Agents. It Is All APIs. Nothing Has Changed
• Why Do I Need Agents When I Have Requests, CRON Jobs, And Events?
• There Is A Lot Of Knowledge And Wisdom Packed Into Speakeasy Agent Skills
• Where Is Governance Guidance Going?
• The Promise Of A New Specification
• Learning About Standards Via Cloudflare Radar AI Insights
• A Bridge Between Human And AI On Your Documentation