11/11/23
Midjourney prompt: dialectic discussion, diagram in a philosophy textbook --ar 2:1 --v 5.2
A major secular shift in the technology of software of the 2010’s was what we now call “the rise of the developer” - the idea that any developer could use externally managed software endpoints to complete a task rather than create it themselves. This dovetailed with a secular shift in the business of software - namely the ability to sell by usage/seats of the people doing the actual development work (the developer) rather than thru a CTO. In the (near) future, I predict the vast majority of software will be made and governed by other software (agents), and human developers will act more as architects (or even “local CTOs”).
Those software agents will make, use, and chain APIs together in new ways, and maybe even give birth to a new category of 3rd party software which I am calling Squishy APIs. I think this technological shift may also give birth to new business models around the buying and consuming of third party software - if software agents are the ones doing the developing, what happens when they also have purchasing authority?
Presently, software communicates to other software via Application Program Interfaces (APIs) to send and receive data. The vast majority of modern APIs conform to REST or GraphQL standards, which are both structured and rigid in both their input and output types. This makes them incredibly brittle; the response to any API request is either a successful response or throwing an error, but it’s never a dialogue. This is in stark contrast to how you and I communicate - natural language is in effect our API for interfacing with the world around us, delegating actions, asking questions, coordinating - all things we would like to do with software and presumably will want to do more of with software agents.
Consider a scenario where you go into a restaurant to order food. You make a request to your server, but it would be awfully odd if their only response was coming with food or just saying “ERROR” and exiting the conversation. Instead, they might tell you they are out of stock on item X, so might you like item Y? And you might request if they can make item Y but spicy? And they might say let me see what the chef says. The robustness of natural language not only allows humans to be more expressive with our queries, but also more expressive with our follow ups, enabling a dialogue. I believe software in the future will also make requests and queries via dialogue.
Already we can see the impact of code synthesis via language model affect how software is getting made with tools like Cursor and Github Copilot. We even have LLMs popping up that have been fine-tuned for the specific purpose of interfacing with traditional APIs. I suspect code synthesis agents will make use of tools like GorillaLM to chain existing APIs together, and equally ambitious companies will make their own APIs to be more agentic and multipurpose (or Squishy). Basically, rather than operating a fleet of endpoints for a customer (currently developer, soon agent) to have to discriminate between, these companies will offer 1 API endpoint - in affect an attendant to help shepherd you through all of their various (now internal) API microservices that you need.
Midjourney prompt: virgil guiding dante, cubist painting --ar 16:9 --v 5.2
The short answer is Developer Experience. Currently, it is the onus of the software engineer or architect to know the set and dependency flow of all external services to use. But that’s not really what a developer wants - they don’t care how their message request/payment/function gets processed, they really only care about the output or end state. While this observation is broadly true about all software development, I believe this observation as it pertains to API businesses exposes a brand new type of business in service of agentic software developers.
Let’s take Stripe’s API docs page as an example.