Verstehst du es nicht, wirf es weg: Die KI-Programmierprinzipien eines Chefarchitekten

Am 19. Oktober wurde MiniMax M3.1 Flash veröffentlicht; am 17. Oktober erfolgte die Aktualisierung von DeepSeek-V4.1-Flash-1017. Einige Tage davor brachte Meta Muse Spark Open auf den Markt; OpenAI aktualisierte die parallele Agent-Fähigkeit von GPT-6 Pro; auch Google stellte Gemini 4 Argon für komplexe Aufgaben vor……

Die Iteration von Modellen wird immer schneller, und KI-Programmierwerkzeuge verändern ständig die Arbeitsweise von Entwicklern. Das Generieren von Code, das Erstellen von Websites und die Entwicklung von Spielen lassen sich heute mit nur wenigen Gesprächsrunden abschließen. Aber bedeutet schnelleres Schreiben von Code auch, dass Software einfacher herzustellen ist?

In dem Podcast *Beyond Coding* stellte der Moderator Patrick Akil dem Chefarchitekten Carlos Kelkboom eine Frage: Was ist die offensichtlichste Veränderung in der Softwaretechnik im Vergleich zu vor einigen Jahren?

Carlos antwortete: „Ich habe ein Phänomen bemerkt, das mir nicht sehr gefällt: Die Zusammenarbeit zwischen Entwicklern nimmt ab. Du arbeitest mit deinem eigenen Agenten, aber nicht mehr mit dem Team.“

Die durch KI verursachten Veränderungen im Programmierbereich gehen längst über die Codegenerierung selbst hinaus. Wie man die Codequalität kontrolliert, verschiedene Agenten zur kooperativen Arbeit anweist und gleichzeitig die ingenieurtechnische Urteilskraft bei gesteigerter Effizienz behält, sind alles neue Probleme, mit denen sich Entwickler auseinandersetzen müssen.

Zu diesen Problemen teilte Carlos seine praktischen Erfahrungen mit. Die von ihm zusammengefassten fünf Prinzipien bieten eine konkrete Perspektive zum Verständnis der KI-Programmierung:

1. Baue das Code-Gerüst persönlich auf und lege im Voraus Verzeichnisse, Schlüsseldateien und Funktionssignaturen fest.

2. Es ist verboten, dass der Haupt-Agent Code und Dateien direkt ändert. Erst nachdem die Anforderungen vollständig verstanden wurden, darf der Ausführungs-Agent gestartet werden.

3. Wenn der generierte Code nicht verstanden wird, wirf ihn weg. Die Ausführungsergebnisse werden im Arbeitsbaum isoliert. Sobald eine Abweichung von der erwarteten Struktur festgestellt wird, wird er direkt verworfen und neu begonnen.

4. Lasse den Agenten nach Möglichkeit größere Aufgaben in einem Zug erledigen, um wiederholte Änderungen zu vermeiden, die dazu führen, dass der Code ständig mit Patches versehen wird.

5. Lasse mehrere Agenten parallel verschiedene Lösungen erkunden, zum Beispiel drei Agenten, die jeweils entwickeln, dann lässt ein vierter Agent die Ergebnisse vergleichen und nur die guten Teile zusammenführen.

KI ist nur der Ausgangspunkt des Projekt-Marathons

Vor dem Hintergrund abnehmender Zusammenarbeit gibt es ein noch direkteres Problem: KI macht es einfach, Projekte zu starten, aber es macht es nicht ebenso einfach, Projekte abzuschließen. Der Moderator hat ähnliche Erfahrungen gemacht: Er stellte fest, dass er viele Projekte leicht starten, sie aber oft nicht abschließen kann.

Carlos hat einmal fünf Compiler-Projekte gestartet, von denen am Ende nur eines wirklich abgeschlossen wurde. Dass Projekte begonnen, aber nicht abgeschlossen werden, ist kein Phänomen, das erst im KI-Zeitalter auftritt. Wenn Entwickler ein Produkt herstellen wollen, dürfen sie nicht in der Phase ständiger Versuche steckenbleiben.

Carlos verwendete den Vergleich von Marathon und Sprint: „Etwas schnell zu machen, aber es nicht abzuschließen, ist etwas anderes als etwas zu machen, das hoffentlich lange Bestand hat. Wenn man ein Projekt alleine durchführt, geht man normalerweise nicht den zusätzlichen Schritt, um es wirklich abzuschließen.“

