Pixel — an LLM co-maintainer in production

May 2026 · puzzlekreis.de · FastAPI + Next.js + React Native

puzzlekreis.de is a swap marketplace for jigsaw puzzles. Backend in Python (FastAPI, async SQLAlchemy, Postgres 16, Redis 7), web in Next.js 14 as a PWA, mobile in React Native (Android and iOS via EAS). Roughly 150 backend files, 30+ pytest suites, ~14k TS/TSX in the frontend, deployed on a Hetzner CX33. There are two maintainers: me, and an agent named Pixel.

Pixel doesn't work in tickets. Pixel works in branches. When Pixel finishes a run, the result isn't a recommendation, isn't a diff in the chat reply — it's a feat/... branch with tests and a commit pushed to origin. I pull it in the morning, read through, merge it or hand it back with notes.

This text describes how that works, how I guarded it against the obvious failure modes, and why it isn't the end-boss agent that I just rubber-stamp branches from.

The loop

Pixel's runner is a sibling script to the bug-bounty runner I describe elsewhere — same Bash, different post-processing. Each run takes:

• a queue.txt with tasks: V2: instrument analytics event hooks · V3: extend listing editor · V4: …
• one prompt per task with context — what the task is, which files are relevant, which tests must pass, and crucially the pointer to convention files in the repo that the agent must read before writing
• a git for-each-ref snapshot before each run, so we can detect new branches afterwards

Pixel opens a fresh Claude CLI process, gets the prompt, and works. --add-dir points at the repo. The agent may do anything in the repo that doesn't commit to main. By the end it should have created a feat/... or fix/... branch, made tests pass, and pushed.

What Pixel does in a day

Run 6, task V2, completed May 1: instrument analytics event hooks. The prompt: "Instrument all backend service methods with calls to analytics.py V1, which isn't yet in main; use fail-soft try-imports so that the missing V1 doesn't break tests; create a test suite."

What Pixel produced:

Branch:  feat/analytics-event-hooks (from main, commit 34953fa)
Files modified:
  backend/app/services/auth.py
  backend/app/services/listing.py
  backend/app/services/listing_photo.py
  backend/app/services/message.py
  backend/app/services/rating.py
  backend/app/services/swap.py
  backend/app/services/user_account.py
Files created:
  backend/tests/test_analytics_hooks.py

17 hook sites covering 18 distinct event types:
  signup, login, logout
  listing_create, listing_publish, listing_unpublish, listing_view
  photo_upload
  swap_request, swap_accept, swap_decline, swap_cancel,
    swap_ship, swap_complete
  message_sent
  account_delete, account_restore
  rating_given

That was a task that would probably have taken me 4-5 hours with breaks. Pixel needed 38 minutes. I read the branch in the morning, gave three notes back (variable naming, a missing edge case in a test, a small API consistency question), and Pixel addressed them in the second run iteration. Merged.

Across 5 completed runs (Run 2-6), Pixel has done roughly 20 such tasks — analytics hooks, photo-gallery lightbox, brand migration, an FTS migration with a Postgres array-IMMUTABLE wrapper, Sentry CSP configuration, a series of edge bugs before soft launch.

What I had to guard

Branch detection instead of status file. The bug-bounty runner expects a status.json as success interface. Pixel's interface is a new branch on origin. Sentinel recovery is correspondingly:

# Before the run: snapshot all branches
branches_before=$(cd "$REPO" && git for-each-ref --format='%(refname)' refs/heads refs/remotes/origin)

# … claude --print … runs …

# After the run, if the agent didn't write a status file:
branches_after=$(cd "$REPO" && git for-each-ref --format='%(refname)' refs/heads refs/remotes/origin)
new_branches=$(comm -13 <(echo "$branches_before") <(echo "$branches_after") | \
                grep -E 'feat/|fix/|chore/|test/' | head -3)

if [ -n "$new_branches" ]; then
  cat > "$STATUS_DIR/$next_id.status" <