亲手做汤才能尝出味道：Airtable 创始人如何把十三年产品为 AI 重做一遍

Host Lenny Rachitsky opens by asking about a viral tweet that declared Airtable dead, claiming it had raised far more than it was worth. Liu says almost none of it was true. The author, who he believes worked at a company that sells private-company data, had revenue and growth numbers wrong by a large multiple, and the tweet gained legs after being discussed on the All In podcast, which later issued a correction.

Rachitsky then turns to a trend he sees Liu embodying: CEOs becoming individual contributors again, writing code and leading initiatives themselves. Liu explains that in Airtable's early years he wrote both backend and frontend code, because for a pure-software platform the intimate design decisions were the product. He compares this to Figma, founded around the same time, where the early team also spent about two and a half years hands-on before launching.

As companies scale, Liu says, leaders drift away from those details and lean on blunter instruments like broad roadmaps and go-to-market playbooks. That can work for scaling something that already works, but he argues AI changes the calculus. Every software product, in his view, has to be refounded, and each model release implies new UX patterns that only someone close to the details will spot.

Liu embraces the idea of being the company's chief taste maker, but adds that it is now hard to taste the soup without participating in creating it. AI cannot be evaluated from screenshots or recorded videos. He says leaders should play with finished apps and also with the underlying primitives through APIs and chat interfaces, pushing them to their limits like a chef getting to know new ingredients.

Rachitsky cites Dan Shipper's rule of thumb that a company will adopt AI well if its CEO uses ChatGPT or Claude daily. Liu goes further and says he is probably the most expensive inference user of Airtable AI, both internally and for a long time across all customers. He runs LLM calls over long sales-call transcripts to extract product and positioning insights, using a map-reduce capability that chunks the corpus and then aggregates the results.

To Liu, spending hundreds of dollars on such a run is trivial next to the strategic value, comparing it to a very smart chief of staff reading every sales call from the past year. A consulting firm could charge millions for similar work. He thinks more people should throw compute greedily but smartly at high-value problems.

His calendar changed too. He cut his standing one-on-ones, preferring urgency-driven meetings seeded with something he has just learned, plus occasional long in-person catch-ups. He keeps a weekly sprint check-in on AI execution, now covering roughly half of the product and engineering org, and constantly asks how an AI-native company like Cursor or Windsurf would execute.

Airtable's product org originally grew into groups that each owned a feature or surface area, such as search or mobile. Liu says that structure produces incremental thinking, because everyone's remit is to improve one feature rather than coordinate a dramatic change across surfaces. A later reorg into business-unit-style pillars, including enterprise, self-serve, AI, solutions and infrastructure, enabled bigger bets but still did not match the pace of AI-native companies.

The latest reorg creates what Liu calls the fast-thinking group, officially named AI platform, aimed at shipping new capabilities on a near-weekly basis that make users' jaws drop. Alongside it sits a slow-thinking group for deliberate work like HyperDB, the data store that can now handle datasets of hundreds of millions of records. That kind of infrastructure, he notes, cannot be shipped in a week as a hacky prototype.

The two groups complement each other. Fast AI launches create top-of-funnel excitement and new use cases, including in large enterprises, while the slow group lets those seeds grow into bigger deployments. Liu says many AI-native companies struggle to turn a wide wave of curious early usage into durable retention and expansion.

For the fast group he looks for autonomous, entrepreneurial people who can think full-stack about the problem and the wow factor, not necessarily former founders. His example is a coming feature that lets the conversational agent Omni generate custom code to extend apps with bespoke visuals. That forces designers and engineers to blend UX thinking with what models can reliably produce in one shot, and to design human approval and re-prompting workflows.

Liu describes himself at heart as a product UX person, using UX in a deeper sense than cosmetics: what the product should do and how it represents that to the user. He thinks AI products are badly under-merchandised. Even ChatGPT, which he calls hugely successful, greets users with a blank chat box, and he wants richer visual metaphors, color and interaction to show what the underlying model can do.

