Wer gut Code Reviews macht, kann auch gut mit AI-Agenten umgehen

 (seangoedecke.com)
15 Punkte von GN⁺ 2025-09-23 | 1 Kommentare | Auf WhatsApp teilen
  • Um AI-Agenten effektiv einzusetzen, sind starke Code-Review-Fähigkeiten wichtig
  • Große Sprachmodelle sind gut in der Codegenerierung, es fehlt ihnen aber oft an tiefgehender Urteilskraft, sodass sie Zeit in die falsche Richtung verschwenden
  • Pedantische Reviews, die nur kleine Syntaxdetails bemängeln, oder unkritische Abstempel-Reviews helfen beim Einsatz von AI nicht weiter
  • Gute Code Reviews prüfen aus struktureller Perspektive, ob es bessere Wege gibt, und helfen dabei, unnötig komplexe Designs zu vermeiden
  • Letztlich ist AI-Coding wie „Centaur Chess“ ein Modell, das menschliches Urteilsvermögen und maschinelle Produktivität verbindet – und die Fähigkeit zu Code Reviews wird direkt zur Fähigkeit, AI gut zu nutzen

Die Beziehung zwischen AI-Agenten und Code Reviews

  • AI-Agenten richtig zu nutzen, ist im Grunde ein Code-Review-Prozess
  • Menschen, die gute Code Reviews machen, nutzen auch AI-Code-Tools wie Claude Code, Codex und Copilot effektiv

Warum Code-Review-Fähigkeiten wichtig sind

  • Große Sprachmodelle sind gut darin, große Mengen Code zu erzeugen, es fehlt ihnen aber weiterhin an der Urteilskraft erfahrener Softwareingenieure
  • Lässt man sie daher ohne Aufsicht arbeiten, verschwenden sie oft viele Ressourcen mit unnötigen oder schlechten Entwürfen

Grenzen von AI-Agenten und Designfehler

  • Beim Beispiel der Entwicklung des Projekts VicFlora Offline investierte Codex viel Aufwand in das Reverse Engineering von Frontend-Code
    • Tatsächlich gab es einen einfacheren Ansatz für den Datenzugriff
    • Bei der Nutzung von AI-Agenten lässt sich ungefähr einmal pro Stunde beobachten, dass sie etwas Verdächtiges tun
    • Wenn man solche Probleme erkennt und die Richtung selbst korrigiert, kann man mehrere Stunden Arbeit einsparen
  • In einer weiteren App-Entwicklungserfahrung schlug AI selbst für eine einfache Aufgabe der Parallelverarbeitung den Aufbau übermäßiger Hintergrund-Infrastruktur vor
    • Obwohl eine nicht blockierende Verarbeitung im Frontend völlig ausgereicht hätte, wollte sie eine komplexe Architektur einführen
    • Um Einfachheit zu bewahren, ist es wichtig, AI kontinuierlich zu steuern
  • Wenn Nichtfachleute nur auf AI vertrauen und entwickeln, sammeln sich Komplexität und Ineffizienz in der Codebasis an, wodurch die Problemlösungsfähigkeit am Ende sogar stark sinkt

Wesen und Wirkung von Code Reviews

  • Die Zusammenarbeit mit AI ähnelt der Zusammenarbeit mit einem motivierten, aber unerfahrenen Junior-Entwickler
    • Da AI ihre Urteilskraft im Lauf der Zeit nicht weiterentwickelt, ist fortlaufende Beobachtung notwendig
  • Der größte Fehler bei Code Reviews besteht darin, nur auf den geschriebenen Code zu schauen und nicht zu überlegen, ob es eine bessere Alternative gibt
    • Das beste Code Review betrachtet aus einer strukturellen Perspektive den Kontext des gesamten Systems integriert
    • Vorrang haben Ansätze, bestehende Systeme wiederzuverwenden, statt unnötig neue Systeme zu bauen
  • Reviewer, die sich nur auf feine Stilfragen versteifen, können den eigentlichen Nutzen von AI-Tools verpassen
  • Wer wie ein Abstempel-Reviewer alles ohne Kritik durchwinkt, kann mit AI oder Junior-Entwicklern kaum effektiv zusammenarbeiten

