Gespräch mit Anthropic über die Zukunft der Softwareentwicklung
Das Übersetzungsbüro von Shenyi ist das Übersetzungsteam von 36Kr. Es setzt sich für Technologie, Geschäft, Arbeitsplatz und Lebensbereiche ein und stellt vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vor.
Herausgeberhinweis: Wenn die KI-Prüfung zuverlässiger ist als die menschliche, werden Programmierer zu "Hirten von Intelligenzagenten". Die Zeit der kumulativen Rendite in der Softwareentwicklung ist angebrochen, und die Barrieren im SaaS-Bereich werden abgebaut. Dieser Artikel ist eine Übersetzung.
Neuerdings habe ich zusammen mit Sivesh und Ash Prabaker von Anthropic eine Runde Tische über die Zukunft der Softwareentwicklung moderiert. Anwesend waren auch die Leiter der Ingenieurabteilungen von Stripe, NVIDIA, Microsoft, Google DeepMind, xAI, Apple und Scale AI sowie der Legende Peter Steinberger von OpenClaw/OpenAI.
Der Ursprung von Claude Code
Die Sitzung begann mit der Wiederholung der Ursprungsgeschichte von Claude Code, von der ein Großteil in öffentlichen Interviews bereits erwähnt wurde. Das Projekt begann Ende 2024 mit einer einfachen Terminal-Benutzeroberfläche (Terminal UI), die zunächst sehr rudimentär war. Das zentrale Prinzip bei der Entwicklung war: Entwurf für die erwarteten Fähigkeiten des Modells in 6 bis 12 Monaten, nicht begrenzt durch den damaligen Stand. Seine Verbreitung erfolgte spontan - es war ein Projekt, das von den unteren Ebenen der Ingenieure (IC) getrieben wurde und sich durch den tatsächlichen Nutzen, nicht durch administrative Anordnungen, massenhaft durchsetzte.
Die Theorie der rekursiven Verbesserung
Eine durchgängige Linie in der gesamten Diskussion war die "geschlossene Schleife" in der Entwicklung. Ein Teilnehmer beschrieb den Prozess seiner Firma: Fehlerberichte werden von Intelligenzagenten automatisch sortiert, nach Schweregrad kategorisiert, anhand einer Bewertungsmenge (Eval set) überprüft und dann direkt wird ein Reparatur-PR (Pull-Request) eröffnet - der gesamte Prozess erfordert fast keine menschliche Intervention. Es wurde allgemein einverstanden, dass diese geschlossene Schleife der wahre Ursprung der kumulativen Rendite ist - bessere Programmierwerkzeuge verbessern das Modell, und ein besseres Modell wiederum optimiert die Programmierwerkzeuge. Mehrere Leiter wiesen darauf hin, dass ihre Firmen aufgrund dieser positiven Dynamik Programmieraufgaben als Vorrang aufgaben.
Die Veränderung des Arbeitsablaufs
Die Teilnehmer tauschten sich über die Veränderungen in ihren jeweiligen Ingenieurpraktiken aus:
Testen als erstes ist jetzt die Standardvorgehensweise. Mehrere Personen sagten, dass sie jetzt zuerst Testfälle definieren und dann den Intelligenzagenten anweisen, um diese Fälle zu implementieren - sie sind der Meinung, dass dies angesichts der großen Anzahl von PRs die einzige vernünftige Vorgehensweise ist.
Zweistufiges Bewertungssystem. Ein Teilnehmer skizzierte die Methode seines Teams: Einmal die Regressionsbewertung (Regression evals), die in jedem PR 100 %ige Durchfallquote aufweisen muss; und zweitens die Bewertung für neue Fähigkeiten (Frontier evals). Die anderen Anwesenden stimmten dieser Methode zu.
Keine Zwangsförderung. Dies traf auf starke Zustimmung. Ein Teilnehmer erwähnte, dass sie durch Wettbewerbe, Hackathons und informelle Belohnungen die Nutzung fördern, statt von oben herab Zwangsmaßnahmen zu ergreifen. Er ist der Meinung, dass Zwangsmaßnahmen Widerspruch hervorrufen, während es den Mitarbeitern hilft, die Ergebnisse der frühen Anwender zu sehen, um die Verbreitung der Werkzeuge auf natürliche Weise zu fördern.
Der Code-Review befindet sich in Bewegung. Ein Teilnehmer gestand, dass die Entwickler in seiner Firma oft binnen wenigen Minuten die Genehmigung geben, weil die KI-Review-Schicht bereits hervorragend funktioniert. Als gefragt wurde, wohin es am Ende gehen würde, gaben sie zu, dass das Modell, dass "es muss von Menschen überprüft werden", am Ende unwirtschaftlich werden würde und andeuteten, dass in einigen Code-Repositories (Repos) sie möglicherweise bereits jenen Punkt überschritten haben. Dies stimmte die Anwesenden sowohl an als auch hinterließ einen leisen Unbehagen.
Die Rückkehr der Kommentare. Mehrere Teilnehmer bemerkten eine interessante kulturelle Umkehr: Anfangs hassten die Ingenieure die langen Kommentare, die von Intelligenzagenten generiert wurden, aber jetzt ist die Meinung dahingehend, diese Kommentare beizubehalten, weil der nächste Intelligenzagent sie bei der Aufgabe sehr nützlich finden wird. Jemand fasste es zusammen: "Wir schreiben jetzt Code sowohl für Menschen als auch für KI zu verstehen."
Das Leben im Terminal. Ein Teilnehmer beschrieb seinen persönlichen Arbeitsablauf: Planung, Planüberprüfung, Ausführung durch den Intelligenzagenten und dann Weitergehen zur nächsten Aufgabe - ohne den generierten Code Zeile für Zeile zu lesen. Dies führte zu einer Debatte darüber, wann diese Vorgehensweise sicher und wann gefährlich ist.
Bereiche, die noch streng überprüft werden müssen
Nicht allen Code sollte gleich behandelt werden. Die Teilnehmer waren sich einig, dass jeder Code, der destruktive Operationen (wie Datenverlust, Erhöhung von Rechten) oder Kerninfrastruktur betrifft, einer intensiveren menschlichen Überprüfung bedarf, während interne Prototypen nicht den gleichen Standards wie öffentlich zugänglicher Code genügen müssen. Wo die Grenze genau liegt, variiert von Firma zu Firma.
Die Engstelle: Langfristige Aufgaben
Es wurde allgemein einverstanden, dass langfristige Aufgaben (Long-horizon tasks) die echte Herausforderung darstellen. Ein Teilnehmer wies darauf hin, dass zwar die Produktentwicklung exponentiell wächst, aber es bisher nicht gelungen ist, eine geschlossene Schleife in komplexeren wissenschaftlichen Arbeitsabläufen zu erreichen. Die offene Frage, der alle gemeinsam gegenüberstehen, lautet: Welche Aufgabe soll man einem Intelligenzagenten zuweisen, der vier oder fünf Stunden lang läuft? Wie beobachtet man ihn? Wie bleibt man "beteiligt", ohne ständig auf ihn zu achten? Bisher hat noch niemand eine perfekte Antwort.
Infrastruktur und Sandbox-Mechanismus
Die Diskussion berührte die Veränderung der Einstellung der Branche gegenüber Sandboxing - zunächst tendierte man aus Sicherheitsgründen zu Sandboxing, später verzichtete man aus Gründen der Bequemlichkeit darauf, und jetzt kehrt man mit mehr Details zurück (z. B. Remote-Programmierintelligenzagenten, unabhängige Sandboxen für einzelne Sitzungen). Die praktischen Probleme, die genannt wurden, umfassen den Rechenleistungskonsum bei langen Sitzungen, die Rechteverwaltung und die Unternehmensbereitstellung.
Observabilität und Bereitschaftsdienst
Ein Teilnehmer beschrieb einen frühen internen Prototypen: Ein Intelligenzagent mit Zugang zu Logs, Quellcodeverwaltung und Chat-System kann die Sortierung und das Debugging von Ausfällen handhaben - obwohl das System noch nicht produktionsreif ist, hat es die Last des Bereitschaftsdienstes (On-call) verringert. Mehrere Teilnehmer bemerkten einen interessanten Nebeneffekt: Ingenieure ohne Infrastrukturhintergrund können jetzt auch an Infrastrukturarbeiten teilnehmen, weil der Intelligenzagent ihre Wissenslücken füllt.
Kontextverwaltung
Jemand fragte, wie man den Kontext bei Tausenden von Personen, die jede Minute den Code ändern, in großem Maßstab verwalten kann. Die ehrlichen Antworten der Anwesenden waren: Niemand hat das wirklich verstanden. Ein Teilnehmer gestand, dass ihre Methode im Wesentlichen fragmentiert ist - der Intelligenzagent liest temporäre Chatprotokolle über das MCP (Modellkontextprotokoll) und sie verlassen sich auf eine starke Schreibkultur, aber es gibt keinen formellen dokumentierten Prozess.
Bei der Sitzung wurde eine Studie erwähnt, die zeigte, dass vordefinierte Markdown-Kontextdateien manchmal weniger effektiv sind als wenn der Intelligenzagent den Code basisierend auf Grundprinzipien durchsucht. Die Gegenmeinung war, dass dies möglicherweise auf veraltete oder von KI generierte Kontextinhalte zurückzuführen ist. Es wurde einig, dass von Menschen geschriebene Kontextdateien nützlich sind, während von KI generierte oder veraltete Dateien möglicherweise kontraproduktiv sein können. Menschen müssen die Kernaussagen liefern.
Personalrekrutierung
Beim Thema Rekrutierung war die auffälligste Meinung: Ein Teilnehmer sucht jetzt nicht mehr nach ursprünglichen Ingenieursfähigkeiten, sondern nach der Bereitschaft, sich ständig mit den neuesten Technologien auseinanderzusetzen. Ihre besten Mitarbeiter sind diejenigen, die die Grenzen der Modelle gut verstehen und wissen, wann sie dem Output vertrauen und wann sie manuell eingreifen sollten. Ein anderer Teilnehmer wies darauf hin, dass aufgrund der KI-unterstützten interdisziplinären Zusammenarbeit ihr Kerninfrastrukturteam schlank bleibt und Produktingenieure auch außerhalb der traditionellen Bereiche beitragen können.
Das SaaS-Bereich unter Druck
Die Diskussion in diesem Teil war sehr lebhaft. Die Teilnehmer teilten die Tool-Kategorien, die sie intern bereits ersetzt haben, mit:
Ereignisverwaltung - jemand sagte, dass sein Team das Tool des Anbieters entfernt hat, weil es für die tatsächliche Arbeitsweise zu komplex war.
Autorisierungsschicht - ein Teilnehmer behauptete, dass er das Autorisierungssystem innerhalb von sechs Monaten mehrmals migriert hat, wobei jede Migration nur Stunden und nicht Wochen dauerte.
Projektverfolgung - jemand entwickelt eine maßgeschneiderte Benutzeroberfläche auf Basis von Programmierintelligenzagenten, um Ingenieuraufgaben zu verwalten, und deutete an, dass diese gesamte Kategorie möglicherweise das nächste Opfer sein könnte.
Interne Mikrowerkzeuge - Kurzlink-Generatoren und ähnliche Tools wurden von mehreren Personen als "leicht erreichbare Siege" erwähnt.
Man bemerkte ein Muster: Bisher wurden nur Entwicklerwerkzeuge ersetzt, weil die Ingenieure in diesen Bereichen Entscheidungsgewalt und Durchführungsgeschwindigkeit haben. Geschäftsorientierte Software (wie CRM usw.) ist fester verankert. Eine Meinung ist, dass die bestehenden Geschäftswerkzeuge nicht deshalb überleben, weil sie gut funktionieren, sondern weil noch niemand ein einfallsreiches KI-ursprüngliches Ersatzprodukt entwickelt hat - bisher gibt es nur einige inkrementelle Plugins.
Eine Gegenmeinung im Raum war: Das Argument der Opportunitätskosten ("Wir sollten uns auf das konzentrieren, was wir am besten können") könnte immer gelten, was bedeutet, dass Modelllaboratorien möglicherweise nie die Entwicklung von SaaS-Ersatzprodukten vor der Verbesserung der Modelle stellen.
Probleme durch die "Alles ist möglich"-Situation
Ein Gründer eines Start - Ups brachte die Gegenmeinung vor: Da die KI alles möglich macht, wird es schwieriger, Prioritäten zu setzen. Vor sechs Monaten hätte es offensichtlich nicht lohnenswert sein müssen, ein Tool intern neu zu bauen; jetzt braucht es nur eine Nacht. Weil es so viel zu tun gibt, sind die Teams überfordert. Außer die Definition klarer "Spuren" und die Behandlung der Einzelpersonen als "Mini - Firmen"-Eigentümer innerhalb der Organisation konnte niemand eine bessere Lösung anbieten.
Code - Qualität
Als jemand nach den Code - Qualitätsstandards fragte, wurde ihm gesagt, dass sich deren Definition ändert. "Guter Code" bedeutete früher, dass er menschenorientiert war - einfach, leicht zu warten und zu erweitern. Jetzt muss er auch die Lesbarkeit für KI berücksichtigen. Die praktische Meinung im Raum war: Starke Regressionsbewertungen und das Prinzip "Testen zuerst" sind wichtiger als das Ästhetik - Konzept von "sauberem Code".
Design - Geschmack und Schrott
Der "lila Farbverlauf - Stil" löste Gelächter aus - alle kannten diese typische von KI generierte UI - Ästhetik. Jemand wies auf eine Zwickmühle hin: Wenn man die Geschmacksvorlieben des Modells aktualisiert, werden alle es nutzen, und diese neue Ästhetik wird schnell zur nächsten Generation von "KI - Schrott". Auch wurde bemerkt, dass einige Modelle die Benutzer aktiv zu bestimmten Frameworks leiten, was tatsächlich eine Lock - in - Wirkung erzeugt.
Risiko der Konvergenz
Ein Teilnehmer befürchtete, dass, wenn alle dasselbe Modell zum Programmieren nutzen und denselben Ratschlägen folgen, die gesamte Branche in die Homogenität von Werkzeugen und Mustern gerät. Die Gegenmeinung war, dass dieses Risiko in den frühen Modellen größer war, weil damals die Modelle in beliebten Web - Technologiestapeln viel stärker waren als in alten Systemen oder seltenen Sprachen - und jetzt diese Lücke schrumpft. Die Modernisierung von Code in alten Systemen wird als ein Bereich angesehen, in dem es sehr schnelle Fortschritte gibt.
Hintergrund - Intelligenzagenten
Es wurde allgemein einverstanden, dass die Entwicklung in Richtung asynchroner Hintergrund - Intelligenzagenten geht - diese laufen in Remote - Sandboxen, können über das Mobiltelefon überwacht werden und können stunden- oder sogar tagelang laufen. Jemand erwähnte, dass das stundenlange eigenständige Laufen erst kürzlich zu seiner normalen Praxis geworden ist, bevor es noch in der Experimentierphase war.
Modell vs. Rahmen (Harness)
Als gefragt wurde, wie viel der jüngsten Verbesserungen auf die Modellgewichte und wie viel auf den externen Rahmen (Harness) zurückzuführen ist, war die Meinung eines Teilnehmers, dass beide wichtig sind, aber mit unterschiedlicher Geschwindigkeit - die großen Sprünge kommen von den Fortschritten des Modells, und die Design - Philosophie des Rahmens sollte sein, "dem Modell nicht im Weg zu stehen". Sie beschrieb ein minimalistischen Prototyp - im Wesentlichen das aktuelle Modellgeneration mit Systemhinweisen und Bash - Zugang - der erstaunlich gut funktioniert, was bei den Modellen aus einigen Generationen zurück unmöglich gewesen wäre.
Regulierte Branchen
Eine Person mit Hintergrund in der Fintech - Branche fragte nach der Bereitstellung in einer regulierten Umgebung. Die Interpretation im Raum war: Die erfolgreichsten KI - Start - Ups in regulierten Branchen (z. B. Rechtstechnologie) sind im Wesentlichen noch "menschlich betriebene" Dokument - Dialog - Produkte. In regulierten Arbeitsabläufen hat noch niemand den Sprung zu eigenständigen Intelligenzagenten geschafft. Die Hürde hier ist asymmetrisch - ähnlich wie bei der autonomen Fahrweise muss die KI viel besser als der Mensch sein, um akzeptiert zu werden. Bessere Interpretierbarkeit und strukturierte Prüfverfolgung werden als der Schlüssel für diesen Bereich angesehen.