AI Coding - Das Spiel ums Überleben: Spec frisst die menschliche Codierung auf, Agenten verschwenden Zeit mit unnötigen Wiederholungen, und nach der Kontrollverlust der Token-Kosten wird die Kontext-Engineering zur entscheidenden Faktor.

Das AI-Coding-Ekosystem im Jahr 2025 definiert für Programmierer im Jahr 2026 eine neue Rolle. Die Antwort könnte in einer Reihe von rauchenden Markdown-Dateien versteckt liegen.

In den letzten sechs Monaten hat die Spec-gesteuerte Entwicklung unglaublich populär geworden. Im Repository stapeln sich schnell Schichten von Agent-gerichteten "Markdown-Scaffolds", die als die neueste Lösung für AI Coding gefeiert werden: Mit einem Vertrag wird der Agent gezwungen, tatsächlich zu arbeiten.

Aber hier stellt sich die Frage: Kann dieser Vertrag die Komplexität von Jahrzehnten der Softwareentwicklung wirklich bewältigen? Oder wird der ultimative Wert eines Programmierers von "Code schreiben" auf "Regeln definieren" wechseln - die technologische Revolution mit einer natürlichen Sprache, die die KI versteht, zu beherrschen?

1

Die Grenzen der Vervollständigung und der unvermeidliche Aufstieg des Agenten

Die Entwicklung von AI Coding hat sich deutlich in zwei Epochen aufgeteilt.

Die erste Welle wurde von Copilot und Cursor eingeleitet: Dies ist eine menschenzentrierte Programmierweise, bei der die KI die Rolle hat, das "nächste Zeichen" oder die "nächste Bearbeitungsposition" vorherzusagen, um die Geschwindigkeit und Flüssigkeit in einem begrenzten Bereich zu erhöhen.

Die Grenzen dieses Paradigmas sind eigentlich sehr klar. Die Vervollständigung muss reibungslos sein, um den Arbeitsfluss nicht zu unterbrechen. Dies bedeutet, dass die Ende-zu-Ende-Latenz streng auf einige Hundert Millisekunden beschränkt ist, und die verfügbare Modellgröße und die Länge des Kontexts natürlich begrenzt sind: Die Modellparameter dürfen nicht zu groß sein, und die Kontextlänge kann auch bei weitem nicht vollständig genutzt werden.

Unterdessen wird die Fähigkeit der Vervollständigung ständig erweitert - von der Inline-Vorhersage bis zur Quervervollständigung über Zeilen, Funktionen und Dateien hinweg sowie zur Neuformulierung und sogar zur lokalen Refaktorisierung. Obwohl es noch viel Raum für Verbesserungen bei der Benutzererfahrung gibt, nähert man sich dem technischen Limit, die globale Absicht, die Projektbeschränkungen und die Abhängigkeiten in so kurzer Zeit zu verstehen: Es werden nahezu maximale Anforderungen an das Nachtraining, die Kontextauswahl, die Inferenzstrategie und die technische Kette des allgemeinen Vervollständigungsystems gestellt.

In der zweiten Welle, insbesondere in den letzten 6 - 12 Monaten, haben wir einen echten Paradigmenwechsel erlebt: Der Aufstieg des Agenten. Er beschränkt sich nicht mehr darauf, das "nächste Zeichen" vorherzusagen, sondern übernimmt direkt Aufgaben - von der Anforderungsanalyse bis zur Codegenerierung, vom Toolaufruf bis zur Ergebnisüberprüfung.

Im Vergleich dazu hat das Vervollständigungs-Paradigma Einschränkungen wie einen kleinen Änderungsbereich und einen hohen Verbrauch an Entwickleraufmerksamkeit. Im Vergleich zum Agenten-Dialogmodus, das Code effizient generieren kann, nimmt die Grenznutzen seiner kontinuierlichen Optimierung ab. Mit der Verbesserung der Modellfähigkeiten und der Toolketten wird der Agent mehr Phasen von den Anforderungen bis zur Lieferung abdecken und allmählich zum Hauptprozess werden; in Agenten-dominierten Szenarien kann die Vervollständigung in den Hintergrund treten und zu einer der zugrunde liegenden Fähigkeiten werden, um die feine Ausführung des Agenten zu unterstützen.

