Was von der IT-Beratung übrig bleibt

Bei INNOQ gebe ich schon seit einiger Zeit Trainings zu „Agentic Software Engineering“. Dort dreht sich alles darum, wie Teams mit KI und Coding-Agents Software bauen.

Eine Frage, die ich mir stelle, kommt in diesen Trainings aber so gut wie nie auf: Was passiert eigentlich mit denen, die davon leben, dass Kunden das (noch) nicht selbst können?

Das betrifft mich natürlich selbst. Ich bin angestellter IT-Berater, und ein guter Teil meiner Arbeit wird nach Tagen abgerechnet.

Im Mai habe ich schon mal über Softwarefabriken geschrieben und am Ende die Frage offen gelassen: Wer baut eigentlich diese Fabrik? Mich beschäftigt inzwischen auch, was aus den Leuten wird, die bisher beim Betrieb dieser Manufaktur geholfen haben. Ich glaube, das, was Leute wie ich liefern, besteht aus zwei unterschiedlichen Arten von Arbeit. Nur eine davon ist in Gefahr. Aber es ist leider auch die, mit der das meiste Geld verdient wird.

Tausend Pull Requests später

Ausgelöst hat diesen Post das umstrittene Gespräch zwischen Lex Fridman und DHH von Ende August. Ich weiß, DHH ist ein schwieriges Thema. Von vielen seiner Ansichten und Aussagen distanziere ich mich sehr stark. Drei Beobachtungen aus dem Gespräch gehen mir trotzdem seitdem nicht mehr aus dem Kopf.

Erstens: der Qualitätssprung. DHH erzählt, dass er in drei Monaten die neue Major-Version seiner Linux-Distribution gebaut hat: über tausend Pull Requests gemerged, und nach eigener Aussage keine Zeile des ausgelieferten Codes von Hand geschrieben. Opus 4.5 nennt er seinen persönlichen AHA-Moment: den Punkt, ab dem der Output „unheimlich nah“ an dem war, was er selbst geschrieben hätte. Diesen Moment hatte ich tatsächlich auch. Das war Ende letzten Jahres.

Man muss dazusagen: DHH ist schon ein extremer und polarisierender Sonderfall (in jeglicher Hinsicht). Ihm gehören seine Produkte, er hat fünfundzwanzig Jahre Erfahrung und entscheidet weitgehend allein, ohne Auftraggeber, Compliance oder Konzern. Sein Beispiel zeigt, was möglich ist, wenn jemand die Qualität selbst beurteilen und selbst entscheiden darf. Für den Durchschnitt steht es kaum. Immerhin erwähnt er auch die rund vierhundert Pull Requests, die ungemergt liegen geblieben sind.

Trotzdem: Diese Zahlen hätte vor einem Jahr niemand für möglich gehalten, DHH selbst am wenigsten. Und die Werkzeuge werden seitdem gefühlt jeden Monat besser.

Zweitens: die Zwischenschicht. Der große Produktivitätssprung entsteht laut DHH nur, wenn ein Mensch direkt mit den Agenten arbeitet. Sobald jemand dazwischen sitzt, der Anforderungen übersetzt, Ergebnisse weiterreicht oder Freigaben einsammelt, ist der Gewinn weg. Seine Formulierung:

You have to interact with the agents directly, and you cannot intermediate that bandwidth with another human because it's simply too slow.

Für Beratungen klingt das erst mal bedrohlich, schließlich sitzen sie im Projektgeschäft oft genau zwischen Kundenwunsch und Code. Ganz so einfach ist es aber nicht. Externe Entwickler:innen können genauso direkt mit Agenten arbeiten wie interne. Entscheidend ist, wie viele Übergaben es gibt, wie gut jemand den Kontext kennt und was er entscheiden darf. Bedroht ist vor allem jede Konstellation, in der Menschen nur Informationen weiterreichen. Die gibt es in Beratungsprojekten allerdings reichlich.

