For two decades, the dominant distribution playbook for developer infrastructure was some version of the same thing: get the SDK installed, land your product in one team, and expand from there. The bottleneck was always developer bandwidth–convincing a developer to add a dependency, configure credentials, and instrument the first API call.

AI coding tools like Cursor and Claude Code are dislodging that bottleneck. Four percent of all public GitHub commits are now authored by AI, and the number is climbing fast. For developer infrastructure companies, this means adjusting your product for AI coding agents, not as a nice-to-have, but as a competitive necessity.

The Old Distribution Model

The best developer-tools companies have always understood that distribution isn’t a sales problem; it’s a friction problem. Reduce friction at installation, and adoption follows. Think of Stripe’s seven-line integration, Twilio’s copy-paste quickstart, or Datadog’s one-command agent install. The entire PLG playbook was an optimization around the same insight: Make the first five minutes magical, and word-of-mouth does the rest.

But PLG never solved the second distribution problem: expansion inside the organization. Getting the SDK installed is step one. Getting it instrumented correctly across every service, every feature, and every team is the unglamorous, ongoing work that determines whether a tool delivers its promised value or sits at 20% coverage forever.

I (Sudhee) lived this problem firsthand. As a product manager at Segment, our two hardest challenges were deceptively simple: (i) getting developers’ time and bandwidth to install analytics.js and instrument events, and (ii) making sure their implementation was actually effective (e.g., knowing what events to track, following the right API syntax) so customers got real value from the product downstream.

The first was purely a developer-bandwidth problem. PMs and marketers had to beg, borrow, and steal engineering time to get Segment implemented. We solved it by making analytics.js dead simple to install. The second was a best-practices problem, and we attacked it head-on. We built Protocols, a tracking plan product that enforced a “plan first, track effectively later” discipline. We even built Typewriter, a type safety plugin that auto-completes event code so developers don’t have to memorize the schema. These were meaningful innovations, and they worked. But they required building entire product lines, creating dedicated engineering teams, and continuing sustained investment just to close the gap between “installed” and “instrumented well.”

That’s the point: Even a company like Segment, which made solving this problem a strategic priority, had to invest enormously to get there. Most developer-tools companies never do, in our observation. Their tools sit at partial coverage, not because they lack capability, but because humans lack consistency. And as such, they never live up to their full potential value.

What Changes With Agentic Development

AI coding agents like Claude Code, Cursor, Codex etc. are rapidly becoming the primary interface through which developers write and modify code. This isn’t a marginal shift. When a developer’s default workflow is “describe what I want, review the code,” the AI agent becomes a powerful intermediary between developer intent and the codebase.

That intermediary is programmable.

With agents like Cursor and Claude Code, the first challenge around developer bandwidth effectively disappears. AI writes the code; “we can’t get engineering cycles” stops being a valid excuse. The real unlock, then, is whether you can teach the agent what the best solutions engineer at your company knows. Can it understand your customer’s industry, ICP, goals, and outcomes well enough to instrument the SDK properly across the entire application?

If so, you have a 10x solutions engineer for every single customer account, one that works on every PR, never goes on vacation, and never forgets the naming convention.

Agent skills make this possible. These are small, installable context packages that teach an AI coding agent how your tool works, what patterns to follow, and what mistakes to avoid. One command, and every interaction the agent has with a codebase carries deep, opinionated knowledge of your SDK.

This is a fundamentally different distribution surface than anything that existed before.

Why This Compounds Inside Organizations

The value of many infrastructure products scales with coverage, and coverage has historically been gated by developer memory and discipline, not technical capability. Skills break that gate.

Consider observability tools. OpenTelemetry is being used at high rates across metrics, logs, and traces. But OTel’s value scales with coverage: The more of your stack that’s instrumented, the more coherent your traces, the more useful your debugging. Coverage requires every developer, on every new service, on every new endpoint, to remember to add spans, propagate context, attach the right attributes, and configure the right exporter. That’s not a technical problem. It’s a human memory problem.

A well-designed OTel skill changes the default. The agent knows that whenever a new HTTP handler is written, it should instrument it. Whenever a database call is added, wrap it. Whenever a service boundary is crossed, propagate context. The developer doesn’t have to remember. The agent does.

This matters beyond adoption metrics. For the many developer-infrastructure products that price on usage like span volume, tracked events, monthly active users, and workflow executions, coverage depth is directly correlated with revenue. An account with 20% instrumentation is generating roughly 20% of its potential billing. Skills close that gap without a single new logo. Every PR the agent instruments is an incremental ARR that previously required a sales motion to unlock.

The same logic applies across categories:

Product analytics (Pendo*, Segment, Amplitude*). Installation is trivial. The value comes from tagging every meaningful user interaction with the right event names, properties, and user context; it’s a never-ending instrumentation task spread across every frontend developer. A skill that understands the organization’s event taxonomy turns sporadic coverage into comprehensive coverage. Sporadic tagging keeps customers in a lower event tier; skills drive upsell automatically.

Feature flags (LaunchDarkly, Statsig). Every new feature should be wrapped in a flag. In practice, maybe a third are, because it adds friction. A skill that enforces “new feature = flag by default” and knows the organization’s naming conventions doesn’t just improve adoption, it changes engineering behavior at the margin, making the right thing the easy thing.

