Your “Moat” Is Fake.

People Are the Moat. Always have been - now especially.

The old game was: build software, tell a story about scale, get funded. Now software is abundant, copyable, and getting cheaper by the week, so if your moat is a feature list, you brought a butter knife to a gunfight and keep calling it “strategy.”

The new advantage is talkability + trust. Software products are turning into marketing channels. The product is the ad.

Read the full post on twitter if you can hold two ideas in your head at once. Otherwise, congrats on reading this far, stop here and go retweet something you didn’t understand.

Cursor AI

Anysphere, the company behind the famous AI coding startup, recently raised $2.3 billion in a Series D funding round. That’s $2.3 billion raised - not valuation.

Even if you imagine Cursor to become one of the biggest software companies, it is an astonishing number. Google, for context, raised approximately $1.67 billion during its initial public offering (IPO) in 2004.

But there is another side to that number.

Cursor’s 2.0 Update and Focus on Margins

With the Cursor 2.0 upgrade, the software removed the ability to add specific Git commits into the chat context and restricted other context options, such as including all open tabs.

These changes might look technical, but they matter. If you wanted a quick way to reduce the average number of tokens used per request, this would be it. The tradeoff, however, is a noticeable drop in the quality of generated code.

Cursor Team would say to this that they are focused on Agents and that 2.0 introduced a significant push on supporting the future in which multiple agents (developers) work simultaneously. That’s true. It is also true that multiple agents were also supported before. Whereas the removal of context features is not backward compatible.

So it would be foolish to ignore that a major tradeoff decision was made, and it is not clear it was in favor of existing developers.

The co-founder departure

Earlier in October one of Cursor’s co-founders left. At the time, the news was surprising. One might even recall the famous “What did Ilya see” and restate: what did Arvid (the departing co-founder) see?

In retrospect, it doesn’t take much imagination to connect the dots. His exit likely signals fundamental disagreements about the product’s direction. Cursor’s AI model costs have probably been eroding margins, and leadership seems to have chosen control over cost:

• focus on their own (cheaper & dumber) model over foundational providers

• smaller context windows for average requests

• less hardcore developer focus, and more focus on “vibe” coders

I don’t know what Arvid has said to his friends about his departure, but I imagine he has serious disagreements with at least one of the above pivots from the initial core product thesis.

Is that the right call? Hard to tell. Building software is a never-ending struggle between prioritizing future users over existing users and vice versa.

As for myself (an existing user), I’ve already rolled back to an older version and turned off auto-updates. The 2.0 changes feel less like innovation and more like survival tactics from a company trying to stay afloat in a market where margins are punishingly bad.

Historical Parallels

There’s a historical parallel worth noting:

When it launched, none of us reasonable people could have predicted how a company could afford to pay for all that bandwidth. And it turned out, it could not. But Google could. And it did so for many many years - until the Ad vs Bandwidth equation turned into its favor.

Can Cursor survive another 5+ years to turn its AI token margins in its favor?

Some VCs have made a $2.3 billion bet that it can and it will. How good that is for the company remains to be seen. Was this number the right number? Would it have been better for them to raise, say, $800 million? Dunno.

Valuations do have consequences: talent joins for cash (not equity); exit options narrow down…

These are 20-year-olds running now one of the most influential companies of the AI age. If you thought Mark Zuckerberg’s rise to fortune was quick compared to that of Steve Jobs’s era, the Cursor team is about to see the whole experience at 10x speed. And they are going to make many mistakes. This 2.0 upgrade and the dollar amount raised in hindsight might yet be viewed as their biggest mistake, but it could also be viewed as the boldest move ever. Time will tell.

Fivetran and DBT in Agentic future

I have written bits here and there about both Fivetran and dbt previously, so before putting this piece together, I pulled my prior opinions from GPT. And it gave me these:

1)

2)

3)

4)

But all that was written prior to the agentic revolution. Agents don’t behave like data analysts. They speculate: issue many overlapping queries, branch, retry, and steer based on partial results and feedback.

There is argument to be made that we need agent-first data systems to cope with scale, heterogeneity, redundancy, and steerability - characteristics distinct from classic BI/ETL. While the Fivetran-dbt era was optimized for dashboard creation and insights, the next era appears to be optimized for what comes after the dashboards: OUTCOMES.

The Fivetran-dbt era was optimized for dashboard creation and insights, but the next era appears to be optimized for what comes after the dashboards: outcomes.

So with all that, a short revisit is necessary.

ETL Consolidation

To recap, Fivetran has previously acquired Tobiko Data (the team behind SQLMesh and SQLGlot). Separately, dbt Labs acquired SDF Labs earlier this year. The widely reported Fivetran ↔ dbt Labs deal is in advanced talks but not publicly closed. If it does close, SDF would come along for the ride under the dbt umbrella, meaning one company would control the leading connector platform (Fivetran), the most adopted transformation framework (dbt), a next-gen typed SQL toolchain (SDF), and a stateful transformation engine (SQLMesh).

