Die Angst vor der Nutzung von KI zur Programmierung – eine Art „Schattenbox

Beginnender Dialog: Wenn Code zu einem Blackbox wird

Shiwen: Gestern hatte ich einen sehr beliebten Beitrag auf Hacker News. Ein Meta-Engineer sagte, dass er nach so vielen Jahren Programmierung zum ersten Mal das Gefühl hatte, seine Arbeit sei nicht sicher. Seine Aussage lautete ungefähr: Wenn man jetzt Code schreibt, hat man das Gefühl, mit einer Blackbox zusammenzuarbeiten. Man kann die höhere Logik verstehen, aber nicht jedes Detail. Das könnte zu einer neuen Branchennorm werden. Was denkst du darüber?

Yongliang: Ich habe den Zitattext aus dem Beitrag gelesen. Die grundlegende Sorge liegt nicht bei AI, sondern darin, dass die Grenzen des Verstehens sich verändert haben. Ich habe siebzehn Jahre lang in der Technologie gearbeitet und war zuletzt in einem Team von siebzig Personen tätig. Früher war es selbstverständlich, dass der vom Engineer eingereichte Code jeden einzelnen Satz erklären konnte. Jetzt wird dieses Standard nicht losgelassen – aber es ist nicht so, dass es keinen Standard mehr gibt. Der Standard hat sich von „Jeden Satz verstehen“ zu „Bis zu welchem Grad Verständnis als Verantwortung gilt“ verändert. Das ist das Thema, über das ich heute gerne genauer sprechen möchte.

Shiwen: Also kommst du nicht, um AI zur Unterstützung des Programmierens zu kritisieren?

Yongliang: Nein. In meinem Team verwenden wir bereits AI, um Tests zu schreiben, Kommentare hinzuzufügen und alten Code zu ändern. Es ist tatsächlich schnell. Aber egal wie schnell es ist, wer ist verantwortlich, wenn etwas schiefgeht? Das ist eine Frage, der Manager nicht ausweichen kann. Heute möchte ich diese Sorge aus vier Perspektiven betrachten: Phänomen, persönliche Erfahrung, Teammechanismus und die Grenzen der Gegenseite.

Q1: Was ist eigentlich die Sorge dieses Engineers?

Shiwen: Lassen Sie uns zunächst das Phänomen klarstellen. Wie drückt sich die Sorge dieses Meta-Engineers in einem Satz aus?

Yongliang: Er hat keine Angst davor, dass AI schlecht programmiert hat, sondern davor, dass er etwas liefert, was er nicht vollständig versteht. In Worten des Beitrags: Ich weiß, was dieses Code-Stück tut, aber wenn man mich fragt, warum eine bestimmte Bedingung so behandelt wird, kann ich es vielleicht nicht erklären. Früher nannte man das „nicht verstanden haben“, heute nennt man es „die normale Situation bei AI-Generiertem Code“.

Shiwen: Ist diese Sorge repräsentativ?

Yongliang: Sehr. Aber es ist nur eine alte Sorge, die einen neuen Mantel bekommen hat. Früher hatten wir auch Sorgen: Die Bibliotheken sind nicht von dir geschrieben, das Framework ist nicht von dir geschrieben, die Grundlagen der Cloud-Dienste sind nicht von dir geschrieben – warum solltest du sie dann verwenden? Die Antwort ist, dass du eine „Vertrauensstruktur“ aufgebaut hast. Du vertraust dem Linux-Kernel, React und AWS, weil sie viele Tests und echte Betriebsdaten hinter sich haben. Das Problem bei AI-Generiertem Code ist nicht, dass es immer falsch ist, sondern dass deine „Vertrauensstruktur“ noch nicht gut genug ist, bevor du es in die Hauptfork einbaust.

Shiwen: Also liegt das Problem nicht darin, dass der Code von AI stammt, sondern darin, dass die Vertrauensstruktur nicht ausreicht?

Yongliang: So kann man es verstehen. Und ich möchte noch hinzufügen: Je erfahrener der Engineer ist, desto größer ist die Sorge, denn du weißt, wie groß ein ungetestetes Detail im Produktionsumfeld sein kann. Neueren Mitarbeiter fehlt diese Last oft, was manchmal kein Nachteil ist, aber auch riskant.

Q2: Wie gehst du als Einzelperson mit dieser Blackbox um?

Shiwen: Kommen wir zu dir als Einzelperson. Mit siebzehn Jahren technischem Erfahrung schreibst du immer noch Code, indem du jeden Satz selbst schreibst?

