KI im Betrieb: Wie diese Website mit KI-Agenten entsteht

Den Programmcode der Website, auf der Sie diesen Beitrag lesen, schreiben KI-Agenten. Ein KI-Agent bearbeitet selbst Dateien, startet Programme und wertet deren Ergebnis aus. Im Chatfenster, in dem KI in vielen Büros bisher genutzt wird, bleiben das Kopieren und Prüfen beim Menschen. Am Beispiel von ravok.de zeigen wir, wie wir die Arbeit aufteilen und was dafür geregelt sein muss.

Aufgaben der KI-Agenten

ravok.de ist eine statische Website mit Astro. Warum wir uns dafür entschieden haben, steht in einem eigenen Beitrag. Neben dem Programmcode schreiben die Agenten auch Infografiken, Prüfskripte, Serverkonfiguration und die automatische Auslieferung. Dabei setzen wir verschiedene LLMs ein.

Wir legen fest, was gebaut wird, sehen uns jedes Ergebnis im Browser an und entscheiden, was veröffentlicht wird; für Inhalte und Freigaben sind wir verantwortlich.

Anfang September 2026 kam die Website in die Versionsverwaltung. Acht Tage später wurde jede Änderung automatisch gebaut, geprüft und ausgeliefert. Seitdem sind Ratgeber, Leistungsseiten, ein Glossar, eine Suche, ein Livechat und eine Besucherstatistik hinzugekommen, die ohne Tracking-Skript auskommt.

• 8Tage

  von der ersten Ablage in der Versionsverwaltung bis zur automatischen Auslieferung

• 78Änderungen

  einzeln nachvollziehbar, jede vor der Auslieferung geprüft

• 48Seiten

  mit Ratgebern, Leistungen, Glossar und Rechtstexten

• 43Skripte

  für Bau, Prüfung und Auslieferung der Website

• 3Browser

  in denen jede Änderung automatisch bedient wird

• 14Minuten

  dauern die Browserprüfungen vor jeder Auslieferung

Stand: 7. November 2026, vor Veröffentlichung dieses Beitrags.

Arbeitsteilung

1. 01
   MenschZiel und Entscheidungen festhalten

   Was gebaut wird und warum. Jede Entscheidung mit Datum, Begründung und dem Anlass, zu dem sie neu bewertet wird.

2. 02
   KI-AgentCode, Grafik und Tests schreiben

   In kleinen Schritten, nach den Regeln in den Anweisungsdateien. Eigene Entscheidungen des Agenten sind als solche gekennzeichnet.

3. 03
   AutomatikJede Änderung prüfen

   Tests, Barrierefreiheit, Sicherheitsregeln, drei Browser. Nur was alle Prüfungen besteht, geht live.

4. 04
   MenschIm Browser ansehen und freigeben

   Auf dem großen Bildschirm und auf dem Handy. Korrekturen gehen zurück an Schritt 02.

Bleibt beim Menschen

• Anmeldungen und Passwörter
• Zugangsdaten für den Server
• Löschen nur nach Rückfrage
• Freigabe für den Live-Betrieb

Ob eine Seite auf dem Handy gut lesbar ist, ob eine Grafik den Sachverhalt erklärt und ob ein Text so klingt, wie wir sprechen, beurteilen wir beim Ansehen im Browser. Wenn uns etwas nicht gefällt, sagen wir dem Agenten genau, was stört, und er baut es neu.

Leitplanken

Vier Regeln begrenzen, was ein Agent ohne uns tun kann.

Entscheidungen schriftlich festhalten. Jede Festlegung bekommt ein Datum, eine Begründung und den Anlass, zu dem sie neu bewertet wird. Ein Beispiel ist unsere Besucherstatistik. Sie wertet nur die Serverprotokolle aus, die ohnehin anfallen, und verzichtet auf ein Tracking-Skript im Browser.

Regeln in Dateien neben den Code legen. Eine Anweisung im Chat kennt der Agent in der nächsten Sitzung nicht mehr. Unsere Arbeitsregeln stehen deshalb in Anweisungsdateien im Projekt, die jeder Agent vor der Arbeit liest.

Rechte eng halten. Der Agent gibt keine Passwörter ein und meldet sich nirgends selbst an. Zugangsdaten für den Server liegen in geschützten Variablen außerhalb des Projekts. Eine Änderung am Hauptzweig geht nach bestandenen Prüfungen sofort online, deshalb geben wir jede einzeln frei.

Automatisch prüfen, bevor etwas online geht. Jede Änderung durchläuft eine feste Folge von Prüfungen, und ausgeliefert wird erst, wenn alle bestanden sind. Ohne diese Continuous Integration würden wir einem Agenten nicht so viel überlassen.

