Seit zwei Jahrzehnten war die vorherrschende Vertriebsstrategie für Entwicklerinfrastruktur im Wesentlichen dieselbe: das SDK installieren, das Produkt in einem Team einführen und von dort aus expandieren. Der Flaschenhals war stets die Entwicklerkapazität– einen Entwickler davon zu überzeugen, eine Abhängigkeit hinzuzufügen, Anmeldeinformationen zu konfigurieren und den ersten API-Aufruf zu instrumentieren.

KI-Codierungswerkzeuge wie Cursor und Claude Code beseitigen diesen Flaschenhals. Vier Prozent aller öffentlichen GitHub-Commits werden mittlerweile von KI erstellt, und die Zahl steigt rasant. Für Unternehmen im Bereich der Entwicklerinfrastruktur bedeutet dies, dass Sie Ihr Produkt an KI-Codierungsagenten anpassen müssen – nicht als nettes Extra, sondern als Wettbewerbsnotwendigkeit.

Das alte Vertriebsmodell

Die besten Unternehmen für Entwicklerwerkzeuge haben immer verstanden, dass der Vertrieb kein Verkaufsproblem, sondern ein Reibungsproblem ist. Reduziert man die Reibungsverluste bei der Installation, folgt die Akzeptanz. Man denke an Stripes Integration mit sieben Zeilen Code, Twilios Schnellstart per Kopieren und Einfügen oder DatadogAgenteninstallation mit nur einem Befehl. Das gesamte PLG-Konzept basierte auf der gleichen Erkenntnis: Die ersten fünf Minuten müssen magisch sein, den Rest erledigt die Mundpropaganda.

Doch PLG hat das zweite Vertriebsproblem nie gelöst: die Expansion innerhalb der Organisation. Der erste Schritt ist die Installation des SDK. Die korrekte Implementierung in jedem Service, jeder Funktion und jedem Team ist die unglamouröse, fortlaufende Arbeit, die darüber entscheidet, ob ein Tool seinen versprochenen Nutzen bringt oder für immer bei einer Abdeckung von 20 % verharrt.

Ich (Sudhee) habe dieses Problem selbst erlebt. Als Produktmanager bei Segment waren unsere beiden größten Herausforderungen trügerisch einfach: (i) Entwickler dazu zu bringen, analytics.js zu installieren und Ereignisse zu instrumentieren, und (ii) sicherzustellen, dass ihre Implementierung tatsächlich effektiv war (z. B. zu wissen, welche Ereignisse verfolgt werden sollen, die richtige API-Syntax zu befolgen), damit die Kunden im weiteren Verlauf des Produkts einen echten Mehrwert erhielten.

Das erste Problem war rein ein Bandbreitenproblem der Entwickler. Produktmanager und Marketingfachleute mussten sich Entwicklerzeit erbetteln, ausleihen und stehlen, um Segment implementieren zu können. Wir haben das Problem gelöst, indem wir analytics.js kinderleicht zu installieren gemacht haben. Das zweite Problem betraf bewährte Vorgehensweisen, und wir haben es direkt angegangen. Wir haben Protocols entwickelt, ein Produkt zur Nachverfolgung von Planungsabläufen, das die Disziplin „erst planen, dann effektiv nachverfolgen“ durchsetzt. Wir haben sogar Typewriter entwickelt, ein Plugin für Typsicherheit, das Ereigniscode automatisch vervollständigt, damit Entwickler sich das Schema nicht merken müssen. Das waren sinnvolle Innovationen, und sie funktionierten. Doch dafür war der Aufbau ganzer Produktlinien, die Schaffung eigener Ingenieurteams und kontinuierliche Investitionen nötig, nur um die Lücke zwischen „installiertem“ und „instrumentiertem“ Brunnen zu schließen.

