Engineering-Kultur & Multi-Agenten-Praxis · August 2026

Software bauen ohne selbst zu programmieren: Was wir beim Entwickeln von KnotenCore mit mehreren KIs gelernt haben 🦀🤖

Über 350 Sprints hinweg haben wir KnotenCore zu einer produktionsreifen, Zero-Trust-gesicherten P2P-Mesh-Engine in Rust ausgebaut – ohne selbst jede Zeile Code von Hand zu schreiben. Die Rolle des Menschen verschiebt sich dabei vom klassischen Programmierer zum System-Architekten, Product Owner und Schiedsrichter. Doch die wichtigste Lektion dieser Entwicklung betrifft nicht den Code selbst, sondern den Prozess: Warum man den Erfolgsberichten einzelner KIs niemals blind vertrauen darf und wie durch den Einsatz getrennter Modelle echte Software-Qualität entsteht.

1. Die Illusion des perfekten Erfolgsberichts

Wer autonome KI-Agenten zum Programmieren einsetzt, erlebt schnell ein wiederkehrendes Muster: Der generierte Abschlussbericht klingt jedes Mal perfekt. „Alle Quality Gates bestanden, Tests 100% grün, Release sauber gebaut und auf GitHub gepusht."

In der Realität zeigte der prüfende Blick auf die tatsächliche Git- und CI-Ebene jedoch regelmäßig Abweichungen:

Der automatisierte CI-Lauf auf GitHub schlug fehl, obwohl der Agent lokal Erfolg gemeldet hatte.
Geänderter Code lag unbemerkt noch ungespeichert oder uncommitted auf der Maschine, während die Zusammenfassung bereits Vollzug meldete.
Ein lokaler Versions-Konflikt wurde vom Agenten eigenmächtig mit git tag -f überschrieben, was die Nachvollziehbarkeit gefährdet hätte.

Die Ursache ist keine Böswilligkeit: Ein KI-Modell neigt schlicht dazu, das fehlerfreie Ausführen eines Befehls mit dessen tatsächlichem inhaltlichem Erfolg gleichzusetzen.

2. Die Rollenverteilung: Bauplan, Coder und unabhängiger Prüfer

Um dieses Auseinanderdriften von Bericht und Realität zu verhindern, haben wir die Aufgaben strikt aufgeteilt. Statt einer einzelnen KI zu vertrauen, nutzen wir unterschiedliche Modelle mit klar definierten Rollen:

Konzeption & Steuerung (Mensch & Gemini): Wir definieren die Architektur-Ziele, Invarianten und Anforderungen für jeden Sprint. Gemini entwirft die exakten technischen Baupläne und Schnittstellen.
Code-Generierung & Umsetzung (AG): Der ausführende Agent setzt den Bauplan direkt im Rust-Workspace um und baut die Funktionen.
Unabhängiges Review (Claude in separater Sitzung): Ein zweites Modell prüft den Code und die Sprint-Pläne ohne Vorkenntnisse oder geteilten Kontext auf logische Lücken und Sicherheitsrisiken.

3. Strukturelles Misstrauen als Qualitätshebel

„Diese Trennung ist mehr als Arbeitsteilung – sie ist strukturelles Misstrauen mit echtem Mehrwert. Ein Modell, das seinen eigenen Code prüft, teilt oft dieselben blinden Flecken, die überhaupt erst zum Fehler geführt haben. Der Wert des zweiten, unabhängigen Modells liegt nicht darin, schlauer zu sein, sondern darin, nichts zu glauben, was sich nicht direkt am Quellcode nachweisen lässt."

Durch diese Reibung wurden echte Sicherheitslücken aufgedeckt, bevor sie im Release landeten – etwa ungesicherte Hintergrund-Schnittstellen, Klartext-Tokens im Konsens-Protokoll oder Lücken bei der Abweisung gesperrter Netzwerkknoten.

Gleichzeitig zeigte sich der Wert der Prüfung auch bei Fehlalarmen: Wenn die Prüfinstanz einen vermeintlichen Bug vermutete, zwang das gemeinsame Nachrechnen dazu, die Logik bis ins Detail zu beweisen.

4. Das Gegenmittel: Präzise Mandate und Beweis durch Rohausgabe

Die wirksamste Methode gegen Schein-Erfolge besteht aus zwei Hebeln: Einerseits überlässt der Arbeitsauftrag (Prompt) an die ausführende KI nichts dem Zufall, andererseits haben wir dem Agenten verboten, das Ergebnis in eigenen Worten zusammenzufassen.

Ein realer Sprint-Auftrag definiert Invarianten, exakte Code-Pfade, Teststufen und das Ausgabeformat bis ins Detail:

// Beispiel: Reales Sprint-Mandat an AG
AG, we are launching Sprint 353 (CRDT Anti-Entropy State Digests v2.24.16).

Human Review Invariant:
No automated merging to `main`. All PRs remain strictly subject to manual review.

1. Deterministic State Digest Implementation (`rpc/handlers/store.rs`):
   - Implement `compute_state_digest(&self) -> String` using `ring::digest::SHA256`.
   - Lexicographically sort active keys before hashing.
   - Implement `knc_store_diff` returning lean delta entries only if digest mismatch occurs.

2. Automated Quality Gates:
   - `cargo fmt --all && cargo fmt --check` (0 diffs)
   - `cargo clippy --workspace --all-targets -- -D warnings` (0 warnings)
   - `cargo test --workspace --all-targets` (100% green)

3. Git Delivery & Strict Tag Immutability:
   - NEVER use `git tag -f` or `--force`.
   - Commit: `feat(store): Add CRDT anti-entropy state digests (v2.24.16)`
   - Tag: `git tag -a v2.24.16 -m "Release v2.24.16"`
   - Push: `git push origin main v2.24.16`

4. Mandatory Literal Raw Terminal Output:
   Provide raw unformatted terminal output for:
   [RAW TERMINAL: git status]
   [RAW TERMINAL: git log -n 1 --oneline]
   [RAW TERMINAL: git push origin main v2.24.16]

Statt einer Prosa-Zusammenfassung muss der Agent zwingend die unformatierten, echten Terminal-Logs liefern:

[RAW TERMINAL: git status]
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

[RAW TERMINAL: git log -n 1 --oneline]
58e2d45 feat(store): Add CRDT anti-entropy state digests and differential mesh sync (v2.24.16)

[RAW TERMINAL: git push origin main v2.24.16]
To https://github.com/holgerbaer-bl/KnotenCore
   533d2be..58e2d45  main -> main
 * [new tag]         v2.24.16 -> v2.24.16

Erst wenn diese Terminal-Ausgaben schwarz auf weiß belegen, dass der Code sauber committet und vom Remote-Server akzeptiert wurde, gilt der Sprint als abgeschlossen.

5. Fazit: Nicht blind vertrauen, sondern Systeme bauen

KnotenCore verfügt heute über mehrere hundert automatisierte Tests, eine durchgängige Zero-Trust-Architektur und höchste Code-Qualität – nicht, weil KIs fehlerfreien Code schreiben, sondern weil unser Workflow darauf ausgelegt ist, Fehler schonungslos sichtbar zu machen.

Man muss heute kein Programmierer mehr sein, um komplexe Softwaresysteme zu erschaffen. Man muss jedoch lernen, wie ein leitender Ingenieur zu denken: Rollen trennen, Annahmen hinterfragen und niemals Berichte mit der Realität verwechseln.

← Alle Beiträge ← Vorheriger: CRDT Anti-Entropy & Zero-Trust Heartbeats