Yongliang: Ich frage mich zuerst: Wem gehört die „Eigentumsrechte“ an diesen Code. Wenn es mein ist, muss ich es verstehen; wenn es das von der AI ist, muss ich es überprüfen. Das ist meine Erfahrung, keine Statistik. Die konkrete Vorgehensweise besteht aus drei Schichten. In der ersten Schicht gibt die AI eine Funktion hinzu, schreibt eine Regularisierung und generiert Testdaten. Bei solchen Stücken schaue ich schnell auf Eingabe und Ausgabe, um sicherzustellen, dass es keine offensichtlichen Semantikfehler gibt, bevor ich sie verwende. In der zweiten Schicht gibt die AI Code, der sich mit Konkurrenz, Sicherheit und Zustandsmaschinen beschäftigt, und ich verlange, dass sie den Code teilweise erklärt und selbst die Grenzfälle durchläuft. In der dritten Schicht, wenn dieser Code in den Kernprozess eingefügt werden soll, behandle ich ihn wie eine PR, die von einem Kollegen eingereicht wurde: Ich lese ihn noch einmal durch, füge Tests hinzu und lasse jemanden ihn überprüfen, anstatt ihn einfach zu verwenden, nur weil „die AI sagt, es ist in Ordnung“.

Shiwen: Gibt es Situationen, in denen du nicht zulässt, dass die AI mit hantiert?

Yongliang: Ja. Zwei Arten. Die erste Kategorie sind Code, die sich mit Finanzen, Berechtigungen und Privatsphäre beschäftigen, wie Bezahlprüfungen, Authentifizierungslogik und Datenmaskierung. In diesen Bereichen sind die Regeln stark und die Folgen schwerwiegend, eine AI-Halluzination kann zu einem Unfall führen. Die zweite Kategorie sind Architekturentscheidungen, über die ich selbst nicht klar war. Wenn du nicht einmal klar hast, was du tun willst, und die AI dir hilft, Code zu schreiben, bedeutet das, dass sie für dich denkt. Das Ergebnis wird immer eine schöne, aber fehlerhafte Hülle sein.

Shiwen: Deine Grundlinie ist also: „Ich kann nicht handschriftlich schreiben, aber ich darf nicht unklar sein.“

Yongliang: Richtig. Dieses Prinzip gilt für jedes Tool. Ob du Git verwendest, eine IDE oder die AI, das ändert nichts: Am Ende bist du es, der unterschreibt, und die Verantwortung liegt bei dir. Die AI kann nicht vor Gericht erscheinen, keine Erklärung abgeben und keine Schuld übernehmen.

Q3: Wie hast du in einem Team von siebzig Personen ein Überprüfungsmechanismus etabliert?

Shiwen: Von individuell auf teambasiert. Du hast mit siebzig Personen gearbeitet, wie fließt der von der AI generierte Code im Team?

Yongliang: Zuerst ein harter Grundsatz: Der von der AI generierte Code muss in der Einreichung angegeben werden. Das ist keine Diskriminierung gegenüber der AI, sondern um bei der Überprüfung zu wissen, wo die Risiken liegen. Als ich das Team leitete, gab es eine spezielle Überprüfungskategorie: „Welche Entscheidungen stammen in dieser Änderung von Menschen und welche von Tools?“ Wenn der Einreicher keine Antwort geben konnte, wurde er zurückgeholt.

Shiwen: Aber es gibt so viele Dinge, die von der AI generiert werden, kann man alle überprüfen?

Yongliang: Nein, daher ist ein mehrschichtiges System notwendig. Wir haben damals die Auswirkungen in drei Kategorien eingeteilt. Die erste Kategorie sind Änderungen an normalen Modulen, bei denen der Anteil der AI-Generierung gering ist und die übliche Überprüfung durchlaufen. Die zweite Kategorie sind Änderungen, die in die Kernmodule einfließen, die von mindestens zwei Personen überprüft werden müssen und mit Unit- und Integrationstests versehen sein müssen. Die dritte Kategorie sind Teile mit den größten Auswirkungen und Bezug zu Finanzen oder Berechtigungen, bei denen die AI nur unterstützend sein darf, nicht direkt Code liefern darf, und am Ende muss jemand jedes Zeile handschriftlich schreiben und unterschreiben. Die Grenzen dieser drei Kategorien sind im Team-Wiki klar beschrieben, Neulinge sollten sich diese zuerst ansehen.

Shiwen: Gibt es besondere Anforderungen an die Tests?