Authentication SDKs (Auth0, Descope). Every new route, API endpoint, or user-facing flow needs identity verification, correct token validation, session handling, and logout logic. In practice, developers shortcut this under velocity pressure. A skill that enforces “every new endpoint validates identity before executing” and knows the organization’s preferred SDK patterns turns authentication from a step developers remember inconsistently into a default that applies everywhere.

Authorization SDKs (Styra*, Permit.io, Oso). Authorization logic is one of the most inconsistently applied patterns in any codebase. A skill that understands the organization’s permission model and automatically wires authorization at every new endpoint improves both security posture and SDK adoption simultaneously.

Runtime application security (Contrast Security*, Arcjet). RASP tools face the same partial-coverage trap, with more asymmetric consequences. A missed instrumentation point isn’t a reporting gap but an unprotected attack surface. A skill that enforces protection hooks at every new route by default turns RASP from a partial perimeter into a true runtime fabric. Security is the category where “the developer forgot” is an unacceptable answer.

Secrets management (HashiCorp Vault, Hush*). Every new database connection string, API key, or credential represents a moment where a developer might hardcode it instead of pulling from the org’s secrets store. A skill that intercepts those moments by flagging os.environ[‘STRIPE_KEY’] and replacing it with hush.get(‘stripe_key’) enforces hygiene at the exact point of failure. The failure mode is invisible at code review: a hardcoded secret looks like normal code. The agent catches what a human reviewer would routinely miss.

Testing frameworks (Playwright, Testcontainers, Cypress*). Testing tools aren’t hard to install, but they’re hard to keep up with. Coverage drifts not because developers don’t value tests, but because writing them is the first thing cut under velocity pressure. A skill that generates opinionated, framework-consistent tests alongside every new function or component changes the agent’s default output from “here’s your feature” to “here’s your feature and its tests.”

Durable workflow engines (Orkes*, DBOS, Temporal). These tools have steep learning curves like opinionated APIs, subtle correctness requirements around determinism, specific patterns for retries and failures. A skill that encodes all that context ensures the tenth developer to touch the workflow layer uses the same patterns as the first.

The Proof Is Already Emerging

Consider what happened with Neon, the serverless Postgres company. Neon invested heavily in agent-native distribution by publishing AI rules, Claude Code plugins, Cursor integrations, and a full agent skills library on GitHub. The result: over 80% of the databases provisioned on Neon were created by AI agents, not humans. That stat was so striking that it became a centerpiece of Databricks‘* rationale for acquiring Neon for $1 billion in 2025. Neon didn’t just build a database; it built itself into the agent’s default workflow and that distribution advantage proved worth a billion-dollar exit.

The Strategic Shift

Skills shift where competitive advantage is built. Today, the winners in developer tools are often those who nail the initial install, like the company that wins the first five minutes. If skills become the dominant adoption surface, winning shifts to whoever gets embedded in the agent context most deeply and most correctly. That rewards a different set of capabilities: the quality and completeness of your skill, the trust developers place in your agent-layer recommendations, and the speed at which you update your skill as your API evolves.

This has an important implication for developer relations and documentation investments. The best SDK documentation has always been a form of distribution: Make it easy to understand how to use the tool correctly, and adoption follows. Skills are documentation that executes. The companies that invest now in building high-quality, opinionated, well-maintained skills are pre-loading their adoption curve into every agent-assisted developer workflow.

Skills also serve as a discovery channel inside organizations. When a new developer joins a team and starts working with an AI coding agent, the agent doesn’t start from zero, rather it suggests the tools and patterns that the rest of the organization already uses. Instead of the new developer searching for alternatives, the skill surfaces the existing choice. This is how tools spread virally inside organizations in an agentic world–not through Slack recommendations or wiki pages, but through the agent’s context.

What This Means for Builders and Investors

For founders building developer infrastructure, the skill is now a first-class product artifact, not a documentation afterthought. The question to ask is not just “how do we make the first install easy?”, but “how do we make every subsequent instrumentation decision easy, for every developer, forever?” The answer is a skill that knows your API as well as your best solutions engineer does.

Investors evaluating developer-tools companies should know that distribution moats are being rebuilt. A company with a mediocre PLG motion but an exceptional skill embedded in every agent context at enterprise accounts may have a stronger expansion engine than a company with a beautiful quickstart and shallow agent-layer presence. The metrics to watch are evolving; coverage depth inside accounts, not just seat count, increasingly signals durable value.

Skills also address two coverage gaps that PLG never touched: retrofitting legacy codebases, where agents can systematically refactor existing uninstrumented code to meet current standards without a dedicated engineering sprint, and DevOps workflows, where infrastructure-as-code, CI/CD pipelines, and deployment scripts benefit from the same pattern-enforcement logic that applies to application code.

The first wave of PLG was about removing friction at installation. The second wave is about removing friction at every commit, forever. The companies that build for the second wave now will be very well-positioned in three years. The question worth asking today, whether you’re a founder building developer infrastructure or an investor evaluating it is simple: What is your AI coding-agent skills strategy, and when does it ship?