Open-source engineering practice

Real code.
Real problems.
Practice beyond
the puzzle.

Interviews and real jobs are not about inverting binary trees. They are about stepping into code you did not write, understanding what is broken and fixing it so it stays fixed. Patchground gives you that practice: a real repository, a real ticket, your own editor and your own AI, and checks that run in Docker.

Get Patchground Browse challenges
  • Local-first, no account
  • Bring your own editor and AI
  • Verified by tests, not scored
  • Apache-2.0
one practice sessionillustration
  1. pgnd start duplicate-charges-on-retry
  2. Building image… workspace ready at ~/patchground/sessions/…/workspace
  3. Ticket: Duplicate charges after a payment retry · timebox 45 min
  4. code . # or your editor and agent of choice
  5. pgnd check
  6. ✗ 12 passed, 2 failed — hidden checks still red
  7. pgnd check
  8. ✓ 14 passed, 0 failed
  9. pgnd submit
  10. Verified outcomes
    Checks
    14 / 14
    Regression test
    fails before · passes after
    Diff scope
    inside src/payments/
    Time
    38 of 45 min
    No overall score. Facts your tests can back.

How it works

One ticket.
Four commands.

A session goes the way real work does. You pick up a ticket, dig into a codebase you have never seen, prove the fix holds and get a record of what you actually did.

  1. 01 · pgnd start

    Pick up a ticket

    You get a real repository with a bug report or feature request, in a fresh workspace. The tests that decide the outcome stay hidden.

  2. 02 · your editor

    Find it and fix it

    Read code you did not write, reproduce the problem and change it. Use your own editor and your own AI agent, or work without one.

  3. 03 · pgnd check

    Check as you go

    Run the checks in Docker whenever you like, as many times as you need. Red turns green only when the behaviour is actually right.

  4. 04 · pgnd submit

    Get verified outcomes

    Your work is frozen into a report you can trust: what passed, whether your test proves the fix and where your diff landed.

What you practise

The skills the job
actually asks for.

Puzzles train you to recall algorithms. Patchground trains the habits that matter on a team and in a practical interview, and gives you evidence to show for them.

Debugging unfamiliar code

Trace a symptom from a support ticket to its root cause in a codebase you have never opened.

Shipping a feature

Extend existing behaviour without breaking what already works, so the old tests stay green.

Proving the fix

Write a regression test that fails before your change and passes after. Patchground runs it on both versions to check.

Working with your AI

Direct Claude Code, Codex, a local model or no tool at all. Then use the outcomes to check what it really changed.

Keeping the change in scope

Fix the problem in the right place. The report shows exactly which files your diff touched.

Working to a timebox

Every challenge has a realistic timebox. See how long you really took and how many hints you used.

What you walk away with

Facts about your work,
not a score.

When you submit, Patchground freezes your workspace and computes a report from test runs alone. When it cannot prove something, it says so instead of guessing.

Verified outcomesduplicate-charges-on-retry · illustration
Checks
14 / 14 passed
Regression test
fails before · passes after
Test structure
0 tests removed · 0 assertions dropped
Diff scope
2 files inside src/payments/
Time & effort
38 of 45 min · 6 checks · 1 hint
No overall score. Missing evidence is reported as "not established".

  1. Does it work?

    Visible and hidden checks run fresh in Docker on your final code.

  2. Did you prove it?

    Your new test is run on the original code and on yours. It only counts if it catches the bug.

  3. Did you cut corners?

    It flags deleted test files or functions and fewer assertions, so a fix can't pass by weakening tests.

  4. Did you stay focused?

    It lists every file you changed and whether each one is in the area the ticket expects.

  5. How did it go?

    Elapsed time against the timebox, plus how many practice checks and hints you used.

Who it's for

Practice for the work
in front of you.

Preparing for a practical interview

Live debugging rounds and take-home feature tasks, rehearsed on real repositories against the clock instead of on puzzles.

Joining a new codebase

Build the habit of reading before changing, of finding the right place for a fix, and of leaving the tests stronger than you found them.

Learning to lead an AI agent

Practise directing your agent on a realistic task, then check its work with tests, regression evidence and diff scope.

Why it exists

The interview changed.
The practice did not.

Live debugging, feature work in an unfamiliar repo, PR review, directing an AI tool under scrutiny. There was no free, structured way to rehearse any of it.

Puzzle platformsPatchground
A function signature and an input/output table.A codebase, a ticket from support, and a failing customer.
Solve it in a browser box, without your tools.Your editor, your terminal, your AI agent—or none.
Graded on output. A number tells you how you did.Verified by tests: what passed, whether your regression test really catches the bug, where your diff landed.
Hosted sandboxes and platform AI behind a subscription.Runs on your machine in Docker. Patchground itself sends nothing anywhere.
Closed problem bank.An open challenge format. Anyone can author one and prove it is sound.

