Breaking
nao Labs joins Y Combinator's X25 batch  ///  “Cursor for data” connects the AI editor straight to your warehouse  ///  Data diffs catch breaking changes before you merge  ///  Native connectors: BigQuery, Snowflake, Postgres  ///  Founders Claire Gouze & Christophe Blefari  ///  Open-source analytics agent builder ships  ///  nao Labs joins Y Combinator's X25 batch  ///  “Cursor for data” connects the AI editor straight to your warehouse  ///  Data diffs catch breaking changes before you merge  ///  Native connectors: BigQuery, Snowflake, Postgres  ///  Founders Claire Gouze & Christophe Blefari  ///  Open-source analytics agent builder ships  /// 
Company Profile Data & AI Tooling

nao Labs and the case for an editor that actually knows your data

Two data veterans forked VS Code, wired it into the warehouse, and taught the AI to read your schema. Their bet: data teams shouldn't have to break a dashboard to learn they made a mistake.

The scariest four words in a data team's chat channel are not “the server is down.” They are “the dashboard is wrong.” By the time anyone types that sentence, the bad number has already been screenshotted into a board deck, quoted in a standup, and used to make at least one decision. The join that broke it was probably one line long. That gap - between a small change and its downstream blast radius - is the problem nao Labs decided to build a company around.

nao (styled lowercase, from the parent company nao Labs) is an AI code editor built specifically for people who work with data. It is a local application - a fork of Visual Studio Code - that connects directly to your data warehouse and runs an AI copilot that has been handed the one thing generic coding assistants never get: the actual context of your data. Your schema. Your tables. Your lineage. The company's public shorthand for all of this is three words that a data engineer understands instantly: Cursor for data.

2024
Founded
YC X25
Y Combinator Batch
7+
Warehouses Supported

01 / THE PROBLEMData teams got left out of the party

Over the last two years, software engineers were handed a series of increasingly capable AI copilots. They started autocompleting functions, then whole files, then reasoning across a codebase. Data teams watched this happen and got, roughly, a chatbot bolted onto a query box. The founders of nao put it plainly in their own pitch: data teams have been left out of the vibe-coding party.

The reason is not that data people are slower. It is that changing data safely is genuinely harder than changing application code. A SQL model feeds a dbt model, which feeds a metric, which feeds three dashboards and a finance report. Editing one column can quietly corrupt something two hops downstream, and nothing crashes to tell you. So data teams compensate the only way they can: with more tools and more tests. Write the query in one tab. Test it in another. Check lineage in a third. Cross your fingers on the BI layer.

Count the context switches in a single data change and the cost becomes obvious. You are toggling between an editor, a warehouse console, a dbt project, a lineage graph and a BI tool, and each hop is a chance to lose the thread of what you were actually trying to do. The work is not intellectually hard so much as it is fragmented, and fragmentation is where mistakes hide. nao's argument is that the fragmentation itself is the bug - and that no amount of individual-tool polish fixes a workflow that lives in six places at once.

“Data teams can't keep the business pace because making changes in data requires too many tools and tests.”nao Labs, on why they started the company

02 / THE PRODUCTAn editor that reads the warehouse

Because nao is a fork of VS Code, it feels familiar the second you open it - same keybindings, same extensions muscle memory, same dark editor most data engineers already live in. What is different sits underneath. nao ships with native connectors for warehouses like BigQuery, Snowflake and Postgres, so the editor is not guessing at your data through a generic model; it is reading the real schema. When you write SQL, Python or dbt, the copilot already knows what a table contains and how it connects to everything else.

STEP 01
Connect
Wire nao directly to BigQuery, Snowflake or Postgres.
STEP 02
Build
Write SQL, Python or dbt with a copilot that knows your schema.
STEP 03
Diff
Compare dev data against production before anything merges.
STEP 04
Ship
Merge knowing lineage and BI aren't quietly broken.
Fig 1 - The nao loop: the whole point is that step 03 happens before, not after, the mistake reaches a dashboard.

The most telling feature is the data diff. Instead of running your change and hoping, nao's agent compares development data against production and runs predefined tests, surfacing exactly what a change would alter and whether it breaks lineage or the BI figures downstream. It turns the panicked, after-the-fact question - “wait, did I just break the pipeline?” - into an answer you get before you click merge. That reordering is small to describe and large to live with.

There is a psychological dividend here that is easy to underrate. When the cost of a mistake is a broken dashboard discovered days later by an executive, people slow down out of self-defense. Every change gets a second reviewer, a manual spot-check, a nervous pause. When the cost of a mistake is a diff you can read in the editor before merging, the fear budget shrinks. That is really what “shipping at business pace” means in nao's telling - not typing faster, but being able to trust your own changes enough to move.

