KI-Entwicklungsstack 2026 im Test: vom Quellcode bis zum Browser

12 Min. Lesezeit · 14. November 2026
Zuletzt geprüft 14. November 2026

Eine Kundin wählt in der Bestellübersicht Open. Die erste Seite zeigt zwei offene Bestellungen. Der Entwickler macht einen Screenshot und schließt das Ticket. Einen Klick später sieht die Kundin zwei abgeschlossene Bestellungen. An welcher Stelle hätte der Fehler auffallen müssen?

Ofri Wolfus, der Entwickler von ChunkHound, beschreibt in seinem Leitfaden vier Werkzeuge für die Softwareentwicklung mit KI-Agenten. Pi führt die Coding-Sitzung, ChunkHound untersucht den Code, pi-schematic verteilt die Arbeit und agent-browser bedient das laufende Frontend. Wolfus entwickelt damit ein Mehrspieler-Spiel. Wir haben einen alltäglicheren Fall gewählt: Welche Belege braucht ein Team, um eine Fehlerkorrektur in einer bestehenden Anwendung freizugeben? Wolfus über seine Arbeit · Sein Praxisbeispiel mit allen vier Werkzeugen

Geprüft am 14. November 2026. Wir haben die vier Pakete installiert, die Erweiterung in Pi geladen, die Beispielanwendung mit ChunkHound indiziert und die Bestellübersicht in Chromium geprüft. Für die Browserprüfung kam Playwright zum Einsatz, da die Testumgebung den lokalen Socket von agent-browser blockierte. Für Recherche und Implementierung mit einem Modell beschreiben wir einen möglichen Ablauf. Beim Test fielen keine kostenpflichtigen Modellanfragen an.

Welche Aufgabe übernimmt welches Werkzeug?

Pi stellt dem Modell eine Arbeitssitzung zur Verfügung. ChunkHound liefert Belege aus dem Repository. Mit pi-schematic lassen sich in Pi Recherche, Implementierung und Review aufteilen. agent-browser liefert die gerenderte Seite und ihre Bedienelemente. Für den Einsatz im Team zählt, welches überprüfbare Ergebnis aus jedem dieser Schritte hervorgeht.

Die vier Open-Source-Projekte mit geprüfter Version und vorgesehenem Beitrag zum Ticket
Komponente	Aufgabe im Beispiel	Beleg für die Übergabe	Lizenz
Pi 1.5.2	Führt die Coding-Sitzung mit dem gewählten Modell, den Repository-Werkzeugen und den Projektanweisungen.	Ein auf das Ticket begrenzter Diff und die ausgeführten Prüfbefehle.	MIT
ChunkHound 6.1.0	Findet die Stellen, die den Filter auslesen und den Link zur nächsten Seite erzeugen.	Datei, Symbol und Zeilenbereich zu jeder relevanten Aussage.	MIT
pi-schematic 0.7.1	Teilt Recherche, Änderung und Review in klar umrissene Aufträge.	Eine kurze Übergabe mit vereinbarten Vorgaben und offenen Prüfungen.	MIT
agent-browser 0.43.0	Bedient einen echten Browser in der Reihenfolge, die die Kundin durchläuft.	URL, sichtbare Bestellnummern und Status vor und nach dem Neuladen.	Apache-2.0

Die vier Projekte stellen ihren Code frei und quelloffen bereit. Für Modellaufrufe, gehostete Embeddings, einen Browserdienst oder GPU-Rechenzeit können Kosten anfallen. Die Regex-Suche und das lokale Browserbeispiel in diesem Artikel kannst du ohne Modellkonto ausführen. Pi-Lizenz · ChunkHound-Repository mit Lizenz · Lizenz von pi-schematic · agent-browser-Repository mit Lizenz

Wie verbindest du Pi, pi-schematic und ChunkHound?

Installiere die Pi-CLI und ergänze pi-schematic als Erweiterung. Registriere ChunkHound im Projekt als Server für das Model Context Protocol (MCP). Über diese Schnittstelle findet Pi die Repository-Werkzeuge und kann sie aufrufen. Pi unterstützt MCP inzwischen direkt. agent-browser kannst du unabhängig davon als Shell-Befehl ausführen. Pi und seine integrierte MCP-Unterstützung