1. Änderung freigeben

   Der Agent legt die Änderung in der Versionsverwaltung ab. Wir geben sie für den Hauptzweig frei.

2. Bauen und testen

   Typprüfung und Tests, etwa für die Kalenderregeln geplanter Beiträge.

3. Das Ergebnis durchsuchen

   Keine unerlaubten Skripte, keine internen Kommentare, nichts Unveröffentlichtes, keine übrig gebliebenen Dateien.

4. In drei Browsern bedienen

   Chromium, Firefox und WebKit unter den Sicherheitsregeln des echten Webservers: Barrierefreiheit, Tastatur, Navigation, Suche, Livechat.

5. Ausliefern und erneut prüfen

   Die Lieferung ist an die geprüfte Änderung gebunden. Der Server prüft sie noch einmal, bevor er umschaltet.

Erst dann ist die Änderung live

Fällt bei einer Stufe etwas auf, sehen wir den Grund im Protokoll und beheben die Ursache.

Jede Nacht kurz nach Mitternacht läuft dieselbe Kette erneut. So erscheinen vorbereitete Beiträge pünktlich und durchlaufen trotzdem alle Prüfungen.

Drei Fehler aus dem Aufbau

Vorschaubilder unveröffentlichter Beiträge. Ratgeber werden vorbereitet und erscheinen an einem festgelegten Tag. Beim Aufbau stellte sich heraus, dass die Vorschaubilder noch nicht freigegebener Beiträge mit auf den Server gekommen wären. Seitdem prüft ein eigener Schritt vor jeder Auslieferung, dass weder Seiten noch Bilder noch übrig gebliebene Dateien unveröffentlichter Beiträge dabei sind.

Ein zweiter Versuch als Notlösung. Die Browserprüfungen scheiterten gelegentlich, weil sie warteten, bis keine Netzwerkanfrage mehr offen war. Manche Seiten halten aber dauerhaft eine Verbindung offen. Ein zweiter Versuch bei Zeitüberschreitung ließ die Prüfung durchlaufen, die Ursache blieb. Behoben war das Problem erst, als alle Prüfungen darauf warteten, dass die Seite tatsächlich bereit ist. Den zweiten Versuch gibt es heute nur noch für eindeutig erkannte Zeitüberschreitungen.

Unterschiede zwischen Test und Betrieb. Der Entwicklungsserver wendet die strengen Sicherheitsregeln des echten Webservers nicht an. Manches, was dort lief, scheiterte unter den echten Bedingungen an der Sicherheitsrichtlinie oder an Eigenheiten einzelner Browser, etwa bei der Scrollposition in Safari. Die Browserprüfungen laufen deshalb heute gegen denselben Webserver mit denselben Regeln wie im Betrieb.

Übertragbare Regeln für Ihren Betrieb

Dieselben Regeln gelten, wenn KI im Büro Texte entwirft, Belege sortiert oder Daten zwischen zwei Programmen überträgt.

Freigaben, Zugriffsrechte und die Kontrolle der Ergebnisse gehören zu einer verantwortlichen Person. Diese Person muss wissen, was das eingesetzte Werkzeug kann und wo es Fehler macht. Dafür steht der Begriff KI-Kompetenz. Außerdem braucht es jemanden, der den eigenen Ablauf genau kennt, denn eine KI setzt auch einen unklaren Auftrag schnell um.

Entscheidungen und Regeln sollten in einer Datei stehen, die jeder nachlesen kann, auch die KI in der nächsten Sitzung. Auf bestehende Daten erhält ein Werkzeug zunächst nur Lesezugriff, gelöscht wird nur nach Rückfrage und mit einer Sicherung. Ergebnisse prüfen Sie unter den Bedingungen, unter denen sie später genutzt werden, auch wenn sie schon fertig aussehen.

Was Sie jetzt prüfen können

Gibt es in Ihrem Betrieb eine kurze, schriftliche Regel, welche Daten in welches KI-Werkzeug dürfen? Wo werden heute Daten von Hand von einem Programm ins andere übertragen, und wie oft passieren dabei Fehler? Und wenn jemand eine Entscheidung zu einem Ablauf getroffen hat: Steht sie irgendwo, wo ein Kollege oder eine KI sie nachlesen kann?

Wenn Sie bei einer dieser Fragen unsicher sind, sprechen Sie uns an. Wir helfen bei der Auswahl passender Werkzeuge, bei Nutzungsregeln und Schulungen unter KI im Betrieb und entwickeln größere Abläufe als Individualsoftware und Automatisierung.