Carlos nahm die Spieleentwicklung als weiteres Beispiel: „Man sieht zum Beispiel viele Leute, die Spiele „schnell“ machen. Ich setze „schnell“ in Anführungszeichen, weil das größte Problem bei der Spieleentwicklung darin besteht, die Meinungen der Nutzer zu berücksichtigen und das Spieldesign gut zu gestalten. Du kannst mit dem intelligenten Agenten iterieren, aber du musst trotzdem mit der Außenwelt kommunizieren.“

Da die Generierung von Code immer einfacher wird, können Entwickler leicht ein erstes Ergebnis erzielen. Aber sie sind nicht immer bereit, kontinuierlich Zeit zu investieren, um nachfolgende ingenieurtechnische Probleme zu lösen. Carlos ermahnte Entwickler: „Du musst dem Dopamin-Gefühl widerstehen, sofort etwas zu bekommen, sobald du beginnst.“

Lege zuerst Regeln für die Agenten fest, bevor du mit der Arbeit beginnst

Wenn das schnelle Starten von Projekten der Vorteil ist, den die KI-Programmierung mit sich bringt, dann wird die Frage, wie man Projekte kontinuierlich iterieren lassen kann, zu dem Problem, dem Carlos mehr Aufmerksamkeit schenkt.

Carlos stellte seinen Arbeitsablauf vor: Vor Beginn der Entwicklung erstellt er manuell Verzeichnisse und Dateien, manchmal ergänzt er auch Sprachspezifikationen, Codebeispiele und die Beziehungen zwischen Modulen. Der gesamte Prozess dauert normalerweise 20 Minuten bis eine Stunde.

Er nennt diesen Schritt Scaffolding, also das Aufbauen eines Gerüsts: „Wenn ich zum Beispiel einen Compiler schreiben will, erstelle ich zuerst die Verzeichnisse, schreibe den Lexer und dann ein paar Sprachspezifikationen. Ich lege die Verzeichnisstruktur fest, wie die Zwischenrepräsentation den ganzen Weg vom abstrakten Syntaxbaum durchläuft, und schreibe viele Beispiele in der Zielsprache. Danach generiert der Agent direkt einen Compiler, der genau zu dieser Sprache passt, wie ein Meister.“

Er erklärte den Grund dafür: „Ich habe festgestellt, dass Agenten sehr gut darin sind, mit roher Kraft eine Lösung zu finden, aber sie vergessen oft, wie diese Lösung in die gesamte Anwendung integriert werden soll.“

Carlos hat einmal versucht, den Agenten direkt von Grund auf eine Anwendung entwickeln zu lassen. Nachdem das Projekt ein bis zwei Monate vorangekommen war, stellte er fest, dass der Code immer schwerer zu verstehen war, die ursprünglichen Bereitstellungsskripte durch andere Skripte ersetzt wurden und der Zweck einiger neuer Skripte nicht mehr bekannt war.

Carlos empfiehlt, bei unbekannten Bereichen zuerst einige ausgereifte Open-Source-Projekte zu finden, den Agenten dabei zu helfen, die ausgezeichneten Entwurfsmuster darin zu extrahieren, und nachdem man sie verstanden hat, schrittweise das Gerüst aufzubauen, beginnend mit einer kleinen Konzeptprüfung, und den Agenten dabei zu helfen, zu überprüfen, ob das Design vernünftig ist.

Auf der Grundlage eines klaren frühen Rahmens neigt Carlos dazu, die vollständigen Funktionen im Voraus zu planen und dann den Agenten größere Aufgaben in einem Zug erledigen zu lassen.

„Agenten sind nicht gut im Ändern, aber gut darin, Dinge in einem Zug abzuschließen. Ihr Training scheint eher auf einmalige Aufgaben ausgerichtet zu sein als auf iteratives Entwickeln auf einer Codebasis“, sagte Carlos. „Das ist genau der Punkt, an dem das Gerüst seine Wirkung entfaltet: Die meisten Dinge sind bereits festgelegt.“

Natürlich vertritt Carlos nicht die Ansicht, dass alle Projekte genauso viel Vorbereitungszeit erfordern. Wenn man nur eine Idee überprüfen will, können Entwickler völlig schnell versuchen, und sobald die Richtung nicht stimmt, sofort neu beginnen.

Er teilte eine Methode der parallelen Erkundung mit: „Erstelle drei Zweige und lasse drei intelligente Agenten ihre Arbeit jeweils in drei Zweigen oder Arbeitsbäumen erledigen. Dann lässt du einen vierten Agenten die drei Ergebnisse vergleichen und nur die guten Teile davon zusammenführen.“