Gedanken zur Kompetenz im Umgang mit AI-Tools

  • Traditionelle Tools wie git haben eine klare Struktur und Bedienlogik, die Grundstruktur von AI ist dagegen undurchsichtig
    • AI kann fast jede Art von Operation ausführen
  • Manche sehen die Fähigkeit im Umgang mit AI darin, AI-Tools möglichst umfassend einzusetzen
    • Tatsächlich können erfahrene Nutzer deutlich mehr Möglichkeiten aus ihnen herausholen
  • Bisher können AI-Code-Agenten bei vielen verschiedenen Aufgaben helfen, erfordern aber weiterhin enge Aufsicht
  • Wie im Modell des „Centaur Chess“ lässt sich optimale Produktivität erreichen, wenn die Richtung erfahrener Menschen mit den Vorschlägen der AI kombiniert wird
  • Die Fähigkeit, AI gut zu nutzen, hängt letztlich von Code-Review-Kompetenz und kritischem Architektururteil ab
  • Je besser die Code-Review-Fähigkeiten sind, desto stärker entfaltet sich der Nutzen von agentic AI-Tools

Abschließende Gedanken und Ausblick

  • AI-Agenten können mit der Zeit den Eindruck vermitteln, als würden sie sich zunehmend wie erfahrene Ingenieure entwickeln
  • In den kommenden Jahren könnte sich die Zusammenarbeit mit AI bis auf das Niveau einer Zusammenarbeit mit Mid-Level-Ingenieuren weiterentwickeln
  • Aktuell ist es sinnvoll, mit verschiedenen AI-Tools wie Codex, Claude Code und Copilot zu experimentieren; die wichtigste Unterscheidung bleibt die Fähigkeit zur kritischen Aufsicht

