KI Neuigkeiten
01 Nov. 2025
Read 15 min
Warum KI Codegeneratoren scheitern und wie Observability hilft
Warum KI Codegeneratoren scheitern: Observability mit Laufzeitdaten schafft echten Wert im Betrieb.
Viele Millionen fließen in Tools wie Cursor oder Replit – doch die großen LLM-Anbieter sitzen am längeren Hebel. Warum KI Codegeneratoren scheitern: Code-Gen liegt zu nah am Fundamentmodell, Differenzierung bricht weg. Eine Chance bleibt: Observability. Wer Produktion versteht, kann echten Mehrwert liefern, sagt Jeremy Burton.
Ein Geldregen hat viele Startups für KI-gestütztes Coden groß gemacht: Replit, Cursor, Windsurf von Cognition AI, Augment Code von Augment Computing, All Hands AI oder auch Anbieter rund um Deployment wie Harness. Trotzdem droht ihnen ein hartes Ende. Der Grund: Die wichtigsten Teile der Code-Erzeugung kommen von Basismodellen großer Anbieter wie Anthropic, OpenAI, Google oder Microsoft. Das sagt Jeremy Burton, CEO von Observe Inc. und langjähriger Enterprise-Software-Manager. Seine Diagnose ist klar: Code-Generierung sitzt zu dicht am Kern der Foundation-Modelle – dort, wo die Wertschöpfung liegt. Wer nur eine dünne Schicht darüber legt, verliert.
Welchen Anteil unseres Mehrwerts liefert das LLM?
Wie schwer wäre es für einen Wettbewerber, dieselbe UX auf das gleiche Modell zu setzen?
Gibt es Daten oder Workflows, die nur wir haben?
Telemetry first: Logs, Metriken, Traces konsistent sammeln und verknüpfen.
Kontextgraph: Services, Deployments, Releases, Tickets und Incidents als Graph modellieren.
Closure of the loop: Jede Code-Änderung mit deren Laufzeitwirkung verlinken.
Das Ziel: Wenn eine Pipeline heute fehlschlägt, sieht der Entwickler sofort, welcher Commit, welche Abhängigkeit und welches Feature-Flag im Spiel war – plus Vorschläge zur Behebung.
Domänenspezifische Produktionsdaten (Telemetrie, Compliance, interne SLAs)
Troubleshooting-Flows und Entscheidungsbäume
Security- und Deployment-Pfade mit echten Betriebskosten
Partnerschaften mit Observability-Anbietern, um Kontext ins Coding zu holen.
Übernahmen/Fusionen mit DevOps-Stacks wie Harness, um vom Commit bis zum Betrieb abzudecken.
Gezielte Produktintegration mit Claude Code oder App Builder Copilot, statt sie zu bekämpfen.
Unique Data: Produktionsdaten als Eigentum und Burggraben.
Hard Problems: Deterministische Systeme, Graphen, Telemetrie in TB-Größe.
Closed Loop: Von der Ursache zur Reparatur – Vorschläge, die Entwickler annehmen wollen.
Sichtbarkeit: Was zeigt mir das Tool in Produktion?
Bezug: Welche Daten verbindet es mit meinem Code, Releases und Incidents?
Eigenständigkeit: Was bleibt, wenn das genutzte LLM morgen gleichzieht?
Warum KI Codegeneratoren scheitern
Nähe zum Fundamentmodell: Zu wenig Raum für Mehrwert
Burtons Kernaussage lautet: „Code generation is so close to the foundation model.“ Genau hier liegt der Grund, warum KI Codegeneratoren scheitern. Wenn ein Tool im Kern nur API-Aufrufe an ein LLM schickt, ist es austauschbar. Das Fundamentmodell wird schneller besser als jede Zusatzschicht drumherum. Das macht es schwer, auf Dauer eine eigenständige Marge zu sichern. Viele der neuen Tools sind im Kern Cloud-IDEs: Sie verbinden Editor, Bibliotheken, Tests und Deployment. Doch wenn die Code-Erzeugung das Herzstück ist, entscheidet die Qualität des zugrunde liegenden LLM. Wird das LLM „gut genug“, fällt der Nutzen der Zusatzschicht weg. Burton formuliert es so: Irgendwann „become [the models] good enough [at coding]“, und dann fehlt den Pure Plays die Differenzierung.Plattformabhängigkeit: Anthropic als Taktgeber
Aus Sicht von Burton hängt ein Großteil der Code-Startups an Anthropic. Seine Einschätzung: „Anthropic models are better than anyone at code generation.“ Wenn die besten Resultate aus Claude kommen, ist es schwer, einen Vorsprung zu halten. Das illustriert, warum KI Codegeneratoren scheitern: Sie bauen auf einer Plattform, die selbst ein eigenes, „gut genuges“ Produkt liefert – Claude Code. Auch Microsoft drückt mit App Builder Copilot in dieselbe Richtung. Für viele Standardaufgaben reicht das Zusammenspiel aus LLM und Code-Repo wie GitHub.IDE als UI, nicht als Motor
Die neuen Editoren glänzen bei Komfort, Shortcuts und Kollaboration. Aber der Motor bleibt das LLM. Genau hier liegt das strukturelle Problem. Wenn der Motor bei den Großen sitzt, geht die Puste der schlanken UI-Startups aus. Aus Sicht von Burton sind diese Produkte eine „thin layer on top of an LLM“. Gute UIs sind wichtig, aber sie sind austauschbar, wenn der Kern nicht im eigenen Haus liegt.Die Macht der Foundation-Modelle
Skalenvorteile: Chips, Rechenzentren, Daten
Die Grundlage der Dominanz sind massive Investitionen. Anthropic, von Amazon unterstützt, trainiert neue Claude-Versionen auf Project Rainier. Amazon will dafür eine Million Trainium2-Chips in mehreren AWS-Rechenzentren einsetzen. Diese Größenordnung zeigt, warum KI Codegeneratoren scheitern, wenn sie versuchen, beim Modelltraining mitzuhalten. Für ein Startup ist dieser Kapitaleinsatz kaum erreichbar. Das Ergebnis: Frontier-Modelle werden in kurzer Taktung besser. Jede neue Generation erhöht die Messlatte. Was gestern als Differenzierung galt, ist morgen „Commodity“.Produktintegration: „Good enough“ für viele Aufgaben
Anthropic hat mit Claude Code eine eigene IDE. Microsoft bietet App Builder Copilot. Beide haben direkten Zugriff auf Modell-Know-how, Trainingspipeline und Integrationen wie GitHub. In vielen Teams reicht „good enough“, um die Lücke zu schließen. Wer nur Code-Vorschläge braucht und keinen tiefen Produktionskontext, wird bei den Anbietern der Grundmodelle fündig. Das drückt die Luft für spezialisierte Zwischenlayer weiter ab.Observability als Wettbewerbshebel
Vom Code zur Laufzeit: Wissen, was in Produktion passiert
Hier setzt Burton den Kontrapunkt: Um echten Nutzen zu stiften, müssen Entwickler sehen, wie Code in Produktion läuft. Deshalb rückt Observability ins Zentrum. Observe Inc. baut dazu einen Knowledge Graph der Anwendung. Dieser Graph verknüpft Signale aus der Laufzeit – Telemetrie, Logs, Metriken, Traces – und macht Fehlerstellen sichtbar. Der Effekt: Wer die reale Systemdynamik versteht, kann Probleme schneller finden und beheben.Schwierig für die Großen: Deterministische Datenarbeit
Burton argumentiert: Foundation-Modelle zu verbessern, ist für die Großen leichter, als ein deterministisches System zu bauen, das hunderte Terabyte Telemetrie verwaltet. Genau hier entsteht eine Nische mit Tiefgang. Observability ist Daten-Infrastruktur, kein Prompt-Trick. Sie braucht stabile Pipelines, saubere Datenmodelle und konsistente Verknüpfungen. Tools wie Observe setzen dabei auf bestehende Datenplattformen, etwa Snowflake auf AWS Iceberg-Tabellen. Das ist robuste, „schwere“ Software – nicht nur eine UI über einem LLM.Von der Ursache zur Abhilfe: Vorschläge statt Rätselraten
Der Ansatz geht über das reine Anzeigen hinaus. Das Tool untersucht Produktionsprobleme aktiv und schlägt Remediation-Schritte vor, die der Entwickler prüft. Burton nennt das „a pretty wild departure from the troubleshooting flow of yesterday“. Aus der Praxis bedeutet das: weniger Springen zwischen Tools, weniger Bauchgefühl, mehr geführte Pfade zu einer Lösung.Szenarien für Code-Tool-Startups
Eigenes Modell bauen – oder verbrennen?
Einige Anbieter versuchen, eigene Modelle für Code zu trainieren. Cursor kündigte das an, um die Abhängigkeit zu senken. Doch der Wettlauf mit Anthropic und Co. ist teuer. Ohne Zugang zu riesigen Rechenclustern ist es schwer, auf Augenhöhe zu kommen. Das ist ein weiterer Grund, warum KI Codegeneratoren scheitern, wenn sie den Kampf auf der Modellschicht suchen.Übernahmen und Fusionen: Wenn die Musik stoppt
Burton erwartet mehrere Pfade: Manche Startups werden übernommen, andere verschwinden. Potenzielle Käufer sind DevOps-Schwergewichte wie Dynatrace, Datadog oder Splunk. Auch Mischformen sind denkbar: Code-Tools verschmelzen mit Plattformen wie Harness oder nutzen Observability-Fähigkeiten von Anbietern wie Observe, um echte Differenzierung zu schaffen. Heute sind einige Ziele noch zu teuer. Fallen die Bewertungen durch Druck der LLM-Giganten, entstehen „Buying Opportunities“. Das Risiko bleibt: Wenn das Wachstum stockt oder die KI-Euphorie abkühlt, sinken Bewertungen stark. Dann drohen „fire sale“-Übernahmen oder Insolvenz. Venture-Kapital kann diese Entwicklung verzögern, aber nicht dauerhaft aufhalten.Adjazenz statt Dünnschicht: Code trifft Betrieb
Burton nennt Observability die „obvious adjacency“. Die Logik ist bestechend: Wer Code schreibt, muss wissen, wie er sich live verhält. Fehler, Latenzen, Ausreißer, kaputte Abhängigkeiten – all das sieht man erst in Produktion. Wer Coding-Assistenz direkt mit Observability koppelt, löst nicht nur „Was schreibt das LLM?“, sondern „Was wirkt in meinem System?“.Wie Produkt- und Engineering-Teams jetzt vorgehen können
1) Abhängigkeiten nüchtern prüfen
Wenn Ihr Tool eine dünne Schicht über einem Fremdmodell ist, droht Austauschbarkeit. Fragen Sie:2) Observability mit Code verzahnen
Überführen Sie Produktionssignale in verwertbare Kontexte für Entwickler:3) Auf bestehende Datenplattformen aufsetzen
Statt das Datenrad neu zu erfinden, nutzen viele Observability-Ansätze vorhandene Speicher wie Snowflake auf AWS Iceberg-Tabellen. Das senkt Integrationsrisiken und beschleunigt den Weg zu stabilen, nachvollziehbaren Workflows.4) „Good enough“ akzeptieren, Fokus verlagern
Bei der reinen Code-Erzeugung wird „good enough“ der Foundation-Modelle zur Norm. Differenzieren Sie dort, wo der Modellanbieter nicht automatisch stark ist:5) M&A-Optionen denken, solange die Zeit noch läuft
Wer groß werden will, braucht Zugang zu Produktionsdaten und DevOps-Funktionalität. Drei Wege liegen auf der Hand:Was dieser Wandel für den Markt bedeutet
Für Entwickler
Entwickler bekommen „gut genuges“ Code-Gen direkt bei den Großen – plus starke Editor-Integrationen. Der Hebel liegt künftig weniger im Prompt, mehr in Produktionsnähe. Wer Fehler schnell findet und sauber behebt, liefert den größten Wert. Tools, die Ursachen und Effekte verbinden, gewinnen.Für Startup-CEOs
Das Spielfeld verlagert sich. Wer weiter nur LLM-Aufrufe hübsch verpackt, spielt gegen die Uhr. Strategien mit Substanz:Für Käufer in Unternehmen
Beschaffen Sie nicht nur einen Editor mit KI. Prüfen Sie:Der rote Faden: Code ist erst der Anfang
Die Geschichte hinter dem Hype ist simpel: LLMs liefern heute schon erstaunlich gute Code-Vorschläge. Morgen liefern sie bessere. Deshalb erklärt sich, warum KI Codegeneratoren scheitern, wenn sie nur die letzte Meile im Editor besetzen. Die nächste Stufe entsteht dort, wo Modelle auf reale Systemdaten treffen – Observability, Fehleranalyse, Handlungsvorschläge. Burton bringt es auf den Punkt: Es ist für die Großen leichter, ihre Modelle zu verbessern, als ein präzises System für riesige Telemetriemengen zu bauen. Genau hier entsteht Raum für echte, dauerhafte Differenzierung. Am Ende läuft es auf Konsolidierung hinaus. Einige Anbieter bauen Brücken zur Observability. Andere werden geschluckt, wenn Bewertungen fallen. Wieder andere verschwinden. Wer überlebt, verbindet Coding, Betrieb und Daten zu einem Kreislauf. Und damit auch die Antwort auf die Leitfrage: Warum KI Codegeneratoren scheitern – und wie Observability ihnen doch noch eine Zukunft geben kann.For more news: Click Here
FAQ
Q: Warum KI Codegeneratoren scheitern?
A: Laut Jeremy Burton scheitern KI Codegeneratoren, weil Code‑Generierung zu dicht am Foundation‑Modell sitzt und damit kaum Raum für dauerhafte Differenzierung bleibt. Wenn die großen Anbieter ihre LLMs verbessern, wird die Zusatzschicht austauschbar und ein eigenständiges Geschäftsmodell schwer zu sichern.
Q: Welche Vorteile haben die großen Foundation‑Model‑Anbieter gegenüber Startups wie Cursor oder Replit?
A: Die großen Anbieter besitzen die zugrunde liegenden Modelle und können Code‑Generierung direkt in eigene Produkte integrieren, etwa Anthropic mit Claude Code oder Microsoft mit App Builder Copilot. Außerdem haben sie massive Infrastruktur und Investitionen, wie Anthropic mit Project Rainier und großem Einsatz von Trainium2‑Chips, die es Startups schwer machen, aufzuholen.
Q: Wie kann Observability Startups helfen, im Wettbewerb zu bestehen?
A: Observability liefert Produktionskontext durch Knowledge Graphs, die Telemetrie, Logs, Metriken und Traces verknüpfen, sodass Entwickler Fehler schneller lokalisieren können. Das ermöglicht automatisierte Vorschläge zur Behebung und schafft eine tiefergehende Differenzierung, die reine LLM‑Layer schwer reproduzieren.
Q: Ist es für Code‑Tool‑Startups sinnvoll, eigene Modellinfrastrukturen zu bauen?
A: Einige, wie Cursor, versuchen eigene Modelle zu entwickeln, doch das erfordert enorme Rechenressourcen und Investitionen, die junge Firmen kaum stemmen können. Ohne Zugriff auf vergleichbare Trainingsinfrastruktur ist es schwer, mit Anthropic oder anderen Frontier‑Modellen mitzuhalten.
Q: Welche Exit‑Optionen haben KI‑Coding‑Startups laut dem Artikel?
A: Mögliche Pfade sind Übernahmen durch etablierte DevOps‑Anbieter oder Fusionen mit Plattformen wie Harness, aber auch Insolvenzen bei ausbleibender Finanzierung. Burton nennt potenzielle Käufer wie Dynatrace, Datadog oder Splunk und warnt vor Bewertungsstürzen, die zu Fire‑Sale‑Akquisitionen führen können.
Q: Was sollten Produkt‑ und Engineering‑Teams jetzt tun, um Risiken zu minimieren?
A: Die Teams sollen Abhängigkeiten vom LLM nüchtern prüfen, Observability in Coding‑Workflows integrieren und vorhandene Datenplattformen wie Snowflake auf AWS Iceberg nutzen. Sie sollten das „good enough“ der Foundation‑Modelle akzeptieren und sich stattdessen auf Produktionsdaten, Troubleshooting‑Flows und Sicherheits‑/Deployment‑Pfad‑Differenzierung konzentrieren.
Q: Können Produkte wie Claude Code oder App Builder Copilot spezialisierte Code‑Tools ersetzen?
A: Für viele Standardaufgaben können integrierte IDEs der Foundation‑Modelle ausreichend oder „good enough“ sein, wenn nur LLM‑Antworten und Zugriff auf ein Code‑Repository nötig sind. Das verringert den Bedarf an spezialisierten Zwischenlagen, solange kein tiefer Produktionskontext erforderlich ist.
Q: Wie verändert sich der Markt und wer hat die besten Überlebenschancen?
A: Der Markt wird sich konsolidieren; einige Anbieter werden übernommen, andere verschwinden, und Gewinner sind jene, die Coding, Betrieb und Produktionsdaten zu einem geschlossenen Kreislauf verbinden. Zugang zu Telemetrie und Observability‑Funktionen bildet laut Artikel den wichtigsten Wettbewerbsvorteil für nachhaltigen Erfolg.
Contents
