Als die Tabellenkalkulation Anfang der Achtzigerjahre in die Unternehmen kam, war die eigentliche Neuerung nicht, dass gerechnet werden konnte. Gerechnet wurde vorher auch. Neu war, wer rechnen durfte.
Bis dahin lief jede Auswertung, die über den Taschenrechner hinausging, über eine Datenverarbeitungsabteilung. Man stellte einen Antrag, wartete, bekam eine Liste und stellte fest, dass man eigentlich eine andere Frage hatte. Die Tabellenkalkulation hat diesen Umweg abgeschafft. Nicht, indem sie aus Kaufleuten Programmierer machte, sondern indem sie die Person, die die Frage hatte, in die Lage versetzte, sie selbst zu beantworten.
Genau dieselbe Verschiebung passiert derzeit mit dem Bauen von Software. Und sie verläuft schneller als damals.
Was Agentic Coding von Code-Vervollständigung unterscheidet
Die erste Generation von KI-Werkzeugen für Entwickler hat Zeilen vorgeschlagen. Man tippte etwas an, das Werkzeug ergänzte es. Nützlich, aber im Kern eine schnellere Tastatur.
Agentic Coding funktioniert anders. Man beschreibt in normaler Sprache, was entstehen soll. Das System liest den vorhandenen Bestand, plant die nächsten Schritte, legt Dateien an und ändert sie, führt Tests aus, sieht die Fehlermeldung, korrigiert und wiederholt den Vorgang, bis es funktioniert. Es arbeitet also nicht an einer Zeile, sondern an einer Aufgabe – und über mehrere Runden hinweg, ohne jedes Mal nachzufragen.
Der praktische Unterschied ist derselbe wie zwischen einem Werkzeug und einem Auftragnehmer. Beim einen muss man wissen, wie man es hält. Beim anderen muss man wissen, was man will.
Das verschiebt die Anforderung. Was jemand mitbringen muss, ist nicht mehr primär Syntax, sondern die Fähigkeit, ein Problem präzise zu beschreiben, das Ergebnis zu beurteilen und zu erkennen, wenn etwas nur so aussieht, als würde es funktionieren. Diese drei Fähigkeiten bringt eine gute Projektleitung ohnehin mit.
Warum das eine Führungsaufgabe ist und keine IT-Frage
In kleinen Unternehmen liegt zwischen dem Problem und seiner Lösung fast immer dieselbe Lücke. Jemand weiß genau, welche Auswertung fehlt, welcher Handgriff sich jede Woche wiederholt, welches Formular niemand ausfüllen will. Diese Person kann es nicht bauen. Und für einen externen Auftrag ist es zu klein, weil das Briefing länger dauert als die Arbeit.
Diese Kategorie von Aufgaben ist über Jahrzehnte einfach liegen geblieben. Sie war zu klein für ein Projekt und zu groß für nebenbei. Genau dort wirkt Agentic Coding. Und deshalb ist es keine Frage für die IT, sondern für die Menschen, die das Geschäft kennen.
Das ist auch der Grund, warum der Excel-Vergleich mehr ist als eine Analogie. Excel hat aus niemandem einen Informatiker gemacht. Es hat den Zugang zur Rechenleistung von der Programmierkenntnis entkoppelt und ihn an das Fachwissen gebunden. Dasselbe passiert gerade mit dem Zugang zur Softwareerstellung. Wer es beherrscht, ist nicht zwangsläufig der, der am besten programmiert, sondern der, der am genauesten weiß, was gebraucht wird.
Was dabei schiefgeht
Die Euphorie in diesem Feld ist beträchtlich, und ein erheblicher Teil davon kommt von denen, die etwas verkaufen. Für ein Unternehmen, das anfängt, selbst zu bauen, sind drei Risiken konkreter als jede Marktprognose.
Software, die niemand versteht. Ein Werkzeug, das in zwei Stunden entsteht, wird jahrelang benutzt. Wenn niemand im Haus erklären kann, wie es funktioniert, ist jede spätere Änderung ein Neubau. Das ist derselbe Effekt, den jede Firma aus ihren gewachsenen Tabellen kennt, nur dass die Datei jetzt eine Anwendung ist.
Zugriff auf Daten, den niemand geprüft hat. Anwendungen, die sich lohnen, greifen fast immer auf echte Firmendaten zu. Wer sie ohne Prüfung baut, verschiebt Kundendaten und Vertragsinhalte an Stellen, die nie jemand freigegeben hat. Das ist kein Argument gegen das Bauen, sondern eines dafür, die Verarbeitungskette zu kennen, bevor etwas produktiv geht.
Der Anschein von Funktion. Ein Coding-Agent erzeugt Ergebnisse, die überzeugend aussehen. Ob sie unter realen Bedingungen tragen, zeigt sich nicht beim Vorführen. Und die eigene Einschätzung ist dabei ein schlechter Ratgeber: In einer randomisierten Studie von METR bearbeiteten erfahrene Entwickler Aufgaben in Projekten, die sie seit Jahren kannten, mit KI-Unterstützung im Durchschnitt 19 Prozent langsamer als ohne KI. Gefragt, wie es gelaufen sei, schätzten dieselben Personen, sie seien etwa 20 Prozent schneller gewesen.
Diese Untersuchung ist kein Argument gegen Agentic Coding, und sie beschreibt eine andere Situation als die hier gemeinte: erfahrene Entwickler in vertrauten, großen Open-Source-Codebasen, nicht jemanden, der ein kleines Werkzeug für die eigene Abteilung baut. Zudem bezog sich die Studie auf die damals verfügbaren KI-Werkzeuge und ist ausdrücklich als Momentaufnahme zu verstehen. In einer Folgeuntersuchung ließ sich die Wirkung neuerer Werkzeuge nicht zuverlässig bestimmen: Auswahleffekte verzerrten die Ergebnisse so stark, dass METR das Studiendesign geändert hat, statt eine neue Zahl zu nennen.
Was die ursprüngliche Studie zeigt, ist etwas anderes und Allgemeineres: Das Gefühl, schneller zu sein, kann entstehen, unabhängig davon, ob man es tatsächlich ist. Wer nicht selbst beurteilen kann, was er bekommen hat, kann sich auf seinen Eindruck nicht verlassen.
Der Engpass wandert
Bis vor Kurzem war die begrenzende Frage in jedem dieser Vorhaben, ob man es bauen kann. Diese Frage verliert gerade an Schärfe. Was an ihre Stelle tritt, ist eine andere: Was weiß das Gebaute eigentlich?
Denn die Anwendungen, die kleine Unternehmen auf diesem Weg tatsächlich bauen, sind selten technische Spielereien. Es sind Assistenten, die Fragen zum eigenen Projektarchiv beantworten. Generatoren, die Angebote, Präsentationen oder Kundenmails erzeugen. Auswertungen, die verstreute Bestände zusammenführen. Sie alle haben eine Eigenschaft gemeinsam: Sie greifen auf Firmenwissen zu und sprechen nach außen.
Ein leeres Werkzeug ist schnell gebaut. Ein Werkzeug, das das Unternehmen kennt, ist genau so viel wert wie das, was hinterlegt ist. Wenn drei Fassungen derselben Leistungsbeschreibung im Bestand liegen, entscheidet die Formulierungsähnlichkeit darüber, welche das Werkzeug findet, und nicht die Gültigkeit. Wenn nirgends festgehalten ist, wie das Unternehmen klingt, füllt das Modell die Lücke mit dem statistisch Wahrscheinlichsten aus seinem Training. Das Ergebnis ist selten falsch und fast immer allgemein.
Aus dieser Perspektive schafft Agentic Coding den Aufwand nicht ab, sondern verschiebt ihn. Was früher in die Entwicklung ging, geht künftig in die Frage, was gilt.
Es ist dieselbe Disziplin
Der Zusammenhang zwischen beidem ist enger, als es zunächst aussieht.
Was einen Coding-Agenten gut arbeiten lässt, ist nicht die geschickte Formulierung der Anweisung. Es ist der Kontext, den er im Moment der Aufgabe vorliegen hat: der bestehende Bestand, die Konventionen des Hauses, eine klare Beschreibung des Gewünschten, Beispiele für richtig und falsch. Wer diesen Kontext bereitstellt, bekommt brauchbare Ergebnisse. Wer improvisiert, bekommt Wiederholungsschleifen.
Beim Markenassistenten ist die Aufgabe dieselbe, nur mit anderem Inhalt. Auch dort entscheidet, was im Moment der Anfrage vorliegt: das belegbare Faktenwissen und die Identität des Unternehmens, also Positionierung, Vokabular, Tonfall und Tabus. Genau diese Trennung beschreibt das KI-Markengehirn: eine zentrale, gepflegte Schicht, aus der jedes Werkzeug, jede Person und jeder Agent denselben Stand bezieht.
Es ist in beiden Fällen dieselbe Entscheidung, nur an verschiedenen Stellen getroffen: Was muss vorliegen, damit die Maschine nicht raten muss? Wer das für seine Software beantwortet hat, hat den schwierigeren Teil für alles andere bereits geübt.
Warum jetzt
Der Grund, früh einzusteigen, ist nicht, dass die Werkzeuge heute besonders gut wären. Sie werden in zwei Jahren besser sein, und ein Teil dessen, was heute mühsam ist, wird dann selbstverständlich sein.
Der Grund ist, dass die Urteilsfähigkeit Zeit braucht. Zu erkennen, wann ein Ergebnis trägt und wann es nur so aussieht, lernt man nicht in einer Schulung. Man lernt es an eigenen kleinen Vorhaben, bei denen ein Fehler nichts kostet. Wer damit erst anfängt, wenn diese Werkzeuge in der eingekauften Software stecken und über echte Vorgänge laufen, lernt es unter deutlich schlechteren Bedingungen.
Die Tabellenkalkulation hat aus niemandem einen Buchhalter gemacht. Sie hat nur den Unterschied sichtbarer gemacht zwischen denen, die ihre Zahlen verstanden, und denen, die sie verwalteten. Bei Agentic Coding wird es genauso laufen, mit einem Zusatz: Diesmal entscheidet nicht nur, wer die Werkzeuge bedienen kann, sondern auch, wer seinem Werkzeug überhaupt etwas Verlässliches zu sagen hat.
Quelle: METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, 10. Juli 2025. Randomisierte Studie mit 16 erfahrenen Entwicklern und 246 Aufgaben in großen Open-Source-Projekten, an denen sie im Schnitt seit rund fünf Jahren arbeiteten. Die eingesetzten KI-Werkzeuge entsprachen dem Stand von Februar bis Juni 2025. METR beschreibt die Ergebnisse als Momentaufnahme; zur Folgeuntersuchung und der geänderten Versuchsanordnung siehe METR, „We are Changing our Developer Productivity Experiment Design“, 24. Februar 2026.
Wo steht Ihr Unternehmen? Im kostenlosen KI-Marken-Check ordnen wir das gemeinsam ein — strukturiert, unverbindlich, in 30 Minuten.