Jetzt mal ganz ehrlich: Ich habe diese Woche einen Post gelesen, der mich nicht mehr loslässt. Ein Entwickler beschreibt seine neue Stelle. Die KI erzeugt dort alles: Anforderungen, Tickets, Tests, Code, Dokumentation, Reports. Die Menschen sitzen zwölf, dreizehn Stunden am Tag davor und bestätigen, was rauskommt. Niemand weiss mehr, was im System passiert. Niemand denkt mehr. Sein Satz dafür: Die Leute drücken nur noch Enter. Fast fünf Millionen haben das gelesen, und ich glaube, er hat recht. Nur nicht mit dem Schluss, den viele daraus ziehen.
Der Post
Der Mann ist anonym, aus Angst vor seinem Arbeitgeber, und das sagt schon etwas. Was er beschreibt, ist kein Einzelfall, ich höre es seit einem Jahr in jedem zweiten Gespräch mit Entwicklern: Das Management misst Sprints, Pull Requests, ausgelieferte Features. Also wird alles an die KI gegeben, was Features schneller macht, von der Anforderung bis zum Backend. Und der Mensch wird zu dem, was er in einem Interview danach „Fleisch-Proxy" nennt: einer, der Ausgaben weiterreicht, ohne sie zu lesen.
Ein Satz aus dem Post ist der wichtigste, und er ist nicht der laute: Code schreiben war nie der Engpass. Der Engpass waren die Systeme drumherum.
Tippen war nie das Problem
Ich baue seit über zwanzig Jahren Software, und ich kann mich an kein Projekt erinnern, das am Tippen gescheitert ist. Die Projekte sind an anderen Fragen gescheitert. Was bauen wir eigentlich, und warum. Wie sieht die Architektur aus. Welche Daten haben wir, und wie gut sind sie. Welche Abhängigkeiten entstehen, und wer kennt sie in zwei Jahren noch. Was passiert, wenn zwanzig Entwickler gleichzeitig ändern. Und heute: was passiert, wenn fünfzig Agenten gleichzeitig ändern.
Keine dieser Fragen verschwindet, weil ein Modell in dreissig Sekunden zweitausend Zeilen schreibt. Sie werden wichtiger. Ich habe das in „Code wird billig. Wissen nicht." beschrieben, und dieser Post ist der Beleg dafür aus der Praxis: Wenn Code nichts mehr kostet, ist alles andere das, was zählt. Und alles andere wird gerade wegautomatisiert, weil es auf keinem Dashboard steht.
Schneller produzieren, als man verstehen kann
Früher war Entwicklung teuer. Ein Feature musste geplant, gebaut, getestet, reviewt werden, und jede dieser Stufen war eine Bremse. Ärgerlich, aber eine Bremse hat einen Nutzen: Sie zwingt zum Anhalten. Heute erledigt ein Agent in Minuten, wofür ein Team eine Woche brauchte. Das ist gut, ich arbeite jeden Tag so. Aber es hat eine Nebenwirkung, die niemand auf dem Dashboard sieht.
Verstehen heisst ganz banal: Jemand weiss, welche Abhängigkeiten es gibt. Warum eine Architekturentscheidung so gefallen ist. Warum Daten so gespeichert werden und nicht anders. Welche Komponente kritisch ist, und was passiert, wenn man sie anfasst. Wenn das niemand mehr weiss, hat man nicht zehnmal mehr Output. Man hat zehnmal mehr Komplexität, die beim ersten Ausfall um 23 Uhr niemand mehr erklären kann. Ich habe es beim Enterprise-Thema schon gesagt: Der Agent schreibt Code. Software bauen ist mehr als Code.
Der Mensch geht eine Ebene höher, oder er geht
Und hier trenne ich mich von dem Schluss, den viele aus dem Post ziehen. Der Schluss ist nicht: weniger KI. Der Schluss ist: Der Mensch muss eine Ebene höher. Nicht der, der jeden Codeblock kontrolliert. Das skaliert genauso wenig wie das Tippen, und es ist genau der Job, den der Mann im Post so hasst. Sondern der, der das System entwirft, in dem die Agenten arbeiten.
Was das heisst: Er legt die Architektur fest. Die Patterns. Die Grenzen, was ein Agent darf und was nicht. Die Qualitätsanforderungen, die Datenmodelle, die Schnittstellen. Und vor allem die Absicht: Was soll dieses System tun, und warum. Das ist nicht weniger Denken als früher. Es ist mehr, nur auf einer anderen Ebene. Ich habe das im Artikel über den Architekten geschrieben, bevor dieser Post existierte, und ich sehe es jetzt bestätigt: Der Architekt stirbt nicht aus. Er wird wichtiger als je zuvor. Nur nennt man ihn in den Firmen, die Sprints messen, gerade weg.
So würde ich es bauen
Ich würde es nicht so bauen, wie es in dem Post beschrieben ist: ein grosses Modell, das alles macht, und Menschen, die Enter drücken. Ich würde es umgekehrt bauen, und so bauen wir es bei NeoCoder, unserem eigenen Agenten-System, seit dem ersten Tag.
Verschiedene Aufgaben, verschiedene Agenten, zum Teil verschiedene Modelle. Einer analysiert die Anforderung. Einer schreibt. Ein anderer prüft die Architekturregeln, und zwar ein anderer, nie derselbe. Einer testet. Einer schaut auf Sicherheit. Für manche dieser Aufgaben ist ein kleines, eigenes Modell besser als das grösste, das es gibt, weil es genau eine Sache kann und man es versteht.
Kein Agent nimmt sich selber ab. Die eine Regel, die bei mir alles zusammenhält. Wer schreibt, prüft nicht. Das ist das Vier-Augen-Prinzip, das jedes gute Team seit dreissig Jahren kennt, nur dass die Augen jetzt zum Teil Agenten sind. Der Mensch prüft nicht jeden Block. Er prüft, ob die Regeln eingehalten wurden, und die Regeln hat er geschrieben.
Das Ziel ist eine Entwicklungsmaschine, nicht ein schneller Entwickler. Der Entwickler baut die Maschine: Regeln, Prüfungen, Grenzen, Rückkopplung aus Fehlern und Reviews. Die Maschine übernimmt immer mehr der operativen Arbeit. Aber jemand versteht die Maschine, und dieser jemand ist der wichtigste Mensch im Team.
Absicht vor Output. Bevor ein Agent baut, steht, warum. Nicht als Ticket-Titel, sondern als Satz, den ein Sachbearbeiter unterschreiben könnte. Ein Feature ohne diesen Satz wird nicht gebaut, egal wie schnell es ginge.
Das ist die Antwort auf „Fleisch-Proxy": Der Mensch reicht nicht weiter. Er entwirft. Und wenn eine Firma das nicht will, weil es auf dem Dashboard nicht als Feature erscheint, dann ist das die Firma, aus der der Mann im Post weg will. Zu Recht.
Wir messen das Falsche
Mehr Pull Requests. Mehr Features. Mehr Tickets. Mehr Code. Kürzere Sprints. Das sieht auf einem Dashboard gut aus, und es ist genau das, was den Post erzeugt hat. Wenn man Output misst, bekommt man Output. Ich würde anderes messen.
Wie viel Komplexität haben wir entfernt. Nicht hinzugefügt. Entfernt. Ein Sprint, in dem Code verschwindet, ist ein guter Sprint.
Wie viel Code brauchen wir überhaupt noch. Wenn ein Agent zweitausend Zeilen schreibt, wo zweihundert reichen, ist das kein Fortschritt. Es ist das, was ich beim Enterprise-Thema Riesenklassen genannt habe.
Wie gut versteht das Team das System. Kann jemand ohne das Modell erklären, warum es so gebaut ist. Wenn nein, ist das die wichtigste Zahl, und sie ist rot.
Wie viele Entscheidungen trifft die Maschine, ohne die Regeln zu verletzen. Das ist die Kennzahl für die Entwicklungsmaschine. Sie steigt, wenn die Regeln gut sind, und fällt, wenn jemand nur Enter drückt.
Ist das Produkt besser geworden. Hundert Features, die niemand braucht, sind nicht besser als zehn gute. Auch wenn die KI sie an einem Nachmittag baut.
Was bleibt
Ich sehe KI in der Entwicklung nicht negativ. Ich finde, was gerade passiert, ist spannender als fast alles, was ich in diesem Beruf erlebt habe. Aber wir sollten sie nicht benutzen, um schneller dasselbe zu machen. Ein Team wird irgendwann aus wenigen Menschen und sehr vielen spezialisierten Agenten bestehen, das halte ich für wahrscheinlich. Diese Menschen werden nicht weniger wichtig. Ihre Aufgabe ändert sich: von „schreib diesen Code" zu „entwirf ein System, das zuverlässig Software bauen kann". Wenn irgendwann jeder in Minuten Code erzeugen kann, ist Code kein Vorteil mehr. Der Vorteil ist zu wissen, welchen Code man überhaupt erzeugen sollte.
Der Mann im Post hat recht: Wer nur noch Enter drückt, hat keinen Job mehr, sondern eine Schicht. Aber die Antwort ist nicht weniger KI. Die Antwort ist, dass der Mensch eine Ebene höher geht: Er entwirft die Maschine, die baut, statt ihr zuzuschauen. Und dass Firmen aufhören, Output zu messen, und anfangen, Verständnis zu messen. Wer das nicht tut, bekommt sehr schnell sehr viel Software, die niemand mehr versteht.
Quelle: Thibault Spirlet, „An engineer's viral post captures the soul-crushing downside of AI coding", Business Insider, September 2026. Zitate sinngemäss.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.