Es dauerte 9 Tage, bkamp.ai mit Claude Code zu launchen – und dieses Know-how habe ich im bkit-Plugin festgehalten.

(bkit.ai)

2 Punkte von agentkay 26 일 전 | Noch keine Kommentare. | Auf WhatsApp teilen

bkit — Claude Code mit Context Engineering „richtig“ nutzen

Im Dezember 2025 habe ich einen Service namens bkamp.ai gelauncht.

11 Microservices
Ein auf Next.js basierendes Portal
AWS EKS + GitOps (ArgoCD)
Terraform-Infrastruktur

Und das alles habe ich in nur 9 Tagen in Produktion gebracht.

Ich war der einzige Entwickler,
und als KI kam Claude Code zum Einsatz.

In diesem Artikel geht es nicht darum, dass etwas „schnell gebaut“ wurde

Viele Beispiele für KI-gestützte Entwicklung werden so erklärt:

„Mit KI in N Tagen gebaut“
„Man muss nur gute Prompts schreiben“

Aber was ich in diesen 9 Tagen Entwicklung tatsächlich gespürt habe, war etwas völlig anderes.

KI kann sehr gut Code schreiben.
Aber was geschrieben werden soll, entscheidet die KI nicht.

Darüber entscheiden am Ende:

Architektur
Regeln
Arbeitseinheiten
Art der Validierung

Das habe ich als Context Engineering definiert.

Was ist Context Engineering?

Einfach gesagt:

Es geht nicht darum, gute Prompts zu schreiben,
sondern die Arbeitsumgebung der KI selbst zu entwerfen

Zum Beispiel:

Zuerst Architekturdokumente erstellen
Arbeitseinheiten anhand von Dokumenten aufteilen
Regeln zur Validierung der Ergebnisse festlegen
Einen wiederholbaren Zyklus aufbauen

Das heißt:

Die KI ist nicht der „Autor“,
sondern eine Engine, die einen festgelegten Kontext rendert

So wurde bei bkamp tatsächlich gearbeitet

1. Day 0 — Regeln festlegen, bevor Code geschrieben wird

Im ersten Commit gab es keinen Code.

Stattdessen habe ich Folgendes erstellt:

.claude/CLAUDE.md (ca. 150 Zeilen)
Anforderungsdokumente
Strategiedokumente

Darin war Folgendes definiert:

PDCA-Zyklus (Plan → Do → Check → Act)
Alle Ergebnisse werden von Menschen validiert
Planung auf Koreanisch, Code auf Englisch, Commits auf Koreanisch
Arbeitseinheiten und Vorgehensweise

Diese rund 100 Zeilen Regeln haben danach die gesamte Entwicklung bestimmt.

2. Die Arbeitseinheit ist nicht „Feature“, sondern „Dokument“

Normalerweise würde man so anfragen:

„Bitte baue eine Chat-Funktion“

Tatsächlich wurde aber so gearbeitet:

„Bitte implementiere Abschnitt 3.2 aus Dokument 7“

Dieser Unterschied ist enorm.

Aus Sicht der KI:

Feature → Interpretation nötig (Unsicherheit)
Dokument → direkte Implementierung (deterministisch)

Das Ergebnis:

Die Variabilität der Ausgabe verschwindet fast vollständig

3. Ein Tag = ein PDCA-Zyklus

Die Entwicklung läuft so ab:

Plan (Entwurf)
Do (Implementierung)
Check (Gap-Analyse)
Act (Korrektur)

Und dieser Zyklus wird täglich wiederholt.

Die Vorteile dieser Methode:

Der Context bleibt immer aktuell
Der Arbeitsumfang ist klar
Für die KI ist klar, „was jetzt zu tun ist“

4. Checkpoints setzen und mutig neu aufbauen

Am 4. Tag wurde das Frontend vollständig neu strukturiert.

Aber davor gibt es etwas, das immer gemacht wird:

Einen rollbackfähigen Checkpoint erzeugen

So gilt:

Selbst ein Fehlschlag ist sicher
→ mutige Strukturänderungen werden möglich

5. Die Infrastruktur wird am Ende in einem Zug angebunden

Am 8. Tag wurden innerhalb eines Tages:

Terraform
Kubernetes
CI/CD
ArgoCD

auf einmal angebunden.

Warum das möglich war, ist einfach:

Weil vorher bereits alle Strukturen sauber ausgerichtet waren

Das zentrale Muster, das sich daraus ergeben hat

Das Muster, das sich in diesen 9 Tagen wiederholt hat, war:

Zuerst Regeln definieren
Zuerst die Architektur erstellen
Anhand von Dokumenten arbeiten
Im PDCA-Zyklus iterieren
Checkpoints erstellen
Unstimmigkeiten in den Dokumenten lösen
Code kommt zuletzt

Aber lässt sich das dauerhaft durchhalten?

Hier entsteht das Problem.

Diese Methode ist mächtig, aber:

Für Menschen ist es zu anstrengend, das dauerhaft manuell aufrechtzuerhalten

Man muss sich ständig an die Regeln erinnern
Man muss die Dokumente fortlaufend abgleichen
Man muss jedes Mal PDCA einhalten

Deshalb wurde bkit entwickelt.

Was ist bkit?

bkit ist ein Claude-Code-Plugin.

Aber es ist nicht einfach nur ein Tool.

Es ist genau die Arbeitsweise aus bkamp, als System umgesetzt

Das wichtigste Konzept: PDCA = Zustandsmaschine

In bkit wurde PDCA so umgesetzt:

Zustände: plan, design, do, check, act usw.
Übergänge: Regeln für den Wechsel zwischen Zuständen
Guards: Prüfung von Bedingungen

Zum Beispiel:

Übereinstimmung zwischen Entwurf und Implementierung liegt bei mindestens 90 % → bestanden
Sonst → automatische Korrekturschleife ausführen

Das heißt:

„Prüfen → Korrigieren“ wird automatisch wiederholt

Die Struktur, die Context Engineering zum System macht

bkit besteht aus folgenden Elementen:

Skills (Domänenwissen)
Agents (rollenbasiertes Verhalten)
PDCA-Zustandsmaschine
Context-Injection-System
Quality Gate (Validierung)
Audit Log (Aufzeichnung)
Feedback Loop (automatische Wiederholung)

In einem Satz zusammengefasst:

Es geht nicht darum, KI zu verwenden,
sondern ein System zu bauen, in dem die KI arbeitet

Ergebnis

Die mit dieser Methode erreichten Ergebnisse sind:

Fortlaufende Kompatibilität mit 79 Versionen von Claude Code
4.000+ Tests, 0 Fehler
200+ CI-Validierungsregeln
Vollständige Synchronisierung von Docs und Code

Fazit

Das ist keine Geschichte darüber, dass KI intelligenter geworden ist.

Es ist eine Geschichte darüber, dass menschliche Arbeit nach vorn verlagert wurde

Erst die Architektur
Erst die Regeln
Erst die Validierung

Danach:

führt die KI aus
validiert das System
und der Mensch gibt frei

TL;DR

Nur mit Prompts gibt es Grenzen
Context Engineering ist der Kern
KI ist nicht der Autor, sondern der Renderer
Der Workflow ist wichtiger als das Modell