The copilot's schema awareness compounds this. Because nao reads the real warehouse rather than a generic snapshot, its suggestions are grounded in tables that exist, columns that are spelled the way your team spells them, and relationships that actually hold. A general assistant will happily hallucinate a plausible-looking join on a field that was renamed six months ago. An assistant that has been handed the live schema has far less room to invent, and in data work the difference between plausible and correct is the whole game.

What you can actually do with it

Build and document data models, write and test dbt pipelines, catch breaking changes with dev-vs-prod diffs, and let non-technical teammates ask questions of the warehouse in plain English through Slack, Teams, WhatsApp or Telegram - without ever writing SQL themselves.

03 / THE DEEPER BETReliability is a context problem

nao's second act is an open-source analytics agent builder, and it carries the company's real thesis on its sleeve: “Agent reliability depends on context. Engineer it.” Rather than betting that a bigger model will magically answer data questions correctly, nao lets teams build a structured, testable body of context - almost like a file system describing what the data means - and even run unit tests to measure how well that context performs. It is an unglamorous idea. It is also the difference between an agent that demos well and one that survives Monday morning.

Fig 2 - Where nao plugs into the stack
Warehouses
7+
Modeling / BI
dbt+
Orchestration
Airflow
Chat channels
5+
LLM providers
BYOK
Fig 2 - nao connects to the modern data stack teams already run, from warehouses and dbt to Airflow, and deploys agents across chat surfaces via MCP.

The open-source choice is strategic, not decorative. Data is the most sensitive thing most companies own, and asking an enterprise to pipe it through a closed AI black box is a hard sell. By open-sourcing the framework and letting teams self-host with their own LLM keys - Claude, Gemini, GPT, Mistral, a local Ollama model - nao lets the warehouse stay inside the company's walls. Trust becomes the unlock, and open source is how you earn it.

The agent builder also quietly widens who nao is for. The editor is a tool for the people who write SQL; the analytics agent is a tool for the people who never will. A structured context layer lets a non-technical teammate ask a question in plain English on Slack, Teams, WhatsApp or Telegram and get an answer that is right because the agent was engineered with real meaning, not just handed a raw schema and told to guess. “Democratize data access” has been a slide in every deck since 2015; nao's version is more specific, and the specificity is the point - the answer has to be trustworthy, or self-service analytics just manufactures confident wrong numbers at scale.

04 / THE FOUNDERSTwo people who felt this personally

nao Labs was founded in 2024 by Claire Gouze and Christophe Blefari, and the product reads like something built by people who lived the pain. Gouze, the CEO, is a self-taught data scientist who started at BCG Gamma and went on to run data at Sunday, a startup that raised a $100M Series A - exactly the kind of high-velocity environment where a broken metric costs real money. Blefari, the CTO, spent more than a decade building data platforms for over ten companies and is a widely followed writer in the data community, which gave a two-person startup something rare on day one: an audience that already trusted its taste.

That combination matters more than it looks. One founder has repeatedly stood in the shoes of the customer, feeling the specific dread of a wrong number at pace; the other has built the plumbing underneath many teams and knows exactly where the pipes leak. Started in Paris and now plugged into Y Combinator's San Francisco orbit, nao carries a European data-community pedigree into an American startup engine. For a category defined by trust, having builders the community already knows is not a marketing detail - it is a head start.

“Data teams have been left out of the vibe coding party. We're building nao so they can data vibe too.”The nao Labs founding thesis

05 / THE MARKETFamiliar analogy, different terrain

Calling yourself “Cursor for data” is a clean way to be understood and a risky way to be measured - it invites the obvious question of why a general AI editor like Cursor or GitHub Copilot can't just do the job. nao's answer is the terrain. General copilots are strong at code and blind to your warehouse; they don't know your schema, can't diff dev against prod, and have no concept of the lineage that makes data changes dangerous. Meanwhile, the data-native tools that do understand lineage and diffs mostly live outside the editor. nao's wager is that combining the editor, the warehouse connection, the schema context and the diff-testing into one local tool is a category, not a feature.

On business model, nao is freemium and open source: self-host, bring your own model key, pay for the tokens you burn, upgrade for managed features. It is early - a small team, a recent YC batch, and the kind of funding numbers that get revised as the company grows - so the honest framing is a bet in motion rather than a finished story. But the bet is aimed at a real and specific ache. Every data engineer has felt the dashboard-is-wrong dread. nao Labs is building for the moment just before it.

Where to find nao Labs

#ai#data-engineering#cursor-for-data#sql#dbt#analytics-agent#developer-tools#yc-x25#open-source#data-warehouse