Die Befehle verwenden die hier geprüften Versionen. Wir haben mit Node 24 und Python 3.12 gearbeitet. Installiere den Browser auf dem Rechner, auf dem du die Oberfläche testen willst. Die von Pi gestarteten Programme müssen über den PATH seines Prozesses erreichbar sein. Pi-CLI installieren und anmelden · agent-browser installieren

npm install -g --ignore-scripts @earendil-works/[email protected]
pi install npm:@chunkhound/[email protected]
uv tool install chunkhound==6.1.0
npm install -g [email protected]
agent-browser install

# Diese zwei Befehle im gewünschten Projektverzeichnis ausführen.
pi mcp add -l chunkhound -- chunkhound mcp --no-daemon
pi mcp list

Mit -l landet die Serverdefinition im Projekt unter .pi/mcp.json. Prüfe die Datei, bevor du dem Projekt in Pi vertraust. Ein gespeicherter Eintrag bleibt wirkungslos, wenn Pi das Programm nicht findet oder die Projektkonfiguration noch nicht als vertrauenswürdig eingestuft hat. Lass dir die erkannten Werkzeuge anzeigen und führe anschließend eine bekannte Suche aus. Prüfe, ob das Ergebnis auf die richtige Stelle im Code verweist. MCP-Konfiguration, Projektfreigabe und Befehle in Pi

Unsere Testumgebung blockierte den lokalen Socket des gemeinsam genutzten Daemons. Mit --no-daemon startete ChunkHound für einen einzelnen Client. Nachdem wir die Projektkonfiguration in Pi freigegeben hatten, meldete Pi eine Verbindung zum Server und zeigte search und daemon_status an. Ein separater MCP-Client fragte anschließend per Regex nach PAGE_SIZE und erhielt die Definition aus der Beispieldatei. Damit konnten wir den Transport und die Suche ohne Modellaufruf prüfen. ChunkHound-CLI und Betrieb ohne gemeinsamen Daemon

Wir haben pi-schematic außerdem in einen frischen Pi-Prozess im Offline-RPC-Modus geladen. Pi meldete die vier Erweiterungsbefehle model-groups, notebook, handoff und readonly. Damit ist die Kombination der beiden Paketversionen geprüft. Ob ein bestimmtes Modell einen brauchbaren Patch schreibt, musst du an einer konkreten Aufgabe beurteilen.

Wie grenzt du mit ChunkHound die Fehlerursache ein?

Stell eine Frage, deren Antwort sich im Quelltext nachprüfen lässt. Für dieses Ticket lautet sie: Welche Funktion schreibt den ausgewählten Bestellstatus in die URL der Folgeseite? Und was macht die Anwendung, wenn der Parameter fehlt? Eine brauchbare Antwort belegt beide Stellen und erklärt den Zusammenhang.

Lade das lokale Beispiel zum Bestellfilter in ein leeres Verzeichnis. Es enthält sechs fiktive Bestellungen und zeigt jeweils zwei pro Seite. Beide Betriebsarten nutzen dieselben Datensätze. Im Verzeichnis kannst du ohne Embedding-Dienst einen lokalen Index aufbauen und durchsuchen. Der Variablenname next_status liefert eine reproduzierbare Suchanfrage. ChunkHound für Indexierung, Regex-Suche, semantische Suche und Recherche

chunkhound index --no-embeddings .
chunkhound search --regex 'next_status'

ChunkHound hat die eine Quelldatei in 20 Abschnitte zerlegt und keine Embeddings erzeugt. Die Suche lieferte drei überlappende Treffer in dieser Datei. Der Link-Builder setzt next_status im fehlerhaften Modus auf alle Bestellungen. Darunter erstellt page_url den nächsten Link. Fehlt anschließend der Parameter status, zeigt der Request-Handler wieder alle Bestellungen an. Alle drei Treffer gehören zu demselben Fehler.

Sobald du den Variablennamen kennst, reicht eine Textsuche. Interessanter wird die Recherche, wenn UI-Link, Router, API-Filter und Tests in verschiedenen Paketen liegen. Dort würde ich die semantische Suche oder ChunkHounds Recherchewerkzeug erproben und für jeden Übergang eine Quellstelle verlangen. Öffne die Fundstellen in der geprüften Revision. Nach einer Änderung muss der Index die aktualisierten Dateien enthalten, bevor eine zweite Anfrage einen belastbaren Vergleich liefert.

