Die Entwicklung der Automatisierung: von Shell-Skripten zu KI-Organisationen

Die Technik ändert sich, der Grundhandel nicht: einmal investieren, um dieselbe Arbeit nicht ewig wiederholen zu müssen.

Ich baue seit Langem Software, und eines ist bei der Automatisierung die ganze Zeit bemerkenswert konstant geblieben: Die Technik ändert sich, die Logik nicht. Wenn ich merke, dass ich dasselbe immer wieder tue, kommt fast immer der Punkt, an dem es sich lohnt, vorab Zeit in die Automatisierung zu stecken.

Ende der 1900er hieß das vielleicht, ein Shell-Skript zu schreiben. Wenn ich einen Haufen Dateien umbenennen, Daten wiederholbar verarbeiten, Dinge zwischen Systemen kopieren oder immer wieder dieselben Befehle absetzen musste, konnte ich es entweder weiter von Hand machen oder die Zeit aufwenden, es einmal zu skripten. Das Skript zu schreiben dauerte womöglich länger, als die Aufgabe einmal zu erledigen, aber darum ging es nie. Der Gewinn kam mit jeder weiteren Wiederholung.

Diese Grundgleichung hat sich nicht geändert. Geändert hat sich die Größenordnung dessen, was wir automatisieren können.

Zuerst automatisierten wir Aufgaben

Die frühesten Formen der Automatisierung, mit denen ich arbeitete, waren klein und lokal. Ein Shell-Skript ersetzte eine Reihe von Befehlen. Ein Cron-Job ließ etwas nach Zeitplan geschehen. Ein Perl- oder Python-Skript machte aus einem repetitiven Ablauf etwas Wiederholbares.

Typische Beispiele sahen so aus:

• Große Mengen von Dateien umbenennen oder verschieben
• Daten jedes Mal auf dieselbe Weise verarbeiten
• Dateien zwischen Systemen kopieren
• Wiederkehrende Deployment-Befehle ausführen
• Regelmäßige Wartungsjobs einplanen

Die Abstraktion war schlicht: Ich weiß genau, was der Rechner tun soll, ich kann es präzise genug beschreiben, und ich stecke die Zeit lieber einmal ins Beibringen, als es für immer selbst zu erledigen. Manchmal hieß das, zwei Stunden in die Automatisierung einer Aufgabe zu stecken, die von Hand fünf Minuten dauerte. Das wirkt absurd, wenn man sie nur einmal erledigen will. Will man sie hundert- oder tausendmal erledigen, liegt es auf der Hand.

Dieses Muster wiederholte sich, während Softwaresysteme immer komplizierter wurden.

Dann automatisierten wir die Infrastruktur

Cloud Computing erweiterte den Rahmen dessen, was sich skripten ließ. Statt eine Aufgabe auf einer Maschine zu automatisieren, automatisierten wir nun das Erzeugen und Konfigurieren der Maschinen selbst.

Terraform ließ uns Infrastruktur als Code beschreiben. Kubernetes ließ uns beschreiben, wie verteilte Anwendungen laufen, skalieren, neu starten und kommunizieren sollen. CI/CD-Systeme automatisierten den Weg der Software von der Versionsverwaltung in die Produktion.

Plötzlich ließ sich deklarieren und neu erzeugen, was traditionell erhebliche manuelle Betriebsarbeit erforderte:

• Server
• Netzwerke
• Datenbanken
• Load Balancer
• Berechtigungen
• Anwendungs-Deployments
• Skalierungsregeln
• Ganze Umgebungen

Was früher bedeutete, dass Menschen sich durch Konsolen klickten, Systeme von Hand konfigurierten und Deployments koordinierten, wurde nach und nach zu etwas, das man versionieren, prüfen, testen und reproduzieren konnte.

Die Vorabkosten wuchsen, weil das Automatisierte wuchs. Gute Infrastrukturautomatisierung ist schwieriger als ein zehnzeiliges Shell-Skript. Sie verlangt mehr Nachdenken, mehr Randfälle, mehr Debugging und mehr Pflege. Der Nutzen aber skaliert mit der Komplexität. Ist eine Umgebung sauber definiert, lassen sich ganze Systeme, die früher Stunden oder Tage manueller Einrichtung brauchten, mit sehr wenig menschlichem Aufwand wiederherstellen.

