Agentic Development heisst nicht, einen Agenten zu starten. Es heisst, das Gerüst zu bauen.

Das Gerüst ist alles, was einen Agenten führt und prüft — und es entscheidet, ob das Ergebnis trägt oder nur schnell da war.
Zwei Bundesportale auf einer Plattform und unser eigenes Werkzeug entwickeln wir agentisch — vom Auftrag bis zum Release. Diese Seite zeigt das Gerüst dahinter — und was davon allgemein nützlich ist, liegt offen auf GitHub.
Die Methode

Was Agentic Development konkret heisst

Agentic Development bedeutet, dass Software-Ingenieure ihre Arbeit gemeinsam mit KI-Agenten erledigen — Werkzeugen, die selbstständig Code lesen, Änderungen vorschlagen, Tests ausführen und Ergebnisse belegen, während der Mensch führt, prüft und verantwortet. Kein Chatbot, der Text ausgibt, sondern ein Arbeitsablauf, in dem der Agent reale Schritte übernimmt und jeder Schritt nachvollziehbar bleibt. Das Tempo kommt daher, dass Routine automatisiert abläuft; die Qualität daher, dass nichts ungeprüft durchrutscht.

Wer macht was

  • Der Agent arbeitet

    • Code lesen und verstehen
    • Änderungen vorschlagen
    • Tests ausführen
    • Das Ergebnis belegen

    Jeder Schritt bleibt einzeln nachweisbar

  • Der Mensch entscheidet

    • Den Auftrag schneiden
    • Den Plan freigeben
    • Die Zusammenführung freigeben
    • Verantworten, was ausgeliefert wird

    Beides zusammengehalten von der Struktur

  • Die Struktur erzwingt

    • Jede Aufgabe hat einen schriftlichen Plan
    • Jeder Plan läuft in einem getrennten Arbeitsbereich
    • Nichts wird zusammengeführt, was das Qualitätstor nicht besteht

So können mehrere Entwickler gleichzeitig mehrere Agenten führen, ohne sich in die Quere zu kommen — nicht weil alle gut aufpassen, sondern weil die Struktur es ausschliesst.

Die Abgrenzung

Der Motor ist nicht Ihr Wettbewerbsvorteil

«Power is nothing without control.»

Werbeclaim von Pirelli, seit 1994
Fünf Wörter aus einer Reifenwerbung sagen, worum es hier geht. Der Motor war nie das Problem. Entscheidend war immer, was davon auf der Strasse ankommt. Bei der Softwareentwicklung mit KI ist der Motor heute für alle gleich. Ihr Mitbewerber nutzt dasselbe Modell wie Sie, zum selben Preis, ab morgen früh. Der Unterschied entsteht erst danach — in dem, was um das Modell herum gebaut ist. Wer dabei am Steuer sitzt, bleibt unverändert: Sie fahren. Wir liefern den Grip — das Gerüst, das aus Motorleistung eine Strecke macht, die Sie auch bei Tempo halten können. Vibe Coding heisst: Prompt rein, Code raus, Augenschein, weiter. Für einen Prototyp am Freitagnachmittag ist das genau richtig. Für Code, der drei Jahre läuft, von jemand anderem gewartet wird und im schlechten Fall vor einem Revisor liegt, ist es das nicht.
  • Ziel

    Vibe Coding: Prototyp, Spike, Wegwerf-Demo

    Agentic Development: Code, der in Produktion geht und dort bleibt

  • Kontext

    Vibe Coding: ad hoc im Chat, lebt in einer Session

    Agentic Development: spezifiziert: Repo-Konventionen, CLAUDE.md, Skills

  • Verifikation

    Vibe Coding: Augenschein — «sieht gut aus»

    Agentic Development: Tests, Typen, CI, Review-Gate vor dem Merge

  • Wiederholbarkeit

    Vibe Coding: nicht reproduzierbar

    Agentic Development: gleicher Prozess, gleiches Ergebnis, auch nächsten Monat

  • Rolle des Menschen

    Vibe Coding: Prompter

    Agentic Development: Architekt und Reviewer

  • Fehlerkosten

    Vibe Coding: fallen später an, bei jemand anderem

    Agentic Development: werden früh und billig sichtbar

  • Audit

    Vibe Coding: keine Spur

    Agentic Development: nachvollziehbare Historie

