CHAPTERS
Greptile’s core product: AI that understands large codebases
Daksh Gupta explains that Greptile builds AI aimed at understanding entire, large codebases—not just generating snippets. Teams use it primarily for pull request review and for answering questions about how their code works.
- •AI is designed to understand large, real-world codebases
- •Primary use cases: PR review and codebase Q&A
- •Positioned as understanding-first rather than code-generation-first
Why code review is expensive—and where Greptile creates value
Greptile targets a major time sink for senior engineers: reviewing pull requests and scanning for issues. The product aims to shorten review cycles while catching bugs that humans commonly miss.
- •Senior engineers spend significant time on PR review
- •Human reviews are time-consuming and imperfect
- •Greptile reduces review time and increases bug detection
- •Frees humans for higher-level, creative/architectural work
Humans + AI in the loop: code review as mentorship and foresight
Customers generally don’t want fully autonomous code review; they want an AI assistant that handles the tedious parts while humans handle judgment. Daksh emphasizes that reviews are also about mentorship and aligning code with the future direction of the codebase.
- •Human involvement remains essential for most teams
- •Code review is more than bug-finding: mentorship and knowledge sharing
- •Senior engineers provide “future-state” architectural intuition AI can’t match (yet)
- •Greptile focuses on meticulous mistake-finding; humans focus on big-picture
Scale and results: millions of lines reviewed and 20,000 bugs per week
Daksh shares usage and impact metrics, highlighting the tool’s scale and the volume of bugs it surfaces. The value is framed as catching issues that would otherwise slip into production and cause downstream problems.
- •Typical weekly volume: ~5–8 million lines reviewed
- •Growth is described as rapid
- •Reported result: ~20,000 bugs found in a week across customer PRs
- •Emphasis on preventing later-stage failures and rework
Why now: LLMs are currently better at reading code than writing it
Greptile’s timing is tied to the maturity of language models, which the team observed early (since around the DaVinci-2 era). Daksh argues LLMs’ strongest near-term leverage is interpreting and analyzing code, making review and bug detection a natural fit.
- •Team began experimenting with LLMs ~3–4 years ago
- •LLMs often understand/read code better than natural language (in their experience)
- •Models are still better at reading code than generating it reliably
- •Strategy: productize LLMs’ best current capability for maximum business value
From codebase Q&A to bug detection as the “most useful” outcome
The team initially built codebase question-answering by loading a repository and allowing queries like “How does XYZ work?”. They realized that once a model can understand a codebase, the highest-value application is systematically finding bugs before code ships.
- •Started with codebase Q&A over entire repositories
- •Core technical challenge: limited context windows vs. huge codebases
- •Insight: understanding enables proactive bug prevention
- •Shifted focus toward bug detection as the enduring pain point
Origin story: struggling with a large front-end codebase and onboarding pain
Greptile’s idea emerged from a practical problem in college projects: a teammate owned the entire front end and then left, leaving the rest unable to work effectively. That experience mirrored industry realities where engineering difficulty often stems from navigating complex, sprawling codebases.
- •Catalyst: key contributor left after writing the entire frontend
- •Founders couldn’t effectively operate in an unfamiliar large codebase
- •On-the-job experience reinforced that codebase complexity drives engineering difficulty
- •Motivation: make large codebases understandable despite model context limits
Bugs are the persistent problem—and software resilience matters more every year
Daksh explains a key product thesis: codebase unfamiliarity is temporary, but bug-finding remains constant. He connects this to rising societal dependence on software (grids, supply chains), raising the stakes for resilience and correctness.
- •Codebase knowledge gap shrinks with tenure; bug-finding persists
- •Bug detection benefits directly from deep codebase understanding
- •Software now underpins critical infrastructure
- •Resilience and reliability become increasingly important over time
What developers think about AI tools: adoption varies wildly
Daksh notes he was surprised by the spread in developer attitudes toward AI. Some highly capable engineers reject AI tools outright, while others enthusiastically adopt them; Greptile evaluates customer fit partly based on conviction that AI can improve the business.
- •Wide variance in willingness to adopt AI developer tools
- •Resistance may stem from discomfort about AI changing job nature
- •Strong adopters treat AI as a leveraged tool
- •Customer fit includes assessing AI conviction and readiness
Not “just another AI coding tool”: distinguishing review/analysis from codegen
Early on, Greptile was often lumped into a generic “AI coding” bucket. Over time, as organizations gained experience with different AI tools, they became better at distinguishing between code generation and augmenting specific workflows like review and analysis.
- •Early market confusion grouped many AI-in-code tools together
- •Greptile is oriented around review/analysis rather than code generation
- •As adoption grows, leaders differentiate where AI can augment their systems
- •Category clarity improves with hands-on usage
Founder advice: ignore distractions and build what customers love
Daksh’s main advice is to stay focused because distractions are constant and seductive. He recommends prioritizing building a product customers truly need and love over the many secondary activities that feel important but matter less.
- •Distraction is inevitable even when you anticipate it
- •Focus on customer love/need as the primary metric
- •Many plausible priorities are less important than core product work
- •Consistent execution on fundamentals can take you far
How to try Greptile: quick signup and GitHub connection
The conversation closes with a simple call to action: Greptile is free to try, with a fast onboarding flow. Users can sign up on the website and connect GitHub to start using it quickly.
- •Free to try
- •Sign up at greptile.com
- •Onboarding takes under a minute (per Daksh)
- •Connect GitHub and begin reviewing/using the tool
