A vibe-coding CTO is an externality problem, not a laziness problem
via Episode 524: My CTO AI-codes big piles of slop and early mornings, late meetings
AI-generated writing.
Dave Smith frames an executive who vibe-codes a project and then hands it to the team to clean up as a textbook economic externality: the person taking the action (generating code) doesn’t bear the costs it creates (review, QA, integration, go-to-market coordination) — the team does. AI removes the one thing that used to stop executives from doing this themselves, which was simply not knowing what code to write; it doesn’t remove any of the downstream costs of shipping code nobody but the author has seen.
The size of the externality scales with how much of the end-to-end process the CTO actually owns. The floor is generating code and dumping the rest — no local testing, no defensible understanding of what was written, so code review from the team becomes pointless because pushback has nowhere to land. Full ownership would mean running it locally, being able to explain and defend the code in review, shepherding it through QA, and handling deployment — at which point the externality shrinks to something close to normal engineering overhead.
The suggested fix isn’t confrontation but a rhetorical question that makes the bypassed process visible to the person bypassing it: asking the CTO why they don’t write prompts for every roadmap item instead of just pet projects tends to make them realize on their own that they’re sidestepping planning rather than saving anyone work. Surfacing that responsibility is framed as the engineering manager’s job, not an individual contributor’s.