Tempo nützt nur, wenn das Ergebnis trägt. Ein Rennwagen ohne Grip ist nicht schnell — er ist nur laut. Ein Entwicklungsteam ohne Tests, ohne Spezifikation und ohne Review-Gate produziert nicht schneller. Es produziert nur schneller Nacharbeit.

Das Gerüst

Das Gerüst um den Agenten — vier Bausteine

Ein Agent ist so gut wie das, was ihn führt und prüft. Genau das nennen wir das Gerüst: vier Dinge, die ihn halten — und sie haben zwei verschiedene Aufgaben. Zwei steuern, bevor der Agent tippt. Zwei prüfen, was er geschrieben hat. Nichts davon ist exotisch. Ungewöhnlich ist, es konsequent zusammen einzusetzen — und dann auch danach zu arbeiten.

Die Ordnung «steuern vorher, prüfen nachher» folgt Birgitta Böckelers Beschreibung von Guides und Sensors: Harness Engineering for Coding Agent Users

Guides · steuern vorher

Skills · Documentation

Sensors · prüfen nachher

Definition of Done · Evals

Guides · steuern vorher

  • Skills

    Wiederverwendbare Arbeitsanweisungen — der Agent weiss, wie wir Dinge tun, statt es bei jedem Auftrag neu zu erraten.

    Unsere Skills auf GitHub ansehen
  • Documentation

    Geschrieben, damit Menschen und Agenten sie lesen. Was nirgends steht, kann ein Agent nicht berücksichtigen.

Sensors · prüfen nachher

  • Definition of Done

    Wann etwas fertig ist. Verbindlich und nicht pro Auftrag neu verhandelt — sonst entscheidet am Ende die Tagesform.

  • Evals

    Prüfen, ob ein Urteil taugt — dort, wo ein klassischer Test die falsche Frage stellt.

Wann geprüft wird

  1. Neben dem Agenten

    Während er arbeitet, in Sekunden

    Schnelle, eindeutige Prüfungen laufen mit, während der Agent schreibt. Er korrigiert sich selbst, bevor ein Mensch den Code überhaupt zu sehen bekommt.

    • Typprüfung und Code-Regeln bei jeder Änderung
    • Schnelle Tests der betroffenen Stellen
    • Einhaltung der vereinbarten Architektur-Grenzen
  2. Nach der Integration

    Wenn die Arbeit zusammenkommt, in Minuten

    Was länger dauert, läuft, sobald die Änderung mit dem Rest zusammengeführt wird — dort stört die Wartezeit niemanden mehr.

    • Die vollständige Testsuite gegen feste Referenzergebnisse
    • Ein Review-Durchgang auf das Gesamtbild, nicht nur die Zeile
  3. Fortlaufend

    Unabhängig von einzelnen Änderungen

    Manches verfällt langsam und fällt in keiner einzelnen Änderung auf: Plan und Code laufen auseinander, Dokumentation altert, Strukturen entfernen sich vom Entwurf.

    • Regelmässige Prüfung, ob Plan, Dokumentation und Code noch übereinstimmen
    • Hinweise auf Abweichungen, die sich über Zeit angesammelt haben

Die Reihenfolge ist die Regel: Was eine Maschine eindeutig entscheiden kann, entscheidet eine Maschine — schnell, gleich und ohne Ermessen. KI kommt erst dort zum Zug, wo ein Urteil nötig ist, das sich nicht in Regeln fassen lässt.

Der Mechanismus

Keine Überraschungen