In dieser Hinsicht hat Tian Zhu, der Kernentwickler von TRAE, darauf hingewiesen, dass dies nicht bedeutet, dass das Vervollständigungs-Paradigma die technologische Grenze erreicht hat: Einerseits gibt es immer noch viele Entwickler, die den Prozess des "Selbstschreibens von Code" genießen, und es gibt immer noch viel Raum für Verbesserungen bei der Vervollständigungs-Erfahrung in diesen Szenarien; noch wichtiger ist, dass von der Fähigkeit her die Vervollständigung immer das gleiche Problem löst - die Vorhersage der vernünftigsten nächsten Bearbeitungsaktion unter Berücksichtigung des Kontexts. In der Vergangenheit wurde diese Fähigkeit hauptsächlich zur Unterstützung des menschlichen Codings genutzt; im Agentensystem kann sie auch wiederverwendet werden, um die eigene Ausführung der KI zu unterstützen. Beispielsweise können das Dialogfeld des Agenten, die Generierung und Vervollständigung von Toolaufrufparametern im Wesentlichen als verschiedene Formen von "Vervollständigungs-Szenarien" angesehen werden.

Außerdem kann man dieses Jahr ein sehr interessantes Phänomen beobachten: Fast alle führenden Programmiertools haben begonnen, sich zu einer Kombination von drei parallelen Formen von Fähigkeiten zu entwickeln: IDE, CLI und Cloud. Viele Produkte beginnen mit einer dieser Formen, erweitern sich aber schnell auf die anderen beiden, denn was die Benutzer wirklich brauchen, ist nicht eine bestimmte Interaktionsmethode, sondern eine vollständige Kette, die "Aufgaben in verschiedenen Szenarien bearbeiten kann". Daher können wir die "Herkunft" und die Eigenschaften einiger repräsentativer Tools deutlicher verstehen: Claude Code stammt aus der CLI, daher könnte es auf der CLI stärker sein; OpenAI Codex stammt aus der Cloud; Cursor stammt aus der IDE und ist einer der größten Akteure auf dem IDE-Gebiet.

Unter ihnen sind CLI- und Cloud-Agenten von Anfang an Agenten-dominiert. Sie haben einen geringeren Bedarf an der Benutzeroberfläche, arbeiten entweder im Terminal oder verwenden eine vereinfachte Weboberfläche und kooperieren und liefern über GitHub PRs.

Dennoch ist Tian Zhu der Meinung, dass die IDE immer noch der am weitesten verbreitete Einstiegspunkt sein wird, und der Grund ist einfach: Sie passt am besten zu den langjährigen Arbeitsgewohnheiten von Programmierern. Er hat in der früheren Praxis seines Teams festgestellt, dass rupturelle Innovationen in professionellen Produktivitätstools oft mit einer umfassenden Umgestaltung der Kognition und Arbeitsmethoden von Entwicklern einhergehen. Nach seiner Meinung wird sich die Form der IDE innerhalb von drei Jahren wahrscheinlich grundlegend ändern und wird nicht mehr um den Editor kreisen - der SOLO-Modus von TRAE und der Agenten-Modus von Cursor sind genau die Exploration und Praxis in dieser Richtung in der Branche.

Einfacher ausgedrückt: Die IDE wandelt sich von einer "Werkzeugkiste für Menschen" zu einer "gemeinsamen Werkzeugkiste für KI und Menschen". Viele menschenzentrierte Fähigkeiten in der traditionellen IDE werden jetzt in kleinere, spezifischere und KI-freundlichere Tools zerlegt, die vom KI-Agenten nach Bedarf aufgerufen werden. Dadurch wird die IDE im Laufe der Zeit immer mehr zu einem Fähigkeitscontainer und einer Ausführungsumgebung für die Zusammenarbeit zwischen Agenten und Menschen.

Diese drei Wege konvergieren schließlich in unterschiedlichem Maße zu Agenten-Verhalten.

Die IDE entwickelt sich weiterhin in der Zusammenarbeitserfahrung zwischen "Menschen + Agenten", die CLI stärkt die Agenten-Fähigkeiten in der technischen Automatisierung und in Pipelines, und der Cloud-Agent erweitert die Grenzen der Forschungs- und Entwicklungs-Zusammenarbeit in Bezug auf Zeit und Raum.

Obwohl sie unterschiedliche Formen haben, sind ihre Ziele sehr einheitlich: Das Agenten-dominiertes Paradigma. Im Agenten-Szenario konvergieren die Kernanforderungen aller: Die Fähigkeit, Tools richtig zu nutzen, die Langzeitstabilität von Aufgaben aufrechtzuerhalten und sich ständig unter Feedbacksignalen zu korrigieren. Daher liegt die Fähigkeit des Coding-Agenten im Wesentlichen in der Langzeitstabilität von Aufgaben und der Fähigkeit, Tools aufzurufen.

Wenn die Ausführungskraft von Menschen auf Agenten übertragen wird, muss die in der Softwaretechnik über Jahrzehnte angesammelte Komplexität zwangsweise als explizite Regeln festgelegt werden - dann wird die Spec abgerufen.

