Software Engineering war nie nur Coding

„Developer werden bald überflüssig, weil AI jetzt Code schreibt.“

Diese Behauptung begegnet einem inzwischen in erstaunlich vielen Varianten. Manchmal klingt sie wie eine Prognose, manchmal wie eine Drohung und erstaunlich oft wie Marketing.

Ganz abwegig ist ihr Ausgangspunkt nicht. AI schreibt Code. Und sie tut das mittlerweile gut genug, schnell genug und in ausreichendem Umfang, um Softwareentwicklung spürbar zu verändern. Coding Agents implementieren Features, erzeugen Tests, führen Refactorings durch, suchen Fehler, analysieren bestehende Systeme und bewegen sich über viele Dateien hinweg. Aufgaben, für die ich früher Stunden gebraucht hätte, lassen sich heute teilweise in deutlich kürzerer Zeit erledigen.

Ich arbeite gern damit. Sehr gern sogar.

Nur folgt aus schnellerer Codeproduktion noch lange nicht, dass damit Softwareentwicklung gelöst wäre.

Der Denkfehler beginnt viel früher:

Coding ist nicht Software Engineering.

Das Sichtbare war nie das Ganze

Code ist der sichtbarste Teil unserer Arbeit. Er liegt im Repository, lässt sich zählen, diffen, reviewen und ausführen. Deshalb ist es verständlich, dass Softwareentwicklung gern mit dem Schreiben von Code gleichgesetzt wird.

Nur war diese Gleichsetzung schon immer falsch.

Bevor sinnvoller Code entstehen kann, muss jemand verstehen, welches Problem eigentlich gelöst werden soll. Anforderungen müssen interpretiert, Widersprüche erkannt und fachliche Zusammenhänge verstanden werden. Systeme brauchen Grenzen. Daten müssen irgendwo entstehen, verarbeitet und gespeichert werden. Komponenten kommunizieren miteinander, externe Systeme fallen aus, Berechtigungen müssen funktionieren und bestehende Daten irgendwann migriert werden. Wartbarkeit, Performance, Betrieb und Fehlerfälle verschwinden nicht dadurch, dass eine Funktion schneller implementiert werden kann.

Und irgendwann muss entschieden werden, welche der möglichen Lösungen unter den gegebenen Bedingungen überhaupt sinnvoll ist.

Das alles ist Software Engineering.

AI macht diese Dinge nicht plötzlich wichtig. Sie waren es immer.

Was sich verändert, ist etwas anderes: Wenn Codeproduktion immer schneller und billiger wird, wird es zunehmend schwieriger, sie mit Engineering zu verwechseln.

Software Engineering wird durch AI nicht plötzlich wichtiger. Es war immer wichtig. Nur wird es schwieriger, Software Engineering mit Codeproduktion zu verwechseln, wenn die Codeproduktion selbst immer billiger wird.

Vielleicht ist das eine der interessantesten Nebenwirkungen der aktuellen Entwicklung.

Wir haben jahrzehntelang erklärt, dass Lines of Code keine sinnvolle Produktivitätsmetrik sind. Jetzt können wir in einer Stunde mehr davon erzeugen als früher in mehreren Tagen – und sind gelegentlich erstaunlich versucht, genau diese Menge wieder als Produktivität zu interpretieren.

Mehr Code ist aber zunächst einmal nur mehr Code. Mehr Agent Runs sind mehr Agent Runs. Und ein Repository, das nachmittags dreimal so groß ist wie morgens, hat damit noch keinen zusätzlichen Business Value bewiesen.

Agentic Work komprimiert Zeit

Die produktive Kraft von Agentic Work ist trotzdem real.

Ein gut formulierter Auftrag mit brauchbarem Context, klaren Constraints und einer passenden Architektur kann beeindruckend schnell umgesetzt werden. Ein Agent kann bekannte Patterns konsequent anwenden, Änderungen über viele Dateien koordinieren und monotone Arbeit erledigen, bei der ein Mensch irgendwann vor allem noch darüber nachdenkt, ob Kaffee bereits als Abhängigkeit des Build-Systems dokumentiert werden sollte.

Das funktioniert besonders gut, wenn klar ist, wohin die Reise gehen soll.

Leider gilt dasselbe in die andere Richtung.

