Ein Zwischenstand aus der Praxis

Ich schreibe kaum noch Code selbst. Weder Bash-Skripte noch Java oder Kotlin, weder Python noch JavaScript. Das ist keine Behauptung über die Zukunft, sondern eine Beschreibung meines Arbeitsalltags heute. Der Code entsteht mit Hilfe von KI, und ich verbringe meine Zeit mit dem, was den Code erst sinnvoll macht: Produktmanagement, Softwarearchitektur, Systemarchitektur, DevOps und Betrieb.

Das fühlt sich anders an als noch vor zwei Jahren, und es ist keine schleichende Veränderung, sondern ein Wechsel der Tätigkeit. Dieser Artikel ist ein Bericht aus erster Hand, kein Manifest. Ich beschreibe, was sich verändert hat, was weggefallen ist, was zugenommen hat, und welche Frage mich dabei umtreibt: wie man diese neue Art zu arbeiten überhaupt misst.

Vom Schreiben zum Entscheiden

Früher war die zentrale Tätigkeit das Schreiben von Code. Man las eine Anforderung, entwarf eine Lösung im Kopf und tippte sie Zeile für Zeile in den Editor. Der Entwurf und die Umsetzung waren derselbe Vorgang.

Heute sind sie getrennt. Ich beschreibe, was das System leisten soll, unter welchen Randbedingungen, mit welchen Schnittstellen und welchen Qualitätszielen. Die Umsetzung übernimmt die KI, und meine Aufgabe verschiebt sich zum Prüfen, Einordnen und Entscheiden. Das ist näher an der klassischen Rolle eines Architekten oder Produktverantwortlichen als an der eines Programmierers.

Was dabei zählt, ist das Ergebnis. Ein lauffähiges System, das die fachlichen Regeln korrekt abbildet, wartbar bleibt und im Betrieb nicht überrascht. Ob die entscheidende Klasse von meiner Hand stammt oder aus einem Prompt hervorgegangen ist, sieht man dem laufenden System nicht an. Und offen gesagt: Es interessiert im Betrieb auch niemanden.

Dokumentation, die es früher so nicht gab

Der für mich überraschendste Effekt betrifft nicht den Code, sondern die Dokumentation. Sie ist heute vollständiger, als sie es in den meisten Projekten meiner Laufbahn je war. Architekturdiagramme sind sauber, Infografiken erklären Zusammenhänge, und die Struktur folgt bewährten Vorlagen wie arc42.

Ich habe kein Zertifikat des iSAQB (International Software Architecture Qualification Board, die Organisation hinter den bekannten Architektur-Zertifizierungen) und trotzdem entsteht eine arc42-Dokumentation, die einem Review standhält. Nicht, weil eine KI mir das Fachwissen ersetzt, sondern weil ich die Themen aus eigener Projekterfahrung kenne und die KI die aufwendige, disziplinierte Ausarbeitung übernimmt.

Hier wird oft etwas falsch verstanden. Ich setze viele Themen heute in einer Tiefe um, die ich mir früher aus Zeitgründen nicht leisten konnte. Die Erfahrung liefert das Urteil darüber, was richtig ist. Die KI liefert die Ausdauer, es vollständig aufzuschreiben. Wer die Themen nicht kennt, bekommt schön aussehende Dokumente ohne Substanz. Wer sie kennt, bekommt endlich die Dokumentation, für die vorher nie Zeit blieb.

Gute Dokumentation richtet sich dabei immer an ihre Stakeholder, also an die Beteiligten und Betroffenen. arc42 macht genau das zum Prinzip: Ein Betreiber braucht andere Sichten als ein Entwickler, ein Auditor andere als ein Product Owner. Diese Adressaten sauber zu bedienen, jede Ebene in ihrer passenden Tiefe, ist aufwendig und blieb früher oft auf der Strecke. Mit KI gelingt mir das deutlich besser, weil ich dieselbe fachliche Grundlage mit vertretbarem Aufwand in mehrere Zuschnitte übersetzen kann, vom knappen Management-Überblick bis zum detaillierten Baustein-Diagramm.