Dass das Ergebnis trägt — das ist leicht gesagt. Wodurch, ist die Frage. Bei uns durch drei Entscheidungen, die alle in dieselbe Richtung zeigen.
  • Der Agent baut das System. Er ist nicht Teil davon.

    Wir lassen keine Agenten unkontrolliert überwachen und steuern. Wir nutzen sie, um die Systeme zu bauen und zu betreiben, die genau das tun — Automatisierung, Pipelines, Metriken, Dashboards, Release-Engineering. Was danach in Produktion läuft, ist deterministisch: gleiche Eingabe, gleiches Ergebnis. Der Agent hat es gebaut, er entscheidet nicht darin mit.

  • Weniger Code, nicht mehr

    Jede Zeile Code hat Fehler. Ein Agent schreibt zehnmal so schnell — das ist nur dann ein Gewinn, wenn am Ende nicht zehnmal so viel Code steht. Wir messen nicht, wie viel entstanden ist, sondern wie wenig nötig war.

  • Schneller heisst mehr Sicherheitsnetz, nicht weniger

    Wenn Änderungen schneller landen, braucht es mehr Metriken, mehr Monitoring, schnellere Review- und Deploy-Prozesse — um mitzuhalten und um Fehler schnell zu korrigieren. Das agentische Setup selbst ist eine Investition, damit es vorhersagbare Ergebnisse liefert. Es reicht nicht, dasselbe schneller zu tun; es muss besser werden.

Wo das Gerüst an seine Grenze kommt

Ein Ticket aus unserem eigenen Plattform-Projekt: rund 600 Zeilen über drei Schichten, saubere Tests, grüner Build, ordentlich dokumentiert. Jede Prüfung war grün — und das Ergebnis wollte trotzdem niemand haben. Kein Sensor der Welt beantwortet die Frage, ob das Gebaute das Gemeinte ist.

Deshalb verschiebt sich die Arbeit nach vorn. Bei uns heisst das konkret: rund vier Stunden am Tag mit Markdown statt mit Code. Ist der Plan präzise genug, überrascht der Pull Request nicht mehr — und der Aufwand für die Prüfung fällt in sich zusammen.

In der Praxis

Was sich im Handwerk ändert, wenn Agenten mitarbeiten

Steht das Gerüst, ändert sich nicht das Tempo beim Tippen — es ändert sich, welche Arbeit überhaupt anfällt. Drei Dinge machen wir heute anders als vor zwei Jahren.
  1. Wir bauen den Prototyp statt des Entwurfs

    Früher entstand die Idee in Figma oder Miro und wurde danach nachgebaut. Heute ist der interaktive Prototyp schneller fertig als das Bild davon — und man kann ihn benutzen, statt ihn sich vorzustellen. Diskussionen über Zwischenstände werden dadurch kürzer und ehrlicher.

  2. Wir jagen keine 100 % Testabdeckung

    Ein Agent schreibt Tests fast gratis, und genau das ist die Falle: Wer alles testet, testet nichts richtig — man bekommt Prüfungen, die nur noch Aufwand binden. Das Definition of Done sagt, was geprüft gehört. Und wo ein Agent urteilt statt rechnet, misst eine Zeilenabdeckung ohnehin die falsche Sache; dort prüfen Evals, ob das Urteil taugt.

  3. Wir führen Agenten, statt Aufgaben abzuarbeiten

    Die Arbeit verschiebt sich vom Schreiben zum Schneiden, Prüfen und Entscheiden. Das ist anspruchsvoller, nicht bequemer — und es ist der Grund, warum Erfahrung wichtiger wird statt unwichtiger.

Wann der Agent führt — und wann der Mensch

Agent-led — der Agent führt

  • Gleichartige Änderungen über viele Dateien
  • Testabdeckung dort nachziehen, wo sie fehlt
  • Eine Migration Schritt für Schritt
  • Eine fremde Codebasis erkunden
  • Einen Prototyp bauen, um eine Frage zu klären

Human-led — der Mensch führt

  • Wenn die Anforderung noch unklar ist
  • Wenn eine Architekturentscheidung Erfahrung braucht
  • Wenn ein Fehler teuer wäre
  • Wenn zu entscheiden ist, was «fertig» heisst
  • Und das soll auch so bleiben
Der Beweis

Zwei Bundesportale auf einer Plattform — und unser eigenes Werkzeug