Ein Agent kann eine falsche fachliche Annahme ebenso konsequent umsetzen. Er kann eine schlechte Abstraktion sauber durch mehrere Layer tragen und eine Architekturentscheidung, die bereits am Ausgangspunkt falsch war, mit Tests, Interfaces, Mappern und bemerkenswert ordentlicher Benennung versehen.

Danach ist der Irrtum nicht mehr nur falsch.

Er ist hervorragend strukturiert.

Ein Agent schützt uns nicht vor schlechten Entscheidungen. Im ungünstigsten Fall professionalisiert er nur deren Umsetzung.

Auch das Problem selbst ist nicht neu. Entwickler haben schon immer falsche Requirements umgesetzt, schlechte Abstraktionen gebaut und lokale Lösungen für Probleme geschaffen, die sie nicht vollständig verstanden hatten.

Neu ist vor allem die Geschwindigkeit.

Agentic Work komprimiert Zeit. Gute Entscheidungen wirken schneller – schlechte ebenfalls.

Genau deshalb haben Menschen derzeit einen deutlichen Vorteil, wenn sie mehr als den unmittelbar sichtbaren Code verstehen. Wer Abläufe, Systemgrenzen, Patterns, Datenflüsse, fachliche Zusammenhänge und Trade-offs kennt, kann einem Agent nicht nur genauer vermitteln, was er tun soll. Er erkennt auch früher, wenn dessen Interpretation in die falsche Richtung läuft.

Das beginnt bereits bei der Aufgabenstellung.

Wer die falsche Frage stellt, kann eine ausgezeichnete Antwort auf das falsche Problem bekommen.

Und das ist oft unangenehmer als eine offensichtlich schlechte Antwort. Offensichtliche Fehler fallen auf. Eine plausible, sauber implementierte und gut getestete Lösung für das falsche Problem kann erstaunlich weit kommen.

Zwischen 10× und „kann sowieso nichts“

Die öffentliche Diskussion macht es uns nicht gerade leichter, vernünftig mit dieser Technologie umzugehen.

Auf der einen Seite steht die inzwischen vertraute Welt der „10× Developer“, Ein-Personen-Teams und an einem Nachmittag gebauten SaaS-Produkte. Eine beeindruckende Demo wird dort gelegentlich direkt zur neuen Einheit für Softwareproduktivität erklärt.

In sozialen Netzwerken kursiert dazu eine schöne Anekdote: Ein CTO soll stolz den Link zu seiner gerade mit AI gebauten Anwendung verschickt haben – und der Link zeigte auf localhost:4200.

Ob das jemals wirklich passiert ist, weiß ich nicht. Vermutlich ist es längst eher Urban Myth als belastbarer Tatsachenbericht. Als Karikatur des aktuellen Hypes funktioniert die Geschichte trotzdem hervorragend.

Etwas startet im Browser. Also ist offenbar das Produkt fertig.

Nur beginnt ein erheblicher Teil von Software Engineering leider genau dort, wo die Demo endet.

Wie wird das System betrieben? Was passiert bei Last? Wer darf welche Daten sehen? Sind die Daten überhaupt korrekt? Was geschieht bei partiellen Fehlern? Wie migrieren wir bestehende Informationen? Was passiert beim nächsten Requirement? Welche Annahmen stecken in der erzeugten Lösung? Versteht in sechs Monaten noch jemand ihre Strukturen? Welche externen Systeme können ausfallen? Und löst die Anwendung überhaupt das fachliche Problem, für das sie gebaut wurde?

Ein funktionierender Happy Path beantwortet davon erstaunlich wenig.

Das andere Extrem ist allerdings kaum überzeugender.

„AI kann sowieso nichts. Ich code lieber selbst.“

Das darf man selbstverständlich tun.

Man darf Provider kritisch sehen, Datenschutz problematisch finden, Kosten hinterfragen, schlechte Ergebnisse ablehnen oder bestimmte Aufgaben ganz bewusst selbst erledigen. Nicht jeder sinnvolle Umgang mit AI muss darin bestehen, möglichst viel Arbeit an einen Agent zu delegieren.

