CHAPTERS
- 0:00 – 0:17
Greptile’s core product: AI that understands large codebases
Brad introduces Daksh and asks what Greptile is. Daksh explains that Greptile is built to understand large codebases and is used for pull request review and codebase Q&A.
- •Greptile focuses on understanding entire codebases (not just single files)
- •Primary use cases: reviewing pull requests and answering codebase questions
- •Positioned as a tool for software teams working in complex repositories
- 0:17 – 0:50
Why code review is painful—and where Greptile creates ROI
Daksh describes why code review is a high-cost activity, especially for senior engineers. Greptile reduces review cycle time and catches issues that humans often miss.
- •Senior engineers spend substantial time on PR/code review
- •Human review is both time-consuming and imperfect
- •Greptile speeds up review turnaround
- •Finds more bugs than a purely human-driven process
- 0:50 – 1:35
Humans + AI in the loop: what should stay human
Brad asks whether customers want fully automated review. Daksh argues that humans must remain involved because code review also serves mentorship and long-term architectural intent.
- •Customers generally agree a human should remain in the process
- •Code review is more than bug-finding: mentorship and team learning
- •Senior engineers have forward-looking judgment AI can’t fully replicate
- •AI should handle tedious detail-checking; humans focus on bigger-picture concerns
- 1:35 – 2:00
Scale and impact: millions of lines reviewed and 20,000 bugs/week
Daksh shares current usage metrics to quantify traction and value. Greptile reviews millions of lines weekly and identifies tens of thousands of bugs that might otherwise ship.
- •Weekly volume: ~5–8 million lines of code reviewed
- •Growth is accelerating
- •Reported impact: ~20,000 bugs found in a week across customer PRs
- •Value framed as catching issues that would slip through and become later problems
- 2:00 – 2:42
Why now: LLMs are better at reading code than writing it
Brad asks why this is the right moment for Greptile. Daksh explains their early experiments with LLMs and the observation that models are especially strong at understanding code, making “reading” use cases compelling.
- •Team began experimenting around the DaVinci-2 era
- •LLMs showed unusually strong code understanding vs natural language
- •Models (still) often read code better than they write it
- •Strategy: productize LLMs’ strongest current capability for maximal value
- 2:42 – 3:13
Evolution from codebase Q&A to bug detection and prevention
Daksh outlines how Greptile started as codebase Q&A and shifted to bug detection. Once you can teach an LLM to understand a codebase, the highest-value outcome is preventing faulty code from landing.
- •Initial product direction: “How does XYZ work?” codebase Q&A
- •Core technical challenge: limited context windows vs large repositories
- •Insight: deeper understanding enables higher-leverage tasks
- •Pivot/up-level: use understanding to find bugs and prevent bad changes from merging
- 3:13 – 3:21
Deeper motivation: software resilience as critical infrastructure
Daksh broadens the stakes beyond developer convenience. He argues software now underpins grids and supply chains, so improving resilience and reducing defects grows more important every year.
- •Software now controls critical systems (grid, supply chains, etc.)
- •System resilience depends on the weakest software component
- •Bug prevention is framed as a societal and economic necessity
- •Importance of software reliability increases over time
- 3:21 – 3:54
Origin story: the pain of inheriting a codebase you don’t understand
Brad asks how they arrived at the idea. Daksh recounts a college project where a teammate authored the front-end and left, leaving the team unable to work effectively—mirroring issues seen in industry.
- •Catalyst: losing a team member who built an entire front end
- •Realized how hard it is to maintain/extend unfamiliar code
- •Industry parallel: most engineering difficulty comes from codebase complexity
- •Sparked the goal of making codebases easier to navigate and reason about
- 3:54 – 4:20
The key realization: “not knowing the codebase” is temporary; bugs are forever
Daksh explains the strategic shift: onboarding pain fades as engineers learn the system, but bug-finding remains a persistent, recurring challenge. Their earlier work on code understanding became the foundation for durable value in review.
- •Codebase unfamiliarity decreases with tenure and exposure
- •Bug detection remains a constant need throughout a product’s life
- •Codebase understanding is a prerequisite to catching subtle issues
- •This insight guided the focus on code review/bug prevention as the enduring wedge
- 4:20 – 5:06
What developers really think: wide variance in AI adoption
Brad asks what’s been surprising about AI in developer tools. Daksh notes a large spectrum: some strong engineers resist AI entirely, while others fully embrace it—so fit depends on customer conviction.
- •Developer sentiment ranges from strongly anti-AI to highly pro-AI
- •Resistance may include discomfort about AI changing job nature
- •Adoption readiness becomes a qualification signal for customers
- •Teams with high conviction in AI benefits tend to be better fits
- 5:06 – 5:33
Not “just another coding tool”: clarifying Greptile vs codegen
Brad asks if Greptile gets lumped with AI coding tools. Daksh describes early confusion in the market, which has improved as engineering leaders gain experience differentiating augmentation areas (review vs generation).
- •Early market confusion: all “AI for code” looked the same
- •Greptile’s focus: code review/understanding, not code generation
- •Over time, users gained higher fidelity about tool categories
- •Better differentiation as teams learn what parts of workflow can be augmented
- 5:33 – 6:16
Founder advice: avoid distractions and build what customers love
Brad closes by asking for startup advice. Daksh emphasizes relentless focus—ignoring tempting but non-core distractions and prioritizing building something customers need and love.
- •Distractions are abundant and hard to avoid even when anticipated
- •Primary objective: build products customers love, need, and want
- •Many “plausible priorities” are less important than core product work
- •Sustained focus on fundamentals can carry teams surprisingly far
- 6:16 – 6:29
How to try Greptile: fast signup and GitHub connection
Brad asks how viewers can learn more. Daksh says Greptile is free to try, quick to sign up for, and integrates via connecting GitHub.
- •Free trial available
- •Sign-up takes under a minute
- •Connect GitHub to start using it
- •Closing thanks and wrap-up
