PatchWitness

Hello Judges :) So I was lucky enough to go to the Dubai Codex Meetup which happened in July 2026. From there, I understood how bullish everyone is on open source and how much of a developer’s day happens inside GitHub.

I also kept thinking about the other side of the AI coding boom. AI has made it much easier to create code and submit pull requests, which is exciting, but maintainers now have more work to review. A pull request can be very long, the checks can be green, and the description can sound confident, while some small but important requirement from the original issue is still missing.

That is why I built PatchWitness.

You paste one public GitHub issue and one pull request from the same repository. PatchWitness extracts the issue’s acceptance criteria and maps each one to the evidence available in the pull request, such as changed files, tests, checks and written claims. It then gives each criterion one of four clear states:

• Supported
• Partial
• Unverified
• Contradicted

It also creates a short maintainer brief showing what deserves human attention and which files should be inspected first. PatchWitness never tells someone to merge a pull request. It is an evidence mapper, not an automated judge, because the final decision should always stay with the maintainer.

One decision I cared about a lot was honesty. PatchWitness does not run the submitted code or execute its tests, so it should never pretend that matching words prove real software behaviour. In live mode, a positive text match is shown only as context, not as proof. Live analysis therefore remains Unverified unless there is specific conflicting evidence, such as a directly related failed check, which can make it Contradicted. The Supported and Partial examples are demonstrated in the bundled synthetic sample where the evidence is deliberately known and controlled.

I wanted anyone, including the judges, to be able to test the main experience immediately. The sample works without a login, GitHub token, API key, database or rebuild. Live mode is also read-only and accepts only a public issue and pull request from the same GitHub repository. PatchWitness does not comment, approve, merge or make any change to GitHub.

I built the project in Codex using GPT-5.6 Sol Ultra as my development partner. GPT-5.6 is not secretly being called by the deployed app at runtime. Instead, I used it throughout the building process to challenge the product idea, inspect assumptions, improve the evidence model, generate adversarial cases and catch places where the wording could overclaim what the tool actually knows. I made the important product decisions myself, especially keeping the scope read-only, separating evidence from proof, limiting the live verdicts, and always keeping a human reviewer in control.

Technically, PatchWitness is built with React, TypeScript, Vite and a small Node server. Some of the hardest parts were turning an issue into criteria that remain understandable, connecting every displayed claim back to visible source evidence, handling GitHub URLs safely, and making the synthetic demo useful without making it misleading. I also added response limits, request cancellation, bounded concurrent analyses, a strict production content security policy and tests for the verdict rules.

The biggest thing I learned is that better AI review does not always mean making a stronger decision for the user. Sometimes it means showing uncertainty clearly, linking the evidence and helping the human make the decision faster.

I hope PatchWitness can become a useful small layer between the growing volume of AI-generated pull requests and the maintainers who still carry the responsibility of deciding what should enter their projects. Thank you for checking it out :)

Built With

• codex
• github-api
• gpt-5.6
• node.js
• react
• typescript
• vite