Aber wer die Technologie grundsätzlich für wertlos erklärt, ohne ernsthaft mit ihr gearbeitet und ihre Möglichkeiten wie ihre Grenzen untersucht zu haben, vertritt keine besonders neutrale Position.

Er hat lediglich das Experiment übersprungen und ist direkt beim Ergebnis angekommen.

Halluzinationen beweisen nicht, dass AI bedeutungslos ist. Genauso wenig beweist ein erfolgreicher Greenfield-Demo-Run, dass Software Engineering gelöst wurde.

Beide Lager haben punktuell valide Argumente. Problematisch wird es dort, wo die Schlussfolgerung bereits feststeht, bevor das Werkzeug wirklich untersucht wurde.

Zwischen „Softwareentwicklung ist gelöst“ und „das kann sowieso nichts“ liegt ein wesentlich interessanterer Raum.

Dort muss man tatsächlich arbeiten.

Prüfen statt glauben

Ein wesentlicher Teil dieser Arbeit ist Verification.

AI-Systeme sind keine Wahrheitsmaschinen. Ein überzeugend formulierter Output wird nicht dadurch korrekt, dass er selbstsicher klingt. Auch ein leistungsfähiger Agent kann Annahmen falsch interpretieren, Context übersehen, eine plausible API erfinden oder auf einem zunächst vernünftigen Entscheidungsweg falsch abbiegen.

Gerade gute Modelle können dabei besonders überzeugend sein.

Das ist kein Argument gegen ihre Nutzung. Es ist ein Argument für Professionalität bei ihrer Nutzung.

Seid nicht leichtsinnig. Prüft.

Prüft Anforderungen und die daraus abgeleiteten Annahmen ebenso wie Code, Tests, Security, Datenflüsse und Auswirkungen auf angrenzende Teile des Systems. Vor allem aber prüft, ob die entstandene Lösung tatsächlich das ursprüngliche Problem löst.

Generation und Verification sind unterschiedliche Aufgaben. Dass wir die erste immer stärker automatisieren können, erledigt die zweite nicht automatisch mit.

Auch Tests verdienen dabei etwas gesundes Misstrauen. Ein Agent, der eine falsche Interpretation implementiert, kann durchaus passende Tests für genau diese Interpretation schreiben. Ein grüner Testlauf beweist dann zuverlässig, dass Code und Test dieselbe falsche Vorstellung teilen.

Das ist immerhin Konsistenz.

Nur leider noch keine fachliche Korrektheit.

Deshalb sind Architekturregeln, explizite Constraints, klare Systemgrenzen und gute Tests für Agentic Work so wertvoll. Nicht weil Agents dadurch magisch unfehlbar würden, sondern weil Abweichungen sichtbarer und teilweise mechanisch überprüfbar werden.

Die entscheidende Frage lautet deshalb nicht, ob wir AI vertrauen oder ihr grundsätzlich misstrauen sollten.

Sie lautet: Was können wir überprüfen?

Neugier ist kein Hobby

Um darauf gute Antworten zu finden, reicht es nicht, gelegentlich eine Produktankündigung zu lesen.

Man muss die Werkzeuge benutzen.

Ich halte Neugier deshalb für eine ernsthafte Engineering-Kompetenz. Damit meine ich nicht, jedem neuen Modellnamen hinterherzulaufen oder den eigenen Arbeitstag in einen permanenten Benchmark zu verwandeln. Es geht darum, praktische Urteilskraft aufzubauen.

Probiert unterschiedliche Modelle aus und beobachtet, was passiert, wenn sie zu wenig oder zu viel Context bekommen. Lasst Agents größere Aufgaben übernehmen und schaut, wann sie anfangen zu driften. Vergleicht kleine und große Modelle, beobachtet Tokenverbrauch und Kosten und findet heraus, welche Aufgaben erstaunlich stabil funktionieren und welche trotz mehrfacher Versuche fragil bleiben.

Gebt ihnen auch schwierige oder unvollständige Requirements. Lasst sie scheitern – im Idealfall gelegentlich so überzeugend, dass ihr erst genauer hinsehen müsst, um den Fehler zu entdecken.

Dabei entsteht ein Wissen, das keine Feature-Liste vermitteln kann. Mit der Zeit entwickelt sich ein Gefühl dafür, wann Rückfragen nötig sind, wann Constraints explizit werden müssen, wann ein Task zu groß wird, wann Context verloren geht und welche Form von Verifikation zu welcher Aufgabe passt.