Neu ist ein Stakeholder, den es früher nicht gab: die KI selbst. Ein Agent, der an einem System arbeitet, ist auf Dokumentation angewiesen wie ein neuer Kollege, nur dass er sie in seiner eigenen Form und Tiefe braucht. Architekturentscheidungen, Kontextgrenzen, Konventionen und Schnittstellen müssen so beschrieben sein, dass ein Modell sie zuverlässig nutzen kann. Dokumentation ist damit nicht mehr nur Nachweis für Menschen, sondern zugleich Arbeitsgrundlage für die Agenten, die den Code schreiben.

Derselbe Effekt zeigt sich beim Marketingmaterial. Es ist besser, als es eine Agentur zu einem Preis liefern könnte, den ich mir leisten kann. Diese Website ist selbst ein Beispiel dafür, nachzulesen im Making-of unseres Astro-Relaunchs.

Delegation an spezialisierte Agenten

Früher brauchte es für bestimmte Themen einen dedizierten Spezialisten. Jemanden für Datenbank-Tuning, jemanden für Sicherheit, jemanden für ein sauberes Frontend, jemanden für die technische Dokumentation. In einem kleinen Team war das der Engpass: Man hatte die Kompetenz nicht durchgängig im Haus und musste sie einkaufen oder das Thema liegen lassen.

Viele dieser Aufgaben delegiere ich heute an spezialisierte KI-Agenten. Ein Agent kümmert sich um die Testabdeckung, einer um die Migration eines Nachrichtenformats, einer um die Aufbereitung eines Diagramms. Ich orchestriere, prüfe die Ergebnisse und setze sie zusammen. Das verschiebt den Flaschenhals von der Verfügbarkeit einzelner Spezialisten hin zur Qualität meiner Anweisungen und meines Urteils über das Resultat.

Wichtig ist die Grenze, die ich schon in KI und Prompt Engineering beschrieben habe: KI ersetzt keine Architektur, keine Tests und kein Review. Für sicherheitskritische Entscheidungen, regulierte Prozesse und deterministische Geschäftslogik bleibt die Verantwortung bei mir. Ein Agent, der eine ISO 20022-Nachricht mappt, nimmt mir die Fleißarbeit ab, nicht die Haftung für die Korrektheit.

Was wegfällt, was zunimmt

Einige Werkzeuge sind ganz von meinem Schreibtisch verschwunden.

Was ich nicht mehr benutze:

  • grafische Modellierungs- und Diagrammwerkzeuge, etwa Enterprise Architect von Sparx Systems, weil Diagramme heute aus einer textuellen Beschreibung entstehen und versionierbar im Repository liegen
  • schwergewichtige Werkzeuge für Anforderungsmanagement und Sprintplanung, etwa Ticketsysteme wie Jira oder dedizierte Requirements-Management-Systeme, weil Anforderungen heute als ausformulierter Text vorliegen und die Feinplanung nicht mehr über ein großes Team synchronisiert werden muss
  • Tabellenkalkulation für Aufstellungen, die sich schneller beschreiben als klicken lassen
  • die vielen kleinen Handgriffe, mit denen man früher Boilerplate zusammengesetzt hat

Was massiv zugenommen hat, ist Sprache. Ausformulierte Sätze, also Prompts, sind zum eigentlichen Werkzeug geworden. Ich diktiere und tippe heute mehr als je zuvor in meinem Berufsleben. Wo früher eine präzise Zeile Code stand, steht heute ein präzise formulierter Absatz, der beschreibt, was diese Zeile leisten soll und warum.

Die Kernkompetenz verschiebt sich von einer formalen Sprache, dem Code, zu einer natürlichen Sprache, die trotzdem genauso durchdacht sein muss. Ein unpräziser Prompt erzeugt unpräzise Ergebnisse, genau wie unklarer Code unklares Verhalten erzeugt. Prompts sind Code, nur in einer anderen Notation.

Mehr Output, nicht weniger Arbeit