Zusätzliche Meinungen

  • Auf Hacker News und anderswo gab es Diskussionen darüber, bis zu welchem Niveau AI-Agenten nützlich sind
    • Der Autor glaubt nicht, dass AI allein auf Basis von Code Reviews Beiträge auf Linux-Kernel-Niveau leisten kann
    • Manche vertreten auch die Ansicht, dass Code-Review-Methoden zu Stil und Benennung wichtig sind
    • Es gibt kritische Stimmen zu der Frage, ob Design-Diskussionen in Code Reviews stattfinden sollten, aber der Autor sieht das nicht negativ

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-23
Hacker-News-Kommentar

  • Ich bin ziemlich skeptisch gegenüber der Vorstellung, dass man selbst mit einem schlechten Prozess gute Ergebnisse bekommt, solange man die Qualität nur gut kontrolliert — nach dem Motto: „Es ist okay, wenn ständig Schrott herausfällt, solange es jemand prüft.“ In der Realität habe ich noch nie gesehen, dass das gut funktioniert. Die US-Autoindustrie hat so etwas einmal versucht, aber mir fällt kein erfolgreiches Beispiel dazu ein. Wenn ich mir vorstelle, mein Vorgesetzter würde zu mir als Teamleiter sagen: „Statt fünf kompetenten Leuten gebe ich dir 25 völlige Anfänger, hoffe auf irgendeinen Glückstreffer, und du prüfst dann alles“ — das wäre völlig absurd. Und doch ist es faszinierend, dass viele Leute bei genau diesem Szenario plötzlich denken: „Hm? Vielleicht klappt es ja doch?“, sobald AI ins Spiel kommt.

    • Code von unerfahrenen oder wenig motivierten Leuten zu reviewen ist auch extrem ermüdend. Es kostet mental und emotional enorm viel Energie. Wenn man dieselbe Funktion viermal reviewt, ist man irgendwann so genervt, dass man aufgibt, obwohl die Qualität eigentlich noch nicht an dem Punkt ist, an dem sie nicht weiter steigen könnte.

    • Das ist das genaue Gegenteil des Qualitätsmanagement-Modells, das Deming (Edward Deming) in Japan entwickelt und im Westen verbreitet hat. Qualität kommt nicht aus Menschen, sondern aus Prozessen. Einen fehleranfälligen Prozess zu wählen und dann zu erwarten, dass Menschen die Fehler schon herausfischen, ist überhaupt kein guter Weg, wenn Qualität das Ziel ist. LLMs kann man auf viele Arten einsetzen, aber nur einige davon bringen wirklich Vorteile. Das Management steckt in der Illusion fest, AI könne jedes Problem lösen, und versteht entweder die Stärken und Grenzen von AI nicht richtig oder hat Demings Lehren vergessen.

    • Evolution ist ein Beispiel dafür — zufällige Mutation und Selektion, oder überhaupt die Existenz allen komplexen Lebens. Es ist nicht die Methode, die ich bevorzuge, aber es gibt die Tendenz, sich von angesagten Buzzwords mitreißen zu lassen und sie wahllos auch dort auszuprobieren, wo sie nicht passen. Bei manchen Kunststoffteilen für Küchenutensilien werden nach wie vor Teile in schlechter Qualität produziert und anschließend von Tagelöhnern manuell mit dem Messer nachbearbeitet, bevor sie verpackt werden. Ich habe selbst einmal so einen Aushilfsjob gemacht. Auch Chip-Binning bzw. Yield-Management in der Halbleiterindustrie kann man als Fall mit sehr hoher Fehlerrate sehen. Wenn man sich nur ein wenig in der Realität umsieht, merkt man: Fragwürdige Prozesse sind nichts Besonderes, sondern eher Alltag.

    • Sobald man anfängt, sich selbst zu attestieren, dass man „gut mit AI umgehen“ könne, gerät man leicht in die Illusion, der Bereich der Probleme, die man lösen kann, habe sich plötzlich enorm erweitert. Dieses Phänomen gibt es bei jeder General-Purpose-Technologie. Früher war es ähnlich, als Genetic Algorithms gerade einen Boom hatten. Alle suchten nach einem „universellen“ Tool und glaubten dann, mit diesem Tool alles lösen zu können. In Wirklichkeit wurde ohne jeden Kontext optimiert. AI ist einfach ein noch extremeres Beispiel für dieses Phänomen.

    • Egal wie gut der Prozess ist, dadurch lernt man nicht automatisch, wie man tatsächlich funktionierende Systeme baut. Das Muster, das ich immer wieder sehe, ist: Das Team irrt lange herum, und am Ende greift doch ein Engineer ein, der weiß, wie man das Problem löst, und bringt die Sache wieder auf den richtigen Kurs.

  • Es ist wirklich schwer, AI dazu zu bringen, sich an die geforderten Parameter zu halten. Sie weicht ständig zufällig in irgendwelche falschen Richtungen ab. Bei der Arbeit an nftables-Highlighting gibt es 230 Tokens, 2.500 States und über 50.000 State-Transitions. Selbst wenn ich der AI fünf klare Regeln gebe, bricht sie an zufälligen Stellen alle davon. Sie bekommt nicht nur das Coding nicht sauber hin, sondern schafft nicht einmal ganz einfaches Vimscript zuverlässig. Am Ende nutze ich AI nur noch für Dokumentationszwecke. Dafür wird sie langsam ziemlich gut darin, Dinge wie rule, chain_block stmt oder map_stmt_expr in Teilstücke zu zerlegen und zu erklären. Ich kopiere dann einfach die Syntaxmuster, die ich brauche.

  • AI-Codegenerierung ist in der frühen Projektphase durchaus nützlich, aber bei reifen Projekten habe ich ernsthafte Bedenken. Kürzlich wurde ein Postgres-Parser mit über 280k LOC in Multigres gemergt, ohne öffentliche Review. Im Open-Source-Ökosystem ist so etwas problematisch. Viele Leute verlassen sich auf solche Projekte zum Lernen und als Referenz. Wenn dann AI-Code ohne ordentliche Review hineinkommt, schwächt das sowohl den pädagogischen Wert als auch das Vertrauen in diese Abhängigkeiten. Code Review dient nicht nur dazu, Bugs zu finden, sondern ist zentral dafür, dass Mitwirkende lernen, Designentscheidungen verstehen und kollektives Wissen aufbauen. Das Problem ist nicht die Geschwindigkeit, sondern der Prozess der Wissensweitergabe. Zum zeitlichen Ablauf bis zur Veröffentlichung des PR siehe auch diesen Link

    • Ich habe diese Arbeit beaufsichtigt, und Feedback zu besseren Vorgehensweisen ist jederzeit willkommen. Das Besondere an diesem Fall war, dass mithilfe von LLMs der Postgres-C-Parser übersetzt wurde. In dieser Größenordnung kann man nicht einfach alles Zeile für Zeile reviewen, deshalb haben wir ein separates Verfahren zur Sicherstellung der Konsistenz eingeführt. Wir haben zwei Monate lang täglich gründlich geprüft. Außerdem haben wir den Großteil der Postgres-Tests übernommen und erfolgreich portiert, sodass die funktionale Zuverlässigkeit ausreichend abgesichert ist. Multigres ist derzeit noch in einer sehr frühen Phase, und wir wollen künftig auch in weiteren Projekten (Vitess usw.) große Kopier-/Übersetzungsarbeiten versuchen. Verbesserungen werden wir annehmen. Der Autor bereitet außerdem einen Blogpost vor, der den ganzen Prozess erklärt. Persönlich war ich sehr überrascht, was mit Unterstützung von LLMs erreicht werden konnte. Natürlich war dafür ein gewisses Maß an Können unverzichtbar, und diese Person übertraf alle hier genannten Kriterien.

  • Mein Prozess sieht ungefähr so aus

    1. Ich gebe der AI die Anforderungen.
    2. Ich lasse die AI Fragen zu unklaren Punkten stellen.
    3. Wenn keine Fragen mehr offen sind, lasse ich sie die Anforderungen noch einmal als formales PRD zusammenfassen.
    4. Ich kritisiere das.
    5. Ich lasse mir zwei alternative Architekturen vorschlagen.
    6. Ich wähle eine aus und kritisiere sie.
    7. Ich lasse mir zwei detaillierte TODO-Listen vorschlagen.
    8. Ich wähle eine aus und kritisiere sie.
    9. Ich lasse zu einem TODO zwei Implementierungsansätze vorschlagen.
    10. Ich wähle einen aus und kritisiere ihn.
    11. Wiederholung ab Schritt 9.
      Zwischendurch mache ich Snapshots, um bei Bedarf zurückspringen zu können.
      So bekomme ich zwar nichts Großartiges, aber immerhin ein Ergebnis, das als Ausgangsbasis für meine eigene Implementierung taugt.
      Der Nachteil ist, dass es unglaublich viel Zeit kostet, und in 80 % der Fälle denke ich am Ende: Es wäre schneller gewesen, alles einfach selbst von Anfang an zu machen.

    • Das wirkt langsamer, als es allein zu machen. AI-Coding fühlt sich für mich an, als würde ein mittelmäßiger Entwickler am Wochenende improvisiert etwas zusammenbauen und am Montagmorgen sagen: „Ich habe nach deinen Notizen und mit einem Drink in der Hand mal grob was gebaut, wie findest du’s?“ Dann sagt man einmal „NEIN, gefällt mir nicht“, und falls die grobe Richtung immerhin stimmt, ist es ein bisschen schneller, das zu refaktorieren, als wirklich komplett am Montagmorgen bei null anzufangen.

    • Wenn ich solche Schritt-für-Schritt-Guides immer sehe, denke ich am Ende, dass sie einfach eine enorme Menge zusätzlicher Umständlichkeit einführen und damit die Effizienz, die AI eigentlich bringen sollte, komplett wieder auffressen. Nach meiner Erfahrung stimmt das fast immer. Klar gibt es Momente, in denen AI hilfreich ist, aber zu wissen, wann und wo sie nützlich ist, ist selbst eine wichtige Fähigkeit.

    • Ich arbeite eher auf einer niedrigeren Ebene und gehe meistens so vor:

      • Ich baue das grundlegende Interface selbst oder nutze ein bereits vorhandenes.
      • Ich verwende das LLM als Autocomplete-Tool.
      • Ich beschreibe die Anforderungen und nenne auch die Entry-Point-Dateien, die geändert werden müssen.
      • Ich gebe das Ziel nicht auf einmal vor, sondern immer nur einen einzelnen Schritt.
      • Wenn sich abzeichnet, dass es in die falsche Richtung läuft, greife ich sofort ein und stoppe es oder lenke die AI zurück auf Kurs.
        Meistens habe ich erlebt, dass Agents bei zu breiten und zu langen Zielen auf einmal oft falsch einschätzen, wann die Arbeit eigentlich erledigt ist.

    • Ich nutze einen ähnlichen, aber etwas vereinfachten Prozess. Ich gebe sogar ein PRD vor, skizziere grob die Architektur und lasse dann die einzelnen Komponenten so implementieren, wie ich es haben will. Es kostet immer noch viel Zeit, und selbst zu arbeiten wäre wohl schneller, aber inzwischen ist es mir zu lästig, alles Zeile für Zeile selbst zu schreiben, deshalb überlege ich, dem LLM Aufgaben auf Funktionsniveau zu geben.

    • Wenn ich AI nur dafür genutzt hätte, mir einen groben Ansatz, passende Libraries oder Spracheigenheiten zu erklären, und die eigentliche Arbeit dann selbst gemacht hätte, wäre ich wahrscheinlich viel schneller gewesen.

  • Wenn man gut im Code Review ist, ist es vielleicht besser, AI-Agents gar nicht erst zu verwenden.

    • Nachdem ich selbst Code reviewed und Bugs behoben habe, die von Kollegen kamen, die sich in Agents wie Claude Code regelrecht verliebt hatten, ist mein Eindruck: Der Code ist oft so schräg, als wäre er im Delirium geschrieben worden, und die Leute, die ihn eingebracht haben, können meist überhaupt nicht erklären, was der Code eigentlich tut. Ich glaube durchaus, dass manche Leute damit wirklich guten Code erzeugen. Aber alles, was ich in der Praxis gesehen habe, war enttäuschend. Zum Glück haben einige das selbst erkannt und wieder zu vernünftigeren Methoden zurückgefunden. Wenn man die Ergebnisse heutiger agent-basierter Workflows kritisch betrachtet, ist die Antwort meiner Meinung nach ziemlich klar. Wer gut im Code Review ist, kommt wahrscheinlich noch viel schneller zu derselben Schlussfolgerung.

    • Wenn ich gut im Code Review bin, möchte ich meine Fähigkeiten darin weiter ausbauen.

  • Menschen, die gründlich Code reviewen, tun sich mit AI-Tools schwer, und Menschen, die nur oberflächlich reviewen, werden AI gegenüber schnell übermäßig abhängig.
    Anders gesagt: Wer gut im Code Review ist, fährt mit selbst geschriebenem Code meist besser, und gerade bei solchen Projekten ist das auf lange Sicht natürlicher, weil man sie ohnehin selbst pflegen muss. Wenn Coding einem nicht lästig ist und man es gut kann, gibt es keinen zwingenden Grund, AI zu verwenden. AI ist am nützlichsten, wenn man sich punktuell in unbekannte Tools oder neue Themen einarbeitet. Ich muss allerdings zugeben, dass dank der heutigen LLMs auch die Zusammenfassungen von Suchmaschinen deutlich besser geworden sind. Die Zeit, in der man sich durch nutzlose Dokumentation quälen oder sich von irrelevanten Details ablenken lassen musste, ist praktisch auf null gesunken.

  • Code Review gehört zwar zur Arbeit, ist aber nicht der angenehmste Teil. Entwickler ziehen Befriedigung aus dem Moment, in dem sie selbst Code schreiben. AI-Tools helfen zwar, aber weil sie unvorhersehbar sind und trotzdem plausibel wirken, muss man sie noch sorgfältiger reviewen, was die Belastung eher erhöht. Warum haben wir Werkzeuge gebaut, die uns den spaßigen Teil wegnehmen und nur den unspaßigen vergrößern? Wo ist der Agent, der ausschließlich „Code Review“ übernimmt?

    • Ehrlich gesagt macht mir das eigentliche Schreiben von Code gar nicht so viel Spaß. Viel spannender finde ich es, Probleme zu lösen, neue Dinge zu erschaffen, Systeme zu zerlegen und in bessere Strukturen neu zusammenzusetzen. Mit LLMs zu coden fühlt sich für mich so an, als könnte ich Ideen viel schneller in greifbare Ergebnisse übersetzen. Bestehender Code bekommt mehr Type Safety, ist besser dokumentiert und komplexe Refactorings werden einfacher. Ich erwarte von LLMs keine Problemlösung an sich, sondern Hilfe beim Sammeln von Kontext, beim Wiederanwenden von Patterns und bei der Automatisierung von Boilerplate. Gerade wenn Code über viele Dateien verteilt ist, ist es extrem praktisch, wenn AI ihn generiert und ich nur noch die einzelnen Änderungen prüfen muss.

    • OpenAI Codex Cloud hat eine Code-Review-Funktion hinzugefügt, und das neue Modell GPT-5-Codex wurde speziell für Code Review trainiert [Einführung in die Codex-Upgrades]. Auch Gemini und Claude haben inzwischen Code-Review-Funktionen mit GitHub-Actions-Integration bzw. Claude-GitHub-Integration, und GitHub selbst hat Copilot Code Review offiziell veröffentlicht. Dazu kommen spezialisierte Startups wie CodeRabbit, Greptile und Qodo Merge.

    • Den wirklich elektrisierenden Moment erlebe ich, wenn ich bei der Implementierung eine tieferliegende elegante Struktur entdecke und sich dadurch meine bisherige Art zu programmieren — oder sogar meine Art zu leben — verändert. (Das passiert allerdings nur sehr selten.)

    • Je jünger Entwickler sind, desto mehr mögen sie es oft, Code direkt zu schreiben; Seniors dagegen lieben es eher, Code zu reduzieren. Für mich persönlich ist Code Review der spannendste Teil meiner Arbeit — solange ich nicht gerade unter hartem Termindruck stehe. Ich stimme also nicht zu, dass Code Review keinen Spaß macht.

    • Im Einstieg hieß es, „die meisten Entwickler bauen gern etwas Neues“, aber in Wirklichkeit gibt es auch viele Leute, die lieber bestehende Codebases analysieren, Patterns und Strukturen verstehen und sie verbessern. Man sollte berücksichtigen, dass manche den Prozess des völligen Neuanfangs (Initial Design - endlose Iteration) anstrengender finden. Zur Frage, warum „der Spaß weggenommen und nur der unspaßige Teil vergrößert“ wurde: Vermutlich, weil man sich auf die Bereiche konzentriert hat, in denen Produktivitätsgewinne am deutlichsten spürbar sind. Für Review-AI gibt es bereits viele Optionen wie CodeRabbit oder GitLab Duo. Mit etwas wie RooCode kann man auch einfach einen Git diff einspeisen und sich dazu ein Code Review geben lassen.

  • Der Titel dieses Beitrags wirkt mir zu simpel. Code Review und Design Review sind nicht dasselbe, und das ist bei weitem nicht alles, was man mit AI versucht. Um AI sinnvoll einzusetzen, braucht man Fachwissen im jeweiligen Bereich. Selbst wenn man nur auf Coding schaut, reicht Review-Kompetenz allein nicht aus — man muss die Fähigkeit haben, zu validieren, was man der AI anvertraut, ganz gleich in welchem Themengebiet. Ironischerweise hilft AI besonders dann, wenn ich eine Sprache oder ein Framework nicht gut kenne, aber genau dann kann ich auch kein tiefes Code Review leisten. Dass das Wort „Coding“ im Zeitalter von AI/LLMs wieder so populär geworden ist, finde ich bemerkenswert. Unternehmen scheinen heute eher Engineers zu bevorzugen, die nicht nur coden, sondern auch Architektur, Anforderungsanalyse, Full-Stack-Entwicklung und Betrieb abdecken können.

    • Mein offizieller Titel ist zwar „Software Engineer“, aber in den letzten fünf Jahren habe ich

      1. Kubernetes-Cluster für unser Team selbst aufgesetzt und betrieben
      2. sehr viel Docker verwendet
      3. CI/CD-Pipelines entwickelt
      4. unzählige Integrationsarbeiten und Tests gemacht
      5. Anforderungen dokumentiert, einschließlich verschiedenster Systemdiagramme
      6. allerlei sonstige IT-Arbeiten übernommen, die das Infrastrukturteam nicht macht
      7. und gelegentlich auch Code geschrieben

    • AI-Agents richtig einzusetzen ist im Grunde dasselbe wie ein Review-Prozess.
      Denn LLMs können zwar enorme Mengen Code produzieren, verfügen aber noch nicht über das tiefe Urteilsvermögen eines kompetenten Software Engineers.
      Es ist viel besser, früh den Kurs zu korrigieren, als Code lange in eine unklare Richtung wachsen zu lassen. Wie bei einem Junior Developer sollte man zuerst das große Bild bzw. das Design besprechen und dann jedes Mal früh eingreifen, wenn die Richtung kippt. Wenn sich erst nach 100K Tokens Code herausstellt, dass schon die ersten 100 Zeilen falsch waren, muss man am Ende alles wieder auseinandernehmen.

  • Ich finde es großartig, dass durch Code Reviews mit Kollegen gemeinsames Wissen und gemeinsame Standards wachsen. Aber allein der Gedanke, den Code einer sturen, unkooperativen AI reviewen zu müssen, fühlt sich an, als würde ich davon direkt ausbrennen.

  • Wenn ich in dem langweiligsten Teil meiner Arbeit besonders gut werde, heißt das dann, dass ich genau diese Arbeit für immer machen muss? Ehrlich gesagt will ich das nicht. Und wie im Artikel gesagt: Bugs gar nicht erst entstehen zu lassen, ist immer besser. Sie erst nachträglich zu finden, ist mit zusätzlichem Risiko verbunden.