Nicht jede Grenze steht in einer Dokumentation.

Manche muss man erleben.

Neugier ist in einer Phase schnellen technologischen Wandels keine Spielerei. Sie ist eine Form von Risikomanagement.

Wer experimentiert, lernt schließlich nicht nur, was ein Werkzeug kann. Er lernt auch, wann er ihm besser nicht blind vertraut.

Ich programmiere seit fast 30 Jahren. Das bedeutet nicht, dass ich all diese Zusammenhänge seit fast 30 Jahren verstanden hätte. Im Gegenteil: Ein Teil von Erfahrung besteht für mich gerade darin, nach und nach zu erkennen, welche Probleme hinter dem sichtbaren Code liegen.

Viele Erkenntnisse, die heute im Kontext von AI wieder relevant werden, sind im Software Engineering überhaupt nicht neu. Die Disziplin wusste manches früher, als ich es als Entwickler verstanden habe.

Erfahrung ist eben nicht einfach die Anzahl vergangener Berufsjahre. Sie verändert im besten Fall das Modell, das wir von einem System haben: welche Zusammenhänge wir sehen, welche Fragen wir stellen und welche Folgen einer Entscheidung wir erkennen können.

Genau dieses Systemverständnis hilft heute enorm, wenn ein Agent plötzlich einen erheblichen Teil der mechanischen Umsetzung beschleunigen kann.

Baut Capability, nicht nur Tooling

Darauf zu warten, dass irgendwann jemand verbindlich erklärt, wie professionelle Softwareentwicklung mit AI nun funktioniert, halte ich deshalb für keine besonders gute Strategie.

Diese Bedienungsanleitung gibt es nicht.

Arbeitgeber werden sie nicht vollständig liefern. Universitäten können einer derart schnellen Entwicklung zwangsläufig nur begrenzt folgen. Zertifizierungen ersetzen keine praktische Erfahrung. Framework-Hersteller kennen euren Systemkontext nicht. Und eine LinkedIn-Timeline ist vermutlich auch weiterhin kein Peer-Review-Verfahren.

Entwickler müssen sich deshalb ein eigenes Urteil erarbeiten – nicht aus Angst davor, morgen arbeitslos zu sein. Das wäre dieselbe billige Zukunftsprognose, nur mit negativem Vorzeichen. Sondern weil Anpassungsfähigkeit eine vernünftige Antwort auf Unsicherheit ist.

Das bedeutet, zu lernen, auszuprobieren, Behauptungen selbst zu überprüfen und Arbeitsweisen zu verändern, wenn bessere entstehen. Es bedeutet auch, herauszufinden, wo Automatisierung tatsächlich hilft und wo sie derzeit nur zusätzliche Komplexität erzeugt.

Die gleiche Verantwortung liegt bei Unternehmen.

Der Investitionsdrang in AI ist nachvollziehbar. Lizenzen werden gekauft, Coding Agents eingeführt, Modelle evaluiert, Compute bereitgestellt und Agent-Plattformen aufgebaut. Vieles davon kann sinnvoll sein.

Nur sind Werkzeuge eine erstaunlich unvollständige Beschreibung von Capability.

Warum Tooling allein keine Engineering Capability erzeugt und Lernräume eine Investition sind, habe ich in Artikel 13 – Die Ökonomie von Agentic Work ausführlich entwickelt.

Menschen brauchen weiterhin Gelegenheit, Domänenwissen, Systemverständnis, technische Breite und Erfahrung aufzubauen.

Das betrifft ausdrücklich nicht nur Nachwuchskräfte.

Zehn oder zwanzig Jahre Berufserfahrung garantieren kein tiefes Systemverständnis. Wer zwanzig Jahre in einem engen Ausschnitt gearbeitet hat, besitzt nicht automatisch zwanzig Jahre Architekturkompetenz.

Engineering Capability entsteht nicht durch Betriebszugehörigkeit. Sie entsteht dort, wo Menschen Wissen aufbauen dürfen, Verantwortung übernehmen, Zusammenhänge kennenlernen und aus Entscheidungen lernen können.

