The agent principal-agent problem(crawshaw.io) |
The agent principal-agent problem(crawshaw.io) |
It also speculates on the practices at Microsoft in its opaqueness but doesn't recognize the development methodology used for Linux despite its transparency or acknowledge how it differs from the pilloried code review that the audience is most familiar with—even though the kernel development project is the cradle for the VCS that everyone decided to use (but also to never use correctly).
Overall, there aren't really any insights here. The solution described just highlights that high-trust teams are composed of members that (are|can be) trusted by one another. But being on that kind of team is a luxury. The introduction of coding agents doesn't change anything. Take out the LLM-powered patch iteration, and it works for all the reasons it already worked before the advent of coding agents. It's a little like the obliviousness-to-privilege of folks who try to address the problems of people who experience poverty with advice that reduces down to the question, "Have you tried <thing that precludes someone who is poor>?"
It begins:
> In David Crawshaw’s recent post “The agent principal-agent problem” there’s a lot of insight beneath the headline “Code review is broken.” Worth reading carefully.
> Toward the end, David reflects on what he calls the old “cowboy” development culture at Microsoft in the 80s/90s. Not much has been written about that era, mostly because there was no social media, no laptops everywhere, no phones recording daily engineering life.
> A few thoughts from someone who lived it.
Conclusion:
> A lot of software quality did not come from pre-commit review gates.
> It came from tight teams, deep ownership, brutal integration pressure, system-wide stress, and developers who fully understood the machinery they were standing on.