Das neue "Programmierungsparadigma" von OpenAI? Eigentlich ist es die Wiederauferstehung des Wasserfallmodells: "Höre auf die Worte des Projektmanagers und schreibe Anforderungsdokumente."

Bei der diesjährigen Konferenz für AI-Engineer hielt der Forscher von OpenAI, Sean Grove, einen Vortrag mit dem Titel "The New Code" (Das Neue Code). Manche halten es für "ein revolutionäres Konzept": In der AI-getriebenen Ära werden klare, menschenlesbare Spezifikationen (Specs) die traditionellen Codes ersetzen und zum Kernprodukt der Softwareentwicklung werden.

"Das Wesen des Programmierens ist die Kommunikation", meint Grove. Die Softwareentwicklung ist nie nur das Schreiben von Code gewesen. Ihr Kern ist eine strukturierte Kommunikation: Zunächst die Anforderungen verstehen, dann die Ziele klar definieren und schließlich diese Ideen klar an Teammitglieder und Computer weitergeben.

Grove betont, dass diese Wende von Code zu Spezifikationen nicht nur ein Update der Methodik ist, sondern die zukünftige Richtung der Ingenieurspraxis. Er weist darauf hin, dass Code an sich nur eine "verzerrte Wiedergabe" menschlicher Absichten ist und beim Übertragen von Ideen in die Realität Informationen verloren gehen oder verzerrt werden können. Die wirklich knappe Fähigkeit ist nicht mehr das Schreiben von Code, sondern wie man menschliche Absichten präzise in klare Spezifikationen und Prompts umsetzen kann.

Groves Worte haben auch in der technischen Community zu einer heftigen Diskussion geführt.

Ein Netizen kommentierte scharf: "Diese Denkweise bedeutet im Grunde, dass man sich mehr an die Worte des Produktmanagers halten soll", indem man bessere Spezifikationsdokumente schreibt, um den Entwicklungsprozess anzutreiben. Und aus Groves Beschreibung zu urteilen, wird der Ingenieur in dieser Art und Weise eigentlich zum "Produktmanager, der die Anforderungsdokumente pflegt".

Kurz gesagt, er möchte, dass man sich mehr an die Worte des Produktmanagers hält und die Anforderungsdokumente ständig verbessert.

Spezifikationen sind Anforderungsdokumente. Er befürwortet nicht direkt "Ambient Programming" oder Paarprogrammierung, sondern befürwortet, durch ständiges Aktualisieren der Anforderungsdokumente "Ambient Programming" mit intelligenten Agenten durchzuführen. Die Prompt-Engineering ist nicht obsolet. Der Titel ist schlecht gewählt (Anm. des Redakteurs: Dies war der ursprüngliche Titel des Videos, als es erstmals veröffentlicht wurde: "Prompt Engineering is Dead"). Er möchte nur, dass sie auf einem höheren Abstraktionsniveau angewendet und wiederverwendbar gemacht wird.

Im Idealfall sollen die Code-Schreiber in Produktmanager, die die Anforderungsdokumente pflegen, umgewandelt werden. Aber er hat keine Beweise dafür geliefert, dass diese Methode derzeit automatisch funktionieren kann. Er hat auch erwähnt, dass diese Anforderungsdokumente hauptsächlich für die Koordination von menschlichen Arbeitsabläufen gedacht sind. Er hat zwar den grundlegenden Aktualisierungsprozess beschrieben, den sie im 4o-Projekt verwendet haben, aber es gibt nichts Besonderes an dieser Vorgehensweise (wenn sich die Spezifikationsdokumente ändern, werden Bewertungsfunktionen hinzugefügt oder aktualisiert).

Andere Netizens stimmten zu und meinten, dass Groves Unterton sei: Die Rollen aller Menschen gleichen sich an, und jeder rückt in Richtung Produktmanager.

nomad_manhattan: Genau das tun Produktmanager seit langem - Benutzeranforderungen und -wünsche sammeln, Produktanforderungsdokumente (Spezifikationen) erstellen und mit allen Beteiligten Einigkeit über die Schlüsselerfolgsindikatoren (KPI) und Erfolgsmaße erzielen, während sie mit Datenwissenschaftlern und Ingenieuren über die Machbarkeit und die Arbeitsaufwände verhandeln. Was der Vortragende nicht klar gemacht hat, ist, dass die Rollen sich angleichen; jeder wird zum Produktmanager.

natenoonen2235: Die Agile Manifest wurde geschrieben, weil die Entwickler sich immer als Programmierer, nicht als Manager gesehen haben. Die AI bringt nichts Neues mit sich, sie bestätigt nur diejenigen, die seit langem für agiles Vorgehen, testgetriebene Entwicklung, verhaltensgetriebene Entwicklung und die Priorisierung von Ergebnissen gegenüber Prozessen plädieren. Wie bei jedem Werkzeug kommt es aber auf den Benutzer an, nicht auf das Werkzeug selbst.