Drittens: die kurze Halbwertszeit von Werkzeugwissen. DHH behauptet, wer ein Jahr lang nichts von agentischer Entwicklung mitbekommen hat, holt den Rückstand in zwei Wochen auf. Für die Bedienung der Werkzeuge glaube ich ihm das sofort, das sehe ich als Trainer auch. „Wir kennen die neuesten Tools“ taugt nicht mehr als Verkaufsargument. Bei allem, was darüber hinausgeht, sieht es anders aus. Da ziehen einige gerade davon. Niemand lernt in zwei Wochen, im Team eine Software Factory mit Evals so aufzusetzen, dass sie verlässlich Software baut.

Im selben Podcast erzählt DHH aber auch ein Gegenbeispiel: Sein eigenes Bestandsprodukt Basecamp, ein großes gewachsenes System, ließ sich überraschend schlecht agentisch beschleunigen. Designer, die dort mit Agenten drauflos gebaut haben, haben nach seiner Erzählung in wenigen Wochen die Architektur beschädigt, aufgeräumt werden musste von Hand. Ein über Jahre gewachsenes System steckt eben voller Konventionen und Abhängigkeiten, die nirgends aufgeschrieben sind. Neue, kleine Projekte profitieren also sofort, große gewachsene Systeme erst deutlich später. Das verschafft Beratungen etwas Zeit, aufhalten wird es die Entwicklung aber vermutlich nicht.

Der Haken mit dem Tagessatz

„Die eine IT-Beratung“ gibt es nicht. So ganz grob könnte man vielleicht drei Sorten unterscheiden. Body-Leasing verleiht Kapazität: Wer zwei Entwickler:innen braucht, bekommt zwei Entwickler:innen. Strategieberatung verkauft Folien und Urteil: „Hier ist unsere Empfehlung, viel Erfolg bei der Umsetzung.“ Und technische Software-Beratung baut tatsächlich Software, für und mit dem Kunden. Die dritte Sorte ist die interessante, weil sie beides mischt, Hände und Kopf, im selben Tagessatz.

Was fast alle drei gemeinsam haben: Sie rechnen nach Zeit ab. Die zwei Größen, über die diese Branche sich steuert, heißen Auslastung und Tagessatz. Beide messen verkaufte Stunden. Keine von beiden misst, ob beim Kunden hinterher etwas Besseres steht als vorher.

Das betrifft übrigens nicht nur große Beratungshäuser. Freiberufler:innen kennen dieselben zwei Größen, sie heißen dort nur Kalender und Stundensatz.

Dieser Konflikt ist älter als jeder KI-Hype. Wer Zeit verkauft, will möglichst viele abrechenbare Stunden. Wer Zeit einkauft, will möglichst viel Ergebnis für möglichst wenige Stunden. Diesen Widerspruch haben alle Beteiligten jahrzehntelang höflich ignoriert, weil die Nachfrage groß genug war. KI verschärft ihn jetzt, weil der Einkäufer plötzlich eine Alternative hat: Einen Teil der Arbeit kann er selbst mit Agenten erledigen. Selbst wenn jede Prognose in diesem Post um Jahre danebenliegt: Dieser Punkt bleibt.

Dass ein Kunde etwas selbst bauen kann, heißt allerdings noch nicht, dass er die Fähigkeit intern aufbauen und dauerhaft betreiben will. Beratung kann also gefragt bleiben, nur vermutlich in anderer Form. Vielleicht macht der Agent fünf sehr gute externe Leute so produktiv wie vorher zwanzig. Ein kleines agent-natives Team, etwa ein Agentic Trio, kann dann die klassische externe Delivery ersetzen und Teile der internen IT gleich mit. Unter Druck gerät dabei vor allem das Modell, in dem der Umsatz an der Zahl der Köpfe und Stunden hängt.

