Daksh Gupta

Daksh Gupta is the co-founder and CEO of Greptile, where he builds AI agents that review and validate software changes using context from the surrounding codebase. His work addresses a growing problem in software development: coding agents can produce changes faster than engineering teams can establish whether those changes are safe to deploy.

From unfamiliar code to code review

Gupta studied computer science at Georgia Tech and interned at Amazon before becoming a founder. His partnership with Soohoon Choi began at Georgia Tech, where they participated in CREATE-X and developed Tabnam, an AI shopping assistant. Together with Vaishant Kameswaran, they turned toward software development and founded Greptile in 2023.

The new direction grew out of an immediate frustration. A collaborator who had written their earlier startup’s frontend did not join full-time after college, leaving the founders with unfamiliar, hurriedly written code. Gupta wanted an AI system that could learn the codebase, answer questions about it, and help diagnose problems. He and his co-founders moved to San Francisco, built an initial version during a weekend hackathon, and began iterating with users.

Greptile joined Y Combinator’s Winter 2024 batch. Its early product combined a codebase question-answering interface with an API for documentation, debugging, and custom review tools. Code review became its central application, giving the company a recurring place in the development process: the pull request, where a proposed change is examined before it joins the main codebase. In September 2025, Gupta announced a $25 million Series A led by Benchmark to support an independent validation layer for software.

Making review useful and investigative

Gupta’s technical work connects finding relevant code, earning developers’ attention, and investigating how a change affects an application.

• Codebase understanding: His work on semantic code search explains why embedding whole files can retrieve text that resembles a question without locating the relevant behavior. He advocates natural-language descriptions of code and smaller, function-level units that reduce unrelated material. The goal is to give a model the information it needs to reason correctly without burying it in noise.

• Useful review over comment volume: Early Greptile users complained that its reviewer produced so many comments that they began ignoring them. Gupta’s team measured whether developers addressed comments, then experimented with prompting and model-based severity scoring. Their eventual feedback-based filtering approach compared new comments with clusters of previously rated comments for each team. This let the reviewer learn which recurring suggestions that team considered unhelpful. A technically correct observation still has to earn the developer’s attention.

• Independent auditing: Gupta argues that code generation and review should have separate incentives. A reviewer built alongside a generator may share its blind spots, while the company behind both has reasons to make its generated code look good. His case for an independent auditor emphasizes an adversarial check at the pull-request stage, regardless of which person or tool produced the change.

• Following a change beyond the diff: Greptile moved from a fixed sequence of retrieval and review steps toward agents that investigate recursively. Gupta’s description of the v3 architecture uses an invoice example: changing a discount calculation can leave an older formula inside a nested helper used for monthly statements. Finding the mismatch requires following calls into unchanged files and examining history. This is what he means by the blast radius of a change: affected behavior beyond the lines being edited.

• Runtime validation: Greptile’s TREX execution layer, introduced in June 2026, extends the investigation into running software. It executes relevant code in a sandbox and attaches logs, screenshots, API traces, scripts, or video to its findings. An endpoint that fails on an actual request or a page that renders incorrectly may escape a careful reading of the diff. Execution gives engineers and downstream agents concrete evidence to inspect.

Validation as coding agents scale

Gupta’s thinking about autonomous coding changed through examining pull requests from established commercial codebases. Initially skeptical that end-to-end agents could make useful contributions there, he compared likely agent-written and human-written changes using revert rates, comparisons involving pull-request size, flagged issue severity, and review rounds before merge. He reported broadly similar outcomes in Greptile’s dataset, although the patterns of failure differed, including SQL injection and authentication bypass. His analysis of agent-written code infers agent involvement from author fields, co-author footers, and branch-name prefixes. These are observational comparisons within Greptile’s data, rather than proof that agents perform equally well on every task.

As coding agents increase the volume of proposed changes, Gupta frames validation around three questions: does a change break behavior users rely on, make future failures more likely, or fulfill its author’s intent? His vision for automating code validation brings codebase knowledge, execution, security checks, and feedback into that task. The ambition is to let engineering teams safely deploy more of the software agents produce, while giving people more time to decide what that software should do.