Warum schreibt man 2026 noch Code?

• Die Rolle von Softwareingenieur:innen hat sich über das reine Schreiben von Code hinaus erweitert: Sie bauen und betreiben heute eine Softwarefabrik. Um Systeme zu verstehen und zu verbessern, muss man Code jedoch weiterhin selbst anfassen.
• Wenn man Agenten mit Prompts, AGENTS.md und einer Wissensbasis anleitet und ihre Ergebnisse mit Tests, Linting, Typsystemen und Evaluation absichert, können selbst leistungs schwächere Modelle brauchbare Änderungen erzeugen.
• Wer selbst codiert, kann direkt in der Laufzeitumgebung denken, ohne den Umweg über Englisch. So spürt man Schwachstellen, schwache Tests und unnötige Ausnahmen, die bei rein passiver Codeprüfung leicht übersehen werden.
• Agenten ähneln eher neuen Praktikant:innen als Compilern: Sie folgen bestehendem Code und ungenauen Anforderungen konservativ und können selbst einmalige menschliche Fehler durch Wrapper und indirekte Schichten noch verstärken.
• Menschen sollten Ansätze selbst erproben, Muster festlegen und diese dann von Agenten wiederholen lassen, damit Verantwortungsgefühl und Urteilsvermögen erhalten bleiben und zugleich die Produktivität der Automatisierung genutzt werden kann.

---

Die Softwarefabrik, in der Agenten arbeiten

• Softwareingenieur:innen betreiben nicht nur Software, sondern auch eine Montagelinie, in der jede Person Änderungen per Prompt anfordern und sofort ausrollen lassen kann.
  • Mit Prompts, Skills, AGENTS.md und Wissensbasen wird die Infrastruktur vorab so aufgebaut, dass Agenten erfolgreich arbeiten können.
  • Mit Tests, Linting, Typsystemen, Evaluationen und automatischer Bewertung durch andere KI werden die Ergebnisse nachträglich abgesichert.
• Wenn ausreichend Einschränkungen und aktueller Kontext bereitgestellt werden, können auch weniger intelligente Modelle brauchbare Änderungen erzeugen, ohne vom Pfad abzuweichen. Dann scheint es, als müssten Menschen Code weder lesen noch selbst schreiben.
• Doch selbst wenn es Agenten mit Intelligenz auf Fable-Niveau gäbe, ermöglicht eigenes Codieren, direkt in der Laufzeitumgebung zu denken, ohne Englisch als Zwischenschicht.
• Nur passiv Diffs und Patches von Agenten zu lesen, reicht kaum aus, um sich tief mit der Systemarchitektur zu verbinden.
  • Wer selbst mit dem Code arbeitet, spürt beim Hinzufügen von Funktionen unmittelbar, was dabei kaputtgeht.
  • Wenn man Code aufräumt und konsistente Architekturprinzipien dokumentiert, statt immer neue Ausnahmen anzuhängen, arbeitet auch die Softwarefabrik stabiler.
  • Wer beim Debugging Schwächen in der Teststrategie findet und behebt, kann ganze neue Klassen von Bugs blockieren.
• Eigenes Codieren ist nicht der einzige Weg, Software zu verstehen, und es gibt auch keinen Grund, auf extreme Handarbeit wie bei einer magnetisierten Nadel und einer ruhigen Hand zu bestehen.
  • Selbst wenn der Großteil des tatsächlichen Codes von KI erzeugt wird, bleibt eigenes Codieren ein nützliches Werkzeug.

Denkfähigkeit und Verantwortungsgefühl durch eigenes Codieren bewahren

• Wer auf die Rolle eines umgekehrten Kentauren reduziert wird und nur noch Code liest und freigibt, verliert Konzentration und Verantwortungsgefühl. Minderwertiger Code passiert dann leichter die Prüfung, und feine Anpassungen werden schwieriger.
  • Wenn Details nicht sorgfältig beachtet werden, häufen sich Schwachstellen an, und langfristig wirkt sich minderwertiger Code auch negativ auf Agenten aus.
  • Wenn Menschen Ansätze selbst ausprobieren und Agenten anschließend etablierte Muster wiederholen lassen, bleiben sie am Ergebnis beteiligt und übernehmen weiter Verantwortung.
