Polsinelli represents Tabnam, Inc. in $50 million Series B financing. Polsinelli congratulates its client Tabnam, Inc., d/b/a Greptile, on its $50 million Series B financing. Greptile is a San Francisco-based software company that develops artificial intelligence-powered code review and validation platforms for engineering teams. Greptile reviews and tests more than 1% of all PRs opened on GitHub every day and have become the code validator for thousands of engineering teams including Nvidia, Coinbase, Decagon and Vanta. The financing was led by Menlo Ventures, with participation from Jump Trading, Wing, Operator Collective, Benchmark, YC, Browder Capital, and Initialized, among others. The financing will fund Greptile's continued mission to automate code validation so even teams building mission-critical software can auto-merge complex changes. More information about the financing can be obtained from Greptile's announcement. The Polsinelli Venture Capital and Emerging Growth Companies team involved in the transaction included Prithvi Tanwar, Nicola DeVita, Cole Anthony and Aleks Fernandez Caballero. Resources. Related people. Related capabilities. Firm Highlights

We have raised a $50M Series B led by Menlo Ventures. The round values the company at $750M.

The code reviewer that got 2x faster and measures bugs in compliments. Greptile shipped v5 claiming it catches more bugs, with higher precision, and 2x faster. The speed claim is exact: 5:04 to 2:25 median review time is 2.097x, measured by A/B test across more than a million live pull requests, which is a better design than most launch posts manage. The other two claims rest on three published numbers and none of them measures bug detection. Greptile maintains a public, reproducible bug-detection benchmark. The v5 post does not use it. Links & resources. | Resource | Link | | Announcement | @dakshgup | | The post | Greptile v5 | | Their bug-detection benchmark | greptile.com/benchmarks | | Previous version | Greptile v4 and new pricing | | Related research | Models are worse at reviewing their own code | Greptile announced v5 on August 5 with a three-part claim: "it catches more bugs, with higher precision, and 2x faster (~2 minutes per review)." One of those three is verifiable from the post, checks out to two decimal places, and is genuinely impressive. The other two rest on three published numbers, and none of the three measures bugs. The speed claim is exact. The post gives before and after directly: Read those as minutes and seconds, which the tweet's "~2 minutes per review" confirms is the intended unit, and 5:04 is 304 seconds against 145. That is 2.097x, so "2x faster" is if anything understated. The word "seconds" in that sentence is a slip, since 5:04 seconds is not a duration, but the numbers behind it are consistent with the tweet and with each other. Worth saying how they got it, because the method is better than the industry norm: Live production data across more than a million pull requests, run as an A/B against the previous version, is a stronger design than almost anything you will see in a launch post. Most releases in this category ship with a static benchmark of a few dozen cases and no control. What the other two numbers actually measure. Here are the remaining metrics, both from the post: Their arithmetic is right. 0.342 divided by 0.266 is 1.2857, so 28.6% is exact, and the 52 to 66 move is 14 points or 26.9% in relative terms. Now read them against the claim they are supporting. The tweet says v5 "catches more bugs, with higher precision." Precision, in review tooling, is the share of flagged issues that are real. Neither of these numbers is that. Comments addressed counts how often an author acted on a comment. That is a reasonable proxy for precision and I think it is the strongest number in the post, but it moves for other reasons too: a comment can be addressed because it was clearer, better placed, or arrived before the author moved on, all of which v5 also changed. Positive replies per PR counts how often a human typed something like "nice catch." That measures sentiment. It is also worth noticing where the level sits rather than only the delta: 0.342 per pull request means that after the improvement, roughly one PR in three draws a positive reply. Neither number can rise or fall in a way that distinguishes "found more real bugs" from "annoyed people less." A false-positive rate would. So would a bug-catch count. The chart makes the substitution explicit. I did not have to infer any of that, because the figure at the top of this post is Greptile's own and it labels its three panels like this: (A) BUGS CAUGHT · POSITIVE REPLIES / PR (B) PRECISION · COMMENTS ADDRESSED EXACTLY (C) SPEED · MEDIAN REVIEW TIME Each panel names a claim and then names the number standing in for it. Panel A is headed bugs caught and plots positive replies per pull request. Panel B is headed precision and plots the share of comments an author addressed. Only panel C measures the thing in its own heading. I find this more disarming than annoying. A chart that quietly plotted sentiment under a "bugs caught" axis would be the bad version. This one prints the proxy next to the claim in the same weight of type, which means anybody reading the figure can see the substitution being made and decide what to do about it. It is a strange kind of honesty, and it is honesty. They have a bug-detection benchmark. It is not in this post. This is the part I did not expect. Greptile publishes a benchmark page that measures exactly the thing the tweet claims: It reports bug detection by severity, and the page says the pull requests "come from public, verifiable repositories, so you can inspect the sources and reproduce the runs on your own." That page is dated 2025 and describes five tools across 50 bugs. It predates v5, and the v5 announcement does not reference it or add a v5 column to it. So the company that maintains a public, reproducible bug-detection benchmark announced a bug-detection improvement without running it. I want to be fair about the tradeoff, because it is real and it cuts both ways. A million live pull requests is a far larger and more representative sample than 50 curated bugs, and A/B data from production tells you things a static benchmark never will. But the static benchmark is the one that can measure precision, and it is the one a reader can reproduce. The v5 evidence is bigger and less specific. The benchmark is smaller and answers the actual question. What changed architecturally. The mechanism is stated plainly and it explains the latency result: Because the agents run in parallel, wall-clock time falls, and because each one holds a single hypothesis, each can search deeper before giving up. That is a coherent story for both halves of the claim, and the halving of median review time is consistent with it. It also suggests why precision might genuinely improve without anyone measuring it: an agent scoped to one hypothesis has less room to pattern-match its way into a comment it cannot support. That is a plausible mechanism, not evidence, and I am flagging it as the former. What to do with this. If review latency is your bottleneck, this is a real and verified improvement. 304 seconds to 145 on median, measured in production against a control. If false positives are your bottleneck, the post does not answer you. The closest available signal is that 66% of comments now get addressed against 52% before, which is a proxy and a good one, and it is not a precision figure. And if you want the precision number, the benchmark that would produce it is already built, public and reproducible on their own site. Adding a v5 column to it is a smaller job than the rewrite they just shipped.