Lokaler Index und lokale Inferenz sind zwei Entscheidungen. Die Regex-Suche funktioniert ohne Modellanbieter. Für die semantische Suche brauchst du Embeddings. Die tiefergehende Recherche nutzt zusätzlich ein Modell und eine passende Konfiguration zur Neusortierung der Treffer. Bei externen Anbietern solltest du wissen, welche Suchanfragen und Codeausschnitte die einzelnen Dienste erhalten. Darf ein Repository den Rechner nicht verlassen, prüfe die Ziele jeder Backend-Verbindung vor der Einführung im Team. Provider und Index in ChunkHound konfigurieren

Wie teilst du die Codeänderung mit Pi und pi-schematic auf?

Gib der Recherche eine konkrete Frage, der Implementierung eine begrenzte Änderung und dem Review ein beobachtbares Abnahmekriterium. Mit spawn startet pi-schematic eine eigene Unterhaltung für einen Teilauftrag. handoff übergibt Entscheidungen an die nächste Phase. Ein Kindprozess übernimmt das Arbeitsverzeichnis. Zwei Agenten mit getrennten Unterhaltungen können also dieselbe Datei ändern. Rollen, Modellgruppen, Notebook und Grenzen der Isolation

Eine mögliche Aufgabenverteilung für den Bestellfilter
Rolle	Auftrag	Kriterium für die Übergabe
Recherche	Verfolge den Status von der ersten Seite über die Linkerzeugung bis zum Request-Handler. Nenne die Quellstellen.	Eine zweite Person kann zeigen, wo der Filter verloren geht und warum danach alle Bestellungen erscheinen.
Implementierung	Übernimm den ausgewählten Status in die URL der Folgeseite. Behalte Route und Verhalten bei leeren Ergebnissen bei.	Ein kleiner Diff. Für Änderungen an diesen Dateien ist genau eine Person oder ein Agent zuständig.
Review	Leite die erwarteten Datensätze auf Seite zwei vor dem Öffnen aus den Testdaten ab. Prüfe URL, Zeilen, Neuladen, Zurück und die leere Ergebnismenge.	Soll- und Istwerte stehen nebeneinander. Ein Screenshot der ersten Seite lässt das Verhalten beim Weiterblättern offen.

Halte die erwarteten Bestellnummern und den Umfang der Änderung im Ticket oder in einem versionierten Regressionstest fest. Das Notebook der Erweiterung kann Entscheidungen über mehrere Übergaben hinweg speichern. Es gehört zum jeweiligen Arbeitsablauf und wird beim Start eines neuen geleert. Für die nächste Freigabe lassen sich ein Git-Diff, ein Test und ein Ticket zuverlässig wiederfinden. Sollen mehrere Agenten gleichzeitig schreiben, trenne ihre Änderungen etwa über eigene Worktrees. Wie ein Coding-Harness Werkzeuge, Zustand und Prüfung zusammenführt.

Wie prüfst du im Browser, ob der Filter beim Weiterblättern erhalten bleibt?

Schreib die erwartete zweite Seite auf, bevor du die Oberfläche bedienst. Nach Auswahl von Open müssen zunächst ORD-101 und ORD-102 erscheinen. Nach Next folgen ORD-105 und ORD-106, beide mit Status Open. Die URL muss Status und Seitennummer enthalten, damit Neuladen dasselbe Ergebnis wiederherstellt.

Starte den lokalen Server zunächst im fehlerhaften Modus. Auf einem Rechner, der den lokalen Browser-Daemon zulässt, kannst du die folgenden agent-browser-Befehle im zweiten Terminal ausführen. Die Befehle sprechen Links über ihre zugänglichen Namen an. Dadurch funktioniert die Abfolge auch dann, wenn der nächste Snapshot andere Elementnummern vergibt. Navigation, Lokatoren und Zustandsabfragen in agent-browser

# Terminal 1
python3 order_filter_lab.py --mode broken --port 8765