• Englisch ist eine unzureichend spezifizierte Sprache, um Berechnungen präzise auszudrücken.
  • Bei algorithmischer Arbeit muss man Ideen als ausführbare Schritte entwerfen und durchdenken.
  • Je nach Situation kann man zwischen Low-Level-Sprachen mit großem Designspielraum und High-Level-Sprachen mit stärker eingeschränkter Rechenumgebung wählen, um die nötige Präzision zu steuern.
• Wenn man Coding-Agenten wie Compiler behandelt, fördert das eine Haltung, nach der auch miserabel geschriebener Code bedenkenlos ausgerollt werden könne.
  • Agenten sind eher neu eingestellte Praktikant:innen als Compiler.
  • Sie lesen bestehenden Code, der unvollständig und qualitativ schwach sein kann, und erzeugen auf Basis ungenauer Änderungsbeschreibungen neue Änderungen.
  • Menschen können ihr Denken und ihren Geschmack nicht einfach an eine Gruppe von Praktikant:innen delegieren; sie müssen sich direkt einbringen, statt nur Konsument:innen zu bleiben.
• Agenten folgen nur schwer aus eigener Initiative der Boy-Scout-Regel, Code in besserem Zustand zu hinterlassen, als sie ihn vorgefunden haben, und es fühlt sich auch belastend an, ihnen das zu überlassen.
  • Sie tendieren dazu, die aktuelle Änderung möglichst sicher zu machen und bestehende Entscheidungen konservativ zu bewahren.
  • In einer Codebasis verwendete ein Mensch beiläufig Browser-Local-Storage für einen Teil des Zustands, während der restliche Zustand in einer Backend-Datenbank gespeichert wurde. Der Agent hielt an dieser Entscheidung fest und fügte Wrapper und indirekte Schichten hinzu, wodurch sich die Anzahl der Codezeilen etwa verdreifachte.
  • Diese Konservativität kann einmalige Fehlentscheidungen von Menschen noch verstärken.
• Das direkte Löschen und Erkunden von Code hilft dabei, zu besserer Architektur zu gelangen, als wenn man nur auf Englisch Anweisungen gibt.
  • Je mehr Aufmerksamkeit man dem Code schenkt, desto stärker werden Denkfähigkeit, das Gefühl als Autor:in und die Fähigkeit, die Softwarefabrik zu führen.
• In der Softwarefabrik sind Details wichtig – von Architekturmustern bis hin zu Algorithmen und Performance.
  • Agenten haben den Bedarf an Evaluation, Messung und Schutzmechanismen erhöht und sogar in persönlichen Projekten dazu angeregt, CI nicht nachträglich, sondern früh einzuführen.
  • Dadurch hat sich der Zustand der Softwareentwicklung deutlich verbessert, doch in jeder Montagelinie bleiben weiterhin Schwachstellen.
• Auch in einer Autofabrik muss man manchmal die Montagelinie zerlegen, sich tief in die Details eines Verbrennungsmotors einarbeiten, um 10 % Verbesserung zu erreichen, oder den ganzen Tag Bremsbelagtests beobachten, um herauszufinden, warum Probleme vor Ort nicht früher erkannt wurden.
  • Auch in der Software darf man keine willkürliche Grenze ziehen, was man selbst anfassen darf, wenn man Details und Gesamtstruktur miteinander verbinden will.

[choijaekyu]

Weil mir die Token ausgegangen sind T_T

[GN⁺]

Hacker-News-Meinungen

