Vom Befehle-Tippen zum Agenten-Orchestrieren

Vor sechs Monaten habe ich noch jeden Befehl selbst getippt. CLI für den Orchestrator. API-Queries für die Analyseplattform. Klicks durch das GUI des Controllers. Dieselben Fragen, dieselben Antworten, dieselben Finger.

Heute beschreibe ich, was ich will, und der Agent entscheidet, welche der gut vierzig Tools er aufruft. Letzte Woche habe ich gefragt: „Wenn diese Ost-West-Faser ausfällt — welche anderen Strecken verlieren ihre Redundanz?“ Eine halbe Minute später hatte ich den Diff, die SRLG-Überschneidung und einen Vorschlag zur Behebung. Ich habe kein einziges Tool selbst geöffnet.

Genau darauf zielt Andrej Karpathy, wenn er unsere Ära als Software 3.0 bezeichnet. Seine These, in einem Absatz: Software 1.0 war handgeschriebener Code. Software 2.0 waren neuronale Netze, deren Gewichte man trainierte. Software 3.0 heißt: Das LLM ist der Computer, und man programmiert es in englischer Sprache — mit Prompts, Kontext und Tools. Karpathy bringt es auf den Punkt: „Prompts sind Programme.“ Der Compiler ist das Modell. Die Laufzeit ist der Agent.

Als ich es zum ersten Mal so gehört habe, habe ich genickt wie bei jeder Marketingfolie. Dann habe ich es an meiner echten Arbeit ausprobiert, und der Boden ist verrutscht.

Was ich konkret gemacht habe

Der Hebel war nicht das LLM. Der Hebel war, meine vorhandenen Engineering-Tools so zu kapseln, dass ein Agent sie nutzen kann.

Ich habe eine Netz-Analyseplattform, die „Was wäre wenn“-Fragen beantwortet. Ein Orchestrierungssystem, das Konfigurationen auf Live-Geräte schiebt. Einen Controller, der den Echtzeitzustand des Netzes kennt. Jedes davon hat seit zehn Jahren eine völlig brauchbare API. Keines davon war für ein LLM geschrieben. Also habe ich sie gekapselt — die Verben als Tools freigelegt, jedem Tool ein klares Schema und eine einzeilige Beschreibung gegeben, und den Agenten entscheiden lassen, wann er welches aufruft.

Das Muster hat inzwischen einen Namen: MCP — eine Tool-Oberfläche, die für Agenten entworfen ist, nicht für Menschen. Die Arbeit war unspektakulär. API-Doku lesen. Inputs definieren. Wrapper schreiben. Wiederholen, für jedes Verb, das zählt. Die Belohnung: Ein paar Dutzend Tools über drei Plattformen hinweg, die ein Modell auf Zuruf kombinieren kann.

Die IDE oben drauf ist Cursor. Der Agent darin liest meinen Code, meine Notizen, meine Git-History, die Topologie, den Betriebszustand — und entscheidet. Manchmal falsch. Dazu gleich mehr.

Die Verschiebung, in einem Satz

Programmieren war früher: Ich weiß, was ich will, ich weiß, wie ich es ausdrücke, ich tippe es ein.

Heute ist es: Ich weiß, was ich will, ich beschreibe es einmal, der Agent entwirft es, ich lese, was er gemacht hat, ich korrigiere, von vorn.

Der Flaschenhals hat sich verschoben. Früher waren es Syntax, Bibliothekswissen, schiere Tippgeschwindigkeit. Heute sind es die Klarheit meiner Absicht und die Disziplin meiner Verifikation. Karpathy nennt das den Generator-Verifier-Loop. Der Generator ist billig, sprachgewandt und mit Selbstvertrauen falsch. Der Verifier — ich — muss scharf bleiben.

Was ich anfangs unterschätzt habe

Ich habe unterschätzt, wie viel vom Wert in der kleinen, langweiligen Schicht zwischen LLM und vorhandener Software steckt. Nicht im Modell. Nicht im Prompt. In der Form der Schnittstelle, die man dem Agenten gibt.

Ich habe unterschätzt, dass Dokumentation jetzt zwei Zielgruppen hat. Menschen überfliegen. Agenten lesen vollständig. Ein „Skill“ in Markdown, mit expliziten Klärungsfragen und einem unmissverständlichen Workflow, ist ein deutlich besseres Artefakt als ein Wiki-Eintrag, der dasselbe in Fließtext „erklärt“. Ich schreibe Skills heute so, wie ich früher interne Wikis geschrieben habe.

Ich habe unterschätzt, dass der Agent keinen Kontext erfindet. Wenn die Topologie, die Design-Regeln, die Latency-vor-Kosten-Präferenz des Kunden nirgends im Workspace stehen, tauchen sie auch nicht in der Antwort auf. Also lege ich Kontext jetzt ins Repo: Rules, Skills, festgehaltene Gotchas, Voice-Profile. Der Agent hört auf, dumme Fragen zu stellen, sobald die Antworten neben dem Code liegen.

Und ich habe unterschätzt, wie viel Spaß das macht. Die Reibung von „Ich will X machen, aber das Werkzeug macht es mühsam“ ist für ganze Arbeitskategorien zusammengebrochen. Diesen Beitrag zu schreiben — Entwurf, Übersetzung, Bildgenerierung, Veröffentlichung auf der eigenen Seite, Verifikation im RSS-Feed — war ein Absatz Anweisung.

Was schwierig bleibt

Selbstbewusstes Falschliegen. Das Modell produziert eine plausible Antwort über ein Netz, das es nie gesehen hat, und die Antwort ist auf eine Weise falsch, die man nur erkennt, wenn man die richtige Antwort schon kennt. Verifikation ist nicht verhandelbar. Tests, Sanity-Checks, „Zeig mir den tatsächlichen Output“, den Trace selbst lesen. So, wie man eine kluge, aber neue Kollegin anleitet.

Für Agenten entwerfen. Die Oberfläche, die man für einen Menschen schreibt (Icons, Wizards, modale Dialoge), ist für einen Agenten feindliches Gelände. Man schreibt die Affordanzen neu — Tools statt Buttons, Schemas statt Formulare, strukturierte Logs statt Toasts.

Wissen, wann das Modell nicht das richtige Werkzeug ist. Software 1.0 ist nicht verschwunden. Der Agent ist großartig bei Orchestrierung und Entwürfen; er ist schlecht bei Dingen, die bitgenaue Korrektheit ohne Verifier brauchen. Der eigentliche Skill ist zu wissen, in welche Schicht das Problem gehört.

Wohin als Nächstes

Mehr Tools, freigelegt als MCP. Mehr Skills, gesammelt aus Dingen, die ich mich selbst zwei Mal erklären höre. Engere Generator-Verifier-Loops, einschließlich Agent-auf-Agent-Evaluation bei Themen, bei denen mein eigenes Urteil der Flaschenhals ist.

Der Spruch „Programmieren ist nur noch durch deine Vorstellungskraft begrenzt“ stimmt fast. Begrenzt wird es durch die Fähigkeit, zu spezifizieren, was man sich vorstellt — klar genug, dass ein Agent es ausführen kann, und präzise genug, dass man merkt, wenn er es nicht getan hat.

Was, wie sich herausstellt, einfach Engineering ist.