Es ist deine Aufgabe, Code zu liefern, dessen Funktionsfähigkeit nachgewiesen ist

• In KI-gestützten Entwicklungsumgebungen häufen sich Fälle, in denen unerfahrene Engineers ungeprüfte, sehr große PRs einreichen
• Die Kernaufgabe von Entwickler:innen besteht nicht einfach im Schreiben von Code, sondern darin, Code zu liefern, dessen Funktion nachgewiesen ist
• Dafür müssen zwingend zwei Schritte durchgeführt werden: manuelle Tests und automatisierte Tests
• Auch Coding Agents sollten so konfiguriert werden, dass sie die von ihnen vorgenommenen Änderungen selbst verifizieren
• Letztlich liegt die Verantwortung beim menschlichen Entwickler, und nur Code mit Nachweisen der Verifikation hat echten Wert

---

Das Problem beim Einreichen ungeprüften Codes

• Es wird auf Fälle verwiesen, in denen Junior Engineers mit LLM-Tools riesige, ungeprüfte PRs einreichen und sich auf das Code Review verlassen
  • Das wird als unhöflich und ineffizient bezeichnet und als Vernachlässigung der Verantwortung eines Entwicklers kritisiert
• Die Rolle von Software Engineers besteht nicht in der bloßen Produktion von Code, sondern darin, Code zu liefern, dessen Funktion nachgewiesen ist
  • Ungeprüfter Code wird als Abwälzen der Last auf die Reviewer betrachtet

Zwei Schritte, um nachzuweisen, dass der Code funktioniert

• Der erste Schritt ist der manuelle Test: Man muss selbst überprüfen, dass der Code korrekt funktioniert
  • Dazu gehört, das System in einen Ausgangszustand zu versetzen, die Änderung anzuwenden und anschließend das Ergebnis zu verifizieren
  • Terminal-Befehle und Ausgaben können als Kommentar im Code Review beigefügt oder durch eine Bildschirmaufnahme nachgewiesen werden
  • Nach der Bestätigung des Normalfalls sollten durch Tests von Edge Cases mögliche Probleme gesucht werden
• Der zweite Schritt ist der automatisierte Test, der dank der Fortschritte bei LLM-Tools als unverzichtbarer Prozess hervorgehoben wird
  • Zusammen mit der Änderung sollten automatisierte Tests enthalten sein, und wenn man die Implementierung zurücknimmt, müssen diese Tests fehlschlagen
  • Das Schreiben von Tests folgt demselben Verfahren wie der manuelle Test, und die Fähigkeit zur Integration in eine Test Harness ist dabei wichtig
  • Es wird darauf hingewiesen, dass es ein falscher Ansatz ist, manuelle Tests wegzulassen, nur weil automatisierte Tests allein für ausreichend gehalten werden

Rolle und Verifikation von Coding Agents

• Ein wichtiger Trend im LLM-Bereich im Jahr 2025 ist das rasante Wachstum von Coding Agents; repräsentative Beispiele sind Claude Code und Codex CLI
  • Sie können Code ausführen und Probleme selbstständig beheben
• Auch Coding Agents müssen ihre eigenen Änderungen nachweisen und sowohl manuelle als auch automatisierte Tests durchführen
  • Bei CLI-Tools kann man den Agenten darauf trainieren, diese selbst auszuführen, oder dies mit Systemen wie Clicks CLIRunner automatisieren
  • Bei CSS-Änderungen kann man sie so einrichten, dass sie das Ergebnis per Screenshot-Erfassung prüfen
• Wenn in einem Projekt bereits Tests vorhanden sind, kann der Agent diese erweitern oder bestehende Muster wiederverwenden
  • Struktur und Qualität des Testcodes beeinflussen direkt die Qualität der vom Agenten erzeugten Tests
  • Ein ästhetisches Gespür für Testcode wird als zentrale Fähigkeit genannt, die Senior Engineers auszeichnet

Die Verantwortung des Menschen und der Wert von Code

• Computer können keine Verantwortung übernehmen; diese Rolle muss der Mensch übernehmen
  • Dass LLMs große Patches erzeugen, ist inzwischen nichts mehr, das an sich Wert stiftet
• Der eigentliche Wert liegt darin, Code zu liefern, dessen Funktionsfähigkeit nachgewiesen ist
  • Beim Einreichen eines PRs sollte man unbedingt Belege dafür beifügen, dass der Code korrekt funktioniert

[tested]

Vibe Engineering

[ethanhur]

Dem stimme ich sehr zu. Derzeit ist die Verantwortung für Code im PR-Verfahren strukturell auf Maintainer und Reviewer abgewälzt. Für jemanden, der nicht überprüften LLM-Code einreicht, gibt es keine Nachteile.

Wenn man einmal zur Google-Codebasis beigetragen hat, sieht man, dass dort so etwas wie der Credit von Contributorn gemessen wird; ich denke, dass andere Open-Source-Projekte und Unternehmen so etwas ebenfalls einführen werden. Vertrauen dürfte noch stärker zu einem wichtigen Gut werden.

[roxie]