Aber das Ende der abrechenbaren Stunde wurde zugegebenermaßen schon oft ausgerufen. Offshoring sollte sie beerdigen, die Cloud sollte sie beerdigen, Plattform-Engineering sollte sie beerdigen. Passiert ist jedes Mal dasselbe: Die Branche ist die Wertschöpfungskette ein Stück nach oben geklettert und hat weiter Stunden geschrieben, nur teurere. Forrester argumentiert genau so: schon wieder eine Welle, schon wieder wird absorbiert.

Vielleicht. Mein Zweifel: Die früheren Wellen haben Ausführung billiger gemacht. Diese Welle macht auch die Schicht darüber billig: die Übersetzung. Und genau dorthin sind Beratungen bei jeder früheren Welle ausgewichen, wenn das reine Umsetzen billiger wurde. Dafür muss ich allerdings genauer auseinandernehmen, was Übersetzung hier meint.

Lost in Translation

Mit Übersetzung meine ich: aus dem, was ein Kunde will, etwas machen, das ein Computer ausführen kann und das dann hoffentlich einen Mehrwert für dessen Endkunden erzeugt. Die Zuspitzung lautet dann: Der Kunde kaufte diese Übersetzung, weil er die Zielsprache nicht beherrschte (Java, Ruby, SQL, was auch immer). Jetzt verstehen Agenten natürliche Sprache, also braucht er diese Übersetzung nicht mehr. Das stimmt und ist gleichzeitig etwas zu grob. Denn meiner Meinung nach war die Zielsprache der Softwareentwicklung nie Ruby oder Java oder sonstwas. Es gab immer zwei Formen von Übersetzung, die nur zufällig im selben Job steckten.

Bei der ersten wird aus einem Wunsch funktionierende Software, etwa aus „Bau mir eine Anbindung ans Identitätssystem“. Diese Sorte Übersetzung können Agenten inzwischen wenig überraschend gut, und sie wird jeden Monat besser.

Bei der zweiten müssen sich Menschen in einer Organisation erst darauf einigen, was sie überhaupt erreichen wollen. Das ist die ältere und schwierigere Aufgabe. Was will dieser Laden eigentlich erreichen? Welche Anforderungen widersprechen sich? Wer darf das entscheiden? Was passt in fünfundzwanzig Jahre gewachsene Systeme? Ein Agent baut in Minuten die Anbindung ans Identitätssystem. Er bringt aber Finanzabteilung, Rechtsabteilung, Plattformteam und Betriebsrat nicht dazu, sich zu einigen, welche Identitäten überhaupt verwendet werden dürfen.

Ich nenne die beiden Informationsvermittlung und Entscheidungsvermittlung. Informationsvermittlung: Ein Mensch erklärt einem zweiten, was ein dritter tun soll. Ich glaube, diese Arbeit schrumpft zuerst. Meistens war sie nötig, weil die Beteiligten sich nicht direkt und schnell genug verständigen konnten. Ganz verschwinden wird sie nicht; Vertrauen, Geheimhaltung oder Regulierung können sie stellenweise am Leben halten. Aber sie wird zur Ausnahme, nicht mehr zum Geschäftsmodell. Entscheidungsvermittlung: Verschiedene Menschen wissen unterschiedliche Dinge, dürfen Unterschiedliches entscheiden und tragen unterschiedliche Risiken. Jemand muss mit ihnen eine Entscheidung erarbeiten, die sie gemeinsam tragen können. Das ist ein komplett anderes Problem. KI kann dabei sogar helfen: Interessenkonflikte sichtbar machen, Optionen durchspielen, Verhandlungen vorbereiten. Aber ein Modell-Upgrade allein löst keinen Interessenkonflikt.

Urteil ist auch nur Arbeit

