February 19, 2026 • Sebastien Andreo

In the age of artificial intelligence, the temptation is to apply this technology to everything, guided by the mantra: “Got a problem? AI can solve it.” or worse “I don’t know the Problem but AI is the Solution.” And indeed, AI can—today, it can boost productivity by orders of magnitude. With the rise of agentic AI, some even dream of offloading work entirely to autonomous agents.

But do we really want agents handling complex operations on their own—today? How do we manage unpredictability, which is for certain a feature not a flaw?

I could imagine that this enthusiasm feels reminiscent of the early days of Assembly language (ASM), the first human-readable representation of machine code. Assembly introduced four key innovations that revolutionized programming:

  • Human-readable mnemonics (e.g., ADD, JMP, MOV) replaced raw numeric opcodes.
  • Symbolic labels (e.g., loop:) replaced hardcoded memory addresses.
  • Macros and subroutines enabled code reuse (a precursor to modern functions).
  • Debugging became feasible—programmers could finally trace execution and fix errors systematically.

Just as Assembly was a foundational step toward modern programming languages, APIs are the modern equivalent of Assembly for agentic AI — the bridge between agents and external systems, databases, or other agents. Today’s APIs are the “instructions” of the digital age, much like Assembly was 80 years ago.

A Mirror to the Past: Challenges Then and Now

Even after Assembly made programming more accessible—

The use of symbolic addresses and a library of subroutines made programming much easier and less error-prone.” (Wheeler, The EDSAC, 1950 it still had major limitations:

  • Architecture-specific code (non-portable across machines)
  • Extremely low-level abstraction (direct hardware interaction)
  • Verbose and tedious syntax (repetitive, manual register management)
  • Debugging nightmares (obscure errors, no high-level tools)

Fast-forward to today, and API development faces strikingly similar challenges:

  • Dependency on external systems – You rely on code you don’t control, running in environments that can change or fail without warning. Authentication complexities – OAuth 2.0’s intricacies and exposed API keys create security risks. Proper scope management adds another layer of confusion.
  • Rate limiting and cost management – Developers often hit restrictions unexpectedly, with no real-time feedback. Usage-based billing leads to surprise charges when free-tier limits are silently exceeded.
  • Versioning headaches – Breaking changes force urgent refactoring, while unclear migration paths complicate upgrades.
  • Reliability concerns – Without transparent SLAs or status pages, teams can’t distinguish between their own bugs and provider outages. Silent failures (returning incorrect data) are particularly dangerous.
  • Inconsistent error handling – Vague messages like “Bad Request” offer no actionable guidance. Absent retry policies leave developers guessing whether failures are temporary or permanent.
  • Compliance and security risks – GDPR requirements, uncertain data residency, and sudden ToS changes can render applications non-compliant overnight. Vulnerabilities like token theft and data exposure threaten user security.

A Thought Experiment: Would You Trust Agents with Your Registers?

Take a moment to reflect: 80 years ago, would you have let multiple agents work on the same program, modifying registers based on their incomplete understanding of context? Probably not.

The same skepticism applies to APIs today. Sure, agentic AI could work—it’s exciting, even fun. But is it reliable? Reproducible? Does it handle edge cases correctly? Does it preserve the integrity of underlying systems? I have my doubts.

I’m not anti-AI—I see its value in my daily work. I use it to assist in coding, but at the end of the day, I can review the output. My expertise acts as a “human compiler,” verifying whether the generated code makes sense.

The Missing “API Compiler”

Wait—did I just say compiler? Why did the computing industry invent compilers (thanks to Grace Hopper’s A-0 System in 1952)? To automate the translation from high-level languages to machine code, solving most of Assembly’s pain points.

So, do we have an “API Compiler” today?

Not in the traditional sense of a C compiler, but we’re seeing the building blocks of what could become one:

  • API Specification (OpenAPI, AsyncAPI, GraphQL…)– A machine-readable contract defining endpoints, request/response formats, authentication, and data models. (Any API interface spec could serve this role.)
  • Arazzo Specification (from the OpenAPI Initiative) – Describes API workflows and sequences, documenting multi-step interactions rather than just individual endpoints. This enables: Better documentation of complex business processes. Improved API testing tools. Reduced integration errors through clear, consistent definitions.

The Path Forward

Just as compilers abstracted away Assembly’s complexity, we need tools that abstract away API chaos—ensuring reliability, security, and maintainability in an agentic world. Until then, blindly trusting agents with critical operations is like letting them rewrite your registers without oversight.

The future of AI is bright, but we must build the right scaffolding first.