Even If the Models Froze Today, We've Extracted One-Millionth of the Value

Howie Liu is co-founder and CEO of Airtable, which now serves half a million organizations, among them Adobe, Amazon, Riot Games, and Pottery Barn. On No Priors, hosts Sarah Guo and Elad Gil bring him on to talk low-code a decade in, a new suite of AI features, and what enterprises actually need in order to adopt the models. The product launched in 2015 after two and a half years of building. Twelve years after the founding documents, Liu says the original map has largely been followed.

Gil has a personal footnote. He knew Liu from the first company, a contacts startup later acquired by Salesforce, and when Liu walked him through Airtable — verticalized apps, a platform a startup was supposed to be unable to pull off — Gil's reaction was that it was crazy. Guo adds another: Opendoor co-founder Eric Wu, talking angel investing, told her he really did not think the thing would work. It was poorly scoped. Liu seemed good. Both investors, on this telling, missed. Liu does not claim they were wrong about the difficulty. He claims the company had a few things going for it that conventional 'killer app, not platform' wisdom did not price in.

People who met Airtable in 2015 still describe it as a spreadsheet on steroids, a productivity tool. Under the hood, Liu says, it was always a real app platform that happened to be easy: relational data, logic, automations, interfaces. The low-code category that already existed was powerful and required technical expertise. Collaboration tools like Trello, and later Asana, were easy and project-management-centric. Airtable sat in between. The idea came from watching Salesforce after the acquisition. Salesforce did not win CRM, in his view, by shipping every CRM feature. It won because the platform could be customized to each customer. He wanted that model democratized for citizen developers.

The existing paradigm they compared themselves to was the spreadsheet — the most prolific app-building platform in the world, four decades in, one of the first core applications on personal computers. That category had already paid the cost of teaching people. Airtable's job was to feel like a spreadsheet. The first version was grid-centric, kept spreadsheet keyboard shortcuts, and let you paste a block from Google Sheets or Excel and have it work. Earlier no-code builders made you define a database schema in a separate modeling UI, or start from form layouts, and the floor jumped. Most spreadsheet use, Liu argues, is not number-crunching. It is customers, inventory, workflows — things that should have been databases or apps. Drive migration cost near zero and people move.

The platform later learned the 'app' lesson too. Templates were the first ready-made apps, each covering a sliver of the long tail, adding up to a platform that did not look like a traditional one. The enterprise turn was not a mid-course rewrite. The 2012 vision deck already said: start with the lowest possible floor, undercut complicated low-code tools plus Salesforce, ServiceNow, and old products like Quickbase, then raise the ceiling. Liu borrows language he attributes to Instagram co-founder Mike Krieger. Nobody looks at SAP and assumes it will get simple. Raising the ceiling meant two concrete bets: data scale, from thousands of rows toward hundreds of thousands and then millions; and code extensibility, so users could write integrations and scripts in Airtable's serverless environment against their own data and automations.

Had they charged enterprise in the first two years, the heavy use cases would have broken the product — some customers were already pushing it to the limit. The platform had to get robust first. The second condition was the product-led flywheel: enough organic adoption that high-value use cases grew up inside companies on their own. Liu's image is a petri dish. The team did not invent a vertical from zero. They looked for the brightest blooms, learned what global content production looks like at media companies, and sold that repeatably. The customer list, he says, was the cheat sheet.

Guo asked around before the taping. A friend wanted Liu's evolved view of product management. He starts with a controversy: Brian Chesky had talked about Airbnb 'doing away with product managers,' which Liu says was misread. The real move was splitting the role into two complementary jobs, product marketing and program management. Product marketing starts from the market: who is the competition, what job is the customer hiring the product to do. The jobs-to-be-done frame was meant to force that emphasis; like all frameworks, Liu says, it is great in theory and hard in practice. The framework does not solve the problem. A lot of PM functions are inward-looking — requirements, sprints, whether engineering is on timeline — which is the program-management half. The market half often has nobody wearing it.

Airtable, more than a consumer company, needs a third hat: creative work on complex UX. The product is information-dense. Automations and AI primitives come with unavoidable degrees of freedom. Someone has to own information architecture and the interaction of a complicated thing. Early Google and Meta PM cultures, he says, were good at recruiting for those hard design problems. The three hats do not have to sit on one head. A design lead can take complex UX, an engineering lead program management, a PM product marketing. What matters is that each hat is worn, especially on work that demands one more than the others. Dry, straightforward features can underweight the market hat. Hiring PMs who were great at other companies will not necessarily mean success here. You have to name why product is hard at Airtable.

He had just been at an NVIDIA onsite listening to Jensen Huang on culture: pick hard problems; if a problem is not hard enough, decline it, because the easy markets become about commoditization and go-to-market excellence. Liu is not about to copy fifty direct reports and zero one-on-ones. He does take the line about unique difficulty. Airtable's hard problems, as he now frames them, are UX and seeing the true job to be done in a novel way, not shipping a slightly better version of someone else's vertical SaaS. That same philosophy, he says, is what they are trying to apply to AI. It will either be the differentiator or they will not win in a big way.

Liu's AI history predates the current wave. In college, from 2005 to 2009, he studied neural networks in what he calls the wintry phase, before ImageNet. The fascination was an engineer's kind of laziness: instead of writing all the interface and business-logic code, show the computer the data and the desired outputs and let it find the rules. Airtable itself is a meta-solve for application SaaS — database, interface, and logic so you do not have to build a hundred vertical products. AI, to him, is a larger meta-solve for handwritten software. He interned at CrowdFlower, then a tiny Mission-alley company whose founder Lukas Biewald later started Weights & Biases. The early work was cheap, scalable click-work: image classification and moderation for social media. He watched the steady state slide from 'humans doing the job' to 'this data trains models that reach human level.'