• Es scheint selbstverständlich, dass man etwas auch nicht prüfen kann, wenn man keinen Code schreiben kann. Trotzdem gibt es Leute und Firmen, die meinen, Claude könne schreiben und Codex prüfen. Warum man das Ergebnis dann aber nicht als Assembler oder kompiliertes Binärformat, sondern in Hochsprachen wie Python oder Java verlangt, liegt letztlich daran, dass Menschen den Code lesen können müssen
  Es ist widersprüchlich, von Entwicklern zu erwarten, dass sie Code lesen, debuggen und darüber nachdenken, ihnen aber gleichzeitig nicht die Übung zu geben, diese Fähigkeit auszubilden

  • Dass man Claude keinen Assembler schreiben lässt, liegt daran, dass es fast keine Lernmaterialien zum Erstellen von CRUD-Apps in Assembler gibt. Ich möchte zwar nicht, dass LLMs Jobs verdrängen, aber es ist nun einmal Realität, dass moderne Modelle Aufgaben gut beherrschen, die im Internet unzählige Male wiederholt und dokumentiert wurden, und ein großer Teil der Softwareentwicklung der letzten Jahrzehnte tatsächlich aus der standardisierten Produktion von CRUD-Apps bestand
    Ob sich die Branche weiterentwickeln kann, wenn man die gesamte kreative Arbeit LLMs überlässt, ist fraglich
  • Code zu schreiben ist zugleich ein Akt des Denkens; wenn man aufhört, Code zu schreiben, hört auch das Denken auf. Selbst wenn man auf einer höheren Ebene denkt, werden LLMs irgendwann auch in diesem High-Level-Design besser sein, sodass der derzeitige Vorsprung nur vorübergehend ist
  • Letztlich scheint es ein Unterschied in der Art des Denkens zu sein. Für manche ist Code präziser und leichter lesbar als englische Beschreibungen, und erfahrene Entwickler können seine Funktionsweise schon beim Überfliegen erfassen; andere tun sich mit Code schwer und bevorzugen natürliche Sprache
    Das heißt nicht, dass die eine Seite besser ist; vielleicht führen Menschen, die weniger auf Details achten, die Welt, oder je nach Problem ist ein anderer Grad an Genauigkeit nötig
  • Casey Muratori und Demetri Spanos haben das wohl in einem Video behandelt: Dass man Binärdateien meidet, hat weniger mit Vertrauen in LLMs zu tun als mit maschinenabhängigem Maschinencode und Offsets sowie der Schwierigkeit der Kontextinterpretation. So wie sich dekompilierter C-Code aus Ghidra anders versteht als vom Entwickler geschriebener C-Quellcode, können Hochsprachen die Absicht des Codes ausdrücken
    Compiler helfen LLMs dabei, Code zu schreiben, der tatsächlich kompiliert und ausgeführt wird; würde man direkt Maschinencode ausgeben, wäre die Wahrscheinlichkeit groß, dass er gar nicht läuft. Wenn man allerdings überhaupt keinen Code schreiben kann, wird die Prüfung natürlich noch viel schwieriger
  • Es gibt tatsächlich Leute, die fordern, Claude solle Assembler oder Binärcode direkt ausgeben. Allerdings wäre das wahrscheinlich weniger portabel als eine Hochsprache, die sich für verschiedene Maschinen in Assembler kompilieren lässt

• „Wie nennt die Branche eine Projekt-Spezifikation, die umfassend und präzise genug ist, um ein Programm zu erzeugen? Code.“ — CommitStrip
  Wenn er richtig geschrieben ist, sollte der Kern von Code die zugrunde liegende Geschäftslogik möglichst einfach ausdrücken. Es mag nicht nötig sein, sämtliche Support-Schichten zu prüfen, aber wenn man den Code nicht gelesen hat, kann man auch kaum behaupten, die Geschäftslogik vollständig zu verstehen

  • Link zum Original
  • Auch in einem anderen Text zu diesem Thema wurde empfohlen, Code statt Spezifikationen zu verwenden. Man kann Agenten per Code instruieren oder ihnen Beispiele geben, denen sie folgen sollen
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • Deshalb braucht man Lisp. Man erstellt zuerst eine Programmiersprache, in der die Grundbausteine der Geschäftslogik zugleich die Grundbausteine der Sprache sind, und schreibt dann in dieser neuen Sprache ein einfaches Programm, das beschreibt, was das Geschäft tut

