Backlog Smith

• 

• 

• 

• 

• 

• 

Inspiration

When you're vibe coding, the changes you want to make rarely arrive as a clean backlog. They're fragmented, out of order, and easy to forget — especially the small product and UX details you notice along the way. The bottleneck was never writing the code; it was capturing that mess and turning it into work an agent can actually execute well. BacklogSmith is built for that messy middle: catch the rough intent, let an agent compile it into ordered, reviewable units, and make the most draining part of the loop a little more structured — and a lot more fun.

What it does

Drop rough requirements into an Inbox attached to a Git repository — as separate notes, or as one rough block. BacklogSmith preserves your original entries, checks a bounded snapshot of the repository, and keeps a live plan of commit-sized work packages. A small change gets the smallest safe adjustment to that plan; when requirements overlap, span several packages, or the code has moved underneath, it reorganizes a larger part instead — splitting mixed entries, merging related work, and working out the dependencies. Independent packages can run in parallel; dependent ones wait.

Planning runs on GPT-5.3 Codex Spark. Each package carries concrete tasks — a precise implementation prompt and its own acceptance criteria — all editable before you approve anything. Approve a package, and BacklogSmith spins up an isolated Git worktree and branch, then dispatches it to the agent under a sandbox, where you choose the execution model and reasoning effort. The agent implements the change but never commits.

When it finishes, an independent review checks every acceptance criterion and reports the evidence, the remaining gaps, the validation results, and the risks. If something's off, you request changes from inside BacklogSmith; the revision continues in the same worktree and Codex thread, and it has to pass a fresh review before it counts. You can also open the worktree in a terminal and run the project locally to see it for yourself.

Once you're satisfied, you Accept and Merge. BacklogSmith confirms the reviewed worktree hasn't changed, creates a single verified commit, and attempts the merge — never pushing on your behalf. If the merge hits a conflict, it keeps a conflict preview, and you can ask Codex to resolve it, then review the result once more before it lands.

Capture → plan → approve → dispatch → review → merge, all local, with you holding every merge decision.

How we built it

BacklogSmith grew out of the same workflow it is designed to formalize, and it was created through an iterative collaboration with GPT-5.6 Sol.

I started by giving my rough, evolving ideas to the agent and letting it implement them. I reviewed the results, identified what needed to change, sent feedback back, and repeated the loop until I was ready to confirm and commit. That manual cycle — capture intent, let an agent execute, review, revise, confirm, commit — became the blueprint for BacklogSmith. I built it to turn that effective but loosely managed process into a structured, repeatable system.

Inside the shipped product, the roles are split by design. The analysis work — recompiling the Inbox into packages and reviewing each result against its acceptance criteria — runs on GPT-5.3 Codex Spark, while for execution you choose the model and reasoning effort that implements each package. For now, BacklogSmith works with Codex, so the whole loop is exercised end to end on one provider before others are added.

Technically, it's an Electrobun desktop app with a hard process boundary: a Bun main process solely owns SQLite, Git, and the Codex App Server, while the React UI gets only a small allowlisted, typed RPC surface and can never run a shell command. Git worktrees are the isolation unit — one package equals one worktree, one commit, one review/revert boundary — and plans are stored as immutable revisions guarded by a fail-closed validator that enforces requirement coverage and dependency cycle-freedom before anything persists.

Challenges we ran into

The hardest problem was not code generation, but alignment.

My prompts were often brief, so the agent filled in the gaps with decisions that were technically sound and consistent with the codebase — but did not always match how I wanted the product to behave. A reasonable engineering decision could still be the wrong product or UX decision.

That meant every user-facing change required human review. Each review produced more small, fragmented adjustments: preserve this behavior, change that interaction, handle this edge case, or rethink an earlier assumption. Managing those corrections quickly became a bottleneck of its own — and became BacklogSmith's core motivation: agents can execute the work, but humans must remain in the approval loop, while the tool captures and organizes the messy feedback generated along the way.

Accomplishments that we're proud of

BacklogSmith completed a real end-to-end run on a live repository: GPT-5.3 Codex Spark turned raw Inbox entries into dependency-aware packages — each with its own implementation prompt and acceptance criteria — a Codex agent implemented an approved package in an isolated worktree, and an independent review checked the result against those same criteria. BacklogSmith then created a single verified commit and merged it only after my confirmation, leaving both the main working tree and the task worktree clean.

I'm equally proud of a boundary that holds: the agent implements but never commits, never pushes, and only ever writes inside a worktree I authorized.

What we learned

Three lessons outlasted the project itself.

First, the compiler is the moat. Dispatching an agent into a worktree is quickly becoming a commodity; turning a rough, half-formed idea into a package an agent can execute and be graded on is the part that's genuinely hard — and the part worth building.

Second, a plan that merely parses is not a plan that's correct. Structurally valid model output can still hide a dependency cycle or an uncovered requirement, so the tool has to fail closed — validating coverage and dependency integrity before anything is stored, not after it breaks.

Third, acceptance criteria are only trustworthy when they're the same contract on both ends. The criteria a package is built from must be the exact criteria it's later reviewed against; the moment those two drift, every green checkmark stops meaning anything.

What's next for BacklogSmith

Next, I'll keep refining the UI and UX so the workflow is simpler, clearer, and asks fewer decisions of the user.

I also plan to strengthen automated validation, so each package is checked more thoroughly against its acceptance criteria before it reaches human review — and to make the change even easier to see before accepting, with an in-app diff to complement the terminal preview. The goal is to lower the cost of reviewing changes without ever removing the user from the final approval loop.

Finally, while BacklogSmith works with Codex today, the plan is to support additional coding agents through a provider adapter — so the same capture → plan → approve → dispatch → review → merge loop can run on Claude Code and other agents, once the lifecycle contract is fully proven on Codex first.

Built With

• bun
• electrobun
• react
• sqlite
• typescript
• zod