What is the problem your project solves?

Every app is frozen at whatever its builders had time for. You know exactly what you'd change. That wish dies in a backlog, because the distance between wanting a change and running it is an entire engineering process.

Coding agents didn't close that distance. They write the code; everything after is untouched. An agent says "fixed it." Is it? Its self-report is not evidence. So a human still reads the diff, runs the tests, and merges. The expensive part never got cheaper.

It's a trust problem before it's a capability problem: a system can't rewrite software you're running unless it proves it broke nothing, and a person keeps the final say.

Pal is a workspace where humans and agents already work side by side. So we closed the loop: the agents inside Pal can now rebuild Pal. Done safely, the cost of a feature collapses to the cost of describing it.

How you are solving it?

We built Forge, and with it Pal became an app that ships itself. Describe a feature in chat or on /builds. An agent codes against Pal's own repo in an isolated git worktree. The change is verified, a human approves, and it fast-forward merges into the checkout the dev servers watch. Backend runs under bun --watch, web under next dev, so the merge is the deploy: the running app reloads with the new feature in it.

Pal itself predates the hackathon (Bun + PostgreSQL, Next.js, SwiftUI iOS; ~87 commits); Forge is entirely new work built here: 8 commits and ~9,000 lines on the forge-pal-building-pal branch.

The real work is what makes this safe to run on live software. Three decisions carry it:

1. Verification is relative. Every check (lint, tests, typecheck, changelog) passes if green or no worse than a baseline from the untouched tree. It's the only rule that survives a real repo with flaky tests and old lint findings. "You did not make it worse" is provable, and it self-tightens as the repo gets cleaner. The checklist lives in code, not prompts, so the agent can't grade its own exam. A second read-only agent reviews the diff against acceptance criteria fixed before the build started, with veto power.

2. Landing is guarded four ways. Checks green, checkout clean, fast-forward only, and still on the exact commit that was verified. Fail any and the run rebases, re-runs the gate, and resolves its own conflicts first. A migration that fails after merge rolls back.

3. The run must outlive its own success. Landing restarts the backend, so a run driven from inside the server would be killed by its own merge. Each run is a detached worker; the run row and an append-only event log are the only shared state; orphans reconcile at boot; progress streams over cursor-based SSE, so the browser resumes across the restart the run just caused.

Also shipped: six agent tools (build_feature, revise_build, get_build, list_builds, cancel_build, ship_build), a live /builds run view, and a skill that maps the codebase for the build agent, versioned in the same commit as the code it describes

How Did You Use Claude?

Claude Code built Forge. Forge is us productising how we already worked with it.

Building Pal with Claude taught us the leverage isn't the model writing code; it's the repo carrying its own instructions. An agents file and a set of skills teach an agent where the seams are and what "done" means. The skill that maps this codebase was written for Claude Code and is now the exact document Forge's build agent reads first, kept current by rule in the same commit as any structural change. A working habit became a product feature.

The pipeline is the same experience distilled: fix acceptance criteria before editing, stream reasoning, report honestly, let a separate reviewer read the diff. All lessons from real repos, not benchmarks.

In the product, Claude Sonnet 4.5 serves Pal's long-context routes (agent chat, context compaction) via the model router, with automatic failover. Forge's build agent runs on Claude Opus 4.8: every feature it writes, verifies, and ships into Pal is Opus doing the work.

What is the deployed URL for this project?

https://pal.muunilinst.space/