Andere Netizens meinten ebenfalls, dass Groves Unterton sei, dass die Rollen aller Menschen sich angleichen und jeder in Richtung Produktmanager rücke.

Natürlich gab es auch Leute, die sich klar gegen die Aussage "Spezifikationen sind das neue Code" aussprachen: "Wenn deine App um drei Uhr nachts abstürzt, debuggst du immer noch den tatsächlichen Code, nicht die Markdown-Dokumente. Wenn die AI fehlerhaften Code generiert (was früher oder später passieren wird), was glaubst du, was wir reparieren müssen? Die Antwort ist einfach: Nicht die Spezifikationen. Der Code ist die endgültige ausführbare Wahrheit, alles andere ist nur eine schöne Vision."

Allerdings kann man nicht leugnen, dass der von Sean Grove skizzierte Weg der "Spezifikation-getriebenen Entwicklung" tatsächlich einen wichtigen Wendepunkt in der gegenwärtigen AI-Programmierung darstellt: Je stärker die Modelle werden und je einfacher es wird, Code zu schreiben, wird der Wert des menschlichen Programmierers möglicherweise von der "Radrerei" zur "Richtungsweisung" verschoben.

Hier sind einige Kernaussagen, die aus Groves Vortrag zusammengefasst wurden und die sehr nachdenklich machen:

• Die Engpässe in der Softwareentwicklung verschieben sich von der Code-Schreibung auf den Prozess der Spezifikations-Schreibung;
• Spezifikationen sind das "neue Code";
• Code ist nur eine verlustbehaftete Projektion der Spezifikationen;
• Der Code selbst enthält nicht die ursprüngliche Absicht, sondern ist eher ein "kompiliertes Produkt" der Absicht;
• Wenn man die Prompts weglässt und nur den Code behält, ist das wie wenn man den Quellcode weglässt und nur die Binärdateien behält;
• Ein gutes Spezifikationsdokument sollte in der Lage sein, Absichts-Konflikte zu entdecken, Strategiebeispiele bereitzustellen, Mehrdeutigkeiten zu kennzeichnen und die "Absicht" anstatt der Syntax auszudrücken;
• Wenn man die Spezifikationen wie Code schreibt, bedeutet das, dass jeder mitwirken kann;
• Die neuen IDEs werden ähnlich den bestehenden IDEs sein, aber der Fokus wird sich von der Typverwaltung, der Syntaxlogik, der automatischen Vervollständigung usw. auf die Unterstützung bei der Erstellung klarer Absichts-Dokumente, die Verwaltung von Absichts-Konflikten, die Hervorhebung von Mehrdeutigkeiten, das Testen, ob die erwarteten Ergebnisse mit der menschlichen Absicht übereinstimmen usw. verschieben;

Um Groves vollständige Überlegungen besser verstehen zu können, haben wir seinen Vortrag übersetzt:

Die "Neue Code"-Revolution: Vom traditionellen Code zu klaren Spezifikationen

Heute möchte ich mit Ihnen über die neue Zukunft des Programmierens sprechen - insbesondere über die neuen Spezifikationen. Dies repräsentiert auch die langjährige Hoffnung der gesamten Branche: Code einmalig durch die Ausdrucksweise der Absicht zu schreiben und dann überall ausführbar zu machen.

Mein Name ist Sean und ich arbeite bei OpenAI, speziell in der Bereich der Alignment-Forschung. Heute möchte ich über den Wert von Code und Kommunikation sprechen und warum wir neue Spezifikationen verwenden sollten, um dieses Ziel zu erreichen.

Im Folgenden werde ich am Beispiel der Modellspezifikation diskutieren, wie man die Absicht mit anderen Mitarbeitern kommuniziert, einschließlich des Problems, dass die Version 4.0 "zu gefällig" ist.

Der Diskussionsprozess wird sich auf die Umsetzung der Spezifikationen, die Weitergabe der Absicht an den Stab und die Umwandlung der Spezifikationen in Code beziehen. Am Ende werde ich auch einige offene Fragen teilen. Zunächst beginnen wir mit Code und Kommunikation.

Code macht nur 10 % aus, wo liegt der Wert der anderen 90 %?

Wenn Sie ein Programmierer sind, denken Sie vielleicht, dass der von Ihnen geschriebene Code das wertvollste Fachprodukt ist?

Das klingt wie Selbstverständlichkeit, schließlich versuchen wir mit Code, Probleme zu lösen. Wir kommunizieren mit anderen, sammeln Anforderungen, überlegen uns die Implementierungsdetails und fusionieren Informationen aus verschiedenen Quellen. Das Endergebnis ist der Code.