Genau das ist der Punkt: Selbst ein Unternehmen wie Segment, für das die Lösung dieses Problems eine strategische Priorität war, musste enorm investieren, um dieses Ziel zu erreichen. Die meisten Anbieter von Entwicklerwerkzeugen tun dies unserer Beobachtung nach nie. Ihre Werkzeuge bieten nur eine teilweise Abdeckung, nicht weil es ihnen an Leistungsfähigkeit mangelt, sondern weil es den Menschen an Konsequenz mangelt. Und so können sie ihr volles Potenzial nie ausschöpfen.

Was ändert sich mit der agentenbasierten Entwicklung?

KI-Codierungsagenten wie Claude Code, Cursor, Codex usw. entwickeln sich rasant zur primären Schnittstelle, über die Entwickler Code schreiben und modifizieren. Das ist keine geringfügige Veränderung. Wenn der Standard-Workflow eines Entwicklers darin besteht , „zu beschreiben, was ich will, und dann den Code zu überprüfen“, wird der KI-Agent zu einem leistungsstarken Vermittler zwischen der Absicht des Entwicklers und der Codebasis.

Dieses Zwischenglied ist programmierbar.

Mit Agenten wie Cursor und Claude Code verschwindet die erste Herausforderung im Zusammenhang mit der Entwickler-Bandbreite praktisch. Die KI schreibt den Code; „Wir bekommen keine Entwicklungszyklen“ ist keine gültige Ausrede mehr. Der eigentliche Schlüssel zum Erfolg liegt also darin, ob Sie dem Agenten beibringen können, was der beste Lösungsingenieur in Ihrem Unternehmen weiß. Kann es die Branche, das ICP, die Ziele und die Ergebnisse Ihres Kunden so gut verstehen, dass das SDK in der gesamten Anwendung ordnungsgemäß instrumentiert werden kann?

Wenn ja, dann haben Sie für jeden einzelnen Kundenaccount einen 10x Solutions Engineer, der an jedem PR mitarbeitet, nie Urlaub macht und die Namenskonvention nie vergisst.

Die Fähigkeiten der Agenten machen dies möglich. Hierbei handelt es sich um kleine, installierbare Kontextpakete, die einem KI-Codierungsagenten beibringen, wie Ihr Tool funktioniert, welchen Mustern er folgen und welche Fehler er vermeiden sollte. Ein einziger Befehl, und jede Interaktion des Agenten mit einer Codebasis beinhaltet tiefgreifendes, meinungsbildendes Wissen über Ihr SDK.

Dies ist eine grundlegend andere Verteilungsfläche als alles, was bisher existierte.

Warum sich dies innerhalb von Organisationen verstärkt

Der Wert vieler Infrastrukturprodukte skaliert mit der Abdeckung, und die Abdeckung wurde in der Vergangenheit eher durch das Erinnerungsvermögen und die Disziplin der Entwickler als durch deren technische Fähigkeiten begrenzt. Fähigkeiten überwinden diese Hürde.

Berücksichtigen Sie Observability-Tools. OpenTelemetry wird in großem Umfang für Metriken, Protokolle und Traces genutzt. Der Nutzen von OTel steigt jedoch mit der Abdeckung: Je mehr Komponenten Ihres Stacks instrumentiert werden, desto kohärenter sind Ihre Traces und desto nützlicher ist Ihr Debugging. Um die Abdeckung zu gewährleisten, muss jeder Entwickler bei jedem neuen Dienst und jedem neuen Endpunkt daran denken, Spans hinzuzufügen, den Kontext weiterzugeben, die richtigen Attribute anzuhängen und den richtigen Exporter zu konfigurieren. Das ist kein technisches Problem. Es ist ein Problem des menschlichen Gedächtnisses.

Eine gut konzipierte OTel-Funktion ändert die Standardeinstellung. Der Agent weiß, dass er jeden neu geschriebenen HTTP-Handler instrumentieren sollte. Immer wenn ein Datenbankaufruf hinzugefügt wird, muss dieser umschlossen werden. Immer wenn eine Dienstgrenze überschritten wird, wird der Kontext weitergegeben. Der Entwickler muss sich das nicht merken. Der Agent tut es.

