Penny Wise and Pound Foolish

Measuring is cheaper than arguing — even faster than explaining yourself.

For most of the careers any of us have lived through, is it worth measuring? was the question engineers reached for to gate measurement work. A benchmark took a half-day. A load test took a week to plan and a day to run. An A/B test cost real money in tooling and real time in setup. So when you proposed measuring something, the responsible-sounding engineer in the room would say: but is it worth measuring? Are we sure the answer would change what we do? The deflection had air cover. The cost was real. Many teams ran on this calibration without examining it.

I never bought it. For over a decade, I have been the person in the room arguing back: we don't know what the answer is, that's what makes it worth measuring; the cost of checking is one quarter of an afternoon and the cost of being wrong is months; let's just check. I have lost some of those arguments. I have won others. Either way, the cost structure was real enough that even when I won, I had to spend an hour persuading the room I was right. The deflection always had at least the appearance of seniority because it pointed at a cost that was, in fact, real.

Then the cost of measurement collapsed.

The senior engineers who taught that calibration were not wrong, not in 2014. They were rationing what they thought was a scarce resource, and engineering hours were scarce at the time. The heuristic had teeth. What has changed is not their judgment. What has changed is the cost structure the judgment was calibrated to.

A bench that used to take a half-day to write now takes five minutes — I describe what I want measured, the model writes the Node script, the LLM sweeps payload sizes, the results land in a text file before my coffee is cold. I never touch the code. A live smoke test against a deployed preview, end-to-end, with real network and real workers, used to require a junior to spend a morning on it. Now I dispatch a Managed Agent and the results are back in three minutes for a few cents. I read what the agent reports and decide whether to trust it. A site preview that I would once have manually checked across three browsers now rebuilds and deploys itself on every push. The whole class of is this worth measuring? questions is one to two orders of magnitude off from what it used to cost — and the part that costs is no longer my labor. It is my judgment about what to ask for and what to do with the answer.

The decade-long argument is over. Not because anyone won the rhetorical fight, but because the cost structure that gave the deflection its air cover is gone. The new question is: if you are about to make a decision based on an unmeasured assumption, what stopped you from spending five minutes to test it? And the most common answer turns out to be the most embarrassing one: the speaker did not realize the cost had changed.

For almost every theoretical objection I hear in 2026, measuring is the cheap option and refusing to measure is the expensive one. The argument I have been losing piecemeal for fifteen years has become unwinnable for the other side.

This essay is about that gap. About the dream house I keep almost cutting before I draw. About the receipts I have for what happens when I draw the whole thing first. And about the new failure mode that wears the costume of the old virtue.

---

Have you ever watched a feature die in design review for reasons that, two minutes later, turned out not to be true?

The full request: count the bytes and tokens of every request and response, write them to Cloudflare's Analytics Engine alongside the existing tool-call metadata. Within two minutes of my proposing it, four objections came back at me from the model. Three sounded good. The fourth had a smell.

Objection one: bundle bloat. The tokenizer would add hundreds of kilobytes to the worker bundle. Workers have a code-size limit on the free tier. That's a real concern.

Objection two: vodka-architecture violation. I have a constraint that says the server should be thin, stateless, and domain-agnostic. Embedding a tokenizer choice — cl100k versus the Anthropic tokenizer — feels like the server picking sides on an LLM-vendor question. That's also a real concern.

Objection three: tokenizer choice as a domain opinion. Different LLM ecosystems have different tokenizers. Picking one for everyone is opinionated. Better to skip the tokenizer entirely and approximate from byte count using bytes / 3.5 or something. That's a thoughtful concern.

Objection four: latency overhead. The tokenizer would be too slow. It would add too much latency to every request.

The first three had the texture of engineering discipline. They invoked constraints, they identified real tradeoffs, they suggested a "safer" alternative. That is what good engineering used to look like. It has never been what good engineering actually looks like. If those had landed in a design review in 2014, I would have done what I have done in nearly every design review for the last decade and a half: pushed back. I have spent a long career arguing with engineers who reach for cost-benefit objections to avoid testing what they could test. In 2014 the dispute was livable — measurement was expensive enough that the deflection had a steelman, even if I never bought it. In 2026 the steelman has evaporated.

The fourth had a smell. Something about the latency claim triggered my BS meter. So I stated the threshold: under ten milliseconds of added latency, on average, would be a no-brainer. More than that, and I would buy the resistance. Then I asked for the bench.

The model wrote a Node bench. The bench swept four tokenizers across payload sizes from 200 bytes to 50 kilobytes, measuring tokenize time, token count, and bundle delta. I sat there. I read email. Five minutes later the script had run and the results were in front of me.

