AI and Team Structure

Dan Lorec, the founder and CEO of Chainguard, had a stray comment one time to the effect that as an industry we’ve decided code review is critical to high quality code but some of the best, most elegant code was written indivdually and plopped into git with an “Initial commit” message and 20K LOC. To a certain extent what we are seeing there is selection on unobservables, we only see the massive initial commits that are good and the only people that can write these massive good intial commits are strong engineers. When they are working in this mode, it’s clear that they have a very clear vision of the thing and the things that make up the thing. Too often, even on mature products, those writing the code do not have a clear vision of the thing they are trying to build, even for incremental changes. When I say they know the thing, I mean they know it from both a product and technical perspective. They knowi it in it’s totalty, not just as a shadow on the wall.

When you look at Apple products, you see the outcome of this total vision. Not all their products land but it’s never for missing their vision (other than Apple maps).

Before AI agents, it was hard for the product to run too far ahead of the product vision because you could only ship so much code and when there was drift it would appear as inconsitiences not broken features that made no sense. The other limiting factor is that as you were implementing code, you had to make decisions for yourself where you didn’t have the product vision in your head. This constant decision making was a natural drag. AI subverts this mechnanism, AI will make decisions for you so that it can complete a task and you don’t even realize all the little decisions that you never made. This let’s the product drift much quicker and suddenly you have two fully built features that are incompatable.

As an individual you can use things like xxx’s grill me skill to force the agent to make you make your decisions.