Screenshot aus dem Kommentarbereich von "Es ist Zeit, aus dem Traum von 'Jeder ein Programmierer' zu erwachen!"

2

Kann Spec wirklich die Probleme von AI Coding lösen?

Seit dieser Begriff populär geworden ist, sind nur ein paar Monate vergangen, und eine peinliche, aber unvermeidliche Realität hat allmählich hervorgetreten: Das "Spec", über das die Leute sprechen, ist nicht mehr dasselbe.

Einige sagen, dass Spec darin besteht, bessere Prompts zu schreiben, andere verstehen es als detailliertere Produktanforderungsdokumente, und wieder andere denken, dass es sich um Architekturentwurfsdokumente handelt. Aber für die meisten Technikteams bedeutet Spec einfach "bei der Codeentwicklung ein paar mehr Markdown-Dateien zu verwenden".

Also werden Sie gemini.md, claude.md, agent.md, cursor - Regeln, verschiedene Fähigkeiten schnell im Repository stapeln, zusammen mit GitHub-Konfigurationsdateien. In den letzten Monaten haben verschiedene Proxy-Tools von großen Unternehmen "wiederverwendbare Kontextrahmenwerke" eingeführt: Claude Skills, Cursor Team Rules, GitHub Copilot Spaces, zusammen mit Drittanbieter-Tessl, BMad Method (BMM) usw. Die gesamte Toolkette hat sich innerhalb eines Jahres explosionsartig entwickelt und eine große Anzahl neuer Infrastrukturspezies hervorgebracht.

Viele Teams haben in der Praxis das intuitive Gefühl, dass die KI beim Schreiben von Code nicht an Spec, sondern an Kontext fehlt. Also setzen einige Leute die beiden einfach gleich: "Spec ist Kontext-Engineering", oder "Spec-gesteuerte Entwicklung ist gleichbedeutend mit Kontext-Engineering".

Dennoch neigen Frontline-Toolteams in China eher dazu, zu denken, dass "es sich um verschiedene Dinge handelt".

Nach ihrer Ansicht ist Spec eher wie der wichtigste und stabilste Inhaltstyp im Kontext, der die Rolle des "leitenden Kontexts" spielt: Es legt klar die Ziele, die Beschränkungen und die Akzeptanzkriterien fest, was dem Agenten gleichkommt, einen ausführbaren Vertrag zu geben, der klar definiert, was er tun soll und in welchem Maße es als korrekt gilt.

Unter dieser Arbeitsteilung löst Spec das Problem von "was wir tatsächlich bauen", während sich das Kontext-Engineering auf "ob das Modell in diesem Moment genug Informationen erhalten hat" konzentriert. Spec selbst wird nicht automatisch in einen effektiven Kontext umgewandelt, aber es ist oft eine langfristige Quelle für hochwertigen Kontext. Die beiden sind stark gekoppelt, können sich aber nicht ersetzen.

Daher sollte Spec nicht auf einige feste Dokumentformen beschränkt sein. Genauer gesagt ist Spec die Summe aller Verträge, die zur Steuerung der Codegenerierung verwendet werden: Produktunterlagen, Entwurfsentwürfe, Schnittstellendefinitionen, Randbedingungen, Akzeptanzkriterien und Ausführungspläne können alle in das Spec-System aufgenommen werden, als Teilmengen in verschiedenen Phasen und Granularitäten.

Aber aufgrund seiner "weiten Abdeckung, vielfältigen Formen und langen Lebenszyklus" ist Spec besonders schwer zu standardisieren.

In dieser Runde von Diskussionen über Spec-gesteuerte Entwicklung wird Kiro oft als einer der wichtigen Förderer angesehen. Sein technischer Leiter, Al Harris, hat in einer öffentlichen Präsentation erwähnt, dass das Team intern etwa sieben verschiedene Implementierungen ausprobiert hat, um eine geeignete Spec-Form zu finden - von der flüchtigen Spec über die hierarchische Spec bis zur TDD-basierten Spec, fast "jedem Ding einen Spec-Suffix hinzuzufügen". Am Ende haben sie wiederholt drei Fragen beantwortet: Wann sollte die Spec "festgelegt" werden, wie detailliert sollte sie sein und wie kann sichergestellt werden, dass der festgelegte Inhalt während der Iteration unverändert bleibt?

Dennoch hat er auch betont, dass die Umsetzung dieser Spec-gesteuerten Entwicklung noch in der Entwicklung ist, und die Richtung, auf die sie sich letztendlich einlassen möchten, ist, dass die Spec die gesamte SDLC-Kette abdeckt, einschließlich Anforderungen, Entwurf, Aufgabenzerlegung und sogar Überprüfungsmechanismen, um die Strenge der traditionellen Softwaretechnik in die KI-Entwicklung zurückzubringen.

