Iâve said this before and Iâll say it again, I never let one AI agent build a feature and check its own work. I have it build the MVP fast, then I bring in fresh agents whose only job is to tear it apart and hunt for bugs. The builder is too deep in it, and too eager to ship, to also be the critic.
Thatâs always been my workflow, even before the age of AI. But itâs the same mistake I keep seeing eng leaders make at team scale: they hand the shiny, might-not-work AI bets to the same people already on the hook for keeping production alive.
Boris Cherny (who leads Claude Code) put his finger on why. Looking at his own team, he saw five archetypes: prototypers who churn out ideas most of which never ship, builders, sweepers, growers, and maintainers who keep a mature system secure and reliable as it scales.
The prototyper and the maintainer are opposite wiring. One is at their best failing fast on things that might not pan out. The other is at their best making sure absolutely nothing breaks. Ask one person to be both and you get neither, because the âkeep it aliveâ work is always more urgent, so it quietly eats every hour the exploring needed. Itâs like asking the line cook in the middle of the dinner rush to also design next seasonâs menu. Thatâs a no-no.
So donât hand your big bet to whoeverâs already carrying the pager. Give it to someone whose actual job, this month, is to explore. Even if thatâs just one person, or a two-person pod inside the same team, with its own goals and permission to fail. Protect the explorer from the maintenance, and the maintenance from the explorer. Itâs time we rethink the way we structure engineering teams.
Youâre not hiring different people. Youâre pointing the right people at the right mode.
So which is it on your team: does your exploration work have someone who owns exploring it, or is it a side quest for whoeverâs also keeping the lights on?
đ§
#EngineeringLeadership #AIStrategy #EngManagement #ClaudeCode
