Yazhiniyan M S@Yazhiniya

Problem: Code review is line-based. A reviewer sees the lines that changed, but not what those lines affect. A four-line rename of an API field can look harmless in a diff while it quietly breaks a frontend component, a contract test, and the published API docs, none of which appear in the pull request. These "untouched but affected" files are where regressions slip through, and finding them by hand means searching the whole repository for every changed name. Solution: DiffLens reviews a pull request by intent. You open a repository (choose a folder, drop a .zip, or use the built-in sample) and DiffLens picks the branches to compare, parses the diff, extracts the changed symbols, routes and fields, and traces them across the repository. It then answers the reviewer's real question first: a merge verdict such as "Not ready to merge - 3 high-risk findings need to be resolved first." Below the verdict, findings are sorted by risk. Each one explains why it matters and exactly where, with file and line evidence: a consumer still reading a removed field, a contract test that will fail, docs that describe the old response. A blast-radius map shows every file the change reaches; selecting a file filters the findings to it. Reviewers dismiss what does not apply (with undo), preview a suggested fix as a diff before applying it, and copy a ready-to-paste review summary into the pull request. Target users: developers and reviewers on teams that ship APIs or shared code, especially when reviewing changes to code they did not write. What makes it creative: DiffLens separates facts from inference. A deterministic core (diff parser, symbol extractor, context engine, rule-based risk model) produces the evidence, and the AI layer interprets it. Every finding is traceable to real files, and each one is labeled as observed in the diff or inferred. The AI provider is pluggable (IBM Bob adapter, Ollama, Hugging Face, or a built-in offline analyzer) behind one interface and one validated response schema. Suggested fixes are guarded: they are checked against file snapshots, so a stale patch is rejected, and secret files and path traversal are blocked. Efficiency: The static build runs entirely in the browser with no server and no upload; a full review of the demo change takes about a third of a second. Every review can also be exported as a Markdown evidence trail (change intent, impact analysis, missing tests, reviewer questions) so the reasoning is auditable.

💻 Online Hackathon | ⏳ Build: 48 hours | 📅 September 25–27, 2026 The official IBM Bob 2.0 hackathon. Build what's next in AI-assisted development, alongside the developers and experts shaping it. ⭐ Get help from experts throughout the event 🤝 Join a team or build solo 💰 Prize pool: $12,000 🧑🏻‍💻 Register before the Kick-Off Stream to start building with Bob