Code, den du nicht verstehst, wirf ihn direkt weg

KI kann schnell Code generieren und ihn auch kontinuierlich basierend auf Feedback ändern. Aber mit der Erweiterung des Projektumfangs häufen sich Probleme wie doppelte Implementierungen, chaotische Module und Abweichungen von der Architektur allmählich an.

Carlos ließ einmal einen Agenten einen Compiler entwickeln. Einen Monat später ließ er den Agenten die Listenfunktion überprüfen und stellte fest, dass dieselbe Funktion fünfmal dupliziert implementiert wurde. Jede Änderung mag das unmittelbare Problem gelöst haben, aber nach wiederholtem Überlagern wird der Code immer schwerer zu warten.

Daher überprüft er regelmäßig, ob der Code den Erwartungen entspricht. Wenn die Implementierungsrichtung abweicht, zieht er es vor, zurückzugehen und neu zu beginnen, statt auf der fehlerhaften Grundlage weiter Patches anzubringen.

Carlos drückte es sehr direkt aus: „Sie sind derzeit noch nicht gut darin, eine vollständige Anwendung aufzubauen.“ Er hat noch ein weiteres Kriterium: „Wenn ich es nicht verstehe, werfe ich es weg“.

Das hier gemeinte „nicht verstehen“ bedeutet, dass der Code von der ursprünglich festgelegten Struktur und den Erwartungen abgewichen ist. Carlos überprüft zuerst, ob die Implementierung dem Design entspricht; wenn die Schlüsselteile nicht übereinstimmen, geht er zum aktuellen Ergebnis zurück, klärt die Anforderungen und das Gerüst neu und startet dann eine neue Runde von Aufgaben.

In China hat das technische Team von Meituan im Mai dieses Jahres eine ingenieurtechnische Praxis veröffentlicht. Das von ihm verantwortliche Geschäftssystem hat einen Umfang von 310.000 Codezeilen, von denen über 90 % von KI generiert wurden. Mit der schnellen Erweiterung des Systems stellte das Team fest, dass ohne einheitliche Architekturspezifikationen der von verschiedenen Entwicklern mithilfe von KI generierte Code die Komplexität des Systems verschärft und die historischen technischen Schulden die nachfolgende Iteration verlangsamen werden.

Aus diesem Grund wandelte das Team die ingenieurtechnischen Spezifikationen in Regeln um, die von KI ausgeführt werden können, und fügte vor der Codeübermittlung einen KI-Selbstprüfungslink hinzu, sodass das Modell zuerst die Spezifikationen, Mängel und Ausnahmebehandlungen überprüft, bevor die Ingenieure sich auf die Prüfung der Geschäftslogik und technischen Lösungen konzentrieren.

Einzelentwickler kontrollieren die Codequalität durch stufenweise Überprüfungen, während Unternehmensteams die Spezifikationen in automatisierte Prüf- und Überprüfungsverfahren umsetzen müssen. Dies zeigt, dass nach der Steigerung der Codegenerierungsgeschwindigkeit die Qualitätsprüfung Schritt halten muss.

Da ein Agent auf einmal eine große Menge Code generieren kann, steht auch die Überprüfung unter neuem Druck. Carlos' Vorschlag lautet, den normalen Iterations- und Überprüfungsablauf beizubehalten. „Die Leute nennen oft die zu große Codemenge als Grund. Aber wenn es zu viel Code gibt, warum lässt du den Agenten nicht weniger schreiben?“

Anstatt nach der Generierung einer großen Menge Code auf einmal konzentriert zu prüfen, ist es besser, den Umfang jeder Änderung zu kontrollieren, mehr Überprüfungspunkte hinzuzufügen und die Diskussion zwischen den Entwicklern beizubehalten. So lassen sich Probleme leichter erkennen, und das Team kann verstehen, warum sich der Code geändert hat.

Der Haupt-Agent schreibt keinen Code, er ist nur dafür verantwortlich, deine Anforderungen zu verstehen

Carlos hat auch einen speziellen Agenten-Arbeitsablauf entworfen: Der Haupt-Agent, mit dem man direkt spricht, ändert keinen Code und greift nicht auf das Dateisystem zu, er ist nur für die Interaktion zuständig. Wenn die eigentliche Arbeit erledigt werden soll, werden Unter-Agenten entsandt. Gleichzeitig läuft eine weitere Schleife eines Haupt-Agenten mit demselben Verhalten.