The bundle was 432 kilobytes gzipped — well inside Workers paid-tier limits, which I already pay for. The tokenizer was six times faster than the alternative I had assumed would be the standard. The byte-divide-by-3.5 heuristic was thirty-four percent high on real text. The "safer" approximation would have produced misleading data; the actual tokenizer produced ground truth. And the latency — the objection that had triggered my BS meter in the first place — came back way better than any of us imagined.

I never wrote a line of code in that exchange. I asked, the model labored, I read, I made the call. Four objections, each phrased as caution. Each falsified by a bench I did not write and a test I did not run. The total cost of my discernment was less than the cost of the conversation that produced the objections in the first place.

This is the new shape of nearly every theoretical objection I hear in technical conversations — including, sometimes, the ones I am about to make myself.

Six months ago my wife and I were having a house built. Semi-custom, which means a lot of options to navigate. Material choices, fixture choices, flooring choices, layout variations, structural upgrades. I treated each one the way I'd been trained to treat engineering decisions: triage by cost-benefit, weigh against budget, decide before moving on. Each meeting with our designer ran long. The next meeting ran longer. It was going to take forever.

At some point our designer, Debbie, stopped me. Many of my clients find it more effective to make the choices for your dream home first. Once you can see the whole thing, you can see how far over budget you are. Then you decide what to swap or sacrifice — and you'd be surprised what you end up keeping while still hitting your number.

What she was proposing felt counterintuitive. She was asking us to spend planning time on rooms and finishes we already "knew" we couldn't afford. Why draw what gets cut?

We tried it. She was right. We were surprised.

We got what felt like our dream home, and the budget worked out. We didn't feel like we sacrificed as much as we would have if we had cut corners along the way. We kept the things that mattered. We cut the things we don't miss. The cuts we made were a few major items — the kind of large structural decisions where the swap was material and worth making consciously. The hundreds of smaller choices, the high-end finishes I see and touch every day, all of those stayed. They're the part of the house I love most. And the running cost of having kept them turned out to be a small dent in the budget — much smaller than my pre-optimizing instinct had been treating them as.

If we had pre-optimized — if we had spent every meeting cutting before drawing — we would have cut things I love. I'd be living in a house designed entirely around constraints, with hardly any of the rooms I actually want to live in. The cuts would have been penny wise and pound foolish. Each one would have shaved a small amount off the budget, and over time I would have noticed the absence of every one of them. The things that look like prudent line-item savings during planning are the things that are lifetime-cost mistakes once you live with the result.

I'll be honest: there are a few cuts I do miss. A couple of the major ones. But I know with confidence that we made the right tradeoffs, because we made them with the whole picture in front of us — not from a pre-optimized version of the house we were never actually choosing between. Missing a few specific things from a known set of cuts is a fundamentally different experience than missing things you never even drew.

That whole arc — Debbie's intervention, the dream version, the few major cuts, the surprise that almost everything mattered — has been the lens I use for nearly every cost decision since. When I find myself about to cut something speculatively now, I stop and ask whether I am about to be penny wise and pound foolish. Often enough, the right move is to draw the whole thing, see what reality says about the budget, and then cut from a position of knowing.

The software version of this lesson is the one I lived this morning. The bench was free. The agent dispatch was free. The five hours of model time spent shipping the tokenizer feature, breaking it four times in Workers-specific ways, fixing it, validating it against production telemetry, and arriving at an honest end state — that was free in the way that matters. What would have been expensive is the version of the project where I dropped the feature in response to objection one, or shipped the byte-divide-by-3.5 heuristic in response to objection three, and lived for the next year with telemetry that could not answer the questions I needed it to answer. Penny wise on the bundle size. Pound foolish on every decision the missing telemetry would have informed.

The dream-house principle is: build the version you want, in software, in writing, in whatever artifact is in front of you. Then cut from contact with reality, not from prediction. The cuts you make from reality are different from the cuts you would have predicted. They are almost always smaller, more targeted, and more correct. And the rooms you would have cut speculatively often turn out to be the load-bearing ones.

That principle predates Debbie. When I architect software, I dream the system I want first and cut from contact with reality — I just hadn't named it. My wife operates the same way in everyday life: dream big, plan for the best, adapt to what's closest. Debbie named it in a domain — building a house — that was different enough from software and from daily life to make the pattern visible across all three.

Since then I've used the analogy with a couple of engineers, and it lands. What makes it land — over and over — is the discovery embedded in it: sometimes what you want is much cheaper than you expect, and the overhead of the dream is less than the cost of the workaround you would have built instead. Measuring is cheaper than arguing — even faster than explaining yourself.

If you are in a technical conversation in 2026 and someone raises a theoretical objection — about cost, about complexity, about scale, about some second-order risk — there is a question worth asking before you accept the objection on its terms.

