Engineering velocity on steroids
I know there’s a common belief that moving fast means building the wrong thing faster. People say, “It’s better to go slow in the right direction than fast in the wrong one.”
In physics, every vector has a direction and a magnitude. The problem with that advice is that finding the right direction takes experimentation. You need speed to experiment. Understanding the right direction takes time, and having a bigger magnitude (speed) helps you learn faster.
To learn fast, you must do 2 things
- Ship fast
- Talk to customers a lot
The dopamine hit of talking to a customer, having an idea, and deploying it within hours is what helps drive velocity and a much higher learning rate.
I now believe that it’s critical to maximize the bandwidth between the people who have the problem, and the people who can actually solve it. The more distance there is, the more waste happens.
Code Review & PR Process
1. Architecture review (before any code)
The most critical review happens before writing code. For any significant task, a human validates that the architectural approach makes sense. This catches problems when they’re cheap to fix.
2. AI code reviews
We use multiple AI code reviewers (Greptile, Propel, Cubic, Graphite, etc.). Yes, there’s overlap, but that’s the point - we want maximal coverage.
Important issues get summarized and sent back to an LLM to fix. Once all AI comments are addressed, it goes to human review.
3. Human review
For any meaningful PR, we have a person look over it. Using the 2 steps above, the time to review has dropped a lot - it’s much easier to quickly find the important things.
Testing & Quality: the next frontier
We’ve shipped bugs - annoying ones, that frustrated customers (sometimes even regressing things that were already working). That’s the price we paid for moving so fast.
The focus should be: maintain velocity while reducing the bug rate.
Our approach is pretty simple: you’ve got to write a lot of tests. We have about 10,000 unit tests and a growing set of end-to-end integration tests. But we’ve under-invested in the testing loop compared to the generation loop, which we optimized.
The return to coding
I could not optimize the engineering team if I was not an engineer on the team itself. You cannot theoretically solve problems. You have to be in it to know what is problematic. Why is it so hard to ship? What are the blockers? Why does it take five hours to review PR?
My job became: find the most painful bottleneck and work on it with the team. Keep asking why, why, why, and then simplify one problem at a time. That’s what led us to move much faster than others in our space.
Building the Right Team (and hiring interns)
We’ve covered many optimizations, but my number 1 tip is to have the right people on the team.
If you have a bunch of engineers who are skeptical about using AI tools, it’s not going to work. You need people who are very bullish and are open to learning new things.
Here’s where I’m contrarian: I hire interns.
Interns and juniors are being overlooked right now in favor of senior folks with lots of experience. That’s an okay strategy, but I’m a risk taker. I’d rather hire for attitude and learning rate.
Software engineering is changing every year. There are newer patterns we’re discovering that are more optimal than the previous years. So we’re not always looking for classical depth, but for the rate of learning, the attitude, and infinite curiosity. Accumulated knowledge matters less when the field is changing this fast.
But it’s also strategic. Interns inject fresh ideas and new perspectives, they come in without assumptions about “how things should be done” - and in 2025, that’s often an advantage.