Yongliang: Ja. Der von der AI geschriebene Code muss einen höheren Testcoverage haben als der handschriftlich geschriebene. Das ist keine Bestrafung, sondern eine Absicherung. Weil du die Details nicht verstehen kannst, musst du den Tests überlassen, dass sie die Verhaltensgrenzen bewachen. Außerdem dürfen für den kritischen Pfad des von der AI geschriebenen Codes nicht dieselbe Modelle verwendet werden, wie in dem Kommentar von edwin0 bereits deutlich gemacht wurde: Die AI kann den Code und die Tests nach demselben Muster schreiben, wodurch Fehler perfekt verdeckt werden können.

Shiwen: Haben Kollegen Einwände gegen dieses System?

Yongliang: Natürlich gibt es das. Manche sagen, dass dies keine Belastung sei. Ist AI nicht dazu da, die Effizienz zu steigern? Meine Antwort ist: AI erhöht die Effizienz der „geschriebenen“ Arbeit, nicht die Effizienz der „abgeglichenen, getesteten und funktionsfähigen“ Arbeit. Wenn man ungetestete Code auf Basis von Geschwindigkeit einsetzt, wird die Zeit für Debugging und Fehlerbehebung um das Zehn- oder Hundertfache zunehmen. Ich habe diese Prinzipien seit vielen Jahren mit meinem Team verifiziert, deshalb wage ich es, sie in den Prozess einzubauen.

Shiwen: Abgesehen vom Code – wie geht es mit Dokumentation, Wochenberichten und Designs?

Yongliang: Derselbe Logik. AI kann dir helfen, Dinge klar zu machen, aber es kann keine Verantwortung übernehmen. Jede Entscheidung und jeder Auswahl in den Dokumenten muss von einer konkreten Person getroffen werden. Unsere Abteilung nennt das „Signaturenprinzip“: Wer die Idee hat, der unterschreibt; AI erstellte Texte müssen schließlich von Menschen überprüft werden, bevor sie veröffentlicht werden. Dieses Prinzip mag formalistisch erscheinen, aber es konkretisiert das Wort „Verantwortung“.

Q4: Was sagen die Gegner? Wo liegen die Grenzen?

Shiwen: Auf HN gibt es viele Stimmen, die dagegen sind oder ergänzend argumentieren. Ich nenne einige repräsentative Beispiele.

Yongliang: Ich zitiere die häufigsten Meinungen aus dem Facts-Bag. Die erste stammt von spacedcowboy: Solange es funktioniert, ist das in Ordnung; genauso wie ich nicht jeden Codebefehl eines Kollegen überprüfe. Aber ich verwende viele Tests und echte Programme als Schutzmaßnahme. Dies stimmt mich zu, denn es platziert den von AI erstellten Code an der richtigen Stelle: Du musst nicht jeden Codebefehl verstehen, aber du brauchst messbare Überprüfungsmethoden.

Shiwen: Was ist das Gegenteil dazu?

Yongliang: Die zweite Meinung stammt von edwin0: Dass AI gleichzeitig Code schreibt und Tests durchführt, ist besorgniserregend, denn beides kann denselben Fehler machen. Diese Erinnerung ist wichtig. Wenn sowohl der Code als auch die Tests von derselben AI erstellt werden, kann der Test zu „Selbstbeweis“ werden: Die AI schreibt den Code nach ihren eigenen Prinzipien, und wenn sie denselben Weg zum Testen wählt, passen die Tests natürlich, aber auch die Fehler werden verdeckt. Unsere Praxis ist also, dass AI Code schreiben darf, aber der wichtige Teil des Tests muss von Menschen durchgeführt werden oder auf andere Weise kruzifixiert werden.

Shiwen: Gibt es noch andere Perspektiven?

Yongliang: Die dritte Meinung stammt von mattbrewsbytes und ist eine Analogie: Es handelt sich dabei um eine Art „Konzeptkompression“, ähnlich wie die ORM-Systeme in Rails. Meistens funktioniert es gut, aber wenn die Datenbank groß wird, musst du wieder zu SQL zurückkehren. Mit anderen Worten, der von AI erstellte Code basiert auf einer Ebene der Abstraktion, die dir hilft, ihn zu laufen zu lassen, aber wenn man die Grenzen erreicht, muss man tiefer gehen. Diese Analogie verwende ich selbst oft, um uns daran zu erinnern: Lass nicht zu, dass AI dir hilft, und vergiss nicht die Grundprinzipien.

Shiwen: Und die vierte Meinung?