Local-first

No account, server or subscription. Image builds may use the network; checks run on an internal Docker network with resource limits.

AI optional, never required

Use Claude Code, Codex, a local model, or nothing—in your own editor. Patchground needs no API key and has no built-in AI; what your assistant sees is up to you.

Verified or it does not ship

Every published challenge must prove, in its container, that the broken state fails and a reference fix passes—deterministically.

Challenges

Small collection. Real bugs.

Each one is a complete repository with a ticket, visible tests you can extend, hidden checks, and a reference fix—validated in Docker before it is published. A handful of excellent challenges beat fifty generated ones.

7 challenges in 1 pack · Python, Typescript · Debug, Refactor, Feature

Put a port between the order service and its storage and email — read the ticket

OrderService imports and constructs SQLite and SMTP adapters itself, so nothing can be swapped for SMS or for fast tests. Introduce ports, inject the adapters and keep behaviour identical.

patchground-examplesbuilt-in

Python / Refactor · architecture, ports-and-adapters, dependency-inversion, refactoringIntermediate · AI-generated
40 MIN

Add unsubscribe and once to the in-process event bus — read the ticket

A synchronous exact-topic event bus cannot take a subscription back or listen once. Add unsubscribe and once with precise snapshot, re-entrancy and error-collection behavior.

patchground-examplesbuilt-in

Typescript / Feature · events, reentrancy, error-handlingIntermediate · AI-generated
45 MIN

Difficulty and realism are not yet human-rated. Challenges marked AI-generated were drafted with a coding agent and validated like any other. built-in means shipped with the CLI and validated in this repository's CI; verified means a community pack whose every challenge passed pgnd validate in Patchground's CI on the date shown. Installing packs by name from the CLI is planned; today the CLI runs challenges from a local path or a pack URL. How to run one · Registry status

Packs

Collections, kept by their authors.

A pack is a git repository with a pack.yaml and one folder per challenge. It stays in its author's repo; Patchground only indexes it after re-validating every challenge in its own CI. Stars and forks come from the host.

1 pack · 0 community

patchground-examples

built-in

Curated examples shipped with the CLI; validated in this repository's CI on every push.

7 challengesDebug, Feature, Refactorvalidated in CI on every push

No community pack has been verified yet. Publish yours and it will appear here after the next registry run.

Install

From install
to first ticket.

Patchground is an early, working release. Install it straight from GitHub: the curated challenges ship with the CLI, so there is nothing else to download. A PyPI package will follow.

  • Python 3.12+ and uv
  • Git and a running Docker engine (or Podman)
  • macOS or Linux; Windows through WSL2
First-session guide README
get started
uv tool install git+https://github.com/franndeli/patchground
pgnd doctor
pgnd list --builtin
pgnd start pagination-last-page

Then open the printed workspace in your editor and run pgnd check as you go. Finish with pgnd submit.

Publish your pack

Know a bug worth learning from?
Publish it. No pull request.

Your challenges live in your own repository. Patchground discovers it, re-runs its validator on every challenge, and lists what passes. The validator is the gate: nothing else is reviewed by hand, and nothing that fails is listed.

  1. 01

    Author and validate locally

    pgnd new my-bug scaffolds a runnable challenge; pgnd validate my-bug proves the broken state fails, the reference passes, and the result is stable. Fix every step until it reads valid.

  2. 02

    Make it a pack

    Put each challenge folder at the root of a public repository next to a pack.yaml that names it. Declare a content_license and provenance in every challenge.yaml; keep services: [].

    spec_version: "0.1"
name: my-pack            # lowercase, hyphens; first publisher keeps the name
version: 0.1.0
description: Bugs from a payments team
challenges: [my-bug]
  3. 03

    Tag the repository

    Add the GitHub topic patchground-pack to the repository. On other hosts, add your https:// clone URL to registry/sources.yaml. That is the whole submission.

  4. 04

    Appear

    Every few hours the registry clones tagged repositories, runs the policy checks and pgnd validate on each challenge in Patchground's CI, and publishes the result. Passing packs show up in the catalog with a verified badge; anything else is explained on the status page with the failing step.

Planned: pgnd pack publish to validate and tag in one command, and pgnd pack add <name> to install by name from this index. Until then the steps above are the whole process. The registry never lists hidden checks, hints or reference solutions; only the public metadata you see in the catalog. Authoring guide

Built in the open

Improve the engine itself.

Patchground is Apache-2.0. Sharpen a ticket, extend the validator, add a language adapter, or report what confused you on your first session.

Contribute on GitHub Open an issue