The 3 AI Use Cases: Gods, Interns, and Cogs | Drew Breunig

LANGUAGE

We talk about so many things when we talk about AI. The conversation can roam from self-driving cars to dynamic video generation, from conversational chatbots to satellite imagery object detection, and from better search engines to dreamlike imagery generation. You get the point.

It gets confusing! For laypeople, it’s hard to nail down what AI actually does (and doesn’t) do. For those in the field, we often have to break down and overspecify our terms before we can get to our desired conversations.

After plenty of discussions and tons of exploration, I think we can simplify the world of AI use cases into three simple, distinct buckets:

1. Gods: Super-intelligent, artificial entities that do things autonomously.
2. Interns: Supervised copilots that collaborate with experts, focusing on grunt work.
3. Cogs: Functions optimized to perform a single task extremely well, usually as part of a pipeline or interface.

Let’s break these down, one by one.

Gods

Gods are the human-replacement use cases. The much hyped artificial general intelligences (AGI) that are allegedly just around the corner…

(Or maybe they’re just imminent when you’re trying to close one of the largest funding rounds in history? After the round is finalized, you can go back to realism. But I digress…)

Gods require gigantic models. Their autonomous nature – their defining quality – means a low error tolerance and a broad, general model. But a giant LLM surely isn’t enough. We could throw every data center and every database at the problem and still be short. We’re going to need breakthroughs, oodles of researchers to find these breakthroughs, and billions of dollars (at least).

Few entities will work towards the AGI or god use case because the barriers are so high. But, so are the rewards. The massively funded private ventures and sovereign-backed labs will continue their work.

But for most of us the Gods use case will most impact us in the form of hype and hand-wringing. It will affect funding, regulation, and politics. (Though if a would-be god-builder visibly hits a wall, we’ll feel it in other ways.)

Interns

Interns are the copilots (and a term I’ve shamelessly borrowed from Simon Willison). Their defining quality is that they are used and supervised by experts. They have a high tolerance for errors because said expert is reviewing their output, and can prevent embarrassing mistakes from going further. Interns are focused on the grunt work: remembering documentation and navigating references, filling in the details after the broad strokes are defined, assisting with ideation by being a dynamic sounding board, and much more.

Github Copilot and Cursor are interns for programmers. Adobe Firefly and Visual Electric are interns for designers. Microsoft Copilot and Grammarly are interns for writers. NotebookLM is an intern for researchers. Monterey is an intern for product managers. There are many more examples.

Adobe’s Project Turntable – a utility for rotating 2D designs as if they were 3D objects – is a perfect example of the intern form. Jess Weatherbed, writing for the Verge, sums it up:

The tool allows users to click a button and then drag a slider along to automatically view and snap a vector image into a different viewing perspective — something that would typically require an artist to redraw the image entirely from scratch. The examples demonstrated at the event retained their original designs when rotated without warping into a new overall shape.

The work being done here – redrawing the vector drawing from many different angles – is the type of grunt work an intern at a design studio might perform. The look and feel of the design and its proportions are already set. The work required is tedious but easily defined. Further, the output of this tool is editable by the expert using it. If Turntable is sloppy with a line or two, the artist can drop in and tweak it.

Because they are tools for specific types of experts, Interns are limited to specific domains. They don’t have to be generalists. Their model sizes are large, but not massive. One could build new interns – starting from scratch – for millions. If you use an open model, the costs are dramatically lower.

Today, Interns are delivering the lion’s share of the realized value from AI. Engineering copilots alone are delivering massive returns, increasing the output and capabilities of expert programmers. I’ve heard of a few large companies who have slowed down hiring due to their effects and have witnessed many tiny teams ship products years beyond what they could have delivered even 3 years ago, thanks to Github Copilot and similar tools.

And while Interns are delivering tremendous value, they are secondary to the experts driving them. How do you improve the output of an AI copilot? Simple: find a better expert.

Interns Toys

“But Drew,” you might say, “what about the fun image generator or friendly chatbot I play with occasionally? It doesn’t really fit in the intern bucket.”

You’re right. I think these are Toys, a subcategory of Interns defined by their usage by non-experts. Toys have a high tolerance for errors because they’re not being relied on for much beyond entertainment.

To improve a toy you don’t usually need to improve the user or the model; rather, the opportunity is usually the interface. We, as a community, just tend to focus on the models because we’re nerds.

But moving on…

Cogs

Cogs is the last use case bucket. Cogs are comparable to functions. They’re designed to do one task, unsupervised, very well. Cogs have a low tolerance for errors because they run with little expert oversight.

Cogs may be built into data pipelines, performing some enrichment or transformation step, alongside bog-standard functions powered by regex or SQL. Cogs may be built into interfaces, transforming human output like speech or scribbles into machine-readable input.

Cogs exist in systems as reliable components. Their focus on one task and a low tolerance for errors mean they are usually built with fine-tuned or heavily prompted small, open models. Cogs are cheap to run and relatively cheap to ship. They are enabled and improved by data, used for fine-tuning and/or developing prompts.

We used a cog here recently! Ollama and an embedding model powered a step in our conflation pipeline, nestled among some SQL queries and string distance functions. This cog was cheap, quick, and reliable after some initial configuration.

Cogs are, by far, the dominant use case amongst enterprise teams building with AI. As we covered after the DataBricks summit, in most discussions among builders, “AI looks like just another pipeline function.”

Cloud platforms – DataBricks, Snowflake, Azure, AWS, and others – have recognized the dominance of the cog use case and have sprinted towards delivering tools and hardware for building, testing, and running them.

Sorting the ocean of AI use cases into the Gods, Interns, and Cogs (and fine, Toys) buckets has helped me tremendously. It’s easier to navigate the noise, ask questions about new products, and identify the bottlenecks holding back each category.

It’s challenging to work in emergent fields as the language has yet to settle. Communication challenges are a tax that must be dealt with before productive conversations can occur. By scaffolding the mess with appropriate structures we can ease exchange.