Die (zu) einfache Antwort auf all das lautet: Tätigkeit stirbt, Urteil überlebt. Hände werden ersetzt, Köpfe nicht. Das klingt naheliegend, hat aber einen Haken: Urteil ist selbst auch eine Tätigkeit. Agenten stecken längst in Aufgaben, die wir gern als Urteil etikettieren: Code-Reviews, Architekturvarianten, Risikoanalysen, Priorisierung, Entscheidungsvorlagen. In meinen eigenen Projekten lasse ich inzwischen jeden Diff erst von einem Review-Agenten prüfen, bevor ich selbst draufschaue, und der findet Dinge, die ich übersehen hätte. Ein Etikett schützt da gar nichts.

Entscheidend ist eher, unter welchen Bedingungen eine Aufgabe stattfindet. Gut an Agenten delegieren lässt sie sich, wenn das Ziel klar formuliert ist, Feedback schnell kommt, das Ergebnis billig überprüfbar ist, der nötige Kontext maschinenlesbar vorliegt, Fehler reversibel sind und niemand persönlich dafür geradestehen muss. Menschen bleiben wertvoll, wo das Gegenteil gilt: wo das Problem selbst erst ausgehandelt werden muss, wo das relevante Wissen implizit und über viele Köpfe verteilt ist, wo Ziele einander widersprechen, wo Fehler richtig teuer werden, wo Entscheidungen legitimiert werden müssen und jemand die Verantwortung trägt.

Diese Liste ist allerdings keine Grenze, hinter der Menschen sicher sind. Die Bedingungen lassen sich verschieben: Kontext lässt sich erschließen und aufschreiben, Feedback beschleunigen, Ergebnisse überprüfbarer machen. Genau darin steckt für mich ein großer Teil der künftigen Engineering-Arbeit. Auch dass jemand für ein Ergebnis geradestehen muss, verhindert keineswegs Automatisierung. Es legt fest, welche Nachweise, Grenzen und Eingriffsmöglichkeiten es braucht, damit sich die Arbeit trotzdem delegieren lässt. Wer sich nur auf die Aufgaben verlässt, die Agenten gerade noch nicht können, setzt auf ein Geschäftsmodell mit ungewissem Ablaufdatum.

Auch bei den beiden Übersetzungen kommt es darauf an, wie klar die Aufgabe ist und wer für das Ergebnis geradestehen muss. Agenten können klar beschriebene Aufgaben übernehmen. Wo Menschen aber erst Ziele aushandeln und Verantwortung übernehmen müssen, bleiben sie selbst gefragt.

Das schließt direkt an den Fabrik-Post an: Wenn Output billig wird, werden Verantwortung, Qualität und Wartung teuer. Auch wenn sich Software billig bauen lässt, bleibt ihr zuverlässiger Betrieb aufwendig. Jedes Werkzeug, das sich ein Team schnell agentisch selbst zusammenballert, muss ab Tag zwei jemand patchen, überwachen und absichern. Da entsteht gerade ein Berg Arbeit, über den noch kaum jemand redet, weil alle aufs Bauen starren.

Der Ast, auf dem wir sitzen

Wenn nur eine der beiden Übersetzungen in Gefahr ist, warum dann die Unruhe? Weil die Branche selbst kräftig daran mitarbeitet, diese eine Sorte schneller zu entwerten. Beratungen schulen überall Kunden im Umgang mit Coding-Agents, solche Trainings sind gefragt wie lange nichts. Aber: Je sicherer die Kunden mit den Werkzeugen werden, desto weniger externe Hände brauchen sie.

Der für mich falsche Schluss daraus wäre: dann halt keine Schulungen machen. Die Werkzeuge reifen auch ohne Zutun der Beratungen zur Massenware. Die Modellanbieter investieren Milliarden genau dahin. Und weil sich die Bedienung der Werkzeuge schnell aufholen lässt, gibt es da ohnehin keinen Wissensvorsprung, den man schützen könnte, indem man nicht schult. Auch ohne Schulungen werden Kunden die Werkzeuge nutzen. Mit Trainings verdienen Beratungen zumindest an diesem Übergang. Reine Tool-Einführungen sind also ein Übergangsgeschäft. Anders sieht es aus, wenn ein Training Teams hilft, ihre Arbeitsweise zu verändern und das Gelernte im Alltag anzuwenden. Das bleibt deutlich länger relevant. Offen bleibt, was mit dem Geld aus den Trainings passiert: ob es in den Aufbau von etwas Neuem fließt oder „nur“ die Zahlen des laufenden Jahres verbessert.