Der Moderator war verwirrt: „Warum ist es standardmäßig nicht erlaubt, dass der Haupt-Agent irgendwelche Dateien ändert? Das Ändern von Dateien ist genau das, was sie können, und sie sind sehr initiativ dabei. Du verbietest es ihnen bewusst, warum?“

Carlos sagte: „Weil ich will, dass er sich auf die Frage konzentriert, die ich wirklich stelle.“ Er hat einmal bei der Spieleentwicklung die KI gefragt, was sie von John Cleeses Rede über das „offene Modus“ und „geschlossene Modus“ der Kreativität hält. Daraufhin fragte die KI Carlos: „Soll ich das in deinem Projekt implementieren?“

Ihm wurde plötzlich klar: „Wenn der Agent alle Probleme nur unter dem Gesichtspunkt betrachtet: ‚Kann ich jetzt Code für dich schreiben?‘, wie kann ich dann jemals eine gute Antwort bekommen?“ Daher setzte er den Haupt-Agenten als eine Rolle ein, die standardmäßig keine Dateien ändert. Dieser Agent ist für Diskussionen, Erklärungen und Klärung von Anforderungen zuständig und kann auch Unter-Agenten aufrufen, um die eigentliche Arbeit zu erledigen.

Um zu vermeiden, dass der Agent mit der Ausführung beginnt, bevor er die Aufgabe vollständig verstanden hat, führte Carlos einen Mechanismus zur Bewertung des Konfidenzniveaus ein. Nur wenn das System feststellt, dass sein Verständnis der Anforderung über 90 % liegt, darf der Unter-Agent gestartet werden. „Sobald der Unter-Agent gestartet ist, kann er die Aufgabe direkt erledigen, auch wenn er zwölf Stunden läuft. Ich kann mehrere Agenten gleichzeitig starten, das ist mir egal. Aber bevor er absolut sicher ist, dass er mich versteht, darf er nicht anfangen.“

Dieser Ablauf stellt die Diskussion über die Anforderungen vor die Ausführung. Entwickler können zuerst Ziele, Designideen und Einschränkungen klar durchdenken, bevor sie den Agenten die Arbeit konzentriert erledigen lassen.

Eine völlig neue Programmiersprache

Carlos ist der Ansicht, dass „wir an einem Wendepunkt stehen, an dem wir eine neue Programmiersprache brauchen“. Er schlug vor, dass mehrere Probleme geändert werden müssen: Entferne den Heap-Speicher, Entwickler brauchen keine Zeiger mehr, keinen dynamischen Speicher und keine Dinge, die um sie herum entstehen.

Diese neue Sprache sollte in drei Ebenen unterteilt sein: Die erste Ebene dient Menschen zum Ausdrücken von Anforderungen, sie kann natürliche Sprache und strukturierte Syntax kombinieren, um Komponenten und ihre Funktionen zu beschreiben. Auf der zweiten Ebene kann das System visuelle Inhalte wie Diagramme und Videos generieren, damit Entwickler überprüfen können, wie das System das Ziel umsetzen will, und dann den Lösungsvorschlag weiter kommunizieren und anpassen. Auf der dritten Ebene wird das bestätigte Design dann in eine Darstellung umgewandelt, die von Maschinen ausgeführt werden kann, um die Bestimmtheit während des Laufvorgangs so weit wie möglich zu erhöhen.

Carlos meinte: „Wir müssen wieder zu einem Zustand zurückkehren, in dem wir schlussfolgern können, was tatsächlich auf dem Computer läuft, statt mit den heutigen unkontrollierbaren KI-ähnlichen Dingen konfrontiert zu sein.“

Warum ist eine deterministische Sprache so wichtig? Stell dir einen Satelliten vor, der in den Weltraum gestartet wird, sein Speicher ist begrenzt. Wenn das Programm Heap-Zuweisung verwendet, kann im Satelliten eine Ausnahme wegen unzureichenden Speichers oder eine Nullzeiger-Ausnahme auftreten. Wir betreten zunehmend Bereiche wie Robotik, Satelliten und maschinelles Lernen, also wollen wir, dass das System so deterministisch wie möglich ist.

Ist Kommunikation und Zusammenarbeit die zweite Sprache im Zeitalter des KI-Programmierens?

KI-Programmierung senkt die Eintrittsschwelle für die Entwicklung. Wenn immer mehr Code von Agenten generiert wird, müssen Entwickler dann noch Zeit darauf verwenden, Programmiersprachen, Frameworks und zugrundeliegende Prinzipien zu lernen?

Nach Ansicht von Carlos können Entwickler mit soliden