• Die wichtige Frage ist, wer noch für manuell geschriebenen Code zahlen wird. Kunden zahlen nicht für das Schreiben oder Erzeugen von Code an sich, sondern für Problemlösung; wer das Problem mit den geringsten Kosten und dem wenigsten Aufwand löst, bekommt das Geschäft, und der Vorteil von AI-Tools, Zeitpläne zu verdichten, ist schwer zu ignorieren
  Ich bin seit den 1990ern in dieser Branche, und durchschnittliche Entwickler, die durchschnittliche Ergebnisse produzieren, gab es schon immer in großer Zahl. Handgeschriebenen Code romantisiert man oft übermäßig, aber reale Codebasen wurden mit der Zeit häufig schwer wartbar und voller Bugs, und schlampig umgesetzte Projekte sind keineswegs ein neues Phänomen

  • Ich denke eher, dass es die Produktivität erhöht, weniger Code selbst zu schreiben. Wenn man einen Tag darauf verwendet, die Architektur manuell neu zu ordnen, spart man Tausende Dollar an Token-Kosten und mehrere Wochen Ärger
    Im Moment ist es, als wolle man mit auf den Rücken gebundenen Händen eine Softwarefabrik bauen
  • Durchschnittliche Entwickler produzieren jetzt zehnmal mehr durchschnittliche Ergebnisse
  • In regulierten Branchen, in denen Softwarequalität wichtig ist, etwa Medizin, Luftfahrt oder Kernenergie, hoffe ich, dass man weiterhin für manuelles Coding bezahlt. Dieser Markt ist allerdings vergleichsweise klein

• Um sich zu konzentrieren und wirklich zu verstehen, reicht es nicht, einem Agenten aus der Distanz zuzusehen und passiv Code zu lesen; man muss Code selbst erleben. Letztlich heißt das: Man muss sein eigenes mentales Modell trainieren
  Beim Codieren fällt das Unterbewusstsein viele Urteile wie „das fühlt sich richtig an“; das entsteht nur durch Wiederholung und tiefe Konzentration, und reiner Code-Review oder das Lesen von Dokumentation stoßen dabei an Grenzen. Hat man ein solches mentales Modell aufgebaut, kann man allein anhand der Fehlermeldung einer Produktionsstörung oft sofort die Ursache erkennen; bei generiertem Code muss man dagegen lange mit langsamem, bewusstem Denken suchen
  Damit LLMs wirklich nützlich sind, müsste man annehmen können, dass sie die gesamte Code-Wartung übernehmen und wie eine externe Bibliothek funktionieren; andernfalls wird es zwangsläufig immer wieder Probleme geben

  • Bei Menschen hat man diese Trennung bereits versucht, und sie funktionierte so schlecht, dass sogar der abschätzige Begriff Elfenbeinturm-Architekt entstand. In realen Systemen führt das zu theoretischen Entwürfen, die sich nicht umsetzen lassen, das Implementierungsteam oder das LLM umgeht die Architektur, und während Architekt und Umsetzer aneinander vorbeireden, verlangsamt sich die Entwicklung massiv
  • Im Bereich Observability würde man sagen: Wenn sich die Ursache nicht allein aus dem dynamischen Laufzeitverhalten finden lässt, muss man das System transparenter und beobachtbarer machen. Da Menschen versetzt werden oder gehen können, sollte man ohnehin nicht von den mentalen Modellen einzelner Spitzenkräfte abhängen — dieses Prinzip galt schon immer
    Welche Seite recht hat, weiß ich noch nicht; ich schaue mir das weiter an

• Auch 2026 ist AI-generierter Code immer noch miserabel. Ob Fable oder ein angepasstes Pi/opencode-LeetCode-Harness — die Ergebnisse sind schrecklich, und wenn man den Qualitätsunterschied zwischen dem eigenen Code und AI-Code nicht erkennen kann, ist das keine gute Nachricht

  • Mein Code war schlechter als AI oder ist es vielleicht immer noch, aber ich werde immerhin bezahlt, also ist diese schlechte Nachricht nicht weiter wichtig

