About us
Our cars are self-driving but we're still fixing race conditions and missing auth checks in our code, one at a time.
Any dev agent can oneshot a dazzling new feature, but whenever we look at the code inside the feature, there's something nasty in store for us. Some days it feels like the whole profession is turning into a game of creating guardrails for agents and prioritizing where to allocate our attention towards cleaning up their messes.
The velocity of code change is overwhelming our ability to keep our products high quality and our codebases sane.
Nocturnal software engineering
We love agentic software engineering. We try out every shiny new tool we find. We're doing in a week what used to take six months.
We think the next step is a "nocturnal phase" for software engineering. We should be able to write code all day, blazing through new ideas, and sophisticated agents should run overnight to fix the bugs and clean up the messes we leave behind.
Compute is cheap, human attention is expensive
Code is cheap now. Wielded properly, the newest models can execute complicated changes, even in large codebases. That means the limiting reagent in building software is human attention. It still takes time and focus for an engineer to ingest information, e.g. existing code, organizational context, and product requirements. These are all necessary before an engineer can articulate what they want in precise terms and exercise the results.
Nocturnal engineering trades compute for quality. Our codebase scans take hours, not minutes – far beyond what would be practical for a code review bot. But the result is that we can make more judicious use of engineers' attention, and that’s going to be the most important variable.
If nocturnal software engineering can be a little more proactive, it can be a lot more powerful. But that’s only going to work if we can make very good decisions about what’s worth a human’s attention. Nobody wants to inherit work from an overactive night shift.
Deserving attention
The most important thing to understand about this kind of product is: finding bugs is easy, picking bugs that matter is hard.
You can point your agent of choice at any codebase and find hundreds of bugs, probably thousands. The problem is that most of them are so unimportant they aren't even worth reading, let alone fixing.
Picking the defects in a codebase that deserve engineers' attention is hard. We do it by tracking which bugs get fixed fast, vs which don't, and optimizing against that signal. Detail's choices get better over time, both within any customer and across customers. If you optimize hard enough against this signal you'll learn something you might call "engineering judgement", automated for low-level work.
A lot of technical debt works this way. There are a zillion ways to make any codebase better, but most aren't worth doing. A self-driving codebase will make these kinds of decisions for us.
Our team
We're obsessed with software, and we think it can be much, much easier to make good software products.
Matt Gaunt-Seo
Matt has been building devtools for ten years, most recently at Augment, Sentry, and Google.
We would love to get to know you, especially if:
You like speed, and you're excited about the prospect of being on a small, high-performing team. You're comfortable making pragmatic choices with imperfect information and learning from contact with reality.
You want to build a company from the ground up. We intend for anyone we hire at this stage to play a major role in shaping everything we do: the product, the team we build, and the company's direction.
You're opinionated about devtools. You have favorite tools. You're the person who teaches your teammates about better ways to do things
We're backed by top-tier angels: Guillermo Rauch, Olivier Pomel, Aaron Levie, Christina Cacioppo, Arash Ferdowsi, Alex Graveley, Barry McCardel, Dev Ittycheria, Guy Podjarny, Zach Lloyd, and many other outstanding people.