Home
Mar 23, 2026
View All

AI Distribution, Specs as Code, and Cursor's Kimi-k2.5 Reveal

·1 underrepresented voice

The Short Version#

Andrew Chen drops the sharpest product strategy provocation of the week — AI still hasn't produced its own distribution channels, and paid acquisition is a dead end for most AI products — while Gabriella Gonzalez (via Haskell for All) makes the case that a sufficiently detailed spec is code, which reframes what "non-technical specification" even means in an agentic world. Simon Willison surfaces that Cursor's Composer 2 is secretly running on Kimi-k2.5, not a first-party model — a meaningful signal about how competitive AI coding tool pricing actually works.

Andrew Chen — AI Still Doesn't Have Its Own Distribution Channels#

Source: https://x.com/andrewchen/status/2035499669841957162 Credibility: High (Andrew Chen is a GP at a16z and a tracked thinker on product growth; this is a direct original thread, March 21, 2026)

What happened: Andrew Chen posted a thread arguing that AI products haven't produced their own native distribution channels the way prior platform shifts did. The argument: Web 1.0 gave products email, search, and link sharing. Web 2.0 gave them feeds, creators, and viral invites. Mobile gave them app stores, SMS invites, and vertical video. AI, so far, has given products... not much that's actually new. The thread notes that lots of AI companies are now defaulting to paid marketing — and Chen's take is direct: "Paid acquisition is a tax on your product's defensibility. The moment you can't out-spend the incumbents and competitors, you die."

Key patterns from the thread:

  • Every major platform shift historically created new organic distribution channels — not just new products
  • AI has accelerated product development but hasn't yet created a new class of channels for reaching users
  • The companies leaning into paid acquisition are signaling that they don't have a defensible distribution advantage
  • Chen frames this as an open question worth watching, not a closed verdict — "we're seeing some big growth experiments"
  • Implication: the AI companies that win long-term will be the ones that discover or invent the AI-native distribution channel, not the ones that buy their way to growth

Why it matters for PMs: This is the right growth strategy question to be asking right now. If you're a PM at an AI product and your acquisition plan is "performance marketing + PLG," you're playing on the same field as every other AI product. The platforms that won prior cycles — Google Search, the App Store, TikTok's algorithm — gave early products asymmetric distribution. Until AI produces an equivalent, the growth economics for AI products are brutally competitive and expensive. Chen's framing gives you a useful audit lens: is your product's growth strategy dependent on channels that existed before AI, or are you building something that could become a channel? For PMs at fintech or productivity products embedding AI, the answer is almost certainly the former — and that should inform how aggressively you invest in paid versus how much you prioritize embedding into existing workflows where distribution already exists.

Critical questions:

  • Is this argument premature? Voice assistants, AI-generated content on social feeds, and embedded copilots in productivity suites might be nascent AI-native distribution channels that haven't fully matured yet
  • Does the "no new channels" observation apply equally to B2B and B2C AI products, or is it more acute for consumer?
  • What would a genuinely AI-native distribution channel look like — agents recommending products to each other? Model-to-model discovery? And what would it take to build one intentionally?
  • Is Chen's framing backwards: maybe the AI-native channel is the product category itself (e.g., LLM fine-tuning on brand voice, AI-generated personalized onboarding) rather than a new external channel?

Action you could take today: Audit your product's top three acquisition channels. For each one, ask: did this channel exist before AI? If yes, what's your plan for differentiated distribution when your competitors use the same channel? That audit will tell you whether you're building for defensibility or for short-term growth.

Gabriella Gonzalez — A Sufficiently Detailed Spec Is Code#

Source: https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code Credibility: High (Gabriella Gonzalez is a tracked engineer and writer known for rigorous technical thinking; this is a first-party blog post, March 2026)

What happened: Gabriella Gonzalez published a post arguing that the promise of "just write a spec and the AI will implement it" runs into a fundamental problem: a specification detailed enough to unambiguously describe what you want is, functionally, code. The more precise your spec, the more it resembles a program. This isn't just a philosophical point — it directly undermines one of the core premises of agentic coding tools, which is that non-technical users can describe their intent in plain language and get working software back.