Code ist das, was wir manipulieren, messen und diskutieren können. Dennoch unterschätzt diese Denkweise in gewisser Weise die von uns geleistete Arbeit. Der Code macht tatsächlich nur 10 % bis 20 % des gesamten Wertschöpfungsprozesses aus, der Rest liegt in der strukturierten Kommunikation.

Die konkreten Umstände können unterschiedlich sein, aber der normale Ablauf sollte so sein: Zunächst kommunizieren wir mit den Benutzern, um ihre Herausforderungen zu verstehen. Wir ziehen Schlüsse aus ihrer Erzählung und überlegen uns, wie wir diese Probleme lösen können. Was sind die zu erreichenden Ziele? Dann planen wir die Methoden, um diese Ziele zu erreichen, und diskutieren dies weiter mit unseren Kollegen.

Dann wandeln wir diese Pläne in Code um. Dieser Prozess ist natürlich sehr wichtig. Dann folgt das Testen und Validieren - das hat nichts mit dem Code selbst zu tun, oder? Mit anderen Worten, wir interessieren uns dafür, ob der Code im Betrieb die Ziele erreicht und die Probleme der Benutzer lindert.

Wir interessieren uns für die Auswirkungen des Codes auf die reale Welt. Deshalb sind Kommunikation, Verständnis, Extraktion, Konzeption, Planung, Teilen, Übersetzung, Testen und Validieren alle wichtigen Schritte in der Arbeit. Dies ist die strukturierte Kommunikation, von der ich spreche, und auch der größte Engpass in der Arbeit. Es ist wichtig, zu wissen, was man bauen soll, mit anderen zu kommunizieren und Anforderungen zu sammeln, zu wissen, wie man baut und warum man baut, und schließlich zu beurteilen, ob das Bauen richtig ist und die ursprünglichen Ziele erreicht werden.

Je fortschrittlicher die AI-Modelle werden, desto stärker wird dieser Engpass.

Im Folgenden werde ich das Beispiel des Ambient Programming verwenden. Das Ambient Programming ist ein gutes Erlebnis, weil es mit der Kommunikation beginnt und der Code eher ein natürliches Ergebnis der Kommunikation ist.

Wir müssen nur unsere Absicht und die gewünschten Ergebnisse beschreiben, und dann übernimmt das Modell die mühsamen Arbeiten. Wir kommunizieren mit dem Modell über Prompts, um unsere Absicht und Wertvorstellungen auszudrücken, und erhalten am Ende ein Code-Artifact. Danach sind die Prompts nicht mehr notwendig.

Wenn Sie schon mal TypeScript oder Rust geschrieben haben, wissen Sie, dass der Code immer durch den Compiler kompiliert oder in Binärdateien umgewandelt wird. Diese Binärdateien sind nicht wichtig, die Quell-Spezifikationen sind der Kern, der wirklich wertvolle Teil.

Aber bei der Verwendung von Prompt-Modellen machen wir genau das Gegenteil. Wir behalten den generierten Code und löschen die Prompts. Dies ist wie wenn man den Quellcode zerreißt und dann sehr sorgfältig die Versionskontrolle der Binärdateien vornimmt.

Deshalb müssen wir durch Spezifikationen die Absicht und die Wertvorstellungen klar festlegen.

Klare Spezifikationen fördern die effiziente Zusammenarbeit und lassen die Teammitglieder in Richtung eines gemeinsamen Ziels arbeiten, um sicherzustellen, dass alle auf dem gleichen Stand sind. Dies ist das Ergebnis unserer Diskussion, Debatte, Referenz und Synchronisierung. Dies ist sehr wichtig, deshalb möchte ich es nochmal betonen: Klare Spezifikationen ermöglichen die effiziente Zusammenarbeit und repräsentieren das Ergebnis von Kommunikation, Diskussion, Debatte, Referenz und Synchronisierung. Ohne Spezifikationen haben jeder nur eine vage Vorstellung in seinem Kopf.

Spezifikationen sind oft stärker als Code

Im Folgenden werde ich darüber sprechen, warum Spezifikationen oft stärker sind als Code, denn Code ist tatsächlich eine verlustbehaftete Projektion der Spezifikationen.

Wenn wir z.B. eine kompilierte C-Binärdatei dekompilieren, verlieren wir immer die klaren Kommentare und die gut benannten Variablen. Dann müssen wir schlussfolgern, was der Entwickler vorhatte. Warum wurde dieser Code so geschrieben? Dies ist eine verlustbehaftete Übersetzung. Ebenso kann auch der beste Code oft nicht alle ursprünglichen Absichten und Wertvorstellungen direkt widerspiegeln. Beim Lesen des Codes müssen wir schlussfolgern, was das Entwicklungsteam ursprünglich erreichen wollte.