Korva is a scroll of the internet’s best ideas.

Check what good looks like into the repo
Review as a bottleneck
Code review became a big bottleneck for human reviewers, and Claude Code Review did not exist last year. Areas that need deep subject matter expertise still get human reviewers. Elsewhere, the more that can be automated by checking in the framework, the better.
Specs in the repo
Specs checked into the repo, kept up to date with the code frequently, let a review confirm the code still matches what was set up. Content design, for example, was recently updated to include a scale.
Test-driven development
Test-driven development fits the same pattern. Writing the test first, watching it fail, then writing the code was a tax, like eating the broccoli first. Now the model generates the test, which made the first bug fix on Claude Code a chance to revisit the principle. Ideas that have been around a long time may be more efficient now that models do more of the work.
Where did test-driven development come from?
Kent Beck popularized test-driven development in the late 1990s as part of Extreme Programming, and described it in his 2002 book Test-Driven Development: By Example. The cycle is called red, green, refactor: write a failing test, make it pass, then clean up the code. Beck has said he rediscovered the technique from older programming practice. It became a standard topic in software engineering courses.
Why must a new test fail first?
A test that has never failed might not be testing anything. Watching it fail proves that the check can detect the problem it was written for. After the code is written, the same test passing shows the change did what was intended. Skipping the failing step leaves the possibility of a test that always passes.
Why does a written spec help automated review?
A reviewer, human or automated, needs something to compare the code against. A spec checked into the repository gives a fixed reference that travels with the code and changes in the same commit. Version control records who changed the spec and when. Mismatches between code and spec are then visible as differences in the diff.
More from Lenny's Podcast: Product | Growth | Career