Dies ist von Bedeutung, die über die reinen Akzeptanzkennzahlen hinausgeht. Bei den vielen Entwickler-Infrastrukturprodukten, deren Preisgestaltung auf der Nutzung basiert, wie z. B. Span-Volumen, verfolgte Ereignisse, monatlich aktive Benutzer und Workflow-Ausführungen, besteht ein direkter Zusammenhang zwischen Abdeckungstiefe und Umsatz. Ein Konto mit einem Instrumentierungsanteil von 20 % generiert derzeit etwa 20 % seines potenziellen Umsatzes. Kompetenzen schließen diese Lücke ganz ohne ein einziges neues Logo. Jede PR-Maßnahme, die der Agent durchführt, stellt einen zusätzlichen ARR dar, für dessen Freisetzung zuvor ein Vertriebsschritt erforderlich war.

Die gleiche Logik gilt für alle Kategorien:

Produktanalysen (Pendo*, Segment, Amplitude*). Die Installation ist trivial. Der Nutzen ergibt sich aus der Kennzeichnung jeder relevanten Benutzerinteraktion mit den richtigen Ereignisnamen, Eigenschaften und dem Benutzerkontext; es handelt sich um eine nie endende Instrumentierungsaufgabe, die auf alle Frontend-Entwickler verteilt ist. Die Fähigkeit, die Ereignisklassifizierung der Organisation zu verstehen, wandelt sporadische Berichterstattung in umfassende Berichterstattung um. Durch sporadische Kennzeichnung bleiben Kunden in einer niedrigeren Event-Kategorie; Fähigkeiten führen automatisch zu Upselling.

Feature-Flags (LaunchDarkly, Statsig). Jede neue Funktion sollte in einem Flag verpackt werden. In der Praxis trifft das vielleicht auf ein Drittel zu, denn es erhöht die Reibung. Eine Fähigkeit, die„neue Funktion = standardmäßig kennzeichnen“ durchsetzt und die Namenskonventionen der Organisation kennt, verbessert nicht nur die Akzeptanz, sondern verändert auch das Entwicklungsverhalten im Detail und macht das Richtige zum Einfachen.

Authentifizierungs-SDKs (Auth0, Descope). Jede neue Route, jeder neue API-Endpunkt oder jeder neue benutzerorientierte Ablauf erfordert eine Identitätsprüfung, eine korrekte Token-Validierung, eine Sitzungsverwaltung und eine Abmeldelogik. In der Praxis umgehen Entwickler dies unter Geschwindigkeitsdruck. Eine Fähigkeit, die sicherstellt, dass„jeder neue Endpunkt vor der Ausführung die Identität validiert“ und die bevorzugten SDK-Muster der Organisation kennt, macht die Authentifizierung von einem Schritt, an den sich Entwickler nur unregelmäßig erinnern, zu einer Standardeinstellung, die überall gilt.

Autorisierungs-SDKs (Styra*, Permit.io, Oso). Die Autorisierungslogik ist eines der am uneinheitlichsten angewandten Muster in jeder Codebasis. Eine Fähigkeit, die das Berechtigungsmodell der Organisation versteht und die Autorisierung an jedem neuen Endpunkt automatisch einrichtet, verbessert gleichzeitig sowohl die Sicherheitslage als auch die SDK-Akzeptanz.

Laufzeitanwendungssicherheit (Contrast Security*, Arcjet). RASP-Tools stehen vor dem gleichen Problem der Teilabdeckung, allerdings mit asymmetrischeren Folgen. Ein übersehener Messpunkt ist keine Meldelücke, sondern eine ungeschützte Angriffsfläche. Eine Funktion, die standardmäßig bei jeder neuen Route Schutzmechanismen erzwingt, verwandelt RASP von einem partiellen Perimeter in ein echtes Laufzeit-Fabric. Bei Sicherheit ist die Antwort „Der Entwickler hat es vergessen“ inakzeptabel.