Vier Richtungen, die ich spannend finde

Wenn ein Teil des bisherigen Geschäfts wegbricht, was trägt dann stattdessen? Darüber habe ich mit Kolleg:innen schon oft diskutiert. Vier Ideen aus diesen Gesprächen will ich hier rauspicken, weil sie sich mit meinen eigenen Erfahrungen decken. Alle vier setzen dort an, wo Kontext verteilt ist, wo verhandelt werden muss oder wo jemand geradesteht.

Menschen durch die Veränderung begleiten. Werkzeuge wechseln in Wochen. Gewohnheiten, Teamstrukturen und Ängste wechseln deutlich langsamer. Wenn Entwickler:innen künftig mehr prüfen als schreiben, müssen Rollen neu geschnitten werden. Karrierepfade können nicht mehr an geschriebenen Codezeilen hängen. Und die Angst, ersetzbar zu sein, sitzt in vielen Teams längst mit am Tisch.

Dazu kommt jede Menge neue Arbeit, die erst durch die veränderte Arbeitsweise entsteht: Eine Software Factory, also eine weitgehend automatisierte Umgebung, in der Agenten Software bauen, will aufgebaut und gewartet werden. Und die frei werdende Entwicklungskapazität muss nicht automatisch in noch mehr Features fließen. Sie kann in Dinge gehen, die heute kaum jemand auf dem Radar hat, etwa bessere Product Discovery, Wartung oder Wissen, das endlich aufgeschrieben wird. Teams auf diesem Weg zu begleiten, gehört für mich genauso dazu. Ein Teil dieser Arbeit lässt sich natürlich auch an Agenten delegieren: Kommunikationspläne, Schulungsunterlagen, Workshop-Vorbereitung. Aber der Kern bleibt zutiefst zwischenmenschlich. Wer einem Team hilft, offen über die eigene Ersetzbarkeit zu reden, braucht dessen Vertrauen. Ein Agent kann bei der Vorbereitung helfen, aber dieses Vertrauen muss zwischen den Beteiligten entstehen. Deshalb halte ich das für ein Angebot mit Zukunft.

Die Produktionsanlage beherrschen. Im Fabrik-Post ging es um die Anlage, die Software baut. Gerade bauen sich viele Organisationen ihre eigene zusammen: Quality Gates, Review-Agenten, Kostenkontrolle für Tokens, Regeln für Agenten, die nachts zuverlässig und ohne böse Überraschungen allein weiterarbeiten. Die Werkzeuge dafür werden die Modellanbieter früher oder später selbst mitliefern. Was bleibt, ist das Handwerk dahinter: Engpässe in einer Agenten-Pipeline finden, „Stoppleinen“ einbauen, die bei schleichendem Qualitätsverlust anhalten, und Erfahrungswissen so aufbereiten, dass Agenten es nutzen können. Das Wissen, wie man so eine Anlage auslegt und prüft, hält deutlich länger als jedes einzelne Werkzeug.

Den Betrieb übernehmen. Weiter oben ging es um den Berg Arbeit, der entsteht, wenn sich Teams ihre Werkzeuge selbst zusammenbauen. Daraus kann ein eigenes Angebot werden: Eine Beratung übernimmt dauerhaft eine klar abgegrenzte Leistung, zum Beispiel Betrieb, Updates und Absicherung einer Handvoll interner Werkzeuge. Dafür muss aus ihr keine SaaS-Firma werden. Spannend sind die Fragen dahinter: Welche Verantwortung kauft der Kunde konkret ein, was bleibt bei ihm, und lässt sich das wirtschaftlich liefern?