Potential implications for the ecosystem are:

• Consolidation of the “T” (and more): Connect (Fivetran) + Transform (dbt/SDF/SQLMesh) positions Fivetran as a de facto end-to-end data pipeline vendor. Great for procurement; dangerous for optionality if primitives don’t stay open. While Tobiko says SQLMesh/SQLGlot will remain open source, it remains to be seen how likely that is.

• Overlapping roadmaps: dbt’s compiler + SDF’s SQL comprehension + SQLMesh’s state management are partially redundant. Expect convergence pressure: one planner, one type system¹, one lineage substrate². The migration path (macro syntax, state stores³, test/eval semantics) will make or break trust.

• Community stewardship risk: dbt/SDF/SQLMesh each have opinionated communities. A single owner raises the bar for transparent governance, long-term OSS commitments, and fair plugin interfaces. This is where the current approach (open APIs, closed products) can backfire.

• Competitive posture vs. cloud platforms: A combined stack is a clearer counterweight to Snowflake/Databricks “one-stop” narratives. Expect heavier bundling, deeper optimizer integrations, and “AI-ready” marketing.

Agentic Future - Out Data Infra, In Outcomes…

The big question though is how much of the above legacy stack is relevant to the agentic future. In a world in which AI community cares much more about obtaining outcomes without the specialized skills of infra, orchestration, and data pipelines, there is demand for a new kind of stack.

The idea is that you should be able to state intent in business terms and the system builds a typed semantic plan⁴ (entities, metrics, governance policy) and proposes data paths across sources. It then auto-generates tests, sample sets, and a minimal “proof” run before scaling, and continuous domain capture (not one-off modeling).

With every prompt, domain knowledge is accumulated as first-class assets (concepts, constraints, SLAs, policies). And any changes to definitions are versioned along with their explanations.

In this new stack, data pipelines are self-healing. When schemas drift or upstream quality dips, the system proposes edits (with diffs, impact analysis), runs shadow plans, and performs rollback (or forward deployments) with approvals.

However, existing Data-AI tools appear to fall far short of this vision. Most remain as features rather than complete outcome-focused products. AI that is designed to pull specific data, often missing the larger context of why that data is needed.

The key here is that the above changes are not going to happen overnight. Warehouses and lakehouses won’t disappear overnight. In the near term, the pragmatic path is to augment existing infra with: (1) typed semantics and static analysis (SDF-like), (2) stateful, multi-engine transforms (SQLMesh-like), and (3) agent-aware orchestration layers that budget, cache, and checkpoint aggressively. Cloud vendors and platforms are already moving to support “agentic AI in production,” but the data layer still needs to catch up. Most likely:

• Near term: You will be able to deliver agentic outcomes by bolting on planner layers to your current warehouse + streaming + MCP + vector DB stack.

• Medium term: Expect agent-first data systems to emerge: query planners and storage built around speculative, branching workloads with native governance⁵.

Bottom line: expect to see an introduction of New (agentic) interfaces, sophisticated retrieval optimizers, new storage with caching⁶ abilities, and entirely new governance engines for sophisticated permission-handling.

Today, most of that is handled manually by specialized infra engineers. No AI can handle spec-driven development of the data infra. For instance, in the case of dbt, an analytics engineer captures this logic in some sort of semantic layer⁷ - part of the stack that resides somewhere between the ETL step and the end-user query. This gives a lot of flexibility, but also comes at a heavy cost: developing the model and maintaining the codebase is a lot of work. Nothing significant has changed since Benn Stencil’s original 2023 quote:

The demos run in small sandboxes that don’t resemble real data environments. The test questions are basic, unambiguous, and could be answered by an experienced analyst in a handful of lines of SQL. The distance between current AI start-ups focusing on Data and companies’ actual data ecosystems is staggering. dbt Labs’ CEO, Tristan Handy, said that a meaningful percentage of their customers are using dbt to create more than 5,000 tables. In that environment, there are no simple questions—answering “How many new European accounts did we add last week?” requires defining an account, what new means, where Europe is, when a week starts, in what time zone it should be calculated in, and if “add” means net or gross.

Taking into account all of the above, I could not shake the feeling that I no longer see the Fivetran <> dbt merger as something that can have a significant impact on the future. We might actually be at a pivotal moment in history that these tools risk becoming irrelevant. Even industry leaders like Snowflake acknowledge the shift – calling themselves an ‘AI data cloud’ – but, as Amplify notes, that’s often ‘bolting new marketing onto old architectures’. Fivetran/dbt merger could prove no different.

Opportunities for new AI-native dev tooling

If the dbt acquisition completes, Fivetran won’t just “own transformation.” It will own three overlapping philosophies of transformation:

• dbt: project-oriented modeling with human-maintained semantics,

• SDF: typed SQL comprehension and static analysis,

• SQLMesh: stateful planning and multi-engine recomputation

That could be fantastic if it’s unified into an AI-native dev surface that starts from intent and ends with governed outcomes. Or it could calcify the last era: three compilers, two planners, and one vendor bundle.

More importantly, this by itself does not guarantee that Fivetran is moving away from infrastructure processes toward delivering outcomes.

In an outcomes-first world, standalone connectors and “T” engines become liabilities: more surface area to integrate, govern, secure, and maintain, without guaranteeing the result the business actually needs. Together, Fivetran + dbt can move teams closer, but real gaps remain, and it’s not obvious that the two can be seamlessly unified in practice.

There is a very real opportunity now to rebuild this stack the AI-native way: let AI maintain the codebase, continuously capture domain context, and orchestrate from intent to answer. Five or ten years ago that sounded unrealistic. Today, it’s within reach.

But even more importantly, it is highly unclear what is the future of traditional data engineers? That’s a post for another time. For now, a picture will do (via x.com/@klabsintexas):

(credit x.com/@klabsintexas)

That’s the bet behind KLabs’ new AI-native DevTool designed to collapse the distance between a question and a reliable result, while the system handles semantics, pipelines, and governance in the background. The bet is clear: outcomes as the product, with AI maintaining the code and the system absorbing complexity: typed semantics, stateful planning, evals, governance, and agent-aware orchestration. Domain experts focus on what needs to happen, not how to wire it together.

So my “take” on the acquisition is simple: it’s a milestone of the last era. The next era belongs to platforms that make outcomes the product, not the by-product…

1. Components that parse/plan SQL and enforce data types

2. System tracking how data flows/transforms across models

3. Storage for job/run state to enable reliable incremental transforms

4. a unified interface where the AI translates high-level business requests into data workflows

5. Planners that can fork and explore multiple paths

6. Data layers designed to reuse results and reduce recomputation

7. Shared business definitions (metrics/entities) between data and queries

Wiz - the end AND the start of an Era

Wiz today has 2,000+ employees. That number is striking considering it had just 40 employees 5 years ago:

The second largest acquisition by Google Cloud before Wiz was Looker. At Looker, I was the 30-something employee, and when I try to visualize the progression from having a CEO lending his car to help move employees across town (true story), to having that same CEO manage an army of thousands 95% of whom he/she does not know, I ask myself if there really is such a difference between Product companies that VCs like to fund and the Services business model.

A 2,000-employee organization after 5 years sure does seem a lot more like a services organization than a product company. For context, Dropbox, which has 3x the ARR revenue, has just 1.5x the # of employees - and that’s an 18-year-old company.

But Wiz is not the only one. Look around, and almost every Series C+ enterprise company looks similar. Every VP / Director is an ex-hyperscaler employee, whose sole job is to come into the new start-up and hire like a machine. At Looker, my teammates and I had a name for our 50-year old VP: The Robot. He did not manage us, he did not lead us - 90% of the interaction was centered around interview schedules and occasional reorgs.

And yet, it is quite possible that this is not what companies are going to look like in the future:

Wiz - the end of an era

Just like Wiz 5 years ago, another company currently with ~40 employees is Anysphere (Cursor.ai). Cursor is three years into its journey with 40 employees, and it is now making $150K in ARR, almost 1/4 of Wiz revenue with 60x fewer employees.

Like Wiz, Cursor.ai started with a team of 4 founders. 4 founders with an average age almost 1/2 of that of the Wiz founders. Age is not the only difference. GTM playbooks are quite different, too. And yet, one can imagine that at their ultimate successful adoption, both product companies look roughly similar: strongly embedded inside enterprise organizations through both technology and relationships (i.e. account management + customer success + professional services).

The striking difference in ARR/employee perhaps highlights not only the background of founders, but also the eras:

Old Era: Experienced Execs leading armies of ICs

New Era: Flat orgs with significant mid-level contributors

The idea is that while relationships will continue to matter, one person can and will be able to handle more.

Shifting tides of ARR/employee - What’s old is new again.

Flashback to 11 years ago: I got hired at Looker as a Data Scientist. Surprise—they didn’t need one. What they needed was someone to solve customer problems. So, I became the first person in Looker’s Professional Services.

For the next two years, I wrestled with two competing internal visions for scaling the team:

Option 1: Scale wide

- Hire more, but increasingly less competent specialists, each handling fewer customers.

Option 2: Scale deep

- Focus on expertise, solve scale problems with smart internal and customer-facing tools.

Leading by example, I was Team 2. While others juggled 1-2 customers, I had 16 concurrent customers, and over two years, 50+ companies such as AbleTo, Carta, Credit Sesame, DigitalOcean, Peloton Cycle, Procore, Plaid, Strava, Wise

👉 Continued on X…