🤓 Latest Submissions
InterLens
The Problem On distributed teams, Git prevents textual conflicts but not semantic ones. Two developers can each edit non-overlapping lines, both pass their own local tests, and both push clean commits — yet the moment those changes meet, the build breaks. A teammate renames a shared type field or an API route while you're mid-edit on a file that depends on it, and neither of you finds out until CI fails or a PR review catches it hours later. That feedback loop is slow, and by the time it fires, the fix means unwinding half a day of work built on the wrong assumption. The Solution InterLens is a VS Code extension that closes that loop to seconds, using nothing but the team's existing Git remote — no server, no new infrastructure to run or trust. Each developer's extension silently pushes a lightweight snapshot of their uncommitted working tree to a hidden per-user Git ref after every save. InterLens polls teammates' refs in the background, and the moment a change appears, it runs three local analysis engines in a worker process: a TypeScript/ts-morph engine that detects renamed or restructured shared types, an endpoint engine that catches frontend calls to backend routes that no longer exist, and a textual merge engine for genuinely overlapping edits. Findings surface immediately as red squiggles in the Problems panel, a live Teammates tree view, and a status bar indicator — while both changes are still uncommitted, not after a broken push. Target Users & Interaction InterLens is built for small-to-mid engineering teams working across a shared codebase — especially teams with a frontend/backend split or a shared-types package, where one person's rename silently breaks someone else's in-flight work. There is nothing to configure to get value: install the extension, and it activates automatically per workspace. A single `.interlens.yml` file declares the team's git-config-mapped emails, the type-check command to run, and which paths count as "shared." From there it's entirely passive — developers just keep working, and InterLens tells them when a collision is forming. What Makes It Different Most conflict tooling — static analyzers, CI type-checks, PR bots — operates on committed, pushed code, which is already too late to prevent the wasted work. InterLens is the only layer that operates on *uncommitted* state, comparing two developers' working trees before either has finished their thought. And because detection is purely local (Git plumbing + ts-morph + a diff), it works with zero added infrastructure and zero added latency — an LLM is invoked only on-demand, when a developer clicks "InterLens: Explain" for a plain-English breakdown of why a specific finding matters and how to resolve it, never as a dependency of detection itself. That separation means the safety-critical path is fast and deterministic, while the LLM adds insight on top, not risk underneath.
27 Sep 2026