Oh, ihr verwendet also so ein Konzept bei Google.

[GN⁺]

Hacker-News-Kommentare

• In letzter Zeit sieht man häufig eine deprimierende Anekdote: Ein Junior Engineer, ausgestattet mit LLM-Tools, wirft einen riesigen, ungetesteten PR Kollegen oder Open-Source-Maintainern hin und erwartet, dass der Code-Review den Rest erledigt. Noch schlimmer ist, dass dieses Verhalten nicht nur von Juniors kommt, sondern auch von Senior-Entwicklern

  • Genau das habe ich gestern und heute getan. Unser Team bekam einen Bug-Report und hielt ihn zunächst für ein Problem eines externen Vendors. Der Vendor schob es jedoch zurück und meinte, das Problem liege bei uns. Also ließ ich Codex draufschauen, es fand das Problem und bereitete einen PR vor. Ich habe ihn weder selbst reviewt noch getestet, sondern mein Team die Verifizierung übernehmen lassen. Der Prozess half dem Team dabei, zu lernen, LLMs als Arbeitswerkzeug zu nutzen
  • In den letzten zwei Tagen haben zwei nicht-technische Teammitglieder einen AI-Agenten gefragt, wie man einen Mobile-Bug behebt, und die Antwort dann als Kerninhalt des Tickets eingestellt. Am Ende musste ich alles lesen und die tatsächlichen Anforderungen neu herausarbeiten
  • Es gibt viele Leute mit dem Titel „Senior“, die sich trotzdem wie Juniors verhalten. Vermutlich liegt das daran, dass man heute schon nach zwei Jahren Berufserfahrung als Senior bezeichnet wird
  • Entwickler, die Regeln ignorieren oder umgehen können, sind am gefährlichsten. Das erinnert mich an die 10x-Entwickler, die ich früher getroffen habe. Wenn sie Regeln ignorieren und einfach nur Features herauspumpen, müssen am Ende andere den Schaden beheben
  • Ich frage mich, wo die Junior-Entwickler während des Code-Reviews sind. Wenn sie sich nicht an Reviews beteiligen, ist es schwer, dass sie Verantwortung für die Qualität ihres Codes empfinden

• Wie man einen guten PR schreibt, gilt nicht nur für AI-generierten Code, sondern immer. Wenn ich eine PR-Beschreibung schreibe, ordne ich sie meist in der Reihenfolge: aktuelles Verhalten, Grund für die Änderung, Inhalt der Änderung. Ich füge Testanweisungen, Screenshots und sogar E2E-Testbefehle hinzu, um die Last für Reviewer zu senken. Das hilft auch bei asynchroner Zusammenarbeit oder Teams über Zeitzonen hinweg

  • Bevor ich ein Review anfrage, prüfe ich alles noch einmal selbst. Kleine Tippfehler oder überflüssige Logs vorher zu entfernen, spart dem Reviewer Zeit. Copilot-Reviews finden solche Dinge ebenfalls gut
  • Selbst wenn man die Beschreibung sorgfältig schreibt, liest sie oft niemand. Ich schreibe sie trotzdem weiter, aus Verantwortungsbewusstsein
  • Egal ob der PR mit AI-Unterstützung entstanden ist oder nicht, er sollte Testnachweise und Verifizierung enthalten
  • Früher schrieb ich längere Beschreibungen, aber ich habe gemerkt, dass sie niemand liest. Es war effektiver, nur die Kernaussagen in Bullet Points zusammenzufassen
  • In unserem PR-Template stehen Ticketnummer, Beschreibung der Anfrage, aktueller Zustand, Zustand nach der Änderung und sogar ein „mood gif“

• Das Wesen des Engineerings besteht darin, Anforderungen zu verstehen, sie in logische Abläufe zu übersetzen, Trade-offs auszubalancieren und Verantwortung für das Ergebnis zu übernehmen. Code generieren zu lassen oder zufällige PRs einzureichen, ist ein Symptom dafür, dass diese Grundlagen fehlen. Coding-Agenten sind eher ein Anlass, uns wieder an das Wesen von Engineering zu erinnern

  • In diesem Artikel gibt es ein Beispiel dafür, wie eine einzige Zeile Code einen Schaden von 60 Millionen Dollar verursachte. Ein 10.000-Zeilen-PR aus AI ohne echtes Verständnis des Codes ist eine potenzielle Katastrophe
  • Realistisch betrachtet legen Unternehmen mehr Wert auf Marketing und Profitabilität als auf Qualität. Produkte mit einem „Premium“-Label verkaufen sich besser als wirklich hochwertige Produkte. Am Ende hat „was sich verkauft“ Vorrang vor gutem Engineering
  • Das Problem ist aber auch: Wenn eine Organisation Druck macht mit „Benutz AI und liefere das Feature in drei Tagen, sonst Gespräch mit HR“, dann ist es schwer, ideale Engineering-Prinzipien einzuhalten

