KI hat Software Engineering nicht vereinfacht: Sie hat nur schlechtes Engineering leichter gemacht

• LLMs haben das Schreiben von Code beschleunigt, aber die inhärente Komplexität des Software Engineerings nicht verringert
• Da Codegenerierung einfacher geworden ist, verbreitet sich die Illusion, dass Fachwissen nicht mehr nötig sei, und einige Organisationen bauen deshalb bereits Engineering-Teams ab
• Die eigentliche Schwierigkeit liegt nicht im Schreiben von Code, sondern in Systemdesign, Spezifikation, Verifikation und der Wahrung von Konsistenz; KI beschleunigt die Belastung in diesen Bereichen eher noch
• Die Fehlanpassung zwischen Spezifikation, Tests und Implementierung (spec drift) verschärft sich schnell, wodurch das Risiko steigt, dass die Zuverlässigkeit von Systemen zusammenbricht
• In mehr als 40 Jahren Berufserfahrung zeigte sich dieses Muster immer wieder; schon in der Visual-Basic-Ära der 1990er gab es dieselbe Behauptung, Fachwissen sei überflüssig, bis sich die Notwendigkeit technischer Disziplin am Ende erneut bestätigte
• LLMs sind hervorragende Werkzeuge für die Erkundung von Designs und die Beschleunigung früher Implementierungsphasen, sollten aber nicht als Ersatz für technische Disziplin, sondern zu ihrer Stärkung eingesetzt werden

---

Der gefährliche Irrtum der Branche

• Seit LLMs Code erzeugen können, herrscht in der Softwarebranche die Stimmung, Software Engineering selbst werde nicht mehr benötigt
• Disziplinen wie Architektur, Spezifikation und sorgfältige Verifikation werden behandelt, als seien sie Relikte aus einer vergangenen Ära
• In manchen Organisationen ist diese Idee bereits in Richtlinien eingeflossen, was mit Verweis auf Fortschritte bei KI zu groß angelegten Entlassungen von Engineers führt
• KI ist dabei nur die neueste Ausrede, um schlechten Geschäftsentscheidungen oder Marktdruck auszuweichen
• Das Eingeben von Prompts in eine KI wird zunehmend so dargestellt, als ersetze es die Disziplinen, die Software Engineering bisher ausmachten

Ein sich wiederholendes historisches Muster

• In mehr als 40 Jahren Berufserfahrung war immer wieder dasselbe Muster zu beobachten: neues Tool erscheint → Erklärung, dass schwierige Probleme gelöst seien → sprunghafte Produktivität und beeindruckende Demos → Personalabbau → zunehmende Systemkomplexität → am Ende Ergebnisse, die den Erwartungen nicht entsprechen
• Die Tools und Behauptungen ändern sich, aber das Muster selbst bleibt fast unverändert

Die Analogie zur Flugzeugwartung

• In der Flugzeugwartung gab es große Fortschritte bei Tools, computergestützter Diagnose, digitalen Handbüchern und der Interpretation von KI-Telemetrie, doch der Bedarf an erfahrenen Technikern ist unverändert
• Verkehrsflugzeuge sind extrem komplexe Systeme mit Millionen von Teilen und Tausenden miteinander verbundener Subsysteme
• Die Diagnose von Problemen erfordert nicht nur das richtige Tool oder das Abarbeiten einer Checkliste, sondern Erfahrung und Urteilsvermögen darüber, wie sich das System unter realen Betriebsbedingungen verhält
• Keine Fluggesellschaft würde wegen besserer Tools ausgebildete Techniker abschaffen und vorschlagen, Reparaturen Gate Agents zu überlassen
• Genau eine sehr ähnliche Behauptung stellt die Softwarebranche derzeit jedoch über sich selbst auf

DIY vs. professionelle Systeme

• Hobbyprojekte, kleine persönliche Apps und Experimente mit neuen Ideen sind überhaupt kein Problem; einige der spannendsten Ideen in der Geschichte des Computings sind aus genau solchen Versuchen entstanden
• Professionelle Softwareentwicklung ist jedoch eine völlig andere Kategorie: Zahlungsabwicklung, Speicherung sensibler Daten, Infrastrukturmanagement und der Betrieb von Systemen, auf die Menschen täglich angewiesen sind
• Kundinnen und Kunden erwarten selbstverständlich, dass Systeme korrekt funktionieren, auch während ihrer Weiterentwicklung korrekt bleiben und die Menschen, die sie bauen, verstehen, wie sie funktionieren
• Diese Erwartung ist die Grundbedingung professionellen Engineerings und der Punkt, an dem Disziplin und Fachwissen unvermeidbar werden

Code war nie der schwierige Teil

• Dass das Schreiben von Code der schwierige Teil der Softwareentwicklung sei, ist ein alter Irrtum
• Das Eintippen von Syntax war schon immer einer der am wenigsten interessanten Teile des Systembaus; die eigentliche Schwierigkeit liegt darin, das Verhalten eines Systems festzulegen, die Interaktion von Komponenten zu entwerfen und Verstehbarkeit trotz wachsender Komplexität zu erhalten
• Das ist kein Coding-Problem, sondern ein Engineering-Problem
• Weniger Aufwand für die Codeproduktion beseitigt diese Probleme nicht, sondern ermöglicht nur, größere und komplexere Systeme schneller zu bauen
• Das als Produktivitätssteigerung zu sehen, ist eine Illusion: Die Last verschiebt sich nur an einen anderen Ort
  • Die kognitive Last, die für Code Reviews und den Umgang mit generiertem Code nötig ist, kann die Produktivität stärker senken als das eigentliche Schreiben von Code
  • Wenn lediglich die Geschwindigkeit steigt, ohne dass das zugrunde liegende Verhalten ausreichend verstanden wird, beschleunigt das nur den Zeitpunkt, an dem Komplexität unbeherrschbar wird, und das Ergebnis ist trotzdem falsch

Dieses Muster gab es schon: die Visual-Basic-Ära

• Schon in den 1990ern gab es bei Visual Basic ein ähnliches Versprechen: Programmierung sei demokratisiert worden und Fachwissen werde überflüssig
• Tatsächlich ermöglichte Visual Basic viele Anwendungen, die sonst wahrscheinlich nie gebaut worden wären
• Doch als Systeme größer und stärker vernetzt wurden, zeigte sich erneut, dass Software-Artefakte zu produzieren nicht dasselbe ist wie verlässliche Systeme zu entwickeln
• Heute erleben wir eine verstärkte Version desselben Musters: Nicht nur die Hürde zum Bau von Anwendungen wurde gesenkt, sondern die Hürde zur Codeproduktion selbst
• Daraus entsteht der verführerische Glaube, Fachwissen sei nun nicht mehr nötig

Das Alignment-Problem

• Verlässliche Software hängt von Alignment ab, einem Thema, das außerhalb des Engineerings kaum diskutiert wird
• Ein System beginnt mit einer Vorstellung seines Verhaltens → wird als Spezifikation dokumentiert → Engineers übersetzen diese Spezifikation in Tests und Produktionscode
• Für die langfristige Zuverlässigkeit eines Systems müssen Spezifikation, Tests und Implementierung ständig aufeinander abgestimmt bleiben
• Sobald diese drei Ebenen auseinanderdriften, verliert das System nach und nach seine Integrität
  • Die Spezifikation beschreibt Verhalten, das nicht mehr implementiert ist
  • Tests verifizieren nur noch Teile des Verhaltens und lassen anderes aus
  • Später hinzukommende Engineers lesen Code und raten, wie sich das System verhält, ob dieser nun noch das ursprüngliche Design widerspiegelt oder nicht
• Mit der Zeit häufen sich diese Vermutungen, bis ein System entsteht, das niemand wirklich mehr versteht
• Dieses Phänomen lässt sich als „spec drift“ bezeichnen: Die Beschreibung eines Systems und das System selbst entfernen sich schrittweise voneinander
  • Der Code wurde geändert, aber die Spezifikation blieb gleich
  • Die Spezifikation hat sich weiterentwickelt, aber die Tests blieben unverändert
  • Das Verhalten hat sich schrittweise verändert, sodass niemand mehr sicher sagen kann, was ursprünglich beabsichtigt war
• Wenn das Alignment bricht, hält Zuverlässigkeit nicht lange stand

KI beschleunigt den Drift

• LLMs beschleunigen die Codeproduktion dramatisch; genau das ist ihre größte Stärke und zugleich der Punkt, an dem das Risiko entsteht
• Wenn Code schneller produziert wird als die technische Disziplin, die ihn umgibt, wird auch die Kraft beschleunigt, die spec drift erzeugt
• Änderungen, die früher sorgfältiges Nachdenken und manuelle Implementierung erforderten, sind jetzt in wenigen Sekunden möglich
• Ganze Systemabschnitte können neu geschrieben werden, bevor irgendjemand überprüft hat, ob das Verhalten noch der Spezifikation entspricht
• Der Code kann vernünftig wirken, kompilieren, gut lesbar sein und sogar bestehende Tests bestehen, während das Alignment, das das System einst zusammenhielt, bereits verschwunden ist
• Was wie Produktivität aussieht, ist in Wahrheit womöglich nur die Fähigkeit, sich schneller als zuvor in Richtung Fehlanpassung zu bewegen

Wo KI tatsächlich hilft

• LLMs sind kein Fehler; wenn sie mit Bedacht eingesetzt werden, können sie die Art und Weise, wie Engineers Systeme erkunden und entwerfen, dramatisch verbessern
• Besonders stark sind sie beim Durchdenken von Problemen, beim Erkunden von Designalternativen, beim Zusammenfassen komplexer Systeme und beim Erstellen von Entwürfen, die frühe Implementierungsphasen beschleunigen
• Schwierig bleiben Bereiche, die über längere Zeit strenge Disziplin und Konsistenz verlangen
• Die Abstimmung zwischen Spezifikation, Tests und Implementierung aufrechtzuerhalten, bleibt Engineering-Verantwortung; kein Tool kann diese Verantwortung ersetzen, sondern allenfalls unterstützen
• Die eigentliche Chance besteht darin, LLMs nicht als stillen Ersatz des Engineering-Prozesses zu nutzen, sondern zu seiner Stärkung

Konversationelles Software Engineering

• Eine der interessanten Möglichkeiten, die LLMs eröffnet haben: Teile des Software Engineerings könnten konversationeller werden
• Über Jahrzehnte hinweg waren Werkzeuge für Systemdesign starr: Spezifikationen waren Dokumente, Architektur waren Diagramme, und das Denken, das dorthin führte, verschwand in Meetings und Flurgesprächen
• Mit LLMs können Engineers Ideen interaktiv erkunden, Annahmen testen und Designarbeit auf eine Weise leisten, die einem natürlichen Gespräch näherkommt
• Doch Konversation ist kein Engineering: Konversation ist eine Methode zur Erkundung von Ideen, Engineering beginnt erst dann, wenn Ideen in einer Form festgehalten werden, die verifiziert, getestet und gewartet werden kann
• Die Aufgabe der nächsten Generation von Engineering-Tools wird darin bestehen, zu lernen, wie sich diese beiden Welten verbinden lassen, ohne die Disziplin zu verlieren, die komplexe Systeme verlangen

Fachwissen ist weiterhin wichtig

• Professionelle Software braucht weiterhin Engineers, die verstehen, wie die von ihnen gebauten Systeme tatsächlich funktionieren
• Tools können die Entwicklung beschleunigen, aber sie beseitigen nicht das Fachwissen, das nötig ist, um komplexe Systeme zu entwerfen, zu durchdenken und zu warten
• Die Branche ist gefährlich nah daran, diese Tatsache zu vergessen
• LLMs können erfahrene Engineers deutlich produktiver machen, ersetzen aber nicht die technische Disziplin, die für den Bau verlässlicher Systeme erforderlich ist
• Diese Tools sollten wirksam genutzt und nicht verehrt werden

[GN⁺]

Hacker-News-Kommentare

• Ich stimme der Prämisse des Artikels nicht zu. Ich denke, Engineering insgesamt ist einfacher geworden, im Guten wie im Schlechten. Früher gab es auch schon viele Leute, die einfach massenhaft Null-Checks eingebaut haben, statt etwas wirklich zu verstehen. Jetzt wurde das nur auf große Skalierung ausgedehnt. Umgekehrt wird großartiges Engineering ebenfalls stärker verstärkt, und ich habe Fälle gesehen, in denen Features, die früher Wochen gebraucht hätten, in wenigen Tagen gebaut wurden

  • Ich finde den Artikel etwas übertrieben. Auch gutes Engineering kann von LLM-basierten Agenten profitieren, aber die Validierung der Ergebnisse bleibt weiterhin Aufgabe des Menschen. Schlechtes Engineering überspringt genau diesen Schritt, und aus Sicht von Amdahls Gesetz beschleunigen LLMs schlechtes Engineering daher deutlich stärker
  • Schlechtes Engineering ist viel einfacher geworden, gutes Engineering ein wenig einfacher. Deshalb machen Leute, die früher gutes Engineering betrieben haben, jetzt dreimal so viel schlechtes Engineering
  • Bei der Entwicklung von Unternehmens-Apps habe ich erlebt, dass Mock-Tests nur prüfen, ob der erwartete Wert zurückgegeben wird. Ich frage mich, welchen Sinn das überhaupt hat
  • Man vergisst leicht, dass LLMs kein magisches Orakel sind. Wie man mit ihren Ausgaben umgeht, bestimmt die Qualität des Ergebnisses. Manchmal kann man sie unverändert verwenden, aber meistens muss man sie anpassen. Dadurch tappt man leicht in die Falle „Wenn das LLM es gesagt hat, wird es schon stimmen“, und schlechtes Engineering wird einfacher
  • Selbst wenn man dem Originalartikel zustimmt, gibt es in der Praxis viele Anwendungsbereiche, in denen die Qualität von Software, ob gut oder schlecht, keine große Rolle spielt. Oft reicht es, wenn sie einfach funktioniert

• Es gibt Fälle, in denen selbst hundert Unit-Tests die Korrektheit von Code kaum beweisen können. Die meisten Entwickler wissen nicht, was ausreichend ist. Leute, die viel Vibe Coding betreiben, überlassen sogar das Testen der Maschine. Auf der Ebene des Systemdesigns braucht man Architekturen, die allgemeine Sicherheit und zeitliche Invarianten garantieren können. Die meisten zeichnen aber nur Kästen und Pfeile und zitieren „Best Practices“. Wie beim Sussman-Effekt, nach dem Software eher den Naturwissenschaften ähnelt, verbringt man mehr Zeit mit Beobachtung. GenAI als Werkzeug zu verwenden kann nützlich sein, aber das Denken einzustellen und sich auf das Werkzeug zu verlassen, ist gefährlich

  • Ich weiß nicht einmal, was Unit-Tests sind, aber dank AI kann ich Programme bauen, die mir bei der realen Arbeit enorm helfen. Elite-Programmierer antworten nicht einmal auf E-Mails, selbst wenn man sie dafür bezahlt

• Jedes Mal, wenn alle paar Jahre ein neues Werkzeug auftaucht, heißt es: „Der schwierige Teil des Software Engineerings ist gelöst.“ Die Produktivität schießt nach oben, die Demos beeindrucken, und die Branche lobt sich selbst. Aber kurz darauf folgen Stellenstreichungen. Es wäre schön, wenn es einen echten Durchbruch gäbe, aber wenn das Ergebnis Entlassungen sind, hat das wenig Wert. Am Ende bleibt dieselbe Frage — wenn das Ziel darin besteht, Arbeitsplätze abzubauen, was ist dann die Vision der Unternehmen, wenn Menschen ihren Lebensunterhalt nicht mehr bestreiten können?

  • Das Ziel ist nicht die Beschäftigung einzelner Menschen. Der Aufbau von AGI ist das eigentliche Endziel, und auf diesem Weg haben Entwicklergehälter und Beschäftigung ihren Höhepunkt bereits überschritten. Einige wenige AI-Superentwickler sind die Ausnahme
  • Ich halte es für unmöglich, Komplexität zu beseitigen. Die Realität und die Menschen selbst sind komplex. Die Vorstellung, Software könne einfach sein, ist unrealistisch. Im größeren Bild wirkt das Ziel letztlich wie das Verschwinden der Mittelschicht
  • Wenn es keine Nachfrage gibt, muss man etwas anderes machen. Wenn man sich weigert, muss man hungern
  • Der Kapitalismus hängt von der Existenz einer Unterschicht ab. Sie setzt andere Arbeiter unter Druck, niedrigere Löhne und schlechtere Bedingungen zu akzeptieren. Programmierer waren vor dieser Realität nur vorübergehend geschützt. Diese Struktur hängt auch mit Migrationsarbeit zusammen, bei der Unternehmen Menschen gefährliche Arbeit aufdrücken und sie bei Ungehorsam abschieben können. Letztlich ist das alles ein System zur Senkung der Arbeitskosten

