01 These 01 · 2025–2026

AI is eating the world

Warum das kein Software-Update ist, sondern ein Strukturbruch

Softwareentwicklung war vierzig Jahre lang ein Handwerk. Man lernte es durch Ausführung, verfeinerte es durch Wiederholung, gab es weiter durch Anwesenheit. Andrej Karpathy — Mitgründer von OpenAI, Architekt von Teslas Autopilot — schrieb Ende 2025 öffentlich: „I’ve never felt this much behind as a programmer. The profession is being dramatically refactored.“

AI is eating the world

Der Buchdruck hat nicht das Schreiben verändert — er hat verändert, wer schreibt, für wen, und zu welchen Kosten. Die Technologie war das Medium. KI verschiebt denselben Hebel: nicht die Qualität von Code, sondern die Frage, wer Zugang zur Produktion hält — und zu welchem Preis.

Marc Andreessen schrieb 2011: „Software is eating the world." Die These ist eingetreten — vollständig. Was sich jetzt verändert, ist eine Ebene darunter: KI frisst die Software, die die Welt gefressen hat. Im Februar 2026 löste ein einziges KI-Plugin einen 285-Milliarden-Dollar-Kurseinbruch bei SaaS-Aktien aus. Das war keine Marktkorrektur — das war Strukturrevision.

In Teams, die GitHub Copilot oder Cursor Agent produktiv einsetzen, liegt der sichtbare Gewinn nicht bei schlechten Entwicklern, die besser werden — sondern bei guten, die gefährlich schnell werden. Wer bisher für die Ausführung zuständig war, könnte bald nur noch für die Entscheidung davor zuständig sein.

Wer bisher Entscheidungsmacht delegiert hat, weil Ausführung teuer war, delegiert sie jetzt an eine Schicht, die keine Verantwortung trägt. Das ist kein Technologieproblem — das ist eine Governance-Frage, die bisher niemand gestellt hat.

Welchen Architekturentscheid in Ihrer Softwareentwicklung würden Sie heute anders treffen — weil KI die Ausführung übernimmt?
02 These 02 · 2025–2026

Offshore ist nicht zu teuer. Es ist zu langsam.

Warum das Offshore-Modell nicht an den Kosten scheitert — sondern am Takt

Die vier größten IT-Outsourcing-Konzerne der Welt sitzen in Indien. TCS verlor 12.000 Stellen. Infosys 8.000. Wipro 5.500. HCL 4.200. Das sind keine Restrukturierungszahlen — das sind Strukturzahlen. NASSCOM, der indische IT-Branchenverband, warnt vor 400.000 bis 500.000 weiteren gefährdeten Jobs. Offshore-IT hat dreißig Jahre funktioniert. Nicht wegen Qualität — wegen Mathematik.

Offshore ist nicht zu teuer. Es ist zu langsam.

Fax-Netzwerke sind nicht wegen der Kosten gestorben. Sie sind gestorben, weil ihr Tempo mit dem neuen Takt unvereinbar wurde. E-Mail war asynchron, sofort, durchsuchbar — das Fax-Netzwerk war keines dieser Dinge, obwohl es technisch funktionierte.

Das Offshore-Modell funktioniert, wenn ein Ticket am Montag nach Mumbai geht und am Donnerstag fertig zurückkommt. KI-gestützte Entwicklung verändert diesen Rhythmus: Ein Entwickler iteriert heute ein Feature in zwei Stunden — Prompt, Feedback, Korrektur, Commit. Die Übergabe wird zur Latenz, nicht zur Arbeitsstruktur. Ob das Ihr Preismodell noch trägt, hängt davon ab, wie viel Ihrer Arbeit in diesen neuen Takt fällt.

Offshore-Teams stehen morgens vor einem System, das sich über Nacht verändert hat. Jede asynchrone Übergabe vervielfacht den Klärungsaufwand, bevor die eigentliche Arbeit beginnt. Mit KI-Tooling beschleunigt sich die Codebasis — der Overhead bleibt. Für Ausführungsaufgaben mit stabilen Spezifikationen bleibt Offshore kalkulierbar. Für explorative Entwicklung wird der Overhead systematisch unterschätzt.

Das Modell steht nicht wegen der Kosten unter Druck. Es steht unter Druck, weil die Übergabe selbst das Produkt war — und die Übergabe verschwindet.