Deshalb sehe ich ein Risiko darin, wenn Unternehmen Investitionen in die Zukunft vor allem mit Investitionen in Automatisierung gleichsetzen und gleichzeitig Weiterbildung, Nachwuchs, technische Breite oder Lernräume unter Kostendruck geraten. Das mag kurzfristig bestimmte Effizienzmetriken verbessern. Ob es langfristig auch die Fähigkeit einer Organisation verbessert, ihre Systeme zu verstehen und weiterzuentwickeln, ist eine andere Frage.

Eine AI-Lizenz ist noch keine Engineering Capability.

Wer in die Zukunft seiner Software investiert, sollte deshalb nicht nur in Modelle und Automatisierung investieren. Er sollte auch in die Fähigkeit seiner Organisation investieren, diese Werkzeuge sinnvoll einzusetzen, ihre Ergebnisse zu beurteilen und die Systeme dahinter weiterhin zu verstehen.

Tools sind ein Teil dieser Investition. Menschen ebenfalls.

Das unentdeckte Land

Und dann bleibt die Frage, die über all dem schwebt: Was bedeutet das langfristig für unsere Arbeit?

Ich weiß es nicht.

AI entwickelt sich schnell, ebenso Robotik und andere Formen der Automatisierung. Es ist völlig legitim, sich Gedanken darüber zu machen, was das für Arbeitsplätze, Unternehmen und Gesellschaft bedeutet. Nur können wir aus dem heutigen Stand von Coding Agents kaum seriös den Arbeitsmarkt des Jahres 2036 ableiten.

Vielleicht entstehen neue Berufe oder völlig andere Arbeitsmodelle. Vielleicht werden Tätigkeiten verschwinden, andere sich grundlegend verändern und neue hinzukommen. Vielleicht werden gesellschaftliche Modelle selbstverständlich, die heute noch utopisch wirken. Vielleicht entwickelt sich vieles auch wesentlich unspektakulärer.

Die Zukunft ist unentdecktes Land.

Gerade deshalb interessiert mich stärker, was wir heute beeinflussen können. AI kann Codeproduktion bereits massiv beschleunigen, und Menschen mit Systemverständnis können diesen Hebel derzeit besonders gut nutzen. Zuverlässige agentische Workflows brauchen weiterhin Context, gute Problemdefinitionen, Constraints und Verifikation. Gleichzeitig gibt es keinen vernünftigen Grund anzunehmen, dass Modelle in genau diesen Bereichen auf ihrem heutigen Stand stehen bleiben werden.

Das alles kann gleichzeitig wahr sein.

Wenn wir die Zukunft nicht seriös vorhersagen können, ist Anpassungsfähigkeit vielleicht eine der vernünftigsten Investitionen, die wir heute tätigen können.

Deshalb möchte ich diese Serie nicht mit einer Prognose beenden, sondern mit einer Einladung: Probiert die Werkzeuge aus und gebt ihnen echte Probleme statt nur vorbereiteter Demos. Beobachtet ihre Grenzen, versteht ihre Kosten und prüft ihre Ergebnisse. Lernt, bessere Fragen zu stellen und baut Wissen über eure Systeme auf. Wartet nicht darauf, dass irgendwann jemand anderes eine fertige Methode dafür präsentiert.

Wir lernen gerade erst, wie Agentic Work in realen Softwaresystemen funktioniert. Einige unserer heutigen Methoden werden wir vermutlich wieder verwerfen, andere werden selbstverständlich werden. Neue Modelle werden neue Möglichkeiten eröffnen – und ziemlich sicher auch neue Arten, überzeugend falsch abzubiegen.

Das Thema ist also alles andere als abgeschlossen.

Nur ein Gedanke erscheint mir nach all den Experimenten bemerkenswert stabil:

Software Engineering war nie nur Coding. AI hat diese Tatsache nicht erfunden. Sie macht sie nur sehr viel schwerer zu übersehen.

Vielleicht macht AI Software Engineering nicht wichtiger. Vielleicht zwingt sie uns nur dazu, bewusster zu betreiben, was schon immer wichtig war.

Und während wir das tun, lernen wir nicht nur, mit neuen Modellen zu arbeiten.

Wir lernen neu, wie Software Engineering mit ihnen funktioniert.