Key argument from the post:

  • The gap between a natural language spec and a working program is filled by ambiguity resolution — and that's exactly what programming is
  • A spec that eliminates ambiguity by being fully precise has essentially become code in a different syntax
  • This creates a trap for agentic coding tools: if you offload ambiguity resolution to the AI, you get inconsistent behavior; if you eliminate ambiguity with a detailed spec, you've done most of the cognitive work yourself
  • The implication is that agentic coding tools shift where the hard thinking happens (from implementation to specification), not how much hard thinking is required
  • "Vibe coding" doesn't eliminate the precision requirement — it relocates it

Why it matters for PMs: This is the clearest theoretical framing I've seen for why agentic coding tools don't actually democratize software development as much as advertised. If you're a PM betting on "non-technical stakeholders will use AI to build their own tools," Gonzalez's argument is a useful check: the users who succeed at that will be the ones who were already good at thinking precisely about what they want — which skews toward people who think like developers, even if they can't write code. For products like Lovable, Replit, or Google AI Studio's Antigravity agent, this frames the core design challenge: how do you help users achieve enough precision in their specs without requiring them to think like programmers? That's a UX and product problem, not just a model capability problem. It also has implications for PM craft: as we use AI to write specs, PRDs, and requirements documents, the standard for "good enough" specification is rising — because now the spec is directly executed, not interpreted by an engineer who fills in the gaps.

Critical questions:

  • Does this argument hold uniformly across task types, or are there domains where natural language specs are genuinely sufficient (e.g., simple CRUD apps, single-screen utilities)?
  • If the spec-is-code argument is correct, what's the right product metaphor — is agentic coding closer to a "compiler for intent" than a "programmer replacement"?
  • How does this reframe the value proposition for tools like Cursor or Windsurf, which target developers who already think precisely? The spec-is-code problem might be less acute for that audience
  • What's the PM-specific implication for PRD writing — if a PRD becomes detailed enough to be executed by an AI, does that change the PM's relationship to engineering?

Action you could take today: Take your most recent PRD or feature spec and ask: if an AI agent tried to implement this directly, what would it get wrong? Each wrong answer is an ambiguity your spec contains. Count those ambiguities — that number is your "spec completeness score," and it's a proxy for how much interpretation work you're currently offloading to your engineering team (and soon, to AI agents).

Simon Willison — Cursor's Composer 2 Is Running on Kimi-k2.5#

Source: https://simonwillison.net/2026/Mar/20/cursor-on-kimi/ Credibility: High (Simon Willison is a tracked practitioner and developer; this is a link/quote post on his blog citing a Kimi.ai statement, March 20, 2026)

What happened: Simon Willison surfaced a quote from Kimi.ai confirming that Cursor's Composer 2 — launched March 19 with per-token pricing and described as "frontier-level coding performance" — is built on Kimi-k2.5, Kimi's coding-specialized model. Cursor did not disclose this in its changelog entry. Willison flagged it as notable: Composer 2 is not running on a first-party model or one of the obvious frontier providers (OpenAI, Anthropic, Google). It's running on a Chinese AI lab's coding model.

