IMerge

Inspiration

Pull requests are usually reviewed through several disconnected tools. Code review explains what changed, CI reports what passed or failed, coverage tools suggest what was exercised, and project-management systems show whether the review is delayed.

What is often missing is a single answer to a more practical question:

What is likely to happen because of this change, and what should the team do next?

A pull request can affect files that were not edited directly, trigger tests in distant packages, increase operational risk, or become delayed because of review and CI bottlenecks. Existing tools often address these consequences separately.

IMerge was inspired by the idea that a repository and its engineering workflow can be treated as one evolving system. A pull request is an intervention into that system, and the product estimates its likely technical and workflow Impacts before merge.

What it does

Users can analyze a change through:

A public GitHub pull-request URL
A Git repository bundle containing history
A project archive accompanied by a .diff or .patch
A prepared guided example with known synthetic ground truth

The application produces five main outputs:

Impact : files, modules, and dependency paths that may be affected
Tests : structurally relevant tests that should run before merge
Risk : a transparent heuristic risk estimate with factor contributions
Workflow : supported estimates for review or CI bottlenecks
Next action : scenario comparisons such as running a test subset, requesting another reviewer, splitting the PR, or rerunning a failed check

The interface separates:

Observed facts retrieved or derived from the repository
Predicted consequences produced by the analysis engine
Suggested actions produced through scenario comparison

Each result includes evidence, confidence, assumptions, provenance, and unavailable information.

How it works

The system first converts every input type into a common representation of:

Repository structure
Changed files and diff hunks
Package and workspace boundaries
Imports and dependency relationships
Test files and test configuration
Git history, when available
Pull-request, review, check, and workflow information, when available

The current analysis engine uses transparent deterministic and statistical baselines.

Impact prediction traverses dependency relationships outward from changed files. Test selection ranks tests using direct mappings, imports, package relationships, path proximity, test type, and safety rules. Risk estimation combines factors such as change size, critical modules, dependency fan-out, cross-package scope, migrations, test discoverability, CI state, and review state.

A simplified objective for comparing candidate actions is:

[ J(a) = w_r R(a) + w_t T(a) + w_c C(a) - w_q Q(a) ]

where:

(R(a)) is estimated engineering risk after action (a)
(T(a)) is estimated time-to-green
(C(a)) is CI or coordination cost
(Q(a)) is confidence in the scenario
(w_r, w_t, w_c, w_q) are documented weights

The system selects the action with the lowest combined estimated cost while displaying the assumptions behind the comparison.

GPT-5.6 is used as an evidence-grounded explanation layer. It receives a bounded evidence pack and explains why the deterministic analysis produced its conclusions. It does not independently generate or replace the numerical scores.

How we built it

The product uses:

Next.js and TypeScript for the web application
FastAPI and Python for ingestion and consequence analysis
GitHub APIs for public pull-request and repository data
Git inspection and secure archive processing for user-provided projects
Deterministic repository-graph analysis for impact prediction
Structural test discovery and ranking for test recommendations
Transparent risk and workflow baselines
Scenario simulation for comparing possible next actions
OpenAI Responses API with GPT-5.6 for grounded explanations
Vercel for the public deployment

The application never installs project dependencies or executes submitted repository code. Uploaded files are inspected as bounded text and metadata using temporary storage and strict extraction limits.

Use of ChatGPT and Codex

The project was developed with extensive assistance from ChatGPT GPT-5.6 Sol and Codex with GPT-5.6.

ChatGPT GPT-5.6 Sol was used for:

Initial market and prior-art research
Testing the usability and novelty thesis
Product positioning
Architecture planning
Critical analysis of weak points
Security and deployment requirements
UX review
Prompt orchestration
Submission planning

Codex with GPT-5.6 was used for most of the implementation work, including:

Project scaffolding
Typed domain schemas
FastAPI endpoints
Fixture generation
Repository and dependency analysis
Test ranking
Risk and workflow baselines
Scenario simulation
Frontend implementation
GitHub integration
Upload processing
Security checks
Automated testing
Debugging
Vercel deployment preparation
Documentation

The human builder remained in the loop throughout the process by selecting the direction, transferring implementation goals, testing the application, evaluating trade-offs, identifying usability problems, redirecting development, and approving the final submission.

Challenges

Turning a research concept into a usable product

The original concept was a learned latent twin of repository and workflow state. Building a reliable trained model would require significantly more historical data and evaluation than was available during Builder Week.

The solution was to preserve the long-term architecture while first implementing transparent baselines behind replaceable interfaces. This made the product functional and testable without pretending that an unvalidated research model was production-ready.

Avoiding a fixture-only demonstration

The first version worked only with prepared repositories. Although useful for demonstrating the interface, it risked appearing static.

We added support for previously unseen public GitHub pull requests, Git bundles, and project archives with diffs so judges can analyze their own code changes.

Producing useful output from incomplete repositories

Many repositories do not expose coverage data, CI history, reviewer history, or test durations. The system therefore had to distinguish between:

Available evidence
Structural inference
Weak historical baselines
Unsupported predictions

Missing information lowers confidence or produces an unavailable state rather than being treated as zero risk.

Test recommendations without executing code

Running unknown repository code would create major security and operational risks. Instead, the product discovers and ranks tests using repository structure, file naming, imports, package configuration, and test-runner configuration.

The recommendations are clearly labelled as structural when real coverage evidence is unavailable.

Serverless file processing

Supporting user uploads on a serverless platform required strict limits on request size, extracted data, file count, execution time, and temporary storage. The hosted version supports small projects, while public GitHub analysis provides the most reliable judge-testing path.

Keeping AI outputs trustworthy

A generic LLM explanation could easily introduce unsupported claims. GPT-5.6 was therefore placed after the deterministic prediction engine. It explains a structured evidence pack and must preserve uncertainty rather than invent new analysis.

What we learned

We learned that developer trust depends less on producing another AI score and more on showing:

What evidence was observed
What was inferred
What remains unknown
How confidence was calculated
Why an action was recommended

We also learned that repository analysis and workflow analysis should not be treated as separate product experiences. A technically risky PR may still be easy to review, while a small change may become delayed because of ownership, CI, or reviewer availability.

Finally, we learned that the most credible path toward a learned repository twin is not simply a larger model. It is better labels, repository-specific calibration, stronger test and coverage evidence, and explicit evaluation against historical changes.

What is next

The current release uses transparent deterministic and statistical baselines. The next research stage is a compact, action-conditioned latent model that learns a shared representation of repository and workflow state.

The planned progression is: