Integrating APIs into AI: New Creativity and Reliable Automation

Erik Wilde has years of experience in the API space. As an ambassador for the OpenAPI Initiative, he advocates for the use of open standards and best practices in API design and management. On YouTube, he runs the channel Getting APIs to Work, which is aimed at IT professionals, developers, and product managers. Wilde has also written numerous articles and books, and he speaks regularly at industry conferences.

iX: Interfaces are an absolute fundamental concept in software architecture; you constantly design, implement, and revise them for application programming. When do you start calling an interface an API? The semantics of this word go beyond a mere abbreviation.

Erik Wilde: You call an interface an API as soon as it is intended to be used by others beyond its immediate implementation context. An interface is just a technical boundary, whereas an API is a published contract. This means it is intentionally disclosed, documented, and stable enough for others—within or outside the development team or system—to rely on. It is primarily the aspect of intent and broader audience that distinguishes an API.

iX: Aren't the approaches that make an API useful and accessible to humans the same ones that make it accessible to AI, i.e., LLM-based automation?

Wilde: Both humans and machines need accessible APIs, but in different ways. For humans, documentation works best when APIs exhibit consistent patterns, as this facilitates understanding and allows for the reuse of tools and procedures across different APIs. Humans can also draw on broader context without becoming confused. Machines, on the other hand, require a clear, self-contained description of each API. Even as context windows grow larger, more context is not always helpful—AI often struggles to utilize larger contexts effectively.

Software Architecture Gathering

On November 25 and 26, the iSAQB Software Architecture Gathering 2025 will once again take place in Berlin. The program of the conference offers around 40 English-language talks and keynotes. Erik Wilde will give a talk at the conference "Your API Is Not Ready for AI (Yet)".

Humans appreciate APIs that are open, reusable, and flexibly adaptable, while machines benefit more from a guided abstraction layer that focuses on what can be achieved and how to do it, rather than exposing every possible operation.

iX: In the past, you've addressed the ecological footprint of APIs on your YouTube channel "Getting APIs to Work." When thinking about software efficiency and CO₂ awareness, does that align well with what is currently being promoted as Agentic AI?

Wilde: The ecological footprint of Agentic AI is significant, as exploratory use by agents often leads to more orchestration, more computation cycles, and higher energy consumption. This seems to contradict the drive for efficiency and CO₂ awareness in software and APIs.

The way forward is to view them as complementary: agents can explore creative solutions and uncover new approaches, but once a promising approach is found, it should be codified into a deterministic, repeatable workflow that is energy-efficient, scalable, and auditable. This balances the benefits of AI creativity with the need for sustainable and compliant operation, using as much AI as needed, but as little as possible.

By developing architectures that enable a smooth and conscious transition from experimentation to efficient execution, we can address both the uncertainty of AI's unpredictability and the need to control its significant energy consumption.

iX: What is the relationship between MCP and OpenAPI? Don't both pursue the same goal: standardizing the description of APIs and their easy accessibility? Or is it more akin to JSON:API, i.e., standardizing the APIs themselves?

Wilde: MCP, OpenAPI, and JSON:API are all about making functions available, but they target different users. MCP is specifically designed for LLMs, providing them with tools and resources tailored to their way of working. OpenAPI, on the other hand, is aimed at developers who want to consume HTTP APIs, focusing primarily on structuring endpoints and adding schemas to them.

JSON:API adds another layer by standardizing how schemas are structured and what common concepts an API should expose, allowing developers to benefit from familiar conventions and reuse tools that support them.

While it's possible to auto-generate MCP servers from OpenAPI, it typically doesn't yield the best results: for more complex APIs, a list of endpoints isn't enough, as LLMs lack the implicit understanding that humans bring when writing code. This is the fundamental difference: OpenAPI and JSON:API assume a human developer can fill in the gaps, whereas MCP needs to provide a sufficiently task-oriented structure for an LLM to succeed without that human intelligence.

iX: Do LLMs make certain automation approaches obsolete? Or are they just another use case? Given their non-determinism, they probably can't really replace reliable system integration.

Wilde: Automation is typically about reliability, repeatability, and efficiency, which LLMs do not provide. They are non-deterministic, not reliably reproducible, and not particularly efficient. What they do offer, however, is a new kind of creativity: the ability to fill in gaps, try out solutions, and handle messier parts of automation that are not possible with traditional approaches.

It's best to think of them as another tool in the toolbox—one that we can selectively employ, for exploration or for specific parts of a process, but not for the parts that require strict guarantees. Architectures that combine LLM-driven exploration with codified, deterministic workflows can unite the best of both worlds: AI where creativity adds value, and traditional automation where reliability is essential.

The interview was conducted by Richard Wallintin of WPS – Workplace Solutions.

(rme)