Hinter diesem liegt eine zentrale Frage, der man nicht ausweichen kann: Spec muss die Komplexität bewältigen, die in der Softwaretechnik über Jahrzehnte angesammelt wurde.

Nach der Ansicht von Huang Guangmin, dem Produktmanager von CodeBuddy, ist der Standard von Spec im Wesentlichen die Konkretisierung der Softwaretechniktheorie in KI-Programmiertools.

Das Problem ist jedoch, dass die Softwaretechniktheorie nach Jahren der Entwicklung keinen einheitlichen Standard gebildet hat, der in der Produktionspraxis universell angewendet werden kann. Daher wägen verschiedene Spec-Varianten tatsächlich verschiedene Widersprüche ab (wie Flexibilität und Strenge), und die optimale Granularität variiert auch je nach Aufgabe.

Er ist der Meinung, dass die Wirksamkeit des Spec-Standards tatsächlich vom Anwendungsfall abhängt, denn Spec nutzt im Wesentlichen ein Dokument/Struktur, um drei Dinge auszutauschen: Korrektheit, Effizienz und Wartungskosten. Verschiedene Szenarien geben diesen drei Faktoren unterschiedliche Gewichtungen, daher wird es keinen einzigen Standard geben, sondern mehrere Formen mit relativ hoher Akzeptanz.

Ist Spec eine Rückkehr des "eliminierten" Wasserfallmodells?

Die Softwaretechnik ist ein hochgradig ungewisser und komplexer System. Bei langfristigen Aufgaben können große Modelle Halluzinationen haben, vergessen oder ein Zielverschieben erfahren; wenn es keinen Mechanismus zur Kompensation gibt, wird der Agent wahrscheinlich immer stärker abweichen, und die Neuarbeitskosten werden schnell steigen. Dies ist der Grund, warum Spec wieder attraktiv geworden ist - sie versucht, die Schlüsselziele, die Beschränkungen und die Akzeptanzkriterien deutlicher festzulegen.

Aber auch Kontroversen folgen. Ein Agile-Praktiker hat einmal direkt gesagt, dass die Richtung von SDD falsch sei. Nach seiner Ansicht versucht diese Methode, ein Problem zu lösen, das bereits als unausführbar bewiesen wurde: Wie können Entwickler aus dem Softwareentwicklungsprozess eliminiert werden? In diesem Szenario werden Programmier-Agenten eingesetzt, um die Entwickler zu ersetzen, und durch sorgfältige Planung wird sichergestellt, dass die Agenten dieses Ziel erreichen können. Dies ist fast dasselbe wie die Anforderungen des Wasserfallmodells: Die Erledigung einer großen Menge an Dokumentationsarbeit vor der Codierung, und die Entwickler müssen nur die Spezifikationen in Code umwandeln.

Das Problem ist, dass die Softwareentwicklung ein nicht-deterministischer Prozess ist, und die Planung kann die Unsicherheit nicht beseitigen, wie in der klassischen Abhandlung "No Silver Bullet" festgestellt wurde. Agile Methoden haben die Entwicklungsansätze, die auf einer großen Menge an vorab erstellten Dokumenten basieren, schon lange eliminiert. Also, wird die AI Coding zu einer "Rückkehr des Wasserfallprozesses" führen?

Wenn man Spec aus technischer Sicht diskutiert, liegt der gemeinsame Schwerpunkt nicht auf "ob alle Gedanken niedergeschrieben werden sollten", sondern auf "welcher Teil strukturiert werden sollte". Nach Huang Guangmins Ansicht will das Spec-Coding tatsächlich nicht den gesamten Denkprozess der Entwickler strukturieren, sondern jene Teile, die in langfristigen Aufgaben am wahrscheinlichsten fehlerhaft sind und am meisten einer Überprüfung und Niederschrift wert sind.

Die Branche befindet sich derzeit in der Erkundungsphase von Spec. Eine vernünftigere Form von Spec ist ein "lebendiger Vertrag". Es ist kein statisches, einmaliges Dokument, sondern ein wichtiger Zwischenzustand in der Plan-Ausführung-Schleife: Eine gute Spec-gesteuerte Praxis besteht nicht darin, "zuerst ein perfektes Spec zu schreiben und dann mit der Codeentwicklung zu beginnen", sondern die Spec zu nutzen, um die Korrektheitskriterien zu klären und dann die Übereinstimmung zwischen der Spec und den