The Cost of a Clever One-Liner

August 8, 2026 · Engineering · Michael Marquez

Back to Michael's Crumbs

Somewhere early in most engineers' careers there is a moment of pride the first time a whole function collapses into one dense line. It feels like mastery. It rarely is. It is usually just compression, and compression has a cost that gets paid by someone else, later, under worse conditions than the ones you wrote it in.

I do not mean this as a rule against short code. Short is often the right answer. I mean it as a warning against clever code, the kind that trades a few keystrokes now for a puzzle every future reader has to solve before they can trust what it does. Six months from now that reader might be you, at two in the morning, trying to understand why a payment failed.

A test I use

Before I let a clever line survive a review, I ask whether an engineer half as familiar with this codebase as I am could read it once and know what it does. If the answer is no, I rewrite it, even if the rewrite is longer. Especially if the rewrite is longer.

AI makes this worse before it makes it better. It has read enormous amounts of code optimized for cleverness, because that is what gets upvoted on the internet, not what survives five years in production. Left unchecked, it will hand you dense, clever code by default. Catching that and asking for the boring version is now a routine part of the job.