In this piece
A 2026 AI agent development stack, tested on a frontend regression
The customer selects Open on the orders screen. The first page shows two open orders. A developer takes a screenshot and closes the ticket. One click later, the customer is looking at two closed orders. Which tool in an AI coding stack should have caught that?
Ofri Wolfus, the creator of ChunkHound, describes a four-tool setup in his public engineering guide. Pi runs the coding session, ChunkHound investigates the code, pi-schematic organizes the work, and agent-browser inspects the running frontend. His example builds a multiplayer game. We put the same division of labor against a smaller decision that maintenance teams face every week: what evidence would justify merging one fix into an existing app? Wolfus on his background · His original four-tool walkthrough
Checked 14 November 2026. We installed the four packages, loaded the Pi extension, indexed the example with ChunkHound, and exercised the order screen in Chromium. We used Playwright for the browser observations because the execution environment blocked the local socket needed by agent-browser. The model-assisted research and coding steps below are a proposed workflow. We sent no paid model requests.
What does each tool contribute to the development stack?
Pi gives the model a working session. ChunkHound finds evidence in the repository. pi-schematic gives separate jobs to researchers, implementers and reviewers inside Pi. agent-browser provides the rendered page and its controls. For a team lead, the useful question is what each step hands to the next person.
| Component | Role on this ticket | Evidence to retain | Code license |
|---|---|---|---|
| Pi 1.5.2 | Run the coding session with the selected model, repository tools and instructions. | A scoped diff and the commands used to verify it. | MIT |
| ChunkHound 6.1.0 | Find where the filter is read and where navigation URLs are generated. | File, symbol and line range for each relevant claim. | MIT |
| pi-schematic 0.7.1 | Keep research, editing and review focused on their respective questions. | A concise handoff with agreed constraints and outstanding checks. | MIT |
| agent-browser 0.43.0 | Drive a real browser through the customer’s sequence. | The URL, visible order IDs, statuses and evidence after reload. | Apache-2.0 |
“Free and open source” describes the four projects' code. A model API, hosted embedding service, browser service or GPU can still carry a charge. You can run the small regex search and the local browser fixture in this article without a model account. Pi license · ChunkHound repository and license · pi-schematic license · agent-browser repository and license
How do you connect Pi, pi-schematic and ChunkHound?
Install Pi as the CLI, add pi-schematic as a Pi extension, and register ChunkHound as a project-local Model Context Protocol (MCP) server. MCP is the interface Pi uses to discover and call the repository tools. agent-browser can stay a separate shell command. Pi now includes MCP support in the harness. Pi’s current harness and built-in MCP support
These commands target the versions inspected for this guide. We used Node 24 and Python 3.12. Install the browser runtime on the machine that will drive the UI. Keep the environment used by your agent on the same PATH as the tools you want it to launch. Pi CLI installation and authentication · agent-browser installation
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
# Run these two commands in the repository you want Pi to use.
pi mcp add -l chunkhound -- chunkhound mcp --no-daemon
pi mcp listThe -l option writes the server definition to .pi/mcp.json in the project. Review that file before trusting the project in Pi. If the executable is missing from Pi’s environment, or the project configuration has yet to be trusted, a saved definition alone cannot establish that tool calls work. Verify discovery, then send one known search and inspect the returned source location. Pi’s project scope, trust and MCP commands
Our machine restricted the shared daemon’s local socket, so we used ChunkHound’s single-client --no-daemon mode. In the trusted test project Pi listed the server as connected and exposed search and daemon_status. An independent MCP client then called regex search for PAGE_SIZE and returned the definition in the fixture. That exercises the transport and lookup without asking a model to select a tool. ChunkHound CLI reference and single-client mode
We also loaded the installed pi-schematic extension into a fresh, offline Pi RPC process. Pi returned the extension’s model-groups, notebook, handoff and readonly commands. That checks whether these particular packages load together. Judging whether a chosen model writes an acceptable patch takes a separate task run.
How do you trace a regression with ChunkHound?
Start with a question whose answer you can check in source. For this ticket it is “Which function serializes the selected order status into the next-page URL, and what happens when that parameter is missing?” A useful research result identifies both ends of that path and shows which one changes the behavior.
Download the local order-filter lab into an empty directory. It contains six fictional orders and a page size of two. Both modes use the same rows. In that directory you can build a local index and search it without an embedding service. The deliberately named next_status makes the query reproducible. ChunkHound indexing, regex, semantic search and research
chunkhound index --no-embeddings .
chunkhound search --regex 'next_status'On the supplied one-file app, ChunkHound indexed one file into 20 chunks with zero embeddings. The query returned three overlapping results in that file. The key line sets next_status to all orders in broken mode. The next line builds the link with page_url. The request handler defaults to all orders when the status query parameter is absent. Three search hits describe one defect.
A text search would suffice once you know the symbol. A more demanding repository separates the UI link, route parser, API filter and tests across packages. That is where I would trial semantic search or ask ChunkHound’s research tool to trace the path and cite each step. Check the cited lines on the revision under review. After a change, refresh the index or confirm it observed the changed files before trusting a second answer.
A local index and local model inference are separate choices. Regex search works without a model provider. Semantic retrieval requires embeddings, and deeper research adds a model and a compatible reranking configuration. If you configure remote providers, inspect what code, snippets and queries those stages send. For a repository with a local-only requirement, pilot each selected backend and record its destination before enabling it for the team. ChunkHound provider and index configuration
How should Pi and pi-schematic divide a change?
Give the researcher a question, the implementer a narrow change, and the reviewer an observable acceptance condition. pi-schematic can start a child with a clean conversation via spawn and carry decisions to a fresh phase with handoff. The child inherits the working directory. Separate conversations can still edit the same file. pi-schematic roles, model groups, notebook and workspace limits
| Role | Instruction | What can move forward |
|---|---|---|
| Researcher | Trace the selected status from the first page through the link builder and request handler. Return source references. | The reader can point to where the filter disappears and explain the fallback. |
| Implementer | Preserve the selected status when building the next-page URL. Keep the existing route and empty-state behavior. | A small diff with one writer responsible for the affected files. |
| Reviewer | Use the seeded rows to predict page two before opening it. Check the URL, rows, reload, Back and empty result. | A record of expected and observed values. A green first-page screenshot is insufficient. |
Write the expected IDs and scope into the ticket or a committed regression test. The extension’s notebook is useful for working decisions across handoffs. It is tied to the work stream and clears with a new one. If two people need to reconstruct the decision at the next release, a Git diff, a test and a ticket are much easier to retrieve. For genuinely parallel writers, assign separate worktrees or otherwise separate their edits. How a coding harness manages tools, state and verification.
How do you prove the browser fix survives the next click?
Write down the expected second page before operating the UI. In this fixture, selecting Open must first display ORD-101 and ORD-102. After Next, it must display ORD-105 and ORD-106, both open. The URL must carry both the selected status and page number so a reload reconstructs the same result.
Start the supplied local server in broken mode. In a second terminal, use these agent-browser commands on a machine where its local browser daemon can start. The browser example uses accessible role names so a different snapshot can return different reference numbers without breaking these instructions. agent-browser navigation, locators and state inspection
# 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 closeAn interactive snapshot (-i) is convenient for finding controls. A full snapshot also includes readable table content. If you use references such as @e3 to click, obtain a fresh snapshot after navigation and use the reference that it returns. Add a screenshot when alignment or clipping is an acceptance condition. Row IDs, status text and URL are the decisive observations for this bug. Snapshot types and element references
| Checkpoint | Broken mode | Fixed mode |
|---|---|---|
| Select Open | ORD-101, ORD-102. Both Open. | Identical first page. |
| Follow Next page | /orders?page=2. ORD-103 and ORD-104, both Closed. | /orders?status=open&page=2. ORD-105 and ORD-106, both Open. |
| Reload page two | The unfiltered URL restores the same two closed orders. | The filtered URL restores the same two open orders. |
| Browser Back | Open page one, ORD-101 and ORD-102. | Same URL and rows as before advancing. |
| Select Cancelled | Zero rows and the message “No matching orders.” | The same empty state, with Cancelled in the URL. |
Stop the server with Ctrl-C and restart it with --mode fixed to repeat the sequence. Both versions pass a superficial “the filter works” test on the first page. Only the combination of row identity and route state demonstrates why Next and Reload fail. Back and the empty state serve as controls for adjacent behavior.
For repeat runs, download the Playwright regression test alongside the fixture. It applies the same product expectations to either version. That gives a reviewer an independent way to reject the broken behavior after the exploratory browser session has ended. In broken mode the test exited with status 1 at Next. In fixed mode it passed all five checks and exited with status 0.
python3 -m pip install playwright
python3 -m playwright install chromium
python3 test_order_filter.py http://127.0.0.1:8765/ordersOur release QA checklist covers the checks around a wider launch.
When is the four-tool stack worth adopting?
Start with the tool that addresses an observed delivery problem. If engineers can already find the owning function, adding embeddings to a six-line fix buys little. If code reviews regularly approve features that fail one click later, a repeatable browser assertion deserves the first investment. Existing projects rarely need all four tools on day one.
- When code discovery is slow, compare an engineer using existing search with the same engineer using ChunkHound on equivalent tickets. Record time to the correct owning file and how many reported references support the explanation.
- When tasks lose scope, try one saved pi-schematic procedure with a single writer and a reviewer. Count repeated investigations, conflicting edits and findings the reviewer can reproduce. Splitting a simple task into three paid sessions can add expense without improving the result.
- When UI defects escape review, record the failure in the browser, preserve an independent expectation and rerun it after the patch. Keep a deterministic regression in CI when the behavior is important enough to protect on every release.
For a pilot, count only fixes that meet the agreed acceptance conditions. Suppose eight accepted fixes consume €12 in model calls and three hours of review at an illustrative €80 per hour. That is €252, or €31.50 per accepted fix, before infrastructure. Include time spent on rejected attempts in the numerator. Compare with the team’s existing workflow on similar tickets. Our multi-model coding stack buying guide covers the broader routing and procurement decision.
For a product moving from prototype to pilot, the Twinsoft AI case study describes the surrounding delivery work. Wavect’s harness engineering service covers how repository tools, agent procedures and release checks fit together. Scope a pilot around an existing ticket.