Ein verbreitetes Missverständnis ist, dass die Arbeit mit KI entspannter sei. Man schicke einen Prompt los und warte, während die Maschine die Arbeit erledigt. In der Praxis ist das Gegenteil der Fall.

Ich verwalte in der Regel mehrere KI-Sessions parallel. Während ein Agent an der Testabdeckung arbeitet, formuliere ich den nächsten Auftrag für eine Formatmigration und prüfe das Ergebnis eines dritten. Jeder dieser Stränge trägt seinen eigenen Kontext: welche Annahmen gelten, was bereits entschieden ist, worauf beim Ergebnis zu achten ist. Diesen Kontext im Kopf zu behalten und beim Umschalten zwischen den Sessions nicht zu verlieren, kostet Konzentration. Context-Switching, also das ständige Wechseln zwischen Aufgaben, war schon immer der teuerste Teil geistiger Arbeit, und es wird nicht billiger, nur weil auf der anderen Seite eine KI sitzt.

Als Software-Ingenieur hatte man ohnehin selten echte Denkpausen. Man trägt das Problem mit sich herum, beim Kaffee und auf dem Heimweg. Mit KI-Agenten ist das nicht anders, eher verdichtet es sich. Sobald ein Agent ein Ergebnis liefert, muss ich es prüfen, einordnen und die nächste Anweisung formulieren. Nach dem Prompt ist vor dem Prompt. Die Schleife läuft praktisch ohne Leerlauf, und der Takt gibt nicht mehr das eigene Tempo vor, sondern die Geschwindigkeit, mit der die Agenten zurückmelden.

Und nein, ich arbeite dadurch nicht weniger. Was steigt, ist der Output, nicht die Menge ruhiger Minuten. KI nimmt einem die Arbeit nicht ab, sie erhöht das Ergebnis bei gleichbleibendem Einsatz an Konzentration. Wer erwartet, dass die Automatisierung Freiraum schafft, verwechselt Werkzeug mit Ruhepause.

Die eigentlich schwierige Frage: Wie misst man das?

Die Produktivität ist spürbar gestiegen. Die Qualität auch, vor allem bei der Dokumentation und der Vollständigkeit. Aber sobald ich das behaupte, kommt die berechtigte Rückfrage: Woran macht man das fest?

Die naheliegende Antwort wäre, Zeilen zu zählen. Früher hat man Produktivität gern in Lines of Code gemessen, also in geschriebenen Codezeilen. Das war schon damals ein schlechtes Maß. Mehr Zeilen bedeuten oft mehr Komplexität, mehr Wartungslast und mehr Fehlerfläche, nicht mehr Wert. Die produktivste Änderung ist manchmal die, die hundert Zeilen löscht.

Heute wäre die scheinbar moderne Variante, Input-Tokens zu zählen, also die Menge an Text, die ich in die KI eingebe. Das ist genauso irreführend. Viele Tokens heißen nur, dass ich viel geschrieben habe, nicht, dass etwas Gutes dabei herausgekommen ist. Ein langer, wirrer Prompt ist kein Fortschritt gegenüber einem kurzen, treffenden.

Beide Maße haben denselben Denkfehler: Sie messen den Aufwand der Erzeugung, nicht den erzeugten Wert. Ich halte die Frage nach der einen Kennzahl für falsch gestellt. Was sich sinnvoll beobachten lässt, sind Wirkungen, nicht Mengen:

  • Durchlaufzeit vom Bedarf zum Betrieb. Wie lange dauert es von der Idee bis zum laufenden, dokumentierten, betreibbaren System? Diese Zeit ist bei mir deutlich kürzer geworden.
  • Umfang dessen, was eine Person verantworten kann. Ich decke heute allein ein Spektrum ab, für das früher mehrere Rollen nötig waren, von der Architektur bis zum Marketing.
  • Vollständigkeit der Nebenprodukte. Dokumentation, Diagramme und Tests entstehen mit, statt liegenzubleiben. Das ist schwer in eine Zahl zu fassen, aber im Alltag sofort spürbar.
  • Wartbarkeit über die Zeit. Der ehrlichste Test kommt später: Lässt sich das System in einem Jahr noch mit vertretbarem Aufwand ändern? Das ist die Kennzahl, die wirklich zählt, und die keine Token-Statistik vorwegnimmt.