Agentic Development ist bei uns keine Theorie. Naturgefahren.ch und MeteoSchweiz laufen auf einer Multi-Tenant-Plattform — eine Datenpipeline, ein CMS, dieselben Qualitätstore: was für das eine Portal gilt, gilt für das andere. Beide tragen im Ernstfall Menschen. Dazu unser eigenes Werkzeug, an dem wir zuerst herausgefunden haben, ob das Gerüst trägt.
  • Naturgefahren.ch

    Das Naturgefahrenportal führt Gefahrendaten aus mehreren Quellen zusammen und erzeugt daraus Warnungen fürs Web — barrierefrei, nach WCAG 2.1 AA zertifiziert.

    Seit Projektstart entsteht jede Änderung über den agentischen Ablauf.

    Bei einer Unwetterlage greifen alle gleichzeitig zu — deshalb ist das Qualitätstor davor nicht verhandelbar.

    naturgefahren.ch öffnen
  • MeteoSchweiz

    Fast 100 Wetterprodukte in Echtzeit, ein eigenes Karten-Framework — für das Bundesamt für Meteorologie und Klimatologie.

    Ebenfalls seit Januar 2026: keine Änderung mehr ausserhalb des agentischen Ablaufs.

    Die automatisierten Qualitätstore dieser Anwendung sind kein Nebenprodukt — sie sind das Gerüst, das genau das zulässt.

    Was wir für MeteoSchweiz gebaut haben
  • Offerten-Generator

    Unser eigenes Produkt, in zwei Stufen: Mit dem Prototyp pitchen wir beim Kunden — fünf Varianten laufen öffentlich. Wird daraus ein Auftrag, entsteht daraus die produktive Anwendung auf der CDS-Plattform, mit Zugangskontrolle und weiteren Generatoren.

    Beide Stufen entstehen über den agentischen Ablauf — der erste Prototyp lief im März 2026, an einem einzigen Vormittag.

    Der Prototyp aus dem Pitch ist die Grundlage der produktiven Anwendung — nicht ein Wegwerfstück daneben. Hier haben wir angefangen, an uns selbst, bevor wir es Kunden empfohlen haben.

    Zum Offerten-Generator
Hybride Teams

Wer in einem solchen Projekt eigentlich schreibt

«Der Agent arbeitet, der Mensch entscheidet» ist oben ein Schaubild. In einem laufenden Kundenprojekt — dem Portal-Rebuild für ein Schweizer Treuhandunternehmen, seit Sommer 2026 — kann man nachsehen, ob es stimmt: Das Commit-Log ist das Diagramm, nur als Liste.
  • Fast die Hälfte der Beiträge kommt nicht aus der Entwicklung

    Vertrieb, Finanzen und die Produktverantwortung schreiben mit — nicht als Reviewer am Rand, sondern als Autoren im Log. Wer Anforderungen kennt, kann sie einbringen, ohne sie zu übersetzen.

  • Die Freigaben stehen namentlich im Log

    Wo ein Mensch entschieden hat, steht ein Eintrag mit seinem Namen: Plan freigegeben, Zusammenführung freigegeben. Diese Einträge tragen keine Agenten-Signatur — sie sind die Stellen, an denen jemand die Verantwortung übernommen hat.

  • Ein Agent ist Teammitglied mit eigenem Konto

    In unserem eigenen Firmen-Repository arbeitet Qubert unter eigener Adresse mit — unser erster autonom mitarbeitender Agent. Man sieht in der Historie, wer was geschrieben hat, weil er nicht unter fremdem Namen committet.

Das ist der Punkt: Nicht dass Agenten schneller tippen, sondern dass ein Team breiter wird. Wer die Fachlichkeit kennt, kommt näher an das Ergebnis heran.

Sprechen wir über Ihren nächsten Schritt

In der KI-Potenzialanalyse schauen wir gemeinsam, wo agentische Entwicklung bei Ihnen trägt — und wo bewusst nicht.

Max

Lieber persönlich?

MaxRufen Sie an oder schreiben Sie eine E-Mail — was Ihnen lieber ist.