Geheimnismanagement (HashiCorp Vault, Hush*). Jede neue Datenbankverbindungszeichenfolge, jeder neue API-Schlüssel oder jede neue Anmeldeinformation stellt einen Moment dar, in dem ein Entwickler diese möglicherweise fest codiert, anstatt sie aus dem geheimen Speicher der Organisation abzurufen. Eine Funktion, die diese Momente abfängt, indem sie os.environ['STRIPE_KEY'] markiert und durch hush.get('stripe_key') ersetzt. Sorgt für Hygiene genau dort, wo es zum Versagen kommt. Der Fehlermodus ist bei der Codeüberprüfung nicht sichtbar: Ein fest codiertes Geheimnis sieht aus wie normaler Code. Der Agent erfasst Dinge, die einem menschlichen Prüfer routinemäßig entgehen würden.

Testframeworks (Playwright, Testcontainers, Cypress*). Testwerkzeuge sind nicht schwer zu installieren, aber schwer auf dem Laufenden zu halten. Die Testabdeckung verschlechtert sich nicht, weil Entwickler Tests nicht wertschätzen, sondern weil das Schreiben von Tests das Erste ist, was unter dem Druck der Entwicklungsgeschwindigkeit gestrichen wird. Eine Fähigkeit, die zu jeder neuen Funktion oder Komponente vordefinierte, frameworkkonforme Tests generiert, ändert die Standardausgabe des Agenten von „Hier ist Ihr Feature“ zu „Hier ist Ihr Feature und seine Tests“.

Langlebige Workflow-Engines (Orkes*, DBOS, Temporal). Diese Tools haben steile Lernkurven, wie zum Beispiel meinungsstarke APIs, subtile Korrektheitsanforderungen im Zusammenhang mit Determinismus und spezifische Muster für Wiederholungsversuche und Fehler. Eine Fähigkeit, die diesen gesamten Kontext kodiert, stellt sicher, dass der zehnte Entwickler, der mit der Workflow-Ebene in Berührung kommt, die gleichen Muster verwendet wie der erste.

Der Beweis zeichnet sich bereits ab.

Betrachten wir, was mit Neon, dem Unternehmen für serverloses Postgres, passiert ist. Neon investierte massiv in die agentenbasierte Distribution, indem es KI-Regeln, Claude-Code-Plugins, Cursor-Integrationen und eine vollständige Agentenfähigkeitenbibliothek auf GitHub veröffentlichte. Das Ergebnis: Über 80 % der auf Neon bereitgestellten Datenbanken wurden von KI-Agenten und nicht von Menschen erstellt. Diese Statistik war so auffällig, dass sie zu einem zentralen Bestandteil der Argumentation von Databricksfür die Übernahme von Neon für 1 Milliarde Dollar im Jahr 2025 wurde. Neon hat nicht einfach nur eine Datenbank entwickelt; es hat sich in den Standard-Workflow des Agenten integriert, und dieser Vertriebsvorteil erwies sich als milliardenschwerer Exit.

Der strategische Wandel

Die Fähigkeiten verlagern sich dorthin, wo Wettbewerbsvorteile entstehen. Heutzutage sind die Gewinner bei Entwicklertools oft diejenigen, die die Erstinstallation perfekt meistern, so wie das Unternehmen, das die ersten fünf Minuten für sich entscheidet. Wenn Fähigkeiten zum dominierenden Aspekt der Kompetenzaneignung werden, geht der Erfolg dahin, wer sich am tiefsten und korrektesten in den Agentenkontext einfügt. Das belohnt eine andere Art von Fähigkeiten: die Qualität und Vollständigkeit Ihrer Fähigkeiten, das Vertrauen, das Entwickler in Ihre Agentenschicht-Empfehlungen setzen, und die Geschwindigkeit, mit der Sie Ihre Fähigkeiten aktualisieren, wenn sich Ihre API weiterentwickelt.