• Ich stimme der Aussage zu, dass „Coding nie der schwierige Teil war“. Experten wussten bereits, was sie bauen wollten; nur die wiederholte Arbeit war lästig

  • Code-Wartung ist weiterhin ein Problem von Menschen und Erfahrung. Wichtiger geworden ist die Frage: „Welchen Code sollte man nicht schreiben?“ Im Moment ist Codegenerierung so einfach, dass wir in einer Ära leben, in der man leicht Spaghetti-Code in Massen produziert
  • Hier liegt der Kern der LLM-Debatte. Manche wollen einfach nur ein Ergebnis, andere wollen Wartbarkeit und Stabilität. Beides wird gebraucht, und die Rollen von Prototyping und Produktion werden sich ganz natürlich trennen
  • Wirklich fähige Leute wollen es immer noch selbst machen. Nicht wegen LLMs, sondern weil das schon immer so war. Am meisten profitieren eher die Leute, die gesagt haben: „Syntax einzutippen macht keinen Spaß.“ Für mich ist das Tippen selbst der einzige interessante Teil

• Junior-Entwickler, die sich zu stark auf AI verlassen, werden später den Preis dafür zahlen, dass ihnen die Grundlagen fehlen. Am Ende genießen nur erfahrene Leute echte Jobsicherheit

• Der Behauptung „Code schreiben war nie der schwierige Teil“ kann ich nur schwer zustimmen. Natürlich ist es nicht immer schwierig, aber unter Zeitdruck wird das Schreiben von Code zum Flaschenhals. AI macht Versuche möglich, die früher unmöglich waren, und verschafft mehr Engineering-Zeit

  • Es ist widersprüchlich, etwas als „schwer ernst zu nehmen“ zu bezeichnen und am Ende doch zuzustimmen. Der Originaltext enthält viel feinere Nuancen
  • Code schreiben war die zeitaufwendigste Aufgabe, und AI macht genau das deutlich. Tippen kann jeder, aber die Fähigkeit, Code zu lesen, ist die eigentliche Kompetenz. Wie ein Holzfäller mit einer Kettensäge statt einer Axt: effizienter, aber mit größerem Schadenspotenzial

• AI hat auch gutes Engineering leichter gemacht. Letztlich ist sie ein Verstärker von Verhalten

  • Gute Ingenieure können dadurch noch besser werden, aber die meisten wissen nicht einmal, was Property Testing ist. Wie nützlich AI für solche Leute wirklich ist, ist fraglich
  • Das Internet hat das Wissen der ganzen Welt vernetzt, aber die Menschen sind am Ende doch in Plauderei und konsumierende Inhalte abgerutscht. Wenn man die menschliche Natur berücksichtigt, wird AI wohl einen ähnlichen Weg nehmen
  • Kreative Probleme werden oft gelöst, während man den Code selbst schreibt. Nutzt man AI, wird genau dieser Denkprozess weniger aktiviert
  • Daten wie der DORA-Report stützen das ebenfalls
  • Der Satz „AI ist ein Verstärker bestehenden Verhaltens“ passt wirklich hervorragend. Den muss ich mir merken

• Ich bin ein AI-Skeptiker, aber ich glaube nicht, dass sie die Jobs meiner Kollegen wegnimmt. Stattdessen spart sie mir Zeit. Ich nutze sie als Recherche-Tool besser als Google, zur Erkundung von Codebasen, zum Erzeugen von Hilfsfunktionen und zur Prüfung von Fehlern

  • Sehe ich genauso. Ich denke, genau diese Nutzung ist letztlich der Endpunkt des AI-Einsatzes

• In letzter Zeit wird die Unterscheidung zwischen Software Engineering und Research klarer. Für explorative Forschung ist AI ein erstaunliches Werkzeug. Wenn ich Potenzial sehe, wechsle ich in den SWE-Modus, verstehe und bearbeite den Code und verfeinere ihn mit meiner Erfahrung. Die Rolle von AI ist begrenzt, aber weiterhin nützlich

  • LLMs können sofort eine viel größere Wissensbreite durchsuchen als Menschen. Das endgültige Urteil hängt jedoch von menschlichem Geschmack und Qualitätsgefühl ab

• Wie viele weitere Modellgenerationen braucht es wohl, bis diese Leute (die Pessimisten) aufgeben? Zwei? Drei?