Could a fifteen-minute experiment falsify or confirm this?

If the answer is yes, and the fifteen-minute experiment has not been run, then what you are hearing is a claim posed as caution, made by someone who has not yet updated to the cost structure of 2026 — not engineering.

I want to be clear about what I am not saying. I am not saying every theoretical objection is wrong. Many are correct. Some are too expensive to test. Some are about questions that experiments cannot resolve. Some are about values, not facts. Those are real exceptions.

But the broad class of theoretical performance objections, theoretical complexity objections, theoretical bundle-size objections, theoretical "this won't scale" objections, theoretical "users won't want this" objections — most of those are now in the category where a fifteen-minute test would resolve them, and the speaker has not run the test. The speaker is not necessarily being lazy. They are, more often, applying a rule that used to be load-bearing and is now obsolete.

The tell lives in the insistence on the objection in the absence of the test that would resolve it, not in the objection itself. In 2010, that insistence was wisdom — a senior engineer triaging which questions deserved a half-day of measurement. In 2026, that insistence is a conversation that costs the operator more attention than the test would have cost in the first place.

The model gave me four textbook examples of the deflection this morning. I pushed back immediately, asked for the bench, and had answers in five minutes. The bench is almost always the antidote, because the bench is almost always free.

---

The discipline I am describing is not "measure everything." It is narrower than that, and more useful. It is measure before you object. If you are about to raise a theoretical concern that would block, water down, or pre-emptively complicate a proposal, run the cheap experiment first. If the cheap experiment falsifies your concern, you have saved everyone a meeting. If the cheap experiment confirms it, you now have evidence rather than a vibe — and the conversation that follows is grounded in something, instead of in seniority signaling.

In our system we now write this as a constraint. Theoretical concerns about performance, cost, complexity, or scale require empirical falsification before they count as engineering input. The fifteen-minute test is the ceiling, not the floor — if a fifteen-minute test would resolve the question and the test has not been run, the concern does not earn the right to block work. It earns the right to be tested.

The constraint is asymmetric on purpose. It does not require testing every speculative concern in advance. It requires testing speculative concerns that would otherwise change the trajectory of work. If a concern is just a passing observation, no test is required. If a concern is the reason a feature is being deferred, simplified, or redesigned, then the cost of running the test is dwarfed by the cost of changing the trajectory on a guess.

There is a corollary that makes the discipline livable. The model should not externalize the test onto the operator. If a theoretical concern arises mid-execution, the model can run the bench itself, dispatch its own agent, hit its own preview deployment. The point of cheap measurement being cheap is that it does not need permission. The model that surfaces a concern and its falsification in the same turn is doing the work of seniority. The model that surfaces only the concern, and asks the operator to decide whether to test, is doing the costume.

What is structurally different about the new world? If the cost shift is real, the implications are not limited to one feature on one project — so what has actually moved?

What changed is the cost of generating an artifact — code, a document, a benchmark, a smoke test, a draft of an essay. With AI as a co-author, the cost of producing the first draft of almost anything has dropped by roughly the same one-to-two orders of magnitude as the cost of measuring. A first draft of a benchmark used to require an engineer's hour at minimum. Now it requires a prompt. A first draft of an integration test used to require setup and tooling and tear-down. Now it requires a description of what you want to verify. A first draft of a deployment script, a documentation page, a configuration file, a CI workflow — all of these used to require sustained human labor. They now require human direction, applied to capable tools, for short bursts.

This means the friction that used to make pre-optimization rational has collapsed on both sides of the equation. Generating the candidate is cheap. Testing the candidate is cheap. The only remaining cost — the only one that has not collapsed — is the operator's attention, the human judgment about whether the candidate is the right one and whether the test means what it appears to mean.

And that is exactly the resource that performed prudence wastes. Every theoretical objection raised in the absence of a test consumes operator attention to evaluate. Every preemptive cut consumes operator attention to debate. Every "should we even build this?" consumes the operator's most expensive remaining input, in service of decisions that would have been better made by building it and seeing.

The operator's attention is the bottleneck of the modern workflow. Theory of constraints says optimize the bottleneck. The way to optimize the bottleneck is to push as much work as possible off of it. That work used to belong to junior engineers. Now it belongs to AI co-authors and to cheap tooling. And the workflow that used to be gate work with senior judgment has flipped to do the work first, surface the receipts, let senior judgment review the receipts. The senior judgment is no less valuable. It is just expensive in a way that nothing else is anymore, and the workflow has to respect that.

---

How do you tell the senior engineer who has updated to the new economics from the senior engineer who has not? From the outside, you cannot — at least, not from the move itself.