When Transformer text applications arrived, he got his hands on early GPT-4 and on ChatGPT the day it shipped. Other people were enamored of sonnets. He was enticed by reasoning — work that felt like it could do meaningful analysis and still has not been fully exploited. His line is the one the episode hangs on: we could pause model development today and still get a million times more economic value from this generation of models than we have realized. Airtable has to play two roles at once, like Figma using AI to co-design, and, more importantly, as a meta app platform that lets half a million customers build AI apps of their own.

The first AI capability in beta was, transparently, a wrapper around OpenAI and later Anthropic. The placement was the point. AI is a field type sitting on your data and workflows: take product inputs and customer insights, generate a first draft of a PRD. You could do that in ChatGPT. Embedded, it runs on a predefined prompt, on a schedule, inside a larger automation. What they learned with a thousand beta customers, and many more since, is fear and intimidation. Beyond experimental chats, most people do not know what the models can do — translation, categorization, or taking a customer's earnings call and extracting insights a sales team can use to sell to Nike. The gap is imagination and know-how. You cannot throw a horizontal feature over the wall and hope enterprises figure it out.

So they did two things. They sat with design partners and made them more ambitious — a top-five law firm already wanted to automate pieces of contracting, and Airtable's job was to widen the claim. And they productized use cases the way templates once lowered the no-code floor: prompt templates for marketing and product management, plus inference that might one day look at an app's data and have an LLM suggest the right LLM questions. The bottleneck will not be solved by a stronger model if nobody can picture the workflow.

Asked what is still missing in the technology, Liu goes after the chat box. ChatGPT made conversation the default UX, and enterprises are doing useful RAG against HR benefits, product docs, anything an employee might ask an AI HRBP. Those are good. They are one small sphere in the TAM. The more interesting cases are structured, recurring processes where you are deliberate about which steps the model can take. Narrow domains already have companies swallowing the whole slice: Decagon on end-to-end support automation with an agentic model. Those firms can each get large. Added up, they still cover a fraction of departmental workflows inside the enterprise.

To go after the rest, he sees two shapes. The heavyweight one is Palantir: AI boot camps, forward-deployed engineers, bespoke processes. The lighter one is a platform that already has data, workflows, and human-in-the-loop, and that lets you decide where the model sits, what the inputs are, how the prompt is written, and how the outputs are shaped so a person can edit, approve, and chain the next model call or human step. In aggregate, that long tail is, in his estimate, trillions of dollars of economic or labor-equivalent value waiting on the right platform. Airtable cannot be Palantir for every customer, so they have been trying to codify the intuition.

They now run a full-day in-person AI workshop — sixty people in Los Angeles from media and big retail — from why Transformers got better, including a slide of parameter counts from GPT-1 to GPT-4, through basic prompt technique and anonymized customer cases. Parameter count is not the whole story, and small models are getting strong, but the curve answers whether this is a fad or an 8086-class jump. There is no turning back. They are digitizing the material into Airtable Academy, useful even if you go write code somewhere else. The valuable core is design patterns for AI workflows, analogous to software patterns like Observer. For translation they run a three-stage pipeline: first pass, self-critique, then a human review or an AI applying the critique back to the draft. Quality jumps. Next they want native many-shot prompting: point at five great PRDs in your base and generate the next from new customer notes, stuffing better examples into the prompt over time instead of a fine-tune — an application-layer RLHF loop. The limit case of onboarding starts from a content source, Google Drive or Box or Gong transcripts, and Autogenerates a table, workflows, and an interface: extract post-money valuation from every VC term sheet, tag every competitor mentioned on a sales call. They are hand-building those patterns now, including for themselves as customer zero, then folding the ones that work into the no-code GUI.

The sharpest question of the hour: if code is getting easy to generate, why does no-code still exist? Liu's view is specific. Codegen will eat some vertical software. It will not, short of AGI, replace no-code. Models are good at code because the corpus is huge, the domain is simulable, and synthetic data works; he cites training innovations at startups such as Magic and Poolside as well as the labs. Generating small snippets is already easy and getting easier. Generating a sophisticated end-to-end process app is a different object. A bespoke content-production system for Netflix or NBCUniversal is, in his analogy, an ERP for digital content: many steps, many nuances in business logic and data modeling.

Code makes sense as an augmentation for professional developers because the output is inspectable. You can read it, re-prompt, edit, take over. Text generation is the same: everyone knows English, so you can reject a marketing idea. If the artifact is a pile of SQL migrations, a business user has no way to iterate. Software is already a conversation full of 'I thought you meant X' even among professionals. Expecting a non-developer to zero-shot a complex app in raw code is, on this view, a category error. Airtable's move is to have AI generate the app in no-code form: a schema a person can see, automation logic as a visual if-this-then-that diagram, a layout you can reach out and change instead of wrestling the prompt. They were about to launch that more aggressively at the time of the recording.

A Cognition-style loop — spec, then tests, then code that passes — he grants for simple cases. For real business applications, unless a human is inspecting requirements along the way and correcting the logic and the interface, you will not generate meaningful complexity. Until AGI, the creative director, the architect, the person who defines the business requirements, is a human. So the generated product has to be a form that human can inspect. That form, by definition, is no-code. Gil's summary is the same argument in one beat: even much better codegen does not help non-technical people if the code is opaque, and if professional developers cannot zero-shot applications, non-developers will not magically do it either.