The same conversation comes around every few months or so. An iOS engineer ships a feature, a bug report comes back saying the data is stale on the second load, and the fix is a one-line cache-policy change against URLSession.shared. Ask those same engineers what URLCache is doing with a 200 response on a GET, and the room shrugs. Apple just does it.

The same shrug shows up at every layer of the stack, but it’s loudest with CLI tools, because the seams are right there if you bother to look. A pipe is a file descriptor. xargs rebuilds an argv. find -exec ... + and find ... | xargs make different trade-offs about how many arguments fit per invocation and how filenames with spaces survive the trip.

The engineer who has read the find(1) man page once can debug a one-liner that misbehaves on a path with a space in it. The one who hasn’t pastes another Stack Overflow snippet and prays. I’ve watched two people debug the same broken pipeline and the one who knew what IFS did had the answer in thirty seconds.

Two things come from that knowledge. The first is trade-off analysis. When you know how a thing works, you can choose between two ways of doing it on real grounds, instead of picking the one the tutorial used. A shell pipeline and a five-line script can both do the job. Which one is right depends on what’s expensive and where the data lives, and you can’t see either of those if the tools are opaque.

The second is pattern transfer. Primitives compose. The buffering intuition you build from tee and | is the same intuition that lets you reason about a Kafka consumer group, an event bus, or an LLM streaming response. Once you’ve debugged one back-pressure problem in your shell, you recognize it everywhere.

The same lesson applies to the new tools. Claude Code, Codex, Cursor, pi. People talk about them like they’re the same thing with different paint. They aren’t. They differ on what context they pass to the model, how tools are exposed, how memory and resumption work, what the harness will do on your behalf without surfacing it. The engineer who hasn’t learned one of them deeply is in the same spot as the one who never read a man page: dependent on incantations, unable to tell whether the model got something right because of the harness or in spite of it.

Read the man page. Print the args. Open the source when the docs run out. Translate that to whatever tool you use. The seams in your tools are where the leverage is, and the engineer who knows them is the one whose work survives the next abstraction shift.