Agentic Coding & KI in der Softwareentwicklung

Worum es geht

Seit Anfang 2025 hat sich die Art, wie Software entsteht, in kurzer Zeit zweimal verschoben. Zuerst prägte Andrej Karpathy den Begriff „Vibe Coding”: man gibt sich dem KI-Output hin, beschreibt das Ziel in natürlicher Sprache, akzeptiert Vorschläge weitgehend ungeprüft und korrigiert nur über weitere Prompts. Ein Jahr später benannte er mit „Agentic Engineering” den bevorzugten Nachfolgebegriff – seine eigene Formulierung: „agentic, because the new default is that you are not writing the code directly 99 % of the time, you are orchestrating agents who do, and acting as oversight.”

Der Unterschied ist keine Wortklauberei. Vibe Coding bleibt legitim für Prototypen, Machbarkeitsnachweise und Wegwerf-Artefakte – überall dort, wo Wartbarkeit keine Rolle spielt. Sobald Software produktiv wird, haftungsrelevant ist oder mit echten Kunden- oder Geschäftsdaten arbeitet, reicht reines Vibe Coding nicht: Ohne Architektur, Tests und Review entsteht Code, den niemand mehr versteht – auch der Agent nicht, der ihn geschrieben hat.

Der Shift von Vibe Coding zu Agentic Engineering

Agentic Engineering ist die ingenieursmäßige Weiterentwicklung: Architektur-, Qualitäts- und Organisationswissen wird durch Agenten nicht entwertet, sondern wertvoller – es muss nur stärker verschriftlicht und in die Konfiguration der Agenten überführt werden. Drei Verschiebungen sind dabei zentral:

Prompt Engineering wird nachrangig, Umgebungsgestaltung entscheidend. Ein Agent bringt ohnehin einen mehrere tausend Tokens langen System-Prompt mit Rolle und Tools mit; der eigene Einzelprompt bewegt das Gesamtverhalten kaum noch. Was zählt, ist die Umgebung: Kontext-Dateien, verfügbare Tools, Skills. Das heißt nicht, dass Prompting verschwindet – es wandert in den Harness, in Skills, Slash-Commands und Loops, wo es strukturierter und wiederverwendbar wird, statt bei jedem Lauf neu erfunden zu werden.

Spezifikation ersetzt den flüchtigen Prompt als Steuerungsinstrument. Beim Spec-driven Development ist die Spezifikation die einzige Quelle der Wahrheit: Ziel, Regeln, Akzeptanzkriterien, Datenflüsse und Nicht-Ziele werden vor der Umsetzung explizit gemacht, Agenten erzeugen daraus Code, Tests und Dokumentation. Ändert sich eine Anforderung, wird zuerst die Spec geändert – nicht im Code gepatcht. Das macht den Prozess auditierbar: Für regulierte oder einfach nur wachsende Software ist nachvollziehbar, welche Anforderung zu welchem Code, welchem Test und welcher Freigabe gehört. Vibe Coding ist gut zum Finden, Spec-driven Development ist gut zum Skalieren.

Wiederkehrende Abläufe werden zu Skills, nicht zu Einzelprompts. Ein Skill kapselt Domänenwissen, Tool-Zugriff und einen wiederholbaren Ablauf in einer Datei mit klaren Grenzen – vom Freiheitsgrad (eng geführt bei riskanten Operationen, offen bei kreativen Aufgaben) bis zur Struktur (kurzer Hauptteil, Details in Referenzdateien, damit Kontext nur bei Bedarf geladen wird). Mehrere Skills lassen sich zu Skill Systems verketten: ein Orchestrator ruft atomare Sub-Skills in Reihenfolge auf, mit definierten Übergaben und Human-in-the-Loop-Checkpoints an den kritischen Stellen. Das Claude Skill Automation Framework schärft davor noch die Vorfrage: nicht jede wiederkehrende Aufgabe verdient einen Skill – erst eliminieren, dann automatisieren, delegieren oder beschleunigen (EADA), erst den Ablauf sauber mappen, dann kodifizieren.

Für Agenten, die über einzelne Sessions hinaus wiederholt an einer Aufgabe arbeiten sollen – etwa Tests reparieren, Performance verbessern oder wiederkehrende Checks fahren – kommt eine vierte Ebene dazu: Loop Engineering. Ein Loop braucht einen Trigger, eine gekapselte Ausführung, ein prüfbares Erfolgskriterium, gespeicherten Zustand zwischen Durchläufen und ein Stop-Kriterium. Ohne klare Verifikation wird aus der Schleife schnell ein teurer Ersatz fürs Nachdenken statt ein Werkzeug dafür.

Auf Repository-Ebene bildet sich mit AGENTS.md ein offener Standard heraus – seit Ende 2025 Projekt der Agentic AI Foundation der Linux Foundation, getragen von OpenAI Codex, Google Jules, Cursor und dem Claude-Code-Umfeld gemeinsam. Die Datei liefert einem Agenten Build-/Test-Befehle, Konventionen und explizit verbotene Muster – die „README für Agenten”, damit ein Coding-Agent ein Repository als Mitwirkender bearbeiten kann, ohne sich die Arbeitsweise selbst zusammenzuraten.

Was das für Unternehmen bedeutet

Für Unternehmen, die Software bauen lassen oder selbst entwickeln, verschiebt sich damit die eigentliche Kompetenzfrage. Wer glaubt, mit Agenten brauche es weniger Softwareentwicklungswissen, beobachtet meist das Gegenteil: Schlechtes Agentic Engineering bedeutet zehn- oder hundertfach mehr generierten Code bei gleichbleibendem oder schrumpfendem manuellem Review – der Engpass verschiebt sich nur von der Produktion zur Qualitätssicherung, ohne dass echte Produktivität entsteht. Gutes Agentic Engineering braucht weiterhin – oder gerade jetzt erst recht – klare Architektur, disziplinierte Spezifikation, automatisierte Tests und eine bewusste Entscheidung, wo Menschen im Loop bleiben müssen: bei Geld-, Compliance- und Identitätsaktionen ist vollautonomes Handeln von Coding-Agenten keine Option, sondern ein Governance-Risiko.

Praktisch heißt das: Wer intern entwickelt oder Dienstleister beauftragt, sollte fragen, ob dort mit Spec statt losem Prompt gearbeitet wird, ob wiederkehrende Abläufe als Skills statt als Zufallsprompts existieren, und ob Reviews und Freigaben vor jedem Merge oder Deployment stehen – nicht danach.