Rachitsky connects this to Nick Turley of OpenAI, who asks of every project whether it is maximally accelerated and who says that with AI you often only learn what people want once it is out. Liu agrees. He notes that Palantir and Harvey succeed with sales-led motions, yet argues the best way to deliver AI value is experientially, and he points to ChatGPT's rise to hundreds of millions of weekly users in under three years as the proof.

Airtable, he says, started as a product-led growth darling, moved up-market with more sales, and he now wants to refocus on builder-led adoption. The company made its agent the default way of doing everything, so that the Airtable app is effectively an artifact manipulated by an agent. Previously the assistant was a secondary sidebar.

Asked about Airtable's homepage now inviting visitors to describe what they want to build, Liu says this is a prime example of form factors evolving with model capability. GPT-3.5-era models could only support autocomplete, which is why GitHub Copilot took that shape. As models improved, Cursor pioneered agentic code generation, and now a tool can build a game from scratch. Airtable's original vision of democratizing software creation makes this a different means to the same end.

Liu says an older company must take a clean-slate approach: if you were founding a company with the same mission today, how would you pursue it with a fully AI-native approach? Then ask honestly whether your existing assets help or hurt. If they do not, he says, you should find a buyer and, if you care about the mission, start its next incarnation. He believes Airtable's no-code components genuinely help.

His reasoning is focused on business apps, such as a CRM or a restaurant's inventory system, not viral consumer games. An agent writing everything from raw code tends to produce bugs, security and data problems, and context collapse as the app grows. Airtable's real-time, collaborative data layer, views, interface layouts and automations work like a domain-specific language the agent can assemble.

The result, Liu says, combines reliable Lego pieces with agentic assembly, and non-technical users can still understand and edit what was built through the GUI. That contrasts with opaque code from tools like v0 or Lovable, where a non-coder who cannot re-prompt successfully is stuck. He compares it to a developer who generates code in Cursor but can drop back into the IDE to finish it.

Liu tries as many AI products as he can, including ones unrelated to Airtable, such as Runway's world engine or Sesame's voice demo. He invents weekend side projects to force deeper use, for example making a comic video using ChatGPT deep research, an AI-written script and HeyGen avatars. Such projects take about an hour once you are proficient, and they teach him both the models and the product form factors that tool calling and agentic workflows make possible.

He argues that in the mature SaaS era you studied competitors like Salesforce for their yearly releases, whereas AI brings major releases every week. A write-up on TechCrunch or a tweet is not enough; you have to try the thing. He also admits he simply finds it fun, noting that five years ago none of this existed.

For his own team, Liu stresses play in the psychological sense: curiosity rather than box-checking. He leads by example, sharing a landing page built in Replit instead of a doc, or a deep research thread instead of a polished memo. He has told people they can cancel their meetings for a day or even a week to explore AI products, and say he told them to.

He also wants working prototypes instead of decks or PRDs, since claims like making Omni better at app building are just words until tried on realistic prompts. A functional prototype shows whether the product feels too slow or needs a progress bar. Execution, he says, shifts from deterministic headcount and eight-week timelines toward experimentation and iteration.

Asked which function has benefited most, Liu says it is about individual attitude and a bit of polymathy. Designers who understand how models and tool calling work can prototype concepts that are interactive rather than static, which matters because the real design of something like ChatGPT happens underneath, in how it responds to prompts. Engineers and designers who can prototype product ideas are gaining an advantage, and AI tools reduce the need to learn computer science first.

On whether any role is in trouble, Liu says you can get more done with fewer people, but he does not see Airtable's work as finite. As an app platform where customers build AI-powered apps, Airtable has what he calls an almost infinite set of capabilities to build, like massive watermelons lying on the ground. He thinks the culture is learnable for people with a growth mindset, and a PM now needs to look like a hybrid PM-prototyper with design sensibilities.

He notes that great multidisciplinary cultures are not new: early Google PMs had to be technical, his co-founder read books on visual design, and at Stripe the directly responsible individual is sometimes an engineer. Asked whether people only need one adjacent skill, Liu says they should be decently good at all three, with a deeper specialty on top.