Das Prinzip der Automatisierung blieb exakt dasselbe. Wir sind nur eine Ebene höher gerückt.

Jetzt automatisieren wir Arbeitsabläufe

KI-Agenten schieben diese Abstraktion erneut nach oben. Zunächst war der naheliegende Anwendungsfall, einen Agenten wie ein sehr fähiges Skript zu behandeln: Aufgabe geben, ausführen lassen, Ergebnis entgegennehmen.

Das ist nützlich, aber auch eine recht enge Sicht auf das, was gerade passiert. Die größere Verschiebung ist, dass wir nun nicht mehr nur einzelne Aufgaben automatisieren können, sondern die Koordination von Aufgaben über mehrere intelligente Arbeitskräfte hinweg.

Ein moderner agentischer Arbeitsablauf könnte so aussehen:

• Ein Agent schreibt den Code.
• Ein anderer prüft die Umsetzung.
• Ein anderer lässt die Tests laufen.
• Ein anderer sucht nach Sicherheitsproblemen.
• Ein anderer verifiziert, ob die ursprünglichen Anforderungen tatsächlich erfüllt wurden.
• Ein Ablauf entscheidet, was geschieht, wenn etwas fehlschlägt.
• Freigabepunkte legen fest, was einen Menschen braucht und was automatisch weiterlaufen darf.

An diesem Punkt skripten Sie nicht mehr die Arbeit. Sie skripten das System, das die Arbeit organisiert. Das ist ein viel größerer Sprung, als eine manuelle Aufgabe durch eine KI-Aufgabe zu ersetzen. Die Grenze der Automatisierung verschiebt sich von der Ausführung zur Koordination.

Orgabot ist die jüngste Fassung derselben Idee

So denke ich über Orgabot. Man betrachtet die Orchestrierung von KI-Agenten leicht als etwas grundlegend anderes als die Automatisierungswerkzeuge davor, doch abstrakt betrachtet ist es dasselbe Muster, das ich seit Jahrzehnten benutze.

Der Verlauf ist ziemlich geradlinig:

• Ein Shell-Skript automatisierte Befehle, die ich nicht ständig tippen wollte.
• Infrastructure as Code automatisierte Systeme, die ich nicht ständig konfigurieren wollte.
• CI/CD automatisierte Deployment-Abläufe, die ich nicht von Hand koordinieren wollte.
• Agenten-Orchestrierung automatisiert Arbeit, die ich nicht Schritt für Schritt steuern will.
• Orgabot treibt das in Richtung einer Automatisierung der Struktur rund um die Arbeitenden selbst.

Der Unterschied ist die Größenordnung. Bei etwas wie Orgabot ist das Automatisierte kein Befehl mehr und nicht einmal eine Deployment-Pipeline. Es kann ein vollständiger Softwareentwicklungsablauf sein, mit mehreren spezialisierten Agenten, Berechtigungen, Prüfpunkten, Verifikationsschritten und Deployment-Logik.

Der Übergang führt vom Skripten einer Aufgabe wie „baue dieses Feature“ hin zur Definition eines Systems, das wieder und wieder entscheiden kann, wie Features gebaut werden sollen, wer sie bauen soll, wie die Arbeit geprüft wird und wann sie ausgeliefert werden kann. Das sieht weniger danach aus, einen Entwickler zu automatisieren, als Teile einer Organisation.

Automatisierung wandert weiter den Abstraktionsstapel hinauf

Rückblickend ist der Verlauf bemerkenswert konsistent:

• Wir automatisierten Befehle.
• Dann automatisierten wir repetitive Aufgaben.
• Dann automatisierten wir Deployments.
• Dann automatisierten wir Infrastruktur.
• Dann automatisierten wir Pipelines und Arbeitsabläufe.
• Jetzt automatisieren wir die Arbeitenden innerhalb dieser Abläufe.
• Und zunehmend automatisieren wir die Koordination zwischen ihnen.

Jeder Schritt verschiebt die Grenze nach oben. Interessant ist, dass sich jede Stufe wie die oberste anfühlt. Als Infrastruktur programmierbar wurde, wirkte das wie ein gewaltiger Abstraktionssprung. Als KI-Agenten anfingen, Software zu schreiben, ließ sich leicht vorstellen, wir hätten den natürlichen Endpunkt erreicht: der KI einfach sagen, was man will, und sie bauen lassen.