# Terminal 2
agent-browser open http://127.0.0.1:8765/orders
agent-browser snapshot -i
agent-browser find role link click --name "Open" --exact
agent-browser find role link click --name "Next page" --exact
agent-browser get url
agent-browser snapshot
agent-browser reload
agent-browser snapshot
agent-browser back
agent-browser snapshot
agent-browser find role link click --name "Cancelled" --exact
agent-browser snapshot
agent-browser close

Der interaktive Snapshot mit -i hilft beim Auffinden der Bedienelemente. Der vollständige Snapshot enthält auch den lesbaren Tabelleninhalt. Wenn du Referenzen wie @e3 für Klicks verwendest, hole sie nach einem Seitenwechsel aus einem neuen Snapshot. Für die optische Prüfung von Ausrichtung oder abgeschnittenen Inhalten ist ein Screenshot sinnvoll. Bei diesem Fehler entscheiden die Bestellnummern, der Statustext und die URL. Snapshot-Arten und Elementreferenzen

Beobachtungen in Chromium mit denselben sechs Bestellungen, Browsersteuerung durch Playwright
Prüfschritt	Fehlerhafte Version	Korrigierte Version
Open auswählen	ORD-101 und ORD-102, beide Open.	Identische erste Seite.
Next page öffnen	`/orders?page=2`. ORD-103 und ORD-104, beide Closed.	`/orders?status=open&page=2`. ORD-105 und ORD-106, beide Open.
Zweite Seite neu laden	Die ungefilterte URL zeigt wieder dieselben beiden abgeschlossenen Bestellungen.	Die gefilterte URL zeigt wieder dieselben beiden offenen Bestellungen.
Zurück im Browser	Erste Seite mit Filter Open, ORD-101 und ORD-102.	Dieselbe URL und dieselben Zeilen wie vor dem Weiterblättern.
Cancelled auswählen	Keine Zeilen. Die Meldung lautet „No matching orders.“	Dasselbe leere Ergebnis. Die URL enthält den ausgewählten Status.

Beende den Server mit Strg+C, starte ihn mit --mode fixed erneut und wiederhole die Abfolge. Den oberflächlichen Test „Der Filter funktioniert auf Seite eins“ bestehen beide Versionen. Erst Bestellnummern und URL zusammen erklären, warum Weiterblättern und Neuladen fehlschlagen. Zurück und die leere Ergebnisliste prüfen die benachbarten Abläufe.

Lade für spätere Wiederholungen den Playwright-Regressionstest in dasselbe Verzeichnis. Er prüft beide Versionen gegen dieselben fachlichen Erwartungen. Im fehlerhaften Modus schlug der Test beim Klick auf Next fehl und endete mit Exitcode 1. Im korrigierten Modus bestand die Anwendung alle fünf Prüfungen. Der Test endete mit Exitcode 0.

python3 -m pip install playwright
python3 -m playwright install chromium
python3 test_order_filter.py http://127.0.0.1:8765/orders

Weitere Prüfpunkte für das gesamte Release findest du in der QA-Checkliste vor dem Produktstart.

Wann lohnt sich dieser Entwicklungsstack für dein Team?

Wähle das erste Werkzeug nach dem Problem, das im Alltag Zeit kostet. Kennt das Team die betroffene Funktion bereits, bringen Embeddings bei einer Änderung von sechs Zeilen wenig. Wenn regelmäßig Fehler erst beim zweiten Klick sichtbar werden, lohnt sich zuerst eine wiederholbare Browserprüfung. Ein bestehendes Projekt kann jede Komponente einzeln erproben.

Dauert die Code-Recherche zu lange? Lass einen Entwickler vergleichbare Tickets mit der bisherigen Suche und mit ChunkHound bearbeiten. Miss die Zeit bis zur zuständigen Datei und prüfe, wie viele Fundstellen die Erklärung tragen.
Verlieren Aufträge ihren Fokus? Erprobe einen gespeicherten Ablauf in pi-schematic mit genau einer schreibenden Rolle und einem Reviewer. Zähle doppelte Recherchen, kollidierende Änderungen und reproduzierbare Befunde. Drei kostenpflichtige Modellsitzungen können eine einfache Aufgabe verteuern.
Rutschen Oberflächenfehler durch das Review? Reproduziere den Fehler im Browser, halte den Sollwert unabhängig fest und prüfe ihn nach der Änderung erneut. Gehört das Verhalten zu den Bedingungen für jede Freigabe, versioniere den Regressionstest und lass ihn in der CI laufen.

Für die Pilotmessung zählen nur Korrekturen, die eure vereinbarten Kriterien erfüllen. Acht abgenommene Korrekturen verursachen zum Beispiel 12 € für Modellaufrufe und drei Stunden Review zu angenommenen 80 € pro Stunde. Das ergibt 252 € oder 31,50 € je abgenommener Korrektur, vor Infrastrukturkosten. Rechne den Aufwand für verworfene Versuche mit ein. Vergleiche das Ergebnis mit ähnlichen Tickets aus eurem bisherigen Ablauf. Der Einkaufsleitfaden für Coding-Stacks mit mehreren Modellen vertieft Modellwahl und Beschaffung.

Wie ein Produkt vom Prototyp in den Pilotbetrieb kommt, beschreibt die Fallstudie zu Twinsoft AI. Mit Harness Engineering verbindet Wavect Repository-Werkzeuge, Agentenabläufe und Freigabetests. Einen Pilotversuch an einem bestehenden Ticket planen.

Häufige Fragen zum Entwicklungsstack mit Pi

Ist Pi selbst ein Coding-Modell?

Pi führt die Sitzung aus und stellt dem konfigurierten Modell Werkzeuge bereit. Halte die Versionen von Pi und seiner Erweiterung getrennt von der Modell-ID fest. Zwei Entwickler können denselben Harness verwenden und mit anderen Modellen, Projektanweisungen oder Berechtigungen unterschiedliche Ergebnisse erhalten.

Kann ich in einem bestehenden Projekt nur agent-browser einführen?

Ja. Die CLI kann den Browser unabhängig von Pi oder ChunkHound bedienen. Beginne mit einer lokalen Seite oder einer Testumgebung und einem schriftlichen Sollverhalten. Über den Accessibility-Snapshot findest du Bedienelemente. Wenn der erwartete Wert vorliegt, kann auch eine andere Person den Befund prüfen.

Bleibt der Code auf dem Laptop, wenn ChunkHound dort läuft?

Das hängt von den aktivierten Funktionen und deren Anbietern ab. Unsere lokale Regex-Suche lief ohne Embeddings und ohne Modellkonto. Für Vektorsuche und Recherche lassen sich externe Dienste konfigurieren. Prüfe bei einem privaten Repository für jede Stufe, welche Daten sie an welchen Endpunkt überträgt.

Legt pi-schematic für jeden Reviewer einen Git-Worktree an?

Ein Kindprozess startet mit einer neuen Unterhaltung und übernimmt das aktuelle Arbeitsverzeichnis. Dadurch können seine Schreibzugriffe weiterhin dieselben Dateien treffen. Weise jeder Änderung eine verantwortliche Rolle zu oder lege Worktrees ausdrücklich an. Die Freigabeentscheidung und die zugehörigen Prüfergebnisse gehören ins Ticket oder Repository.

Brauche ich neben agent-browser noch Playwright-Tests?

Ein Playwright-Test lohnt sich, wenn dein Team einen Ablauf bei jeder Freigabe wiederholen will. Mit einer Browser-CLI kannst du neue Abläufe erkunden, Seitenelemente untersuchen und verschiedene Wege ausprobieren. Ein versionierter Test kann dieselbe URL und dieselben erwarteten Datensätze bei jedem Release prüfen. Für das Beispiel steht ein solcher Regressionstest zum Download bereit.

Wie prüfen wir, ob der Stack für unser großes Repository taugt?

Nutze einen repräsentativen Checkout und reale Tickets, deren zuständige Module bekannt sind. Miss Dauer der Erstindizierung, Indexgröße, Verzögerung nach Änderungen, Treffergenauigkeit und die Zahl abgenommener Änderungen. Erfasse Speicherbedarf und Providerkosten. Der kleine Funktionstest in diesem Artikel liefert noch keine Kapazitätsmessung für euren eigenen Bestand.