Key details:

  • Cursor's Composer 2 pricing post (March 19) said "frontier-level coding performance" without naming the underlying model
  • Kimi.ai (Moonshot AI, a Beijing-based lab) confirmed in their own communications that Kimi-k2.5 powers Composer 2
  • Willison's framing: this is "a really big deal" — both as a signal about the competitive coding model landscape and as a disclosure issue
  • Kimi-k2.5 is a coding-specialized model; its use in Cursor suggests it outperformed or cost-competed with alternatives from the major US labs on the specific benchmark Cursor cares about (coding task performance)
  • This is the second signal this week (after Anthropic's Claude Code vs. Cursor comparison from Shreya Shankar) suggesting the underlying model choice in coding tools is actively contested and not locked in to the obvious providers

Why it matters for PMs: Two things here. First: the build-vs-buy calculus for AI coding tools is more fragmented than it looks from the outside. Cursor — the market-leading AI editor — is running its flagship new capability on a model most PMs have never heard of. That means the "which model is best for coding" question is genuinely open, and the answer is changing faster than the public coverage suggests. Second: the non-disclosure is a product trust question. If you're paying per-token for "frontier-level coding performance" and you don't know what model you're paying for, you can't compare it against alternatives or evaluate the risk profile (data handling, geopolitical considerations for enterprise customers, etc.). For PMs managing AI tool budgets or vendor relationships, "what model is this running on" is now a legitimate procurement question, not a technical curiosity.

Critical questions:

  • Why didn't Cursor disclose Kimi-k2.5 in the Composer 2 changelog? Is this a competitive positioning decision (don't highlight a lesser-known Chinese lab), a contractual constraint, or an oversight?
  • For enterprise customers using Cursor with sensitive codebases, does Kimi-k2.5's data handling and provenance meet their compliance requirements?
  • Does Cursor's model-agnostic architecture mean Composer 2's underlying model could change without notice — and if so, what's the customer's recourse?
  • Is Kimi-k2.5 genuinely competitive with Claude Sonnet or GPT-4o on complex coding tasks, or is this a cost-optimization play that trades quality for margin?

Action you could take today: If your team uses Cursor and has data handling or compliance requirements (especially for fintech, healthcare, or enterprise software), send a question to your Cursor account rep or legal team: what is the data processing agreement for Composer 2, and what model does it run on? The answer will tell you whether Kimi-k2.5's provenance is a risk factor for your context.

Quick Hits#

  • Cursor — Composer 2 with Per-Token Pricing (March 19, 2026): Cursor ships Composer 2 with per-token pricing and "frontier-level coding performance" — revealed to be running on Kimi-k2.5 without public disclosure, signaling that the competitive coding model landscape is more fragmented than advertised: https://cursor.com/changelog/composer-2

  • Notion — Custom Agents (March 20, 2026): Notion launches Custom Agents, enabling users to create AI agents with custom knowledge bases and specialized behaviors; includes security architecture post on agent capabilities and constraints: https://www.notion.com/blog/introducing-custom-agents

  • Dan Shipper — Introducing Proof (March 19, 2026): Every announces Proof, a platform for collaborative long-form thinking and research, with practical learnings on scaling from "vibe code" to production-grade infrastructure: https://every.to/on-every/introducing-proof

  • Vercel — Activity Log now available in Vercel CLI (March 23, 2026): Teams can now query all team activity events (user, event type, timestamp) directly from the CLI with filtering. Small but meaningful governance addition for teams using Vercel in production: https://vercel.com/changelog/activity-log-now-available-in-vercel-cli

  • Mistral AI — Leanstral: Open-Source Code Agent for Lean 4 (March 16, 2026): Mistral releases Leanstral, the first open-source code agent for Lean 4 (a formal verification language), positioning verified, provably-correct code generation as a differentiation angle: https://mistral.ai/news/leanstral

The Thread#

The model layer is becoming invisible — and that's both a feature and a risk. This week surfaced three separate signals pointing at the same tension: Cursor ships Composer 2 on Kimi-k2.5 without disclosing the model; Shreya Shankar finds that the interface model matters as much as the underlying model; Andrew Chen notes that AI products still lack native distribution channels of their own. The common thread: the commodity pressure on foundation models is happening faster than the transparency infrastructure to support it. For PMs, "what model are we running on" is no longer a technical question — it's a product, compliance, and trust question. Teams that treat it as the former will get caught flat-footed by the latter.

Sit With This#

Gabriella Gonzalez's argument: a spec detailed enough to eliminate ambiguity is functionally code. Which means agentic AI doesn't reduce the precision requirement — it just moves it earlier in the process, from implementation to specification.

For your product's PRD process: The next time your team writes a requirements document that an AI will interpret (for agent workflows, AI feature specs, or anything a coding agent will implement directly), ask: where are the ambiguities we're leaving for the AI to resolve? And are we comfortable with how the AI is likely to resolve them? That question is the new "will engineering build what we meant?"

Sit With This is a daily reflection prompt. Take 5 minutes. One concrete answer beats three abstract ones.