PATCHPILOT
An AI-assisted path from a GitHub issue to a validated patch, so the model sees a ranked slice of the repository rather than the whole tree.
Most of the time spent on a GitHub issue is not writing the fix — it is finding the right files, giving a model enough of the repository to be useful, and proving the change against the code as it actually was. Dumping the whole tree into a prompt is expensive and noisy; validating against a moving HEAD cannot tell a pre-existing failure from a regression.
A GitHub issue is diagnosed against a ranked slice of the repository, patched, validated on a commit-pinned snapshot, and opened as a pull request. Redis holds the analysis so a session can resume after a restart.
The issue lifecycle, end to end
PatchPilot runs a GitHub issue through Diagnosis → Patch → Validation → Review → Pull Request as one path rather than a set of disconnected tools. The visitor sees the same sequence the backend actually executes.
Deterministic code intelligence
Before a model sees anything, the repository is analysed for the files, declarations, types, callers, contracts and tests that actually matter to the issue. That work runs across Dart, TypeScript, JavaScript and Python so the prompt is assembled from structure rather than from a keyword grep.
Tiered context under a budget
A T0–T6 context-generation pipeline ranks defect sites, dependencies and tests, then packs them under a line and token budget. The model gets the densest useful slice, not the whole repository.
Commit-pinned validation
Patches are applied against a snapshot of the repository at a specific commit, then checked with analyzer diagnostics and automated tests. That is how a pre-existing failure is distinguished from a regression the patch introduced.
WHAT I CHOSE, AND WHAT IT COST.
Five decisions where the alternative was reasonable and I picked the other one. Each of these is a constraint the system now lives with.
Deterministic analysis, not dumping the repository
Sending the whole tree to a model is simpler and wastes the context window on files that have nothing to do with the issue. Ranking declarations, callers, contracts and tests first means the prompt is assembled from structure, at the cost of writing that analysis for every language the product claims to support.
Tiered T0–T6 packing, not unbounded context
An unbounded prompt would have been easier to ship and would degrade as repositories grow. A ranked budget forces a choice about what the model is allowed to see, and it means a defect site that ranks poorly can be missed.
Commit-pinned validation, not HEAD
Validating against whatever HEAD is now cannot tell a pre-existing analyser failure from one the patch introduced. Pinning the snapshot to a commit makes that distinction possible, and it means every run has to fetch and hold that snapshot rather than assuming the working tree is the truth.
Redis persistence, not in-memory sessions
Keeping analysis in process is cheaper until the backend restarts and the visitor's work disappears. Redis holds the run so OAuth restoration and anonymous-to-authenticated adoption can resume rather than start over.
S3 and CloudFront for the client, Railway for the API
Serving Flutter Web from the same box as FastAPI would have been one deploy. Splitting them means the static client sits on S3 behind CloudFront and the Python API runs on Railway, so each can scale and fail on its own, at the cost of two pipelines and a CORS seam.
The Flutter Web client is served from AWS S3 behind CloudFront. The Python/FastAPI backend runs on Railway. GitHub OAuth and a GitHub App cover sign-in and repository access. Redis holds analysis persistence and session restoration. The product is reachable at patchpilot.sanjaybuilds.online.