• Tests sind notwendig, aber nicht hinreichend. Man muss Code auch logisch verifizieren. Tests demonstrieren korrektes Verhalten nur für bestimmte Eingaben und Umgebungen

  • Sehe ich genauso. Selbst Code, der gut funktioniert, kann trotzdem schrecklich sein
  • Statt „beweisen“ ist „demonstrieren“ wohl passender. Tests sind nur Evidenz für bestimmte Fälle
  • Ich verlasse mich nicht nur auf Tests, sondern versuche auch selbst auf verschiedene Arten, die App kaputtzumachen. Dabei verbessere ich den Code oft noch weiter
  • Die meisten Codebasen lassen sich nicht formal beweisen, deshalb scheint ein Ansatz wie property-based testing nützlich zu sein
  • Selbst 100 % Testabdeckung sind bedeutungslos, wenn der Code nicht robust ist

• Ich teste nicht, weil es Pflicht ist. Ich teste einfach, weil ich sehen will, dass der Code wirklich funktioniert. Wenn es einen nicht begeistert, den laufenden Code zu sehen, ist dieser Beruf vielleicht nichts für einen

• Ich habe gehört, dass Juniors dank LLMs riesige PRs einreichen, aber in unserer Organisation gibt es das bisher nicht

  • Riesige PRs nicht unbedingt, aber LLM-generierten Code, den die Entwickler selbst nicht verstehen, sehe ich oft
  • Solche Fälle gibt es auch bei uns. Die Probleme sind folgende
    • Der Agent macht früheres Feedback wieder rückgängig
    • Er hält sich nicht an die Standards der Codebase
    • Er erfindet bestehende Lösungen neu
    • Er antwortet auf PR-Feedback mit Agent-Output
    • Aus einer Änderung von 10–20 Zeilen wird ein PR mit 50.000 Zeilen
    • Zu wenig Tests, schwaches Error Handling
  • Leute, die schon früher PRs mit niedriger Qualität eingereicht haben, reichen sie dank LLMs jetzt einfach nur schneller ein
  • In WireGuard Android PR #82 und #80 sieht man, dass AI-kopierte Antworten unverändert stehen geblieben sind. Wenn man den Tab „files changed“ anschaut, ist das ziemlich verwirrend
  • Ein Freund arbeitet in einem Startup mit 11 Leuten, und dort pusht der CTO um 3 Uhr morgens direkt 10.000 Zeilen Code auf main. In der Explorationsphase mag das noch gehen, aber in der Stabilisierungsphase ist es ein fürchterliches Risiko

• Ich stimme der Aussage „Dein Job ist es, Code in nachgewiesen funktionierendem Zustand zu übergeben“ nicht zu. Der eigentliche Job ist es, Business-Probleme zu lösen. Natürlich führt das in den meisten Fällen zu Code, aber die Unterscheidung ist wichtig

  • Aber die Korrektheit von Code nachzuweisen ist Teil davon, Business-Probleme zu lösen. Es ist keine separate Aufgabe
  • Man kann kein Business-Problem lösen, indem man Code abliefert, der die Anforderungen nicht erfüllt
  • Wichtig ist, ein Problem zu lösen, ohne neue zu schaffen. Deshalb braucht man Sicherheit und Stabilität
  • Vielleicht liegt es daran, dass ich noch nicht lange im Beruf bin, aber ich verstehe nicht, wie man ein Problem mit nicht verifiziertem Code lösen soll
  • Letztlich dienen alle Berufe der Problemlösung. Wir tun das nur mithilfe von Computern

• In einem früheren Job arbeitete ich bei einem japanischen Hersteller hochwertiger Hardware, und wenn die QA-Abteilung einen Bug fand, wurde der Produkt-Release gestoppt. Deshalb richteten die einzelnen Entwicklungsabteilungen eigene QC-Teams ein, um die Vorabtests zu verstärken. Dadurch wurde die Software sehr gründlich verifiziert

  • Ich frage mich, was „get dinged“ genau bedeutet. So eine Struktur könnte auch dazu führen, dass Leute Angst vor Änderungen bekommen

• Heutzutage hat sich das Wesen der Arbeit zu Tickets schließen verändert. Codequalität taucht in den Kennzahlen nicht auf und wird deshalb unwichtig. Ich mache bei so einem System nicht mit. Handwerksstolz verschwindet, und alle wollen nur noch billiges Sperrholz und Leim

  • In dem Moment, in dem LLMs flächendeckend eingeführt werden und von allen erwartet wird, sie zu benutzen, ist Software Engineering keine ernsthafte Ingenieursdisziplin mehr
  • Manche fragen Leute, die diese Haltung kritisieren: „Lebst du dann von staatlichen Subventionen?“

• Das Problem ist, was mit „nachgewiesen funktionierendem Code“ gemeint ist. Es gibt auch Fälle, in denen jemand einen riesigen PR mit von LLMs erzeugten Tests einreicht. Ich selbst mache bei privaten Projekten zwar vibe coding, aber im Team ist das eine schlechte Gewohnheit. Man stellt Engineers ein, um für ihre Expertise zu bezahlen

  • Deshalb betone ich manuelles Testen. Schon Screenshots oder Videos, die das tatsächliche Verhalten zeigen, können großes Vertrauen schaffen