Airtable Cobuilder AI: What It Can (and Can't) Do

Airtable Cobuilder is the most genuinely useful AI feature Airtable has shipped. Type a description of what you want, watch a base appear, click around, refine. For solo founders and small teams, it gets you from blank canvas to working draft in under a minute. For consultants, it's a kickoff accelerator. For everyone, it's worth understanding what it does and where it stops.

This review is based on using Cobuilder on real client work since it launched. I'll cover what it generates well, where it falls short, how it compares to building from scratch, and the workflow we use to get value from it without ending up with a base we have to rebuild later.

What Cobuilder Is

Cobuilder is a prompt-driven base generator. You type something like "I need a CRM for a small consulting firm" or "Build me a content production tracker for a marketing agency with 8 people." Cobuilder takes the description and produces:

• A complete set of tables with field types and primary fields chosen
• Linked record relationships between tables
• A starter interface — usually a dashboard or a record-detail layout
• Sometimes, basic native automations if your prompt asks for them
• Sample data in each table so the result feels real

The whole generation takes 20-60 seconds. The result opens in your workspace as a new base you can immediately start working in.

Under the hood, Cobuilder uses large language models trained or prompted on Airtable's schema patterns. It has clearly seen a lot of bases and knows what a "CRM" or "project tracker" typically contains. That training shows in the output — generic workflows produce solid schemas, niche ones produce stranger ones.

What It Does Well

Five things Cobuilder consistently gets right.

1. Table identification. For common workflows, it picks the right set of tables. A CRM gets Clients, Contacts, Deals, and Activities. A project tracker gets Projects, Tasks, Team Members, and Time Entries. The level of decomposition is reasonable — not too granular, not collapsed into one mega-table.

2. Field types. Number fields stay numbers, dates stay dates, currency formats are picked correctly more often than not. The percentage-of-rework on field types is much lower than it would be if you imported a CSV.

3. Linked records on common relationships. Standard one-to-many relationships (Client → Projects, Project → Tasks) get linked correctly. The reverse fields appear on the right tables.

4. Reasonable primary fields. Cobuilder picks primary fields that actually identify records — Client Name, Project Name, Deal Title — not row numbers or unhelpful concatenations.

5. Starter interface. The auto-generated interface page is rarely the one you want long-term, but it's good enough to demo the base immediately to a stakeholder. Compared to staring at a raw grid view in a meeting, it's a meaningful win.

Where It Falls Short

The honest list of limitations after using it on a few dozen real projects.

1. Niche workflows produce weak schemas. Ask for a CRM and you'll get a CRM. Ask for "a system for a non-medical home care agency to track caregiver shifts, client care plans, and billing to multiple state Medicaid programs" and the output will be much rougher. The further your workflow is from common business patterns, the more rework you'll need.

2. Linked record direction is sometimes wrong. Cobuilder occasionally puts the linked field on the wrong side of a relationship or creates two separate linked fields where one bidirectional link would do. You have to look at the schema diagram and check direction before you trust it.

3. No data migration. Cobuilder generates a base and sample data, but it can't take your existing spreadsheet and restructure it into the new schema. That's still on you. For real migration, see our migration guide.

4. Limited automation generation. Cobuilder can create simple automations like "send an email when status changes to Approved." It can't build multi-step flows with conditions, scripts, or external API calls. Anything beyond a single trigger and a single action you'll still build yourself.

5. No integrations. Cobuilder doesn't connect your new base to Stripe, Xero, Gmail, or anything else. Those integrations still get built in Airtable's automations or in Make / Zapier.

6. Junction tables are inconsistent. For many-to-many relationships that need to store metadata about the relationship itself, Cobuilder often skips the junction table and just creates a direct link. You'll add it manually after.

7. Hard to replicate an existing base. If you have a base you love and want a second one like it, Cobuilder isn't the tool — it generates from a prompt, not from an example. Use template duplication instead.

How to Use Cobuilder for Real Work

After enough Cobuilder runs, a consistent workflow has emerged. We use it as a first-draft tool, not a finished-product tool.

Step 1: Write a detailed prompt

The quality of the output tracks the quality of the prompt. A one-line prompt produces a generic schema. A paragraph that includes specifics produces a much better one.

Good prompt structure:

Build me a base for [type of business] that does [main activity]. The team uses it for [primary use case]. Key data we track includes [list of entities]. The most important workflow is [describe one workflow end-to-end]. Users include [roles].

Example:

Build me a base for a small commercial photography studio that produces product packshots for ecommerce clients. The team uses it to track shoots, deliver photos, and bill clients. Key data: Clients, Projects, Shoots (each project can have multiple shoots), Photos delivered, Invoices. The most important workflow is taking a project from new inquiry through scheduling, shooting, delivery, and final invoice. Users include the studio manager, photographers, and retouchers.

This prompt produces a meaningfully better base than "build me a photography studio CRM."

Step 2: Review the schema before doing anything else

Open the Schema view (in Airtable, top-right in the data section). Look at:

• Are all the tables you expected here?
• Are the linked record relationships pointing the right way?
• Are the primary fields meaningful?
• Are there any tables you don't need? Any missing?
• Are there fields that should be linked records but were generated as text?

Edit the schema before adding data, interfaces, or automations. Schema changes get harder once anything depends on the structure.

Step 3: Refine in iterations

Cobuilder supports follow-up edits — you can ask it to add a table, add fields, or adjust the structure. The interactions feel like a conversation rather than a one-shot generation. Use that.

Typical follow-ups we make:

• "Add a junction table called Project Team Members that links Projects to Team Members and includes a Role field"
• "On the Invoices table, add a rollup that sums Amount from linked Line Items"
• "Add an automation that sends a Slack message to #studio when a Project status changes to Ready for Delivery"

Step 4: Build the interface manually

The auto-generated interface is rarely the right one for production use. Once your schema stabilizes, build a real Interface Designer layout that matches the actual workflow — usually a different layout per role.

Step 5: Add the real automations and integrations

Cobuilder doesn't build the Make scenarios, the Zapier zaps, or the scripts you need for cross-system workflows. Those still take real work.

When Cobuilder Saves Time vs When It Doesn't

Cobuilder is a big time-saver when:

• You're prototyping or kicking off a new project and need something concrete to react to
• The workflow is a common business pattern that's well-represented in Cobuilder's training
• You can articulate the requirements in detail before generating
• You have time to refine the output rather than ship it as-is

Cobuilder is less helpful when:

• You're rebuilding or extending an existing base — generating a new schema from scratch creates more work, not less
• The workflow is highly domain-specific (healthcare, legal, industrial)
• You need a particular set of integrations to work — Cobuilder doesn't touch those
• The migration of existing data is the main effort — the new schema is the easy part

How We Use It on Client Projects

A typical Cobuilder-augmented project looks like this:

1. Pre-kickoff. I generate a Cobuilder base based on the client's intake form. The base sits in a sandbox workspace, ready for the meeting.
2. Kickoff meeting. I share screen and walk the client through the Cobuilder base. "Here's what an AI thinks your CRM looks like. What's right? What's wrong?" The conversation is faster than starting from a whiteboard because we have something concrete to argue with.
3. First-week build. I take the elements that work, rebuild the schema in the client's real workspace, and refine based on the conversation. By end of week one, we have a working base — about 30-50% inherited from Cobuilder, the rest rebuilt or added.
4. Production phase. Cobuilder is no longer in the loop. Interfaces, automations, integrations, data migration — all handled in the standard way.

The value isn't that Cobuilder built the system. The value is that it shortened the discovery phase by giving us a concrete artifact to react to from day one.

Cobuilder vs Building from Scratch

Cobuilder isn't replacing the consultant. It's becoming the new starting point.

Where Cobuilder Is Heading

Airtable has signaled that Cobuilder will continue to add capabilities. Already in 2026:

• PDF and document data extraction through Airtable AI — you upload a document, Airtable extracts structured data into fields
• Public web content pulling — research data into your base from public pages
• Improved logic and automation generation — more complex flows generated from prompts

The trajectory is clear: Cobuilder will keep absorbing more of the "starting setup" work. The question for consultants is what the equilibrium looks like. My current bet is that schema generation continues to be commoditized, and the value moves further into requirements gathering, integration design, and ongoing optimization — the parts that depend on talking to people, not on typing field names.

Where to Go Next

If you've never used Cobuilder, the lowest-risk way to start is to generate a base for something you already know well. Compare its output to your mental model. You'll quickly see where it gets things right and where it drifts. Pair Cobuilder output with our linked records guide to catch schema issues early, and use Interface Designer to build the real front-end after.

For the official Cobuilder announcement and feature list, see Airtable's Cobuilder launch post.