Die gestiegene Produktivität ist real, aber sie zeigt sich in Ergebnissen und Durchlaufzeiten, nicht in einer bequemen Zahl auf einem Dashboard. Wer sie in Tokens misst, wiederholt nur den alten Fehler mit den Codezeilen.

Was sich nicht verändert hat

Bei aller Verschiebung bleibt der Kern gleich. Die Verantwortung für das Ergebnis liegt weiterhin bei einem Menschen. Das Urteil darüber, ob eine Architektur hält, ob eine Sicherheitsannahme stimmt, ob eine regulatorische Anforderung korrekt umgesetzt ist, lässt sich nicht delegieren. Es setzt Erfahrung voraus, und diese Erfahrung entsteht nach wie vor durch echte Projekte.

Genau das ist die Positionierung, aus der heraus wir bei rypox arbeiten. Software, die mitdenkt, entsteht nicht dadurch, dass eine KI möglichst viel produziert, sondern dadurch, dass jemand mit Erfahrung entscheidet, was produziert werden soll und ob das Ergebnis wirklich trägt. Die KI hat den Hebel vergrößert. Die Hand am Hebel ist dieselbe geblieben.

Häufige Fragen

Schreibt ein Software-Ingenieur mit KI überhaupt keinen Code mehr? Doch, aber deutlich weniger von Hand. Der Code entsteht überwiegend mit Unterstützung von KI, während sich die menschliche Tätigkeit auf Entwurf, Prüfung und Entscheidung verlagert. Kritische oder besonders heikle Stellen schaut man weiterhin Zeile für Zeile an.

Ersetzt KI die Ausbildung oder Zertifizierung, etwa iSAQB? Nein. KI kann eine saubere arc42-Dokumentation ausarbeiten, aber das fachliche Urteil, ob die Architektur richtig ist, kommt aus Erfahrung. Ohne dieses Wissen entstehen Dokumente, die gut aussehen, aber inhaltlich dünn bleiben.

Wie misst man Produktivität in der KI-gestützten Entwicklung? Weder in geschriebenen Codezeilen noch in eingegebenen Tokens, denn beide messen Aufwand statt Wert. Aussagekräftiger sind Wirkungen: die Durchlaufzeit vom Bedarf bis zum Betrieb, der Umfang dessen, was eine Person verantworten kann, die Vollständigkeit von Dokumentation und Tests, und die Wartbarkeit über die Zeit.

Welche Werkzeuge fallen durch KI weg? Bei mir vor allem grafische Diagramm-Editoren und Tabellenkalkulation. Diagramme entstehen heute aus einer textuellen Beschreibung und liegen versioniert im Repository. Zugenommen hat dagegen das Formulieren von Prompts, also Sprache.

Bedeutet das Arbeiten mit KI weniger Arbeit? Nein. Der Output steigt, der Aufwand nicht. Wer mehrere KI-Sessions parallel führt, muss laufend Kontext halten, Ergebnisse prüfen und den nächsten Schritt formulieren. Dieses Umschalten zwischen den Aufgaben kostet mindestens so viel Konzentration wie das frühere Schreiben von Code.

Fazit

Die Arbeit eines Software-Ingenieurs hat sich verschoben, nicht abgeschafft. Weniger Tippen von Code, mehr Formulieren von Absicht. Weniger Einzelspezialisten, mehr Orchestrierung spezialisierter Agenten. Weniger grafische Werkzeuge, mehr Sprache. Die Produktivität und die Qualität sind deutlich gestiegen, gerade dort, wo früher aus Zeitmangel Lücken blieben.

Die interessanteste offene Frage ist darum nicht, ob man mit KI produktiver ist, sondern wie man diese Produktivität ehrlich misst, ohne in den alten Reflex zu verfallen, einfach die nächste bequeme Zahl zu zählen.