To build that range, he advises studying the best existing products the way an industrial designer would study an Eames chair, then building your own repeatedly. He learned his own product sensibilities by trial and error and weekend projects, such as a Yelp-style app with synced map and list views. He also says these projects can be daytime work, and tells his field agents team to prototype ideas like deep research on every row of a table.

Liu notes that the heads of both OpenAI and Anthropic have converged on evals as a key skill, but he adds a nuance. For a completely new product experience, he says you should begin with vibes: open-ended, ad hoc testing of whether the idea works at all. Defining what good looks like before you know the shape of the product can constrain you too early.

His example is a long-running AI crawler agent that researches the web for a type of entity, such as every Marvel movie or every DC spin-off series, and compiles a list rather than a report. You first test a wide range of queries yourself and learn which kinds, such as people and companies with certain parameters, work well. Only then can you start measuring improvements programmatically.

By that point you may have scoped the product to specific entity types and explicit filter criteria. Evals then become a way to iterate toward improvement, and companies at the scale of OpenAI or Anthropic can A/B test everything. Early on you lack that luxury and are in open-ended discovery. Rachitsky compares this to the double diamond: diverge first, then converge.

Asked what Rachitsky's summary of the advice is missing, Liu adds breaking down role silos. In marketing, he says, the traditional split between a performance marketer tweaking ad parameters, a copywriter, and a product marketer producing positioning could collapse into people who can do much of the whole chain themselves. The ideal person is deep in one dimension yet well-rounded enough to be dangerous in the others.

The same applies to sales. Salespeople used to rely on sales engineers to be the product experts, but Liu says it is hard to sell any AI product without being fluent enough to demo it, so account executives must be SE-fluent. The goal is to be outcome-oriented and remove dependencies on marketing assets and SE help so you could close deals alone if needed.

Rachitsky likens this to the early startup days, when nobody has a head-of-product title and people just do what needs doing. He sees it as an upside-down T: a strong specialty with a rising baseline across adjacent roles. Liu agrees, calling it a new operating mentality for any company that wants to compete in the AI era.

Asked for his most counterintuitive lesson, Liu cites Brian Chesky's founder-mode ideas as resonating with his own experience. In the early days, technical, design and commercial decisions are intertwined and a small team thinks full-stack. As companies scale, conventional advice says to industrialize with executives managing separate swim lanes, which he says can be efficient for production but loses holistic thinking and the bigger, step-function bets.

He says the product is ultimately the thing, and the best innovation comes from a larger vision of how the product must leap rather than from small improvements spread over many surfaces. Refinding product-market fit regularly requires a different operating and leadership model, which is the same one AI demands. His meta-lesson is that everyone is like an LLM trained on a different corpus, so he now values the reasoning behind advice more than the recommendation itself.

On the link to the IC CEO trend, Liu cautions that taken to an extreme, being in the details becomes micromanagement, which is not what founder mode means. It means caring about details that matter and tying them together across departments so that people are not each optimizing locally. He says the times he felt most disconnected from the company were when he forced himself away from the details because he thought that is what an at-scale CEO should do.

His advice to a decade-ago self is not to step away from the details he loves. Scaling creates new management jobs and some of that is unavoidable, but he says to keep the product the number one priority. Liu adds that some of the best product-centered companies are run by people who simply love the product, citing Sam Altman and Chesky.

Liu closes with a call to action for people in product, engineering and design roles to bolster the skills where they are weakest. He believes anyone can reach a good-enough proficiency in software engineering, just as many people can write competently even if they will never be Hemingway. Bootcamps, coding exercises and nights-and-weekends projects all help, and he says the only thing stopping you is going out and doing it.

He uses ChatGPT as a tutor, asking how he would build something like Manus, and calls it an endlessly patient expert always available. Tools like Cursor let beginners generate code and study what it does. He contrasts this with building JavaScript single-page apps around 2008 to 2010, when there were few tutorials and even rounded corners meant slicing images in Photoshop.