India has nearly six million developers, a lot of them working in fintech, healthtech, defense, or anywhere else proprietary code isn’t allowed to leave company infrastructure. That quietly rules out almost every good AI code review tool, because Copilot, Cursor, and CodeRabbit all assume your diff can be uploaded to the cloud. For that entire slice of developers, “AI code review” has meant “no code review.”
So the three of us - Hardik, Vatsal, and Dhruv - asked a simple question going into the Snapdragon Multiverse Hackathon: what if the model just ran on the same machine that owns the code? Snapdragon NPUs are fast enough now that this isn’t a compromise anymore. That became DevMesh: an AI code review agent that runs entirely on-device on a Snapdragon X Elite NPU, reviews your commits the moment you make them, and never sends a single line of code anywhere.
We finished as a top-8 finalist out of the 50 teams who made it to the onsite build, and when the scores were read out, we placed runner-up for the whole hackathon. This is the story of how we got there, and the parts that almost didn’t work.
The pitch was simple to say and much harder to build:
Nothing about that plan sounds exotic. What made it hard was that almost every piece of it had to be re-learned once we got real hardware in front of us.
How a commit turns into a reviewed, triaged, reported finding - entirely on device.
Before the onsite build, we assumed we’d be picking whatever Python and JS tooling felt comfortable. Orientation reset that in about five minutes: everything had to run on ARM64. Not “mostly.” The dev machine was a Snapdragon X Elite Surface laptop running Windows on ARM, and any dependency that assumed x86 or CUDA was dead on arrival. That single constraint quietly decided a lot of our stack later on - most notably how we generated the final PDF report.
Our original plan was Phi-4-Mini-Instruct strong coding benchmarks, a family we’d already been prompt-tuning against. But once we had real hardware to test on, that plan fell apart: Phi-4-Mini could only reach the community llama.cpp runtime on this device, not the native QNN/NPU path, and its usable context capped out at 512 tokens in NPU mode. Not enough room for a real diff plus our review instructions.
Qwen3–4B-Instruct-2507 turned out to be the actual answer - native QAIRT runtime, a full 4096-token context, and once we benchmarked it directly on the hardware: roughly 1,300 tokens/sec prefill and 23 tokens/sec decode. We swapped the primary model less than a day before the build phase started, on the strength of a benchmark we ran ourselves rather than trusting the spec sheet.
Most AI review tools treat a developer’s “this isn’t a real issue” as the end of the conversation. We didn’t want that. When you mark a finding as a false positive on the mobile app, you have to actually explain why a one-word dismissal gets rejected before it ever reaches the model. Then, when you generate the report, DevMesh sends your reasoning and the original diff back to the model and asks it to reconsider: maintain the finding, withdraw it, or land somewhere in between with a smaller residual concern.
Watching the model push back on our own dismissals during testing - politely disagreeing, or conceding a real point while still flagging a smaller one is what convinced us this was worth building around. It turns the false-positive button from a silent trapdoor into an actual conversation, and every exchange shows up in the final PDF next to the developer’s own comment. If you ask us why judges responded to this project, this is almost certainly the part that did it - it’s the moment the tool stops feeling like a linter and starts feeling like a second engineer who’s actually listening.
A hackathon build is really just a sequence of things quietly failing until you notice.
The REPL that wouldn’t talk to Windows. Our first idea for running inference was a persistent session, so we weren’t paying model-load cost on every call. On Windows it failed immediately - the interactive REPL needed a real console handle, and a plain subprocess pipe doesn’t give it one. We dropped the persistent session and moved to one-shot calls per hunk instead. Slower per call, but it actually worked.
The prompt file that vanished mid-flight. Early runs would sit at “ model…” for twenty seconds and then exit with nothing - no error, no output. The cause was a race: we wrote the prompt to a fresh temp file per call and deleted it right after our subprocess returned. If the runtime opened that file lazily, after its own internal retry loop, the file could already be gone. The fix was almost embarrassingly simple: write to one fixed path, overwrite it every call, never delete it. The race disappeared completely.
Two processes, one truth. This one was the scariest because it looked like flaky Wi-Fi at first. Sometimes the mobile app showed a stale or null commit hash. The real cause: if a second review process ever started while the first was still alive, it would silently fail to bind the WebSocket port in a background thread while the rest of it kept running normally - so you’d get two independent, isolated sessions, and the phone would connect to whichever one happened to win the race. The fix was a pre-flight port check that fails loudly, in the main thread, before anything else happens.
A parser built for a model that doesn’t quite follow instructions. We asked for one exact output format, and real model output drifted from it in small, very human ways - markdown bold around severity labels, numbered-list prefixes, occasionally a real finding followed by a contradicting “no issues found” on the next line. Rather than fight the model into perfect compliance, we spent the time making the parser tolerant instead. A couple of smaller gaps - filenames with spaces breaking the matching regex, and the model occasionally writing out severities in ways we hadn’t accounted for stayed on our known-issues list going into judging. We’d rather be upfront about that than pretend the pipeline was flawless.
By the end of the build window we had, running fully on-NPU on real hardware:
Benchmark on the real device before you commit to a model. Our spec-sheet favorite lost to a benchmark we ran ourselves, and that decision mattered more than almost anything else we did.
Write your parser for the model you actually have, not the one you wish you had. Every LLM drifts from your requested format in small, predictable ways - a slightly more forgiving parser gets you further than a stricter prompt ever will.
When something behaves strangely under load, look for state that two things can touch at once before you look anywhere else. Our worst bug wasn’t a logic error - it was two processes quietly disagreeing about reality.
And don’t let “it’s a hackathon” talk you out of the one feature that makes the whole thing feel alive. For us that was the model defending or withdrawing its own findings.
Twenty-four hours earlier, DevMesh existed only as a proposal document. By the end of the weekend it was running entirely offline on Snapdragon silicon, reviewing real code in real time, without a single line ever leaving the machine. We finished as a top-8 finalist out of 50 teams, and walked away runner-up for the whole hackathon. We came for the hackathon. We left convinced this is genuinely how private AI tooling should work.
Paul Torres (Senior Director, Qualcomm) was one of the jury, and we ended up talking to him twice.
The first time was during the presentation that decided who made the top 8. He seemed genuinely struck by the problem we were solving, not just the build - the idea that a huge chunk of developers are locked out of AI code review entirely because of where their code is allowed to go. That conversation is a big part of why we made the cut.
The second time was after our final top-8 presentation. He told us we had an impressive solution and that he thought we had a real shot at winning.
What stuck with us most, though, was what he said at the very end: he loved the idea, and thought it was worth developing further - that DevMesh had the shape of something that could become an actual product, not just a hackathon demo. That’s stayed with us more than the placement did.
Watch the demo: DevMesh live demo Explore the code: github.com/hardikjp7/DevMesh - full architecture, the known issues we didn’t hide, and everything described above, warts and all.
DevMesh: The AI Code Reviewer That Never Touches the Cloud was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.