• Es wurde in den Regeln festgehalten, dass der Agent das Boy-Scout-Prinzip befolgen, Profiling ausführen, die Code-Coverage prüfen, kritisch reviewen sowie Berichte und Folgeaufgaben verfassen soll. Heutige State-of-the-Art-LLMs befolgen solche Regeln viel besser als 90 % der Leute, mit denen ich zusammengearbeitet habe, und ich frage mich, ob das wirklich etwas Schlechtes bedeutet

  • Der Agent ist derzeit auf maximale Sicherheit der aktuellen Änderung ausgerichtet. Noch vor dem ersten Kaffee habe ich einmal gedankenlos vorgeschlagen, den lokalen Speicher des Browsers zu verwenden, und obwohl der restliche Zustand komplett in der Backend-Datenbank lag, hat er Wrapper und indirekte Schichten hinzugefügt, um diese falsche Entscheidung beizubehalten, und dabei die Anzahl der Codezeilen fast verdreifacht
    Agenten sind konservativ und können einmalige menschliche Fehler verstärken. Es gibt viele Wege, das zu lösen, und Menschen denken unterschiedlich, daher sind sowohl Ansätze möglich, bei denen man den Code nicht liest, als auch solche, bei denen man ihn direkt liest und schreibt; zugleich ist der Vorteil groß, den man aus der Präzision von Code gewinnt, der nicht durch ein LLM gegangen ist

• Ich muss den Code selbst schreiben, weil LLMs sonst viel zu viel Code erzeugen. Nur wenn man das Problem vollständig versteht und verallgemeinert, kann man verhindern, dass an "Hello World" 10.000 Zeilen und 5 Abstraktionsschichten hängen
  Da LLMs Token-Prädiktoren sind, neigen sie dazu, mehr Code-Tokens auszugeben, je mehr zu lösende Probleme es gibt

  • LLMs mögen eher die defensive Umhüllung von Code, statt das Ganze ganzheitlich zu durchdenken, und blähen ihn deshalb leicht auf. Menschliche Entwickler können dagegen beim Arbeiten dem Boy-Scout-Prinzip folgen und den umgebenden Code gleich mit aufräumen
  • Peter Naur erklärte schon vor Jahrzehnten, dass Programmierung nicht die mechanische Produktion von Quellcode, Spezifikationen und Dokumentation ist, sondern eine menschliche Tätigkeit des Aufbaus einer tiefen mentalen Theorie darüber, wie die einzelnen Teile eines Systems mit Problemen der realen Welt zusammenhängen. Das eigentliche Ergebnis der Programmierung ist das gemeinsame mentale Modell der Entwickler
    Diejenigen, die ein zu lösendes Problem haben, sind Menschen; wenn man das Problem nicht versteht, kann ein X/Y-Problem entstehen, bei dem das LLM ein Problem löst, das mit den tatsächlichen Anforderungen nichts zu tun hat. LLMs abstrahieren Nicht-Kernaspekte wie Bibliotheken oder Hochsprachen besser, aber der Kern des Problems muss weiterhin formal ausgedrückt werden
    Auch Vibe Coding, bei dem man schrittweise Einschränkungen hinzufügt, bis das gewünschte Ergebnis erreicht ist, ist letztlich lockere und informelle Programmierung. Besser ist es, dem LLM das Umfeld des Problems zu überlassen und den Kern selbst zu schreiben und zu verstehen
  • 99 % meiner Arbeit sind C#, aber dank LLMs kann ich mich jetzt ganz ohne eigenes Zutun als den Low-Level-Programmierer bezeichnen, der ich immer sein wollte
  • Ich hatte darum gebeten, ein Projekt so aufzusetzen, dass es wie andere Module der Firma in K8s läuft, und das LLM schrieb sogar Unit-Tests für die Hello-World-Implementierung
  • Ich habe einem aktuellen US-Modell eine kleine Aufgabe gegeben, nämlich clientseitige Informationen anzuzeigen, und es änderte den Code auf beiden Seiten so, dass der Server die Informationen beim initialen Handshake an den Client überträgt, und es funktionierte sogar tatsächlich. Dabei waren diese Informationen bereits auf dem Client vorhanden, also wäre es eine Aufgabe für genau eine Zeile Client-Code gewesen
    Oberflächlich hat es die Anfrage perfekt gelöst, aber der Code war unnötig und schlampig. Unternehmen, die verbrauchsabhängige Tokens verkaufen, haben einen ökonomischen Anreiz, Rube-Goldberg-artige Lösungen zu erzeugen, die das Problem nur grob lösen, dabei aber möglichst viele Tokens verbrauchen; und nicht nur bei der Generierung, sondern auch später, wenn man mit riesigem Code voller neuer Bugs umgehen muss, werden noch mehr Tokens verbraucht
    Es ist schon komisch, wie Leute, die früher über Copy-and-Paste-Code gespottet haben, jetzt für schlampig zusammengeklebten Code schwärmen

• Wenn ich mir die Entwicklung von ChatGPT 3.5 im November 2022 bis heute ansehe, frage ich mich, ob ich in vier Jahren noch Code reviewen werde. Auch ohne AI-Extremist zu sein, scheint es gut möglich, dass Software Engineering und Entwicklung in ihrer heutigen Form in 5 bis 10 Jahren verschwinden, wenn das aktuelle Tempo anhält
  Für Menschen könnte nur noch so etwas wie UI-Design übrig bleiben, während alles andere abstrahiert wird und die AI die eigentliche Arbeit übernimmt

  • Wenn es eine Maschine wäre, die Wünsche auf einmal erfüllt, dann wäre eine einzelne Anfrage leicht zu verarbeiten; Software ist jedoch die Akkumulation tausender Wünsche, und in jeder Ecke müssen feine Entscheidungen getroffen werden, dies zu wollen und jenes nicht. Beim aktuellen LLM-Ansatz müssen all diese Entscheidungen weiterhin von Menschen verwaltet werden, aber in Zukunft könnten Methoden entstehen, die wir uns heute noch nicht vorstellen können
  • Das setzt voraus, dass die Entwicklung im gleichen Tempo weitergeht, aber für mich sieht es so aus, als seien wir bereits in eine gewisse Stagnationsphase eingetreten. Mit jedem größeren Modell steigen die Kosten exponentiell, und es scheint sich auch ziemlich klar zu zeigen, dass das Geschäft, immer größere Modelle zu trainieren, nicht profitabel ist
  • Ich hasse schon jetzt die Zukunft, in der man nicht einmal mehr direkt inkompetente Menschen dafür verantwortlich machen kann, eine Website gebaut zu haben, für deren jede Funktion JavaScript nötig ist und in deren Eingabefeld man nicht einmal ordentlich tippen kann. Wenn Managements, die Äußerlichkeiten über Funktion stellen, und Trainingsdaten, die vor allem aus solchen Websites bestehen, dazu führen, dass LLMs denselben Müll in noch viel größerem Maßstab produzieren, dann fühlt sich das nach einer existenziellen Krise an
    Das Web ist ohnehin schon chaotisch genug; ich hätte wenigstens gern, dass wir mindestens noch so wie heute unfähige Menschen dafür verantwortlich machen können

• Unabhängig vom KPI-Druck schreibe ich bei jeder Gelegenheit selbst Code und erwarte von AI höchstens eine clevere Code-Autovervollständigung

• Ich schreibe den Code selbst, weil ich Coding liebe und dabei wirklich glücklich bin. Es gibt keinen Grund, auf etwas zu verzichten, das ich mag

  • Es hat einen magischen Reiz, einem Computer Arbeit zu geben und zu sehen, wie er sie milliardenfach schneller als mit jedem anderen Mittel erledigt
  • Ich bin in dieses Feld gegangen, weil es mir Spaß macht, Programme zu entwerfen und Code zu schreiben. Beim Einsatz von AI bin ich zurückgefallen und muss mehr dazulernen, aber mit dem Coden von Hand will ich niemals aufhören
  • Wenn es einen glücklich macht, fürs Coden sogar noch bezahlt zu werden, kann die Firma aufhören, diese Belohnung zu geben. Wenn man für den Erhalt eines Visums auf dieses Einkommen angewiesen ist, ist die Wahrscheinlichkeit sehr hoch, dass man sich gezwungenermaßen an den Wandel anpasst und das Coden aufgibt