The behavior that used to be senior — saying but is it worth doing? before doing it — looks identical to the behavior that is now obsolete. Same surface, same tone of measured caution. The only difference is whether the speaker has updated to the new cost structure.

You can, however, tell by looking at the next move. The senior engineer of 2010 would say "is it worth measuring?" and, when convinced it was, would proceed to measure. The senior engineer of 2026 says the same thing, and, when convinced it might be, proceeds to measure immediately, because measurement now costs what proceeding-without-measurement used to cost. The junior of 2026 — or the senior who has not updated — says "is it worth measuring?" as a terminating move, expecting the conversation to end with a decision rather than an experiment.

When the move is a terminator, it is performed prudence. When it is a precursor to running the test, it is real prudence. Same words, opposite functions.

I name this not to shame anyone for using the old move. It has been the dominant move in much of engineering culture for decades, and many of the people deploying it are doing so in good faith — they are applying a heuristic that used to have teeth. I name it because once you see the pattern, you cannot un-see it, and the cost of leaving it unaddressed is the slow-burn loss of every project where the dream house never got drawn because the cuts were made first.

---

This principle may be the reason senior engineers get passed up by vibe coders and non-engineers who start building apps themselves in the age of AI.

They don't have the baggage, so they just try it. Muscle memory doesn't exist to kick in. They just ask the AI to build it. And if they're persistent enough to tell the AI to do it anyway, they may build what many of us wouldn't think possible.

---

I do have an advantage. I have written efficient tokenizers for over a decade. That experience is irreplaceable. It is the discernment layer that human experts must focus on in this age.

Honestly, with four objections coming from the best SOTA model available — equivalent to a senior engineer's knowledge — most people would have been intimidated and buckled.

---

If you are an engineer, ask yourself: when was the last time you raised a theoretical performance objection without running a five-minute test? When was the last time you accepted one from someone else?

If you are a manager, ask yourself: when one of your engineers proposes a feature and someone in the room raises an unmeasured theoretical concern, what is your default? Do you treat the concern as engineering, or as a claim that owes evidence?

If you work with AI co-authors, ask yourself: when the model raises an objection mid-task, do you accept it? Do you ask the model to test it first? Do you run the test yourself? Or do you engage in the debate as if the cost of resolving it empirically were what it used to be in 2014, when in fact it is one to two orders of magnitude lower right now, in this session, with the tools open in front of you?

The dream house has become the default. It became the default the moment the cost of drawing the rooms collapsed. The cuts you make from reality will be sharper, smaller, and more correct than the cuts you make from imagination.

Build the wing. See what reality says about it. Make the cut from contact, not from prediction.

The bench was free. The agent dispatch was free. The receipts are sitting in production right now. What were the three things you talked yourself out of last week, that a fifteen-minute experiment would have settled?

The cost of dropping the old habit, if you held it, is just the discomfort of letting go of a posture that used to make you the most senior person in the room. That posture worked for the people who held it. It was earned. And it is no longer load-bearing. The senior move in 2026 is showing the receipt.

The dream house got built. Most of the rooms got kept. The version we shipped is honest about what got cut. And the alternative — the version where I would have listened to the four theoretical objections this morning and shipped a worse feature with less information — is a version I would have lived inside for the next year, defending decisions I did not have evidence for, debating concerns that a five-minute test would have settled.

Show me the receipts. Or run the test. There is rarely a third option that is honest anymore.

---

I want to name what would change my mind, because a claim without a falsifier is just a belief.

The economic-shift thesis rests on the kind of work I do: infrastructure, tooling, governance, public-facing writing, open-source server code. Domains where a bench is a few lines of Node, where an integration smoke is a container dispatch, where deployment is a git push. In that shape of work, the 50-to-100x ratio I describe is what I observe week over week.

There are shapes of work where the ratio is smaller or does not hold. Hardware that requires a physical fab cycle. Clinical trials. Cryptographic work where the cost of testing is the cost of waiting for a real-world attack. Regulated domains where the measurement itself is a legal event. In those, the old economics may still be the right economics, and a theoretical objection may still be a cheaper move than the test.

If I found myself consistently running experiments that cost more than the theoretical conversations they replaced, the thesis would be wrong and I would retract it. If I found that the experiments were systematically producing results that the subsequent work contradicted — suggesting the experiments were easy to run but hard to interpret — I would revise the claim to "measurement is cheap, interpretation is expensive," and the discipline would look different.

The thesis also rests on one specific project's data this morning, supplemented by a year of similar patterns across my other work. It is a working heuristic I have now codified in my own system's canon — not an established industrial fact. I offer it as a pattern I am willing to defend, not as a law I am claiming to have discovered.

Treat the numbers as estimates from one practitioner's workbench. Test them against yours.

---

What's yours?