Dies hat wichtige Auswirkungen auf die Entwicklerbeziehungen und Investitionen in die Dokumentation. Die beste SDK-Dokumentation war schon immer eine Form der Verbreitung: Wenn man es leicht verständlich macht, wie man das Tool richtig benutzt, folgt die Akzeptanz von selbst. Fähigkeiten sind Dokumentation, die ausgeführt wird. Unternehmen, die jetzt in den Aufbau hochwertiger, meinungsstarker und gut gepflegter Kompetenzen investieren, integrieren ihre Adoptionskurve im Voraus in jeden agentengestützten Entwickler-Workflow.

Fähigkeiten dienen auch als Entdeckungskanal innerhalb von Organisationen. Wenn ein neuer Entwickler einem Team beitritt und mit einem KI-Codierungsagenten arbeitet, beginnt dieser nicht bei Null, sondern schlägt die Werkzeuge und Muster vor, die der Rest der Organisation bereits verwendet. Anstatt dass der neue Entwickler nach Alternativen suchen muss, zeigt die Funktion die bereits vorhandenen Optionen an. So verbreiten sich Tools in einer agentenbasierten Welt viral innerhalb von Organisationen – nicht durch Slack-Empfehlungen oder Wiki-Seiten, sondern durch den Kontext des Agenten.

Was dies für Bauherren und Investoren bedeutet

Für Gründer, die eine Entwicklerinfrastruktur aufbauen, ist diese Fähigkeit heute ein erstklassiges Produktartefakt und nicht mehr nur ein nachträglicher Gedanke in der Dokumentation. Die entscheidende Frage lautet nicht nur „Wie gestalten wir die Erstinstallation einfach?“, sondern „Wie gestalten wir jede nachfolgende Instrumentierungsentscheidung für jeden Entwickler und für immer einfach?“ Die Antwort ist eine Fähigkeit, die Ihre API genauso gut kennt wie Ihr bester Lösungsingenieur.

Investoren, die Unternehmen im Bereich Entwicklerwerkzeuge bewerten, sollten wissen, dass die Wettbewerbsvorteile im Vertrieb neu aufgebaut werden. Ein Unternehmen mit einer mittelmäßigen PLG-Strategie, aber außergewöhnlichen Fähigkeiten, die in jedem Agentenkontext bei Unternehmenskunden verankert sind, verfügt möglicherweise über einen stärkeren Expansionsmotor als ein Unternehmen mit einem gelungenen Schnellstart und einer oberflächlichen Präsenz auf Agentenebene. Die zu beachtenden Kennzahlen entwickeln sich weiter; die Abdeckungstiefe innerhalb der Kundenkonten, nicht nur die Anzahl der Sitzplätze, signalisiert zunehmend einen nachhaltigen Wert.

Die Fähigkeiten schließen außerdem zwei Lücken in der Abdeckung, die PLG nie angegangen ist: die Nachrüstung von Legacy-Codebasen, bei der Agenten bestehenden, nicht instrumentierten Code systematisch umgestalten können, um den aktuellen Standards ohne einen dedizierten Engineering-Sprint zu entsprechen, und DevOps-Workflows, bei denen Infrastructure-as-Code, CI/CD-Pipelines und Bereitstellungsskripte von der gleichen Mustererzwingungslogik profitieren, die für Anwendungscode gilt.

Die erste Welle von PLG bestand darin, Reibungsverluste bei der Installation zu minimieren. Die zweite Welle zielt darauf ab, Reibungsverluste bei jedem Commit für immer zu beseitigen. Die Unternehmen, die jetzt für die zweite Welle rüsten, werden in drei Jahren sehr gut aufgestellt sein. Die Frage, die sich heute stellt, egal ob Sie als Gründer eine Entwicklerinfrastruktur aufbauen oder als Investor diese bewerten, ist einfach: Wie sieht Ihre Strategie für KI-Codierungsagentenfähigkeiten aus, und wann wird sie ausgeliefert?