Bessemer’s recent Developer Laws in the AI Era is a strong and timely contribution to the ongoing conversation about how AI is reshaping developer ecosystems and platforms. It’s the kind of framework that helps us step back from the hype and think more structurally about what will matter in the years ahead.
As I read through their proposed “laws,” I found myself both nodding in agreement and scribbling notes about what felt missing. Rather than treat their framing as definitive, I see it as a valuable foundation to build upon. My reflections fall into two buckets: the strengths of their argument that I strongly concur with, and the areas where I see something missing or where the conversation could be broadened.
At the heart of it all is one conviction: the quality of developer ecosystems—not just the tools—will determine who thrives in the AI era.
Where Bessemer’s Laws Resonate
Agent Experience meets Developer Experience
The idea that AI agents are now as much a “user” of platforms as human developers is spot on. Building for both human experience (DX) and agent experience (AX) is not a trivial adjustment. It requires rethinking interfaces, APIs, and documentation so they serve two very different but equally important audiences.
Documentation as infrastructure
I share their view that documentation has graduated from being a developer aid to being core infrastructure. It’s no longer just about human readability—documentation is becoming the connective tissue that allows LLMs and agents to understand, navigate, and integrate.
Bessemer introduces the concept of Generative Engine Optimization (GEO)—essentially SEO for the AI era. The premise is that just as companies once optimized content for Google’s search algorithms, they now need to optimize documentation so that LLMs can quickly parse and surface accurate answers. This means structuring technical docs, API references, and code examples in ways that keep developers in flow rather than forcing them to context-switch between tools. GEO encompasses everything from clean markdown formatting to consolidated expert-level information in accessible locations, ensuring that AI agents can find and utilize documentation as effectively as human developers.
This is a fascinating angle that I believe will evolve into a discipline in its own right, though, as I’ll share later, the cultural and organizational challenges of maintaining high-quality documentation may prove harder to solve than the technical aspects of making it LLM-friendly.
Pricing dynamics
They are right to call out the economic shift AI forces on platform pricing. Inference isn’t free, and per-seat SaaS models don’t map neatly to usage-heavy AI applications. The challenge for platforms will be creating usage-based pricing models that still offer predictability for enterprises. That’s going to require innovation in contracts and billing, not just product.
However, there’s a tension Bessemer acknowledges but doesn’t fully unpack: platforms still need to provide generous free tiers and sometimes loss-leading solutions to their developer and partner communities. Why? Because the platform’s value multiplies when third parties build apps, integrations, and tools on top of it. This creates a tricky economic balance—platforms must absorb inference costs to fuel ecosystem growth while figuring out where and how to monetize without killing the flywheel. The winners will be those who get the subsidy strategy right: investing heavily in enabling developers to build, while capturing value from the end-user consumption or enterprise deployment of what gets built. Bessemer notes this tension around “reducing friction to onboard” but the ecosystem implications run deeper than onboarding—it’s about sustaining a healthy developer economy over time.
Protocols as defensibility
Bessemer’s recent Developer Laws in the AI Era is a strong and timely contribution to the ongoing conversation about how AI is reshaping developer platforms. It’s the kind of framework that helps us step back from the hype and think more structurally about what will matter in the years ahead.
As I read through their proposed “laws,” I found myself both nodding in agreement and scribbling notes about what felt missing. Rather than treat their framing as definitive, I see it as a useful foundation to build upon. My reflections land in two buckets: the strengths of their argument that I strongly concur with, and the areas where I see blind spots or where the conversation needs to be broadened.
At the heart of it all is one conviction: the quality of developer ecosystems—not just the tools—will determine who thrives in the AI era.
Where Bessemer’s Laws Resonate
Agent Experience meets Developer Experience
The idea that AI agents are now as much a “user” of platforms as human developers is spot on. Building for both human experience (DX) and agent experience (AX) is not a trivial adjustment. It requires rethinking interfaces, APIs, and documentation so they serve two very different but equally important audiences.
Documentation as infrastructure
I share their view that documentation has graduated from being a developer aid to being core infrastructure. It’s no longer just about human readability—documentation is becoming the connective tissue that allows LLMs and agents to understand, navigate, and integrate. The emergence of Generative Engine Optimization (GEO), akin to SEO for the AI age, is a fascinating angle that I believe will become a discipline in its own right.
Pricing dynamics
They are right to call out the economic shift AI forces on platform pricing. Inference isn’t free, and per-seat SaaS models don’t map neatly to usage-heavy AI applications. The challenge for platforms will be creating usage-based pricing models that still offer predictability for enterprises. That’s going to require innovation in contracts and billing, not just product.
However, there’s a tension Bessemer acknowledges but doesn’t fully unpack: platforms still need to provide generous free tiers and sometimes loss-leading solutions to their developer and partner communities. Why? Because the platform’s value multiplies when third parties build apps, integrations, and tools on top of it. This creates a tricky economic balance—platforms must absorb inference costs to fuel ecosystem growth while figuring out where and how to monetize without killing the flywheel. The winners will be those who get the subsidy strategy right: investing heavily in enabling developers to build, while capturing value from the end-user consumption or enterprise deployment of what gets built. Bessemer notes this tension around “reducing friction to onboard” but the ecosystem implications run deeper than onboarding—it’s about sustaining a healthy developer economy over time.
Protocols as defensibility
I also agree that defensibility increasingly rests on ecosystems, integrations, and protocols rather than product features alone. Whoever defines or hosts the connective tissue—like the emerging Model Context Protocol (MCP)—will hold real power in shaping the future of developer ecosystems.
But here’s the crucial layer Bessemer implies but doesn’t fully articulate: defensible barriers emerge not just from having an ecosystem, but from cultivating a vibrant one. That vibrancy comes from three interconnected elements:
First, world-class developer experience—not just good documentation and clean APIs, but the entire journey from discovery to production deployment. Developers choose platforms where they can be productive quickly and stay productive over time.
Second, consistent value delivery—the platform must continuously evolve in ways that make existing integrations more valuable, not obsolete. Breaking changes, deprecated APIs, and shifting priorities erode trust faster than any competitor could.
Third, genuine economic opportunity—developers and partners need to build sustainable businesses on top of the platform. This means transparent revenue sharing, predictable pricing for their own cost structures, and go-to-market support that helps them reach customers. Platforms that treat ecosystem partners as cost centers rather than co-creators will struggle to maintain defensibility.
The protocol layer (like MCP) provides the technical foundation, but the moat comes from the economic and experiential reasons developers choose to build there and stay there. Feature parity is temporary; ecosystem loyalty built on sustained value creation is durable.
Where the Conversation Needs Expansion
1. Ecosystem Governance: The Missing Layer
While Bessemer focuses on platform control as defensibility (Law #8), they underplay the critical question of who controls the protocols that platforms depend on. This isn’t just a technical question—it’s a political and economic one.
The governance gap: MCP and similar protocols need more than technical excellence to become standards. They need governance structures that developers trust. History shows us that durable standards emerge from neutral foundations—Linux, Kubernetes, Ethereum—not from single-company control, even when open-sourced.
Why this matters: If Anthropic controls MCP’s roadmap, competitors will be wary of building on it. If it’s governed by a neutral foundation with multi-stakeholder input, it becomes infrastructure everyone can trust. The “political economy of standards-setting” is where the real battle for ecosystem dominance will be won or lost.
What platforms should do: Consider early transition to foundation governance, establish clear contribution processes, create transparency in roadmap decisions, and build diverse steering committees before market dominance makes neutrality claims feel hollow.
2. Global Dynamics: Beyond Silicon Valley
Bessemer’s framework reads with a heavy Silicon Valley lens, yet the most consequential developer ecosystems in AI are being built globally, with fundamentally different approaches.
Asia’s vertical integration: State-backed national AI strategies combined with consumer super-apps like WeChat and ByteDance create ecosystems with built-in scale that Western platforms must build from scratch. China’s approach to AI developer tools assumes government-industry coordination that changes the rules of ecosystem building.
Europe’s regulatory catalyst: GDPR was initially seen as a burden, but it forced adoption of privacy-preserving architectures that now look prescient. The EU AI Act and Digital Markets Act may similarly push toward open standards and interoperability requirements that create different competitive dynamics. Regulatory-heavy doesn’t mean slow—it can mean more durable.
Emerging markets leapfrogging: Africa and Latin America have rapidly growing developer populations that may skip Web2 platform patterns entirely. With Web3 infrastructure already present and lower legacy system constraints, these regions could pioneer hybrid governance models that combine the best of centralized and decentralized approaches.
The implication: A truly defensible global platform must be “global by design,” accounting for these regional differences from inception. Documentation must be internationalized, governance must reflect diverse stakeholder interests, and pricing must flex to vastly different economic contexts.
3. The Web2/Web3 Question: Control vs. Composability
Bessemer treats protocols as another layer of defensibility—a way to lock in an ecosystem. But there’s a deeper question they don’t fully address: should AI infrastructure follow Web2’s centralized playbook or Web3’s decentralized ethos?
Two competing visions:
Web2/AI ecosystems are platform-dominated. Anthropic, OpenAI, and Google control their models, APIs, and increasingly the protocols around them. Value capture is centralized. Defensibility comes from proprietary data, inference optimization, and ecosystem lock-in.
Web3/AI ecosystems, at least in principle, are community-governed and composable. Protocols live on neutral foundations. Value capture is distributed through token incentives. Defensibility comes from network effects of trust and neutrality rather than control.
The tension: Bessemer’s Law #6 notes that “integration lock-in effects have weakened” because AI makes switching easier. But this cuts both ways. If switching costs are lower, why would developers choose platforms that maintain control over protocols rather than neutral ones?
What we might see: A hybrid model where base protocols are neutrally governed (like MCP under a foundation), while platforms compete on execution, performance, and vertical integration. The companies that figure out how to profit from open protocols without controlling them may prove most durable.
4. Culture Eats Strategy: The Documentation Problem
Bessemer’s Law #2 states that “documentation must serve models as well as humans” and positions GEO as the solution. I agree with the destination but think they underestimate the journey.
The cultural reality: Teams chronically underinvest in documentation because organizational incentives reward shipping features, not maintaining clarity. Engineers get promoted for building new capabilities, not for writing comprehensive guides. Documentation debt accumulates invisibly until it becomes a crisis.
Why LLMs won’t automatically fix this: Yes, LLMs can parse messy documentation better than humans. But they can’t create documentation that doesn’t exist. They can’t update docs when APIs change if no one made updating docs part of the deployment process. GEO risks becoming another layer of complexity—another thing to maintain—unless the underlying culture changes.
What actually works: Make documentation a prerequisite for production deployment. Measure documentation coverage like test coverage. Create rotation systems where senior engineers spend time on docs. Celebrate and promote engineers who improve information architecture. Until documentation becomes as non-negotiable as security reviews, GEO optimization is premature.
The platform engineering connection: Bessemer’s Law #7 describes platform engineers as “autonomous flow architects.” These are exactly the people who should own documentation-as-infrastructure, with authority and incentives to enforce standards across product teams.
5. Speed vs. Sustainability: Questioning the Velocity Imperative
Bessemer emphasizes that “speed matters more than ever” and companies must “think through their Act 2 and Act 3 visions dramatically earlier.” This reflects conventional VC wisdom, but ecosystem durability often requires the opposite.
The counterargument from history: Linux didn’t win by moving fastest. It won through careful consensus-building and neutral governance that made it safe for competitors to collaborate. Kubernetes succeeded because Google handed it to the CNCF rather than controlling its destiny. Ethereum’s deliberate, research-heavy approach to protocol upgrades has created more trust than competitors who moved faster but broke things.
When speed compounds advantages: Early in platform formation, being first to define interfaces and capture developers creates real moats. Stripe’s developer experience became the standard others copied. GitHub’s centrality in version control made expansions into Actions and Copilot natural.
When speed creates fragility: Rapid protocol evolution without community buy-in fragments ecosystems. Too-fast deprecation of APIs alienates developers. Racing to add AI features before understanding use cases creates technical debt that slows future innovation.
A framework for deciding: Choose speed when you’re establishing a new category or when user needs are clear. Choose deliberation when building protocols others will depend on, when governance questions are unresolved, or when trust is the primary moat.
6. The Open Source Paradox
Open source appears throughout Bessemer’s framework but primarily as a distribution and adoption strategy. This misses how open source functions as the mechanism through which durable standards get set.
More than marketing: Companies open-source for developer goodwill and faster adoption. But the projects that become infrastructure—Linux, PostgreSQL, React, Kubernetes—do so because they transition from company projects to community assets with governance that outlasts any single stakeholder.
The MCP test case: Anthropic released MCP as open source, which is commendable. But the real question is whether they’ll transition governance to a neutral foundation. If MCP stays under Anthropic’s control, competitors like OpenAI might create alternatives. If it becomes community-governed, it has a chance of becoming universal infrastructure.
For founders building platforms: Consider your open source strategy not just as a GTM motion but as a governance roadmap. When will you transition control? To what entity? With what decision-making process? Companies that answer these questions early and credibly will build more defensible ecosystems than those that treat open source as a marketing channel.
7. From Theory to Practice: The Execution Gap
Bessemer’s framework is strategically sound for founders and investors. But there’s a gap between high-level laws and the tactical work of building ecosystems. The practitioners—developer relations teams, platform engineers, open-source maintainers—need different guidance.
What platform builders need:
Governance audit frameworks: How do you assess whether your protocol governance inspires trust or skepticism? What are the red flags that you’re too platform-centric? How do you transition from a company project to a community asset without losing control of your roadmap?
Incentive alignment playbooks: How do you make documentation, maintenance, and community-building as valuable as feature shipping in your organization? What metrics demonstrate ecosystem health vs. just adoption numbers?
Cultural transformation guides: How do you restructure engineering teams so that platform engineers (Law #7’s “autonomous flow architects”) have the authority to enforce documentation standards? How do you celebrate ecosystem contributions?
Global readiness checklists: Is your documentation internationalized? Does your governance reflect stakeholders beyond your home market? Can your pricing flex to radically different economic contexts?
Bridging strategy and execution: The most valuable work isn’t articulating more laws—it’s helping teams operationalize them. Case studies of companies that successfully made documentation first-class. Scorecards for evaluating ecosystem maturity across governance, culture, and global readiness dimensions. Decision frameworks for when to prioritize speed vs. sustainability.
8. A New Framework: The Six Pillars of Durable AI Developer Ecosystems
Building on Bessemer’s foundation, here’s how I’d extend their thinking into a framework focused specifically on ecosystem durability:
Pillar 1: Governance Neutrality
Who controls the protocol matters more than the protocol’s technical design. Establish clear paths to foundation governance, diverse steering committees, and transparent decision-making before market dominance makes neutrality claims hollow. Governance is not a later-stage problem—it’s a Day 1 architecture decision.
Pillar 2: Global by Design
Ecosystems that account for regional regulatory differences, economic contexts, and cultural approaches to developer community from inception will outlast those that retrofit internationalization later. This means multilingual documentation, regionally-appropriate pricing, and governance that reflects global stakeholder interests.
Pillar 3: Economic Vibrancy
Defensible ecosystems require more than adoption—they need developers and partners building sustainable businesses on top of the platform. This means transparent, dynamic, and realistic revenue-sharing models, predictable cost structures that enable partners to price their own offerings confidently, and active go-to-market support. Platforms must subsidize ecosystem growth through generous free tiers and loss-leading developer tools, while capturing value from end-user consumption and enterprise deployment. The economic model should answer: “Can a developer or partner company thrive here long-term?” If not, the ecosystem will remain shallow regardless of technical excellence. World-class developer experience—from discovery through production deployment—combined with consistent value delivery that enhances rather than breaks existing integrations, creates the conditions for economic vibrancy. Treat ecosystem partners as co-creators, not cost centers.
Pillar 4: Incentive Alignment
Make documentation, maintenance, and community-building as prestigious and promotable as feature shipping. Measure ecosystem health metrics (contribution diversity, documentation coverage, community sentiment, partner economic success) alongside product metrics (adoption, revenue, engagement). Celebrate the work that makes platforms durable, not just what makes them grow fast. This extends beyond internal teams to external partners—incentives must align across the entire ecosystem value chain.
Pillar 5: Cultural Execution
Tools don’t scale without an organizational culture that supports them. GEO doesn’t work without a disciplined approach to documentation. MCP servers don’t thrive without engineering teams that prioritize integration quality. Platform engineers need authority, not just responsibility. Culture is evident in how platforms handle breaking changes, their communication of roadmap decisions, their response to partner feedback, and whether they prioritize short-term feature velocity over long-term ecosystem stability. Culture is where most ecosystem strategies fail—get it right and everything else becomes easier.
Pillar 6: Trust Infrastructure
The underappreciated moat in AI ecosystems. Trust is manifested through neutral governance, stable APIs, transparent roadmaps, responsive maintenance, and community accountability. It’s demonstrated when platforms honor commitments to partners even when market conditions change, when they grandfather pricing for existing integrations, and when they provide ample migration windows for deprecated features. Web3 principles, such as decentralization and composability, may offer trust advantages that offset the velocity and vertical integration benefits of Web2. Trust accumulates slowly but compounds powerfully—it’s the force multiplier that amplifies the effectiveness of all other pillars.
Developer Ecosystems as the Deciding Factor
Here’s where I’d extend Bessemer’s framework: developer ecosystems will be a deciding factor in who succeeds. Tools matter, but ecosystems determine adoption, stickiness, and trust.
A well-executed ecosystem isn’t just SDKs, APIs, and a Discord server. It’s governance that developers trust, feedback loops that shape the roadmap, and incentives that align contributors—not just customers. Execution is everything. Strong ecosystems accelerate integration velocity, reduce churn, and create switching costs that make them nearly impossible to displace.
Looking Ahead
Bessemer’s framing provides a valuable starting point, and I find myself aligned with much of it. But the most important insight might be this: developer ecosystems are destiny.
The winners in AI won’t be those who merely ship clever features or even compelling platforms. They’ll be the ones who build ecosystems that balance openness, incentives, governance, and trust. Ecosystems that invite both humans and agents to contribute and create. Ecosystems that reflect not just the logic of Silicon Valley, but the realities of a global developer community.
The questions that will determine success:
- Will MCP and similar protocols transition to neutral governance, or remain under company control?
- Can platforms create cultural incentives that make documentation and maintenance as valued as feature velocity?
- Will global regulatory differences fragment ecosystems or force healthy standardization?
- Can Web2’s velocity and vertical integration coexist with Web3’s trust and composability?
- How do we measure ecosystem health beyond adoption metrics?
That’s where the real battle for the future of AI will be fought—and won. Not in the features, not in the models, but in the governance, culture, and trust infrastructure that makes ecosystems durable across decades, not just funding cycles.
I welcome dialogue on these ideas. If you’re building AI developer platforms, wrestling with ecosystem governance questions, or thinking about how regional dynamics shape technology adoption, let’s talk.