Doch selbst das sieht bereits nach einem Zwischenschritt aus. Statt einem Agenten zu sagen, was er tun soll, bauen wir Systeme, die entscheiden, welche Agenten arbeiten sollen, wie sie zusammenarbeiten, wie ihre Arbeit bewertet wird und was als Nächstes geschieht. Das wirft die naheliegende Frage auf: Was liegt über der automatisierten Orchestrierung?

Was wird in zehn Jahren skriptbar sein?

Setzt sich das Muster fort, könnte die nächste Abstraktion viel größer sein als alles, was wir heute Arbeitsablauf nennen. Vielleicht wird die Einheit, die wir automatisieren, eine ganze Organisation.

Sie könnten ein Geschäftsziel beschreiben und ein System die Entsprechungen davon zusammenstellen lassen:

• Produktentwicklung
• Engineering
• Infrastruktur
• Marketing
• Kundenbetreuung
• Finanzen
• Juristische Prozesse
• Analytik
• Betrieb

Die Eingabe wird womöglich weniger prozedural und mehr absichtsgetrieben. Statt Aufgaben, Abläufe oder Agenten zu spezifizieren, äußern Sie vielleicht nur ein Ziel wie „ich finde, es sollte ein Produkt geben, das dies tut“, und das System ermittelt alles, was nötig ist, um diese Idee Wirklichkeit werden zu lassen.

Dahinter steckt auch ein größeres historisches Muster. Die Interaktion zwischen Mensch und Maschine bewegt sich stetig zu höheren Ebenen der Absicht:

• Maschinencode wurde zu Programmiersprachen.
• Programmiersprachen bekamen Bibliotheken und Frameworks.
• Server wurden zu Infrastrukturdeklarationen.
• Befehle wurden zu Prompts.
• Prompts werden zu Zielen.

Der logische Endpunkt: Wir verbringen weniger Zeit damit zu beschreiben, wie etwas geschehen soll, und mehr damit zu beschreiben, was existieren soll. Vielleicht wirkt in zehn Jahren selbst der Gedanke, Agenten ausdrücklich zu orchestrieren, primitiv. Vielleicht äußern wir schlicht eine Absicht und lassen ein System darunter beliebige Kombinationen von Agenten, Werkzeugen, Abläufen, Infrastruktur, Organisationen und Prozessen zusammensetzen.

Im Extremfall fühlt sich die Schnittstelle weniger nach Programmieren an als nach Manifestieren: sich etwas denken, es beschreiben und zusehen, wie ein automatisiertes System diese Absicht in etwas Wirkliches verwandelt. Das klingt dramatisch, aber jede frühere Abstraktionsschicht hätte dramatisch geklungen, bevor es sie gab.

Die Ökonomie der Automatisierung hat sich nie wirklich geändert

Am interessantesten finde ich, dass der Handel trotz all dieses Fortschritts fast identisch mit dem ist, den ich vor Jahrzehnten beim Schreiben von Shell-Skripten einging. Automatisierung verlangt nach wie vor eine Vorabinvestition. Man muss den Prozess definieren, das System bauen, Randfälle behandeln, Fehler debuggen und entscheiden, was geschehen soll, wenn die Realität nicht zu den eigenen Annahmen passt.

Handarbeit wirkt anfangs oft leichter, weil sie genau diese Anfangsinvestition vermeidet. Dann läuft die Automatisierung an, die Wiederholungen häufen sich, und der Nutzen wird offensichtlich.

Das galt, als die Automatisierung ein zehnzeiliges Shell-Skript war. Es galt, als daraus Tausende Zeilen Infrastrukturkonfiguration wurden. Es gilt jetzt, da wir anfangen, Teams von KI-Agenten zu orchestrieren. Die Größenordnung nimmt immer weiter zu, das Prinzip hat sich kaum verändert: den Aufwand einmal betreiben, um ihn nicht ewig betreiben zu müssen.

Und wenn sich dieses Muster fortsetzt, lautet die interessanteste Frage nicht, was wir heute automatisieren können. Sondern was morgen noch zu groß zum Automatisieren wirkt.