Featured
AI or API? | Chatbot cuckoos are bloating tech
OpenAI wrappers are becoming a shortcut for start-ups, but are they sustainable?
APIs enable more than anything else in software
Teams can bring pre-made external features into a product when they integrate with external APIs, including third party AI. I use an API to let users generate 3D models from prompts on matchboxxr.
But while there are an increasing number of start-ups whose focus is all about AI and nothing else, a significant portion of those are really front-ends acting as a ‘ChatGPT wrapper’. In other words, “any application that provides a purpose-built user interface (UI) to interact with OpenAI’s GPT models.”
When you see some of the branding, they would have you think they are assembling cyborgs under thunder and lightning. Not making API calls to an oven-ready chatbot made by someone else.
Solopreneur wrappers
Large Language Models (LLMs) let individuals and small teams build lightweight apps and websites with AI features to save users time. A quick search on Reddit finds the following small scale start-ups:
The thing is, you could make these for free in ChatGPT or Gemini, in 15 minutes.
Well-funded ventures
Larger scale operations produce polished platforms. But much of the budgets seem to go on marketing and visual design. This makes me wonder if they are also wrappers. See below.
- Friend — a wearable chatbot that pretends to be your friend
- Artisan — a virtual sales agent
- Elicit — a research paper analysing chatbot
Friend, albeit strange, offers a screen-less device that listens to you all day. Artisan offers a Hubspot-level CRM solution with AI a mere feature. And Elicit sits on a database of 125 million research papers.
These are all interesting challenges, but not about AI. It would appear that all three products send API requests to an LLM. Now that would have its own set of challenges.
The impacts building for AI-first, API-second
API bloat
Relying on a high volume of poorly designed API calls will slow down a product and make it less scalable.
It’s dangerous to ignore API throttling or building a product to play nicely with rate limits, instead treating a third party API like it’s a native function in your app’s codebase.
Heating up the planet
The sheer power of AI at the moment is, like crypto, using an insane amount of computing power. And this heats up our planet.
Even if space-based servers do become a reality, they may never be available in the quantities we need. “To prevent new AI models from becoming ecological catastrophes, AI experts need to be intentional about how they design them” as said by Nat Meysenburg.
Missing the nuance
A shortcut is always a blunt tool. Assuming AI is the answer often comes from a failure to properly study the question. This might not only lead to a poorly executed solution, but the wrong solution entirely.
Proper user research and problem framing seems to be lost in the buzz around the AI promise.
Design offers more than you think
Data as a product
I put together a checklist last year to use as a set of principles when building anything that sends or receives data. Keeping the user experience in mind when shaping API behaviour.
If a piece of software or a feature is acting as a wrapper to an external AI model of some kind, paying attention to this as much as the front-end will ensure the user gets the best quality experience available.
The above linked article goes into much more detail, but the basis is the below checklist. Data products must ensure the user experience meets the following qualities.
Google’s AI Principles
Another great resource when building a product is to consider whether AI is needed and, if so, in what form. Google have put together some fantastic principles to do just this.
So be mindful that when you build anything with AI, you aspire to the following:
- be socially beneficial
- avoid creating or reinforcing unfair bias
- be built and tested for safety
- be accountable to people
- incorporate privacy design principles
- uphold high standards of scientific excellence
- be made available for uses that accord with these principles
What’s next?
Developer/creator experience to be front and centre
Developer experience was still being nurtured when LLMs blew up. But it isn’t as snappy or easy to grab as AI.
DevEx is more than an AI copilot or LLM assistant. Well-structured, well-named schemas, flexible functions, up-to-date documentation, sufficient testing data… this are just a sample of must-haves from the dozens of interviews and workshops I ran throughout the first half of 2024 with real developers. Not chatbots, people. I have the anecdotes and swearwords to prove it.
This will become even more important as we see increasingly impressive techniques like LLMs become mainstream. Because they are going to be harnessed as third party SDKs, plugins and APIs.
The future is more of the same — integrations
Friend and AIPin are cool products, because they use new and innovative haptics, gestures and voice control. Beyond a departure from screens and a take-up in chatbots, further expansion into integrations seems the ideal next step.
Imagine a smart mirror that can detect early prodrome signs of a migraine, so the sufferer can plan ahead.
Imagine an earbud that can alert law enforcement officers when a colleague’s cortisol is at dangerous levels during an altercation.
Or even a bracelet that can record subtle daily triggers for Cognitive Behavioural Therapy, while encrypting voices and names for GDPR.
AI may be the answer, but what is the question?
AI is awesome. But the art of bringing together hardware, data and interactions, that’s where the fun is.
I’m excited about the future of artificial intelligence, but I hope we can pause our awe and question it, the same way we question other technology.
