How will API’s evolve alongside AI?

And where there are opportunities to build

Happy Monday from NYC! I’m coming off an excellent weekend of rest, after a busy week that included a YC alumni gathering I hosted at one of my favorite bars in the city (Martiny’s) and a 2 AM outing to see my current DJ muse (Peggy Gou). This week I’m experimenting with more short form; feel free to share any feedback you have on the below.

The phrase “Application Program Interface” first appeared in a 1951 book called The Preparation of Programs for an Electronic Digital Computer, which also happens to be the first book written on computer programming. API’s have since become ubiquitous, as the glue that holds the Internet together.

API’s all attempt to achieve similar goals — give users the ability to access data or actions in the underlying application. But, the design of API’s is more of an art than a science. First, the soundness of an API reflects the underlying codebase; clean, modular code can more easily be turned into corresponding, structured API’s. A well-designed API also reflects the intentions of a program, and should be both easy to use and hard to misuse. As Joshua Bloch states in his paper How to design a good API and why it matters, “It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.”

The reality is, most API’s suck. Any developer who’s had to build integrations has encountered their fair of bad documentation and unexpected behavior. Some legacy applications are still stuck on outdated, hard-to-use protocols like SOAP, which can sometimes increase development time by 2X. Poorly designed APIs also result in an unending stream of support calls and tickets for the API owners. Even with clean API’s, users will sometimes run into limitations and need to reach out to the team to request a new endpoint.

LLMs can solve these issues from the ground up:

1. An agent should be able to crawl through a codebase and redesign functions to be more modular, and then spin out standardized endpoints.

2. This can subsequently enable agents to create more thorough documentation, which not only describe what endpoints can do, but also resources that describe the object types and broader concepts in an API.

3. It should become relatively trivial to translate aging API’s into more modern protocols like GraphQL.

4. And most importantly, the feedback loop between API users and owners can become extremely efficient. API owners should be able to put up ‘request endpoint’ forms for their users to submit requests for data and functionality. They can then feed this back to their internal code-generating agent to automate the process of receiving and actioning on endpoint requests.

As API development becomes fully automated, the explosion of endpoints will grow unmanageable for human developers. To work through the noise, it’ll be crucial for API users to leverage code generating LLMs of their own, which will likely be packaged into existing copilot tools. These agents will be able to read documentation, determine which endpoints to work with, and then implement the API integration within their custom codebase.

All of this is to say, API’s aren’t going away anytime soon, but the way we develop and work with them is going to look completely different within a few years. Ultimately, a lot more of the work will become invisible, with fewer people even knowing what an API is.