GPT-3 came out this summer and the takes have been… predictable. One camp thinks it’s the beginning of AGI. The other camp calls it a stochastic parrot – very expensive autocomplete. I think both sides are missing the most interesting implication.
Language models are going to change how humans interact with software. Not because they’re intelligent. Because they’re useful.
Whether GPT-3 “understands” anything is a fun bar argument. Professionally, I don’t care. What I care about is what it can do. You give it a natural language description and it generates plausible code, SQL queries, regex patterns, API calls, data transformations. You give it a few examples and it continues the pattern. You ask it a question about a block of text and it pulls out the relevant bits.
Is it perfect? No. The error rate is too high for unsupervised production use. But it’s good enough to work as a translation layer between what a human wants and what a system needs. And that’s the thing that matters.
For fifty years we’ve made humans learn the language of computers. Programming languages, query languages, CLI syntax, GUI conventions. What if we invert that? What if computers start learning the language of humans? That’s what’s happening here, and I don’t think the industry has fully processed it yet.
Think of it as a new layer in the stack. Below it you have traditional software – APIs, databases, business logic – running with precision and determinism. Above it you have humans, communicating with all our usual ambiguity and imprecision. The language model sits in between, translating intent into operations and results back into explanations.
Concretely: instead of writing SQL, an analyst describes what they want to know. The model generates the query. The system runs it. The model summarizes the results. The analyst reviews the SQL to sanity-check it, but the barrier to just asking a question drops massively.
Or: instead of trying to remember the exact kubectl syntax for whatever you’re doing, you describe what you want to happen. Model generates the command. You review it, approve it. You still need to understand what the command does, but you don’t have to remember the flags.
Or: instead of keyword-searching docs, you ask a question. The model, grounded in the doc corpus, gives you a direct answer with references. This is different from search because it handles the synthesis step that right now falls to the human.
The big challenge is trust. These models are confident. They sound authoritative. And they’re wrong often enough that you can’t just accept the output blindly. For anything that matters, you need a human checking the work.
I don’t see that as a failure – I see it as a design constraint. The model amplifies human capability. It doesn’t replace human judgment. So you design the interface to make verification easy: show the generated query alongside the results. Show the generated command alongside a preview of what it’ll do. Show the source material alongside the synthesized answer.
The orgs that figure out this trust interface – how to present model output so it’s quick to verify and correct – are going to unlock huge productivity gains. The orgs that try to remove the human entirely are going to have a bad time.
This one might sound aggressive: within five years, natural language is going to be a standard input for most developer tools. IDEs, dashboards, database clients, cloud consoles – they’ll all have a natural language interface alongside the traditional one.
It won’t replace the traditional interface. Someone who knows SQL is still going to write SQL when they know exactly what they want. Someone who knows kubectl will still type from muscle memory. But for exploratory stuff, unfamiliar tools, complex operations – natural language is going to be the starting point.
The accessibility implications are huge. Right now, interacting with most software systems requires specialized knowledge. If the barrier drops to “describe what you want in plain English” – even with a human still verifying the output – that’s a massive change.
If you’re an engineer, start playing with the OpenAI API. Build something small that uses a language model as an interface to an existing system. Get a feel for what these models do well and where they fall on their face. Build that intuition now, because the engineers who understand both the potential and the limitations are going to be really well-positioned as this matures.
We’re at the beginning of a big shift in how humans interact with software. I’m not sure exactly how it plays out, but I’m increasingly confident it plays out fast.