Welche Ihrer aktuellen Offshore-Aufgaben würden Sie sofort intern behalten, wenn Ihr bester Berliner Entwickler dreimal so schnell liefert wie bisher?
03 These 03 · 2025–2026

Dein Junior hat ein Problem

Über das Ende des klassischen Lernpfads und was das für Ihre Teamstruktur bedeutet

Anthropic, OpenAI und Google haben ihre Junior-Einstellungen 2025 drastisch reduziert. Nicht aus Budgetgründen. Sondern weil KI die Ausführungsaufgaben übernimmt, an denen Junioren ihr Handwerk erlernen: das Debuggen unklarer Fehler, das Schreiben von Code ohne Vorlage, das Navigieren durch schlecht dokumentierte Systeme.

Dein Junior hat ein Problem

Londoner Taxifahrer mussten jahrelang den sogenannten Knowledge Test absolvieren — eine kognitive Leistung, die nachweislich die Hippocampus-Struktur veränderte. GPS hat nicht nur den Test obsolet gemacht. Es hat die kognitive Fähigkeit obsolet gemacht, die durch den Test entstand. Die Fähigkeit existierte, weil die Ausführung sie erzwang. GPS hat das nicht angeordnet. Es hat es einfach überflüssig gemacht.

Eine Fattly-Studie (Juli 2025, n=791 Entwickler) zeigt: Junioren mit KI-Unterstützung lösen 13 Prozent mehr Aufgaben als ohne — Senioren 32 Prozent mehr. KI multipliziert vorhandenes Urteilsvermögen. Wer keines hat, wird mit KI schneller zu falschen Lösungen kommen. Das ist kein Leistungsproblem — es ist ein Strukturproblem: KI übernimmt genau die Aufgaben, an denen Junioren dieses Urteilsvermögen entwickelt hätten.

Der Effekt ist verzögert. Organisationen bemerken den fehlenden Senior-Nachwuchs erst, wenn die aktuellen Senioren fehlen — nicht nächstes Quartal, sondern in fünf bis acht Jahren. Die Lücke ist heute kalkulierbar. Der Schmerz tritt ein, wenn niemand mehr da ist, der die KI-Ausgaben beurteilen kann.

Die logische Konsequenz wäre eine widersinnige Empfehlung: Junioren sollten KI-Werkzeuge in ihrer Lernphase bewusst weniger nutzen. Nicht weil KI schlecht ist — sondern weil Urteilsvermögen nur durch Reibung entsteht, durch Fehler, durch das mühsame Durchdenken von Problemen, die niemand vorher gelöst hat. Ob Organisationen bereit sind, diese Ineffizienz zu verteidigen, während ihre Konkurrenz auf maximale KI-Beschleunigung setzt — das werden wir in fünf Jahren wissen.

Benennen Sie die letzte Aufgabe, bei der ein Junior in Ihrem Team etwas strukturell Schwieriges selbst lösen musste — ohne Autocomplete, ohne Senior, der einspringt, mit echtem Scheiternrisiko.
04 These 04 · 2025–2026

Dein Senior ist das knappe Gut

Warum Ihre besten Entwickler gerade einen Schalter umlegen müssen — und ob sie es wollen

GitHub Copilot-Daten zeigen: Entwickler schreiben bis zu 55 Prozent ihres Codes nicht mehr selbst. Der Wert eines Senior Engineers war vierzig Jahre lang an Produktivität gebunden — mehr Code, besserer Code, schneller. Diese Gleichung hat sich verändert. Was das für den Wert von Urteilsvermögen bedeutet, ist noch nicht eingepreist.

Dein Senior ist das knappe Gut

Ein Dirigent spielt kein Instrument. Die produktivsten Entwicklungsteams in Silicon Valley haben ihre Strukturen bereits danach ausgerichtet: kleinere Teams, höhere durchschnittliche Seniorität, KI als Multiplikator für Urteilsvermögen statt als Ersatz für Ausführung.

Wert entsteht dort, wo Knappheit herrscht. Überfluss vernichtet Wert. GitHub meldet 55 Prozent KI-generierten Code in aktiven Projekten. Die leistungsstärksten Teams nutzen diesen Hebel nicht, um größer zu werden — sondern um mit weniger Menschen mehr Komplexität zu beherrschen. Was bleibt, wenn Ausführung automatisiert ist: das Gespür für technische Schulden, die sich noch nicht in Fehlern zeigen. Das intuitive Erkennen von Systemrisiken. Die Fähigkeit zu entscheiden, was nicht gebaut werden sollte.

Nicht alle Senioren wollen diese Rolle. Viele haben ihre berufliche Identität an Ausführung gebunden — an das Schreiben von Code, an das Lösen technischer Probleme durch direkte Intervention. Manche werden diese Verschiebung als Aufwertung erleben. Andere als Enteignung. Beides ist eine rationale Reaktion.

Coden wird zur Fotochemie — eine Fähigkeit, die jeder haben wird, und die deshalb aufhört, Wert zu erzeugen. Die interessantere Frage ist nicht, wer dieses Urteil trifft. Sondern wie Organisationen erkennen, wenn es fehlt.

Fragen Sie Ihren besten Senior Engineer: Welche Architekturentscheidung der letzten sechs Monate wäre ohne sein Urteil anders ausgefallen?
05 These 05 · 2026

Code ist eine Commodity

Warum mehr Entwicklungskapazität das falsche Problem schneller löst — und wer jetzt den Engpass hält

Cursor Agent und Claude Code schließen ganze Tickets ohne menschliche Intervention. Der Engpass, um den wir zwanzig Jahre lang unsere Industrie organisiert haben — Code zu schreiben — hat sich aufgelöst. Das macht schneller sichtbar, warum so viel von dem, was gebaut wird, falsch ist.

Code ist eine Commodity

Als Malcolm McLean 1956 den Standardcontainer einführte, kollabierte die Verladezeit im Hafen von Tagen auf Stunden. Die Reedereien feierten die Effizienz. Was folgte, überraschte sie: Die Häfen selbst wurden zur Bremse — Zollbehörden, Terminplanung, Lagerflächen, Dokumentationspflichten. Die Schiffe waren schneller. Das System dahinter hatte sich nicht verändert. Mehr Durchsatz machte sichtbar, was vorher im Rauschen der allgemeinen Langsamkeit verschwunden war.

Wer heute KI-gestützten Code in Stunden produziert, steht vor ähnlichen Fragen. Woher kommt die Spezifikation, wenn das Entwicklungsteam kaum noch nachfragt? Wer übernimmt Verantwortung für Anforderungen, die bisher implizit im Ping-Pong zwischen Entwicklern und Fachbereich entstanden? Was passiert mit dem institutionellen Wissen, das sich in genau diesem Rückkopplungsprozess angesammelt hat?

Cataldo, Herbsleb und Carley haben 2008 an einem realen Softwaresystem gemessen: Wenn Kommunikationsmuster zu tatsächlichen Entwicklungsabhängigkeiten passen, sinkt die Bearbeitungszeit von Änderungsanfragen um rund 32 Prozent — nicht durch mehr Code, sondern durch bessere Klärung darüber, was gebaut werden soll.

Es gibt keine etablierte Rolle, die diese Lücke institutionell schließt. Product Management kommt ihr nahe, ist aber historisch aus Priorisierungsdruck entstanden — und wurde selten für Spezifikationstiefe ausgestattet. Mehr Entwicklungskapazität bei gleichbleibender Anforderungsqualität beschleunigt nicht die Lieferung des Richtigen — es beschleunigt die Lieferung. Was gebaut wird, entscheidet sich früher im Prozess — in einem Moment, den die meisten Organisationen noch nicht einmal als Moment erkannt haben.

Prüfen Sie, ob in Ihrer Organisation irgendjemand weiß, dass er für Spezifikationsqualität verantwortlich ist.
06 These 06 · 2026

Deine Org-Struktur ist von gestern

Über 170 Jahre altes Organisationsdesign, KI-Pods und die zwei Rollen, die Middle Management ersetzen

In den meisten Unternehmen hängt heute noch dasselbe Diagramm an der Wand wie 1854 — Kästchen, Linien, Ebenen. Nicht weil irgendjemand es so entschieden hätte. Weil es nie jemand in Frage gestellt hat. Strukturen, die gut genug funktionieren, werden nicht ersetzt. Sie werden vererbt.

Deine Org-Struktur ist von gestern

Daniel McCallum zeichnete 1854 das erste bekannte Organigramm der Geschichte — für die Erie Railroad. Nicht aus Überzeugung, sondern aus Not: Züge fuhren auf mehreren Strecken gleichzeitig, und niemand wusste, wo welcher war. Span of Control, die Kernregel jeder Hierarchie seither, ist eine direkte Antwort auf Informationsknappheit. Maximal acht direkte Berichte — weil mehr nicht koordinierbar war. Das Organigramm in Ihrem Unternehmen ist ein 170 Jahre altes Werkzeug für ein gelöstes Problem.

Eine Panelanalyse von über 160.000 Betrieben in Europa zeigt: Überall dort, wo Unternehmen in integrierte Informationssysteme investiert hatten, weiteten sich Entscheidungsspielräume aus und der Span of Control wuchs. Das ist kein Korrelationsbefund — es ist ein Mechanismus. Was McCallum 1854 gezwungen hatte, eine Hierarchie zu bauen, ist seither schrittweise weggefallen. Gartner erwartet, dass bis 2028 sechs von zehn Organisationen ihre Management-Strukturen wegen KI-Adoption umgebaut haben werden — heute sind es weniger als zehn Prozent. Der Abstand zwischen dem, was möglich ist, und dem, was existiert, wächst schneller als die meisten Organigramme sich ändern.

Melvin Conway beobachtete 1968 dasselbe Muster auf einer anderen Ebene: Organisationen bauen Systeme, die ihre eigene Kommunikationsstruktur spiegeln. Zwei Abteilungen ohne Austausch produzieren eine Schnittstelle ohne Funktion — unabhängig davon, welche Technologie eingesetzt wird. Conway beschreibt denselben Mechanismus wie McCallum, nur rückwärts: Nicht Informationsknappheit erzeugt Struktur, sondern Struktur erhält Informationsknappheit. Wenn Koordination wegfällt, wandert Verantwortung zum Einzelnen — und damit steigt der Bedarf an Urteilsvermögen schneller als er in den meisten Organisationen aufgebaut wird. Wer die Hierarchie abbaut, bevor dieses Urteilsvermögen sitzt, schafft keine Agilität. Er schafft einen Zustand, in dem unklar ist, wer was entscheiden kann. Die interessantere Frage ist nicht, wie viele Ebenen ein Organigramm hat — sondern wo im Unternehmen Wissen heute lokal bleibt und warum.

Organisationen erkennen den Übergang meistens nicht von innen. Tobi Lütke hat 2025 bei Shopify eine interne Regel eingeführt: Wer neue Mitarbeitende anfordert, muss zuerst belegen, warum KI die Aufgabe nicht übernehmen kann. Danach hat Shopify Management-Ebenen gestrichen — nicht als Effizienzprogramm, sondern weil der Koordinationsbedarf weggefallen war, der diese Ebenen ursprünglich erzeugt hatte. Das ist keine Ausnahme. Das ist McCallums Logik rückwärts. Span of Control war nie eine Wahrheit — es war ein Kompromiss mit dem damaligen Informationsproblem. Die offene Frage ist nicht, ob Ihre Hierarchie zu tief ist — sondern wo in Ihrer Organisation heute Aufmerksamkeit knapp ist, wo Wissen lokal bleibt und wo Entscheidungen verzögert werden, weil die Struktur sie nicht durchlässt.

Wer in Ihrem Unternehmen hat heute mehr Informationen als Entscheidungsmacht — und warum ist das so geblieben?
07 These 07 · 2026

Intent ist das neue Coding

Über Klärungszeit als Investment und die einzige Kombination, die wirklich funktioniert

Der Entwickler lieferte exakt das, was im Ticket stand. Und exakt das Falsche. Wer ein KI-Modell falsch brieft, merkt es nach zwei Minuten. Mit KI wird Unklarheit nicht gnädiger — sie wird nur schneller sichtbar.

Intent ist das neue Coding

Schnellere Autos auf falscher Straße kommen schneller ans falsche Ziel. Der Wert der Navigationsentscheidung wächst mit der Fahrzeuggeschwindigkeit — er sinkt nicht. Es ist die operative Realität jedes Produktteams, das KI-gestützte Entwicklung einsetzt, ohne den Klärungsprozess davor neu zu denken.

Ein Intent Statement ist eine Seite. Darauf steht: Wer nutzt das, wozu, was ist Erfolg, was ist ausdrücklich kein Scope. Teams, die das konsequent tun, investieren 15 bis 25 Prozent der Projektzeit in die Klärung, bevor sie mit der Implementierung beginnen. Wer vorher klärt, was er will, braucht hinterher weniger Korrekturen. Wer es nicht tut, iteriert — nur schneller.

KI produziert ohne klaren Kontext konsistent plausible, aber falsche Lösungen. Schneller als jedes menschliche Team es je konnte. Der Hebel wirkt in beide Richtungen: Teams, die Intent präzise formulieren, werden überproportional schnell. Teams, die es nicht können, werden überproportional falsch — und das mit wachsender Geschwindigkeit.

Wer den Intent definiert, bestimmt die Richtung — und was überhaupt als Erfolg gilt. Intent-Formulierung ist keine kognitive Übung. Sie ist eine Machtfrage. Ob KI diesen Prozess künftig übernehmen kann — Intent aus Kontext extrahieren, Widersprüche benennen, bevor das Team sie baut — ist offen. Was nicht offen ist: Solange Menschen entscheiden, wer das Ziel definiert, entscheiden sie, wessen Ziel gebaut wird.

Wer in Ihrem Team hat das letzte Intent Statement geschrieben?
08 These 08 · 2026

Der Projektantrag ist das neue Faxgerät

Über IT als internen Auftragnehmer und den Koordinationsapparat, der für eine Knappheit gebaut wurde, die es nicht mehr gibt

Projektanträge waren kein bürokratischer Fehler. Sie waren Warteschlangen-Verwaltung für eine knappe Ressource — Entwicklerzeit. Das Rationierungssystem war präzise auf den Engpass ausgerichtet.

Der Projektantrag ist das neue Faxgerät

Das Modell hatte seine eigene Logik: Business formuliert Anforderungen, IT schätzt Aufwand, der Projektmanager verwaltet die Warteschlange. Es war für seinen Engpass gebaut — nicht aus Nachlässigkeit, sondern weil der Engpass real war. Wer Monate auf Umsetzung wartet, braucht einen Prozess, der diese Monate verwaltet. Der Projektantrag war keine Bürokratie. Er war die Antwort auf ein echtes Problem.

Wenn der Engpass wegfällt, fällt der Bedarf am Engpassmanagement weg. Ein Finanzunternehmen in Frankfurt ging 2024 den klassischen Weg: Projektantrag, sechs Monate Entwicklung, Chatbot live. Der Chatbot löste das falsche Problem. Die sechs Monate waren keine Ineffizienz — sie waren Systemlogik. Der Prozess hat funktioniert. Das Ergebnis nicht.

Was bleibt, wenn der Projektantrag wegfällt, ist nicht Chaos — es ist eine Frage, die der Prozess bisher verdeckt hat: Wer entscheidet eigentlich, was gebaut werden soll? Der Projektantrag hat diese Entscheidung erzwungen, formalisiert, dokumentiert. Stakeholder-Management, das Abwägen widersprüchlicher Anforderungen, das Urteil unter Unsicherheit — das alles hat im Prozess mitgelaufen, unsichtbar. Wenn der Prozess wegfällt, wird das Urteilsvermögen sichtbar. Oder es fällt weg, ohne dass jemand gemerkt hat, dass es da war.

Story Points messen, wie lange ein Entwickler braucht, um etwas zu bauen. Sprint-Velocity ist die Durchsatzrate dieser Messung — wie viele solcher Einheiten ein Team pro Woche abarbeitet. Beides optimiert für denselben Engpass wie der Projektantrag, nur eine Ebene tiefer: knappe Entwicklerkapazität als planbare Ressource. Wenn ein KI-Agent einen Ticket-Backlog in einem Sprint abarbeitet, misst Sprint-Velocity die falsche Einheit. Die Frage ist nicht, ob Teams schneller werden — sondern was die Einheit sein soll, wenn Kapazität kein Engpass mehr ist.

Was gerade passiert, ist keine Effizienzfrage. Unternehmen, die Projektanträge streichen, beschleunigen nicht — sie legen frei, was der Prozess verborgen hat: dass Organisationen bisher nicht entschieden haben, was sie bauen wollen, sondern was sie sich leisten konnten zu bauen. Das ist ein anderes Urteilsvermögen. Und es ist unklar, ob es in den meisten Organisationen vorhanden ist.

Messen Sie es: Vom ersten Gespräch über eine neue Idee bis zum ersten produktiven Deployment — wie viele Tage vergehen, und welcher Anteil davon ist reine Wartezeit im Prozess?
01 / 08