Yongliang: Die Meinung von Billylo ist eher an der Engineering-Praxis orientiert: Risiken werden durch Laufzeitüberwachung, Kruzifixierung und Warnungen abgewehrt. Das ist eine weitere Darstellung unseres Teammechanismus. Man kann nicht alle schwarzen Box-Risiken vorhersehen, aber man kann sicherstellen, dass Probleme sofort entdeckt werden, wenn sie auftreten.

Shiwen: Wo liegen also die Grenzen?

Yongliang: Die Grenze ist die „Verifizierbarkeit“. Wenn die Eingabe und Ausgabe eines Moduls klar getestet werden können, durch Logs und Monitoring abgedeckt werden können und von Kollegen überprüft werden können, dann macht es nichts aus, dass es eine schwarze Box ist. Aber wenn es nicht verifizierbar ist, nicht nachverfolgbar und nicht überwacht werden kann, sollte es, egal ob AI oder nicht, nicht direkt in die Produktion gehen. Diese Grenze hat nichts mit AI zu tun, sondern mit der Engineering-Kultur.

Schlusswort: Das Schwarze Kästchen wird nicht verschwinden, aber die Verantwortung darf nicht abgewälzt werden

Shiwen: Abschließendes Wort. Ein Satz für diese Ausgabe.

Yongliang: Die Angst vor dem Schwarzen Kästchen bei der AI-Programmierung ist im Grunde eine Neuverteilung der Verantwortung. Früher lag die Verantwortung darin, ob man „Code geschrieben hat“, jetzt liegt sie darin, ob man „versteht“, prüft und verantwortungsbewusst handelt. Je mächtiger die Tools sind, desto wichtiger wird das Urteilsvermögen des Menschen. Das Schwarze Kästchen wird nicht verschwinden, aber durch Tests, Reviews, Überwachung und Signaturmechanismen kann man es erträglicher machen.

Shiwen: Genauer gesagt: Was kann ein gewöhnlicher Ingenieur heute mitnehmen?

Yongliang: Drei Sätze. Erstens: AI kann dein Beifahrer sein, aber das Fahrzeugkennzeichen gehört dir. Zweitens: Code, den man nicht versteht, muss entweder verstanden werden oder genügend Tests und Überwachung durchgeführt werden, damit das Schwarze Kästchen nicht ungeschützt bleibt. Drittens: Jeder Code, der in die Produktionsumgebung gelangt, muss letztendlich von einem echten Menschen verantwortet werden. Egal wie sich die Technologie verändert, das bleibt bestehen. Wenn du das nächste Mal lässt, dass AI einen Code schreibt, warte nicht sofort mit der Zustellung – frage dich selbst: Wenn dieser Code morgen Probleme macht, kann ich erklären, warum er so geschrieben wurde?

Quellen

• Diskussionspost auf Hacker News, 19.10.2026, Ask HN: Meta-Engineer Ali Hamie sagte: „Ich schreibe in diesen Tagen Code und alles fühlt sich wie ein Schwarzes Kästchen an… Du verstehst das hohe Niveau, aber nicht jedes Detail. Vielleicht wird das der neue Standard.“ (Wiedergabe von Fakten, Originalzitat)
• HN-Hot-Comments von spacedcowboy: „Wenn es funktioniert, ist alles in Ordnung; ich prüfe nicht jede Zeile des Codes jedes Kollegen, sondern verlasse mich auf Tests und echte Programme als Sicherheitsvorkehrungen.“ (Zusammenfassung von Fakten)
• HN-Hot-Comments von edwin0: „Dass AI sowohl Code schreibt als auch Tests durchführt, ist beunruhigender, weil sie möglicherweise dieselben Fehler machen können.“ (Zusammenfassung von Fakten)
• HN-Hot-Comments von mattbrewsbytes: Die Konzepte werden mit Rails ORM verglichen; die Abstraktion funktioniert meistens, aber bei größeren Datenmengen muss man wieder zu SQL zurückkehren. (Zusammenfassung von Fakten)
• HN-Hot-Comments von billylo: Risiken werden durch Laufzeitüberwachung, Kreuzprüfungen und Warnungen abgewehrt. (Zusammenfassung von Fakten)
• Erfahrungsberichte des Gastredners: Siebzehn Jahre technische Erfahrung, Peak-Team von siebzig Personen; Code-Review-Signatursystem, AI-Code-Markierung, Testumfang als Risikominderung, Doppelreview für Kernmodule – all das sind persönliche Praktiken.