Erfahrung in etwas gießen, das bleibt. Der Stundenverkauf ist nach oben gedeckelt. Das gilt für Beratungshäuser genauso wie für alle, die freiberuflich entwickeln, designen, texten oder beraten. Fieser ist, dass nach jedem Projekt fast alles verdampft, was dabei gelernt wurde, und das nächste Jahr wieder bei null Stunden anfängt. Neben Kundennutzen und Umsatz sollte aus einem Projekt etwas bleiben, das beim nächsten hilft: ein Muster, ein Werkzeug, eine Checkliste, eine festgehaltene Erfahrung. Aus Mustern werden Werkzeuge, aus Werkzeugen manchmal Produkte, und deren Erlöse hängen dann vielleicht nicht mehr am Kalender. Mit Agenten bekommt das noch mehr Gewicht: Was ich an Kontext, Regeln und Erfahrungen festhalte, steht meinen Agenten beim nächsten Projekt sofort zur Verfügung. Dieser Vorrat wächst mit jedem Projekt, und er hängt stark an den Menschen, die ihn pflegen. Genau deshalb ziehen manche Teams davon.

Den Unterschied habe ich selbst erlebt. Neben der Beratung habe ich fünf Jahre lang mit einem kleinen Team ein SaaS-Produkt für Reisekostenabrechnung betrieben. Da hat uns nie jemand für Stunden bezahlt. Die Kunden zahlten ein Abo für ein Produkt, das ihre Reisekosten abrechnet. Ob ich dafür zehn Minuten oder drei Nächte gebraucht habe, war mein Problem. Das Produkt ist am Ende (leider) gescheitert, aber diese eine Erfahrung hat sich eingebrannt: Es fühlt sich fundamental anders an, für ein Produkt bezahlt zu werden statt für Anwesenheit.

Wichtiger wird außerdem sichtbares Urteil: Artikel, Talks, Tutorials, Screencasts, freie AmA-Sessions. Wer seine Erfahrung öffentlich nachvollziehbar und erlebbar macht, wird eher als fachliche Referenz wahrgenommen und bleibt gefragt.

Known Unknowns

Ein Post wie dieser lädt zu einer Gewissheit ein, die ich nicht habe. (Mindestens) Zwei Dinge weiß ich schlicht nicht.

Ob billigere Software mehr Software bedeutet. Wenn Entwicklung zehnmal produktiver wird, kann ein Kunde neunzig Prozent weniger Externe brauchen, oder er baut zehnmal mehr, weil plötzlich Dinge wirtschaftlich werden, die es vorher nicht waren. DHH glaubt an Letzteres: Jeder baut sich die fünf Prozent eines Produkts, die er wirklich braucht, selbst. Dann entsteht in jeder Firma ein Zoo selbstgebauter Werkzeuge, den irgendjemand betreiben muss. Welche Richtung dominiert, ist die größte Unbekannte in diesem Gedankenexperiment.

Wie schnell das alles geht. Ob die Branche auch diesen Wandel wieder auffängt und weiter Stunden verkauft, ist offen. Und ob die Trägheit großer Organisationen zwei Jahre Zeit kauft oder sechs Quartale, macht den Unterschied zwischen geordnetem Umbau und Panik.

Was ich dagegen ziemlich sicher weiß: Die Frage, ob man für Stunden bezahlt wird oder für etwas, wofür man geradesteht, wird in den nächsten Jahren jede Rechnung erreichen, die nach Zeit gestellt wird. Meine auch. Aber ich stelle sie mir lieber jetzt, solange ich noch die Zeit habe, meine Arbeit danach auszurichten.

Danke an Markus Harrer und Robert Glaser fürs Gegenlesen und die vielen Diskussionen zum Thema.