If It’s Working, Why Are You Shrinking?
Nobody got promoted for using a billion screws — and no company reached the future by laying off the people who knew how to build the car.
Written with Claude Opus.
A company announces layoffs and gives the reason out loud: AI has made our engineers more productive, so we need fewer of them. It’s said as though the logic is self-evident. It is not. It is exactly backwards, and I want to take it apart, because it is the clearest tell I know of a leadership team that does not understand the thing it is holding.
Let me say where I stand before I start, because it changes what this post is. I am not an AI skeptic. I think AI is going to be one of the most consequential things to happen to hardware engineering in my twenty-five years in it — I’m betting my own next chapter on exactly that. So this is not a complaint that AI underdelivers. It’s the opposite worry. A tool this powerful deserves to be deployed properly and reasoned about honestly, and instead I keep watching leaders take the easiest number on a dashboard, build a story out of it, and make an irreversible decision on the strength of that story. They are going to fumble something real — and not by being too skeptical of AI. By being too lazy about what they measure, and too thoughtless about what they do next.
Sit with the layoff logic for a second, because it doesn’t hold together. You are using “our people just got dramatically more capable” to justify “so we need less of that capability.” That only makes sense under one assumption: that you had no further use for the upside. That your ambition was capped, precisely, at what you were already shipping — and a faster way to ship it is a reason to send people home rather than to build more. That is a confession, not a strategy. It says the work was never that valuable to you, and that you have no roadmap worth the capacity you just unlocked.
Watch what the companies that actually believe in this technology do instead. They keep their engineers and they ship ten times as much. The products that were too expensive to attempt last year become this year’s roadmap. The verification that always got cut for schedule gets done. The architectural bets nobody had the headcount for get made. A productivity multiplier, in the hands of leadership with ambition, is not a way to do the same work with fewer people — it’s a way to do the work you could never afford with the people you already have. The strong company uses the same engineers to produce ten times the output. The cost-center company produces the same output, pockets the salaries, and calls it efficiency.
So how does a leadership team end up making the second choice while believing it’s being shrewd? It starts upstream, with what they decided to measure. And the measurement mistake is easier to see at the level of a single engineer, so start there.
Nobody got promoted for using a billion screws
We’ve all read the posts by now, and for me this isn’t something I read about from the outside — I’ve sat in the rooms. I’ve watched these dashboards go up on the wall: the org ranked by pull requests opened, commits pushed, lines generated, AI “acceptance rate.” I’ve heard an engineer called the team’s standout performer because they were burning ten billion tokens a month, more than anyone else. The reflex is everywhere: AI activity is suddenly easy to count, so count it, rank it, and call the top of the leaderboard your best people.
The ten-billion-tokens line contains its own refutation, and the person saying it can’t hear it. Ten billion tokens a month is not a productivity number. It’s a cost number. It belongs on the same spreadsheet line as the cloud bill and the EDA licenses — the things you’re trying to get more output per dollar from, not less. An engineer producing the same finished, signed-off work as a colleague while consuming five times the tokens isn’t a star. They’re an efficiency problem wearing a cape.
The cleanest way to see why the activity number lies is to walk onto the factory floor that a certain kind of executive keeps gesturing at — the one who, pressed, will tell you engineers are basically assembly workers, that the cleverness has been squeezed out and what’s left is throughput. Let’s take that frame all the way to the floor, because it is going to do something they won’t expect.
You run an automotive plant. One of your line workers has consumed a billion screws this quarter, far more than anyone else on the floor. Do you promote them?
Of course not. The question is absurd, and everyone knows it’s absurd, and it’s worth being precise about why, because the same reasons apply one-for-one to the engineer with ten billion tokens.
First: nobody cares how many screws you used. They care how many finished cars came off the line, and how many screws each one took. A worker who consumes a billion screws might be assembling more cars than anyone. They might also be dropping screws on the floor, stripping threads and starting over, driving them into the wrong panels and backing them out again. High consumption is perfectly consistent with high waste. Consumption alone tells you nothing about output — you can’t even tell the direction of the relationship without measuring the thing the screws were supposed to produce.
Second, and this is the one that matters: suppose the cars are coming off the line. What’s their quality? How many come back? How many have a rattle at 60 because a bracket was driven in crooked, a panel that’s loose because two fasteners were skipped, a recall waiting to happen because the torque was wrong on something that holds a wheel on? A high screw count paired with a high return rate isn’t productivity. It’s a defect factory running at speed.
So the worker who consumed a billion screws is, on the evidence presented, equally likely to be your best employee or your worst. The screw count cannot tell them apart. That is the entire problem with the metric, stated plainly — and it is exactly, not approximately, the problem with counting tokens.
The factory analogy carries the bigger point too, the one this whole post is about. A plant retools and each worker can suddenly build ten times the cars. The visionary running it builds more cars — enters segments it couldn’t serve, takes the capacity it just unlocked and does something with it. The one who lays off nine workers in ten to build the same number of cars at the same revenue has told you, plainly, that its leadership could not imagine selling more cars. Same factory. Same gain. Opposite reading of what the gain was for.
Why the easy number is the wrong number
Tokens, PRs, commits, generated lines — these are screws. They measure motion. And motion has always been the easiest thing in the world to manufacture when someone is watching for it; the difference now is that AI has made motion nearly free to produce. You can generate a thousand lines of plausible RTL before lunch. You can open six pull requests that each touch four files. You can run the token meter to the moon. None of it requires that anything work, and increasingly, none of it requires that you even understand what you produced.
Here’s the trap that makes this worse than an ordinary measurement error: activity feels like progress. It always has. Generating the thousand lines, opening the pull requests, watching the meter climb — it feels productive, viscerally, both to the person doing it and to the manager watching the dashboard light up. AI has made that feeling cheaper to produce than at any point in the history of the field. The sensation of velocity has never been more abundant, and it has never been more disconnected from whether anything actually got finished and got finished right.
That gap is what a manager standing outside the work cannot see. The token count tells a story, the story is confident, and the story is pointed at motion rather than output. Grade engineers on that number and two things happen, both bad. You reward the people producing the most motion regardless of what comes out the other end, and you teach everyone else that motion is the game. One large study of AI-heavy teams found exactly this shape: more pull requests, bigger pull requests, slower reviews, and flat delivery throughput. The motion went vertical and the output didn’t follow.
And then comes the part this post is really about. When the quarter’s delivered work doesn’t match the dashboard’s fireworks, the story on offer is that the engineers are now so productive the team is overstaffed — which is how a measurement error becomes a layoff. The same false signal that ranked your busiest engineer as your best also tells you that you can afford to lose people. You can’t. You were never measuring what you thought you were.
The thing nobody wants to say
Here is what the screw-counting actually reveals, and I’ll say it the way I’d say it in a review.
When a leader reaches for tokens-per-month as a measure of engineering productivity, the metric is not the mistake. The metric is the diagnosis. It is what surfaces when someone is making decisions about a technology they have not done the work to understand. Someone who genuinely understood what an AI does inside a design flow — where it helps, where it generates confident garbage, what has to be checked and by whom — would no more reach for token count than a plant manager who understood manufacturing would promote on screws consumed. The reach for the activity number is a tell. There is a word for confidently steering something you haven’t taken the time to learn, and it isn’t visionary.
And the diagnosis gets confirmed by what they do next. A misunderstanding that stays on a dashboard is recoverable. The same misunderstanding, turned into a headcount decision, is not — and the leaders most likely to make that decision are precisely the ones who never understood the number they’re acting on.
I want to be careful here, because there’s a version of this critique that blames the engineers, and that version is wrong. The engineer running ten billion tokens is responding rationally to what gets rewarded. If the org has decided activity is the scoreboard, people will produce activity — that’s not a character flaw, it’s working as designed. The failure is upstream. It belongs to whoever decided to count screws instead of doing the harder thing.
Because the honest reason activity metrics win is that they’re easy, and the right metrics are hard. Activity is countable in real time. Outcomes are measurable but they lag — sometimes by a full design cycle. And judgment, the actual thing you’re paying a senior engineer for, is neither countable nor immediately measurable at all. So leadership counts what’s countable, calls it productivity, and tells itself it’s managing.
What you’d measure if you meant it
You’d measure finished cars and you’d measure rework. Everything else is screws.
In silicon terms, “finished cars” is work that actually closed — a block that reached clean sign-off, a milestone hit with the verification status it was supposed to have, a feature that’s genuinely done rather than generated. And “rework” is what came back: bugs that escaped to integration and bring-up instead of being caught before, the fraction of generated RTL that had to be torn out and rewritten because it was plausible and wrong, the crossings that got waived in a hurry and turned into silent functional lies. A team shipping more closed work with a falling escape rate is winning, regardless of its token bill. A team with a soaring token bill and a rising rework rate is the defect factory, and the token bill is hiding that fact rather than revealing it.
These numbers are harder to collect. They lag. Some of them you only see at bring-up, months downstream of the quarter where the activity looked so impressive. That lag is exactly why activity metrics are seductive and exactly why they’re a trap — the cost of measuring the wrong thing doesn’t show up in the quarter you measure it. As I argued a couple of posts back, AI replaces activity, not judgment; the bill for confusing the two comes due late, and it comes due at the worst possible place, which is silicon. It is also what you would have wanted in front of you before you decided the team was overstaffed — and it’s the number nobody ran.
If it’s working, why are you shrinking?
So we come back to where we started, because now the decision and the measurement are the same mistake wearing two faces.
Cutting engineers because AI made them productive is the screw count again, one level up. Counting tokens mismeasures the individual engineer. Cutting the team because the team got faster mismeasures the entire engineering function — it treats engineering as a fixed pile of work to be cleared as cheaply as possible, rather than an open-ended capacity to build more than you could yesterday. Both mistakes come from the same place: not understanding what you’re actually holding. One of them you discover at bring-up. The other you discover when a competitor who kept their engineers ships the products you decided you had no use for.
And this is the one you can’t walk back. A bad metric, you can fix next quarter. A team you dismantled on the strength of it is gone, and so is the roadmap you’d have needed them for. The most expensive kind of not-knowing isn’t the dashboard. It’s the irreversible decision made on its authority by someone who never asked what the number meant.
Measuring the right thing is more work and it tells you the truth later than you’d like. That’s the job. Deploy AI well and it will deliver enormously — I believe that without hedging. But that is precisely the case for keeping the people who can aim it at something bigger, not for sending them home to bank a saving that a real competitor is about to turn into products. Nobody ever got promoted for using a billion screws. And no company ever got to the future by counting them, calling it efficiency, and laying off the people who knew how to build the car.
Marco Brambilla is a semiconductor industry veteran with 25 years in chip design, most recently as Senior Technical Director at Meta Reality Labs. He writes about AI, chip design, and the future of hardware engineering at Above the RTL.