How "fair" workload distribution quietly buries your best engineer
The best engineer I ever worked with spent most of his week doing what amounted to shelf-stacking.
Not by accident. By policy.
He was one of those people who reads a stack trace the way other people read a the Sunday newspaper. Give him a kernel panic on a Friday afternoon and he would come back with a one-line patch and an explanation of why the vendor's documentation had been wrong since a version three years earlier. Undiagnosed autistic, most likely - never said it, never needed to. Terrible at status meetings. Catastrophic at self-promotion. Made a senior architect cry once, purely by being correct in public.
And his manager assigned him to the general queue rotation. Same volume of password resets, license questions and "have you tried restarting" tickets as everybody else.
Because that was fair.
The fairness that isn't
The official reasoning was elegant: everyone shares the boring work, nobody gets special treatment, morale stays intact. Written down like that, it sounds like leadership.
What actually happened: the team's one irreplaceable diagnostic capability was rationed down to roughly six hours a week, and the escalations he wasn't touching sat in the pipeline for days, quietly compounding into churn risk that nobody attributed to the rotation policy. Because nobody measures the cost of a genius doing data entry. There's no dashboard for that.
Job security through indispensable spaghetti code worked great - until it didn't.
Every engineering org has one. The guy whose code looks like it was written during a fever dream in a language he invented on the spot. No comments. No docs. Variable names like xTmp_v2_FINAL_real. Functions that call themselves through three other files for no discernible reason.
And nobody touches it. Because nobody understands it. And nobody understands it because that's the whole point.
I worked with an engineer - let's call him Gerald - who had perfected this art over five years. Five years of building what was essentially a hostage situation disguised as a codebase. Every module he owned was a booby-trapped labyrinth. New developers assigned to his area would last about two sprints before requesting a transfer, a therapist, or both.
Management knew the code was bad. They could smell it. But Gerald had made himself the only person who could navigate the maze, and the business logic underneath was critical. Classic single point of failure wrapped in a single point of attitude.
The implicit threat was never spoken out loud, but everyone understood it: fire me and enjoy your next six months of outages.
There's one unmistakable smell that tells you a company has quietly entered its death spiral. It isn't mass layoffs or missed earnings. It's the moment management looks at a genuinely broken tool, UI, script, or workflow and decides the easiest fix is... another process.
An email goes out. A new KB article appears. Someone records a TOI video. A fresh Slack channel is born. The wiki gets another page that nobody will read after next week. And just like that, the organization has chosen to compensate for bad tooling with human friction.
I watched this exact pattern play out at a mid-sized software company that, on paper, still looked healthy.
The internal escalation tool had a nasty bug in its search function. Simple queries returned incomplete results about 40 % of the time. It had been that way for months. Instead of fixing the underlying indexing issue (which the devs swore would take "only a couple of sprints"), leadership sent the classic memo: "Please use this new workaround when searching for escalations." The workaround involved three extra steps, copying ticket IDs into a separate spreadsheet, cross-referencing with another system, and then posting in a dedicated Slack channel so someone else could verify you hadn't missed anything.
German is objectively denser than English. It still makes your prompts worse. And the reason tells you exactly where this is all heading.
A while ago, someone asked me, with the sincere enthusiasm of a person who had just had a Big Idea: "German is so precise. Wouldn't prompting in German be more token-efficient?"
As a German, I wanted this to be true so badly. Finally, a competitive advantage from the language that gave the world Schadenfreude, Kummerspeck and Weltschmerz.
It is not true. But the reason it fails is more interesting than the idea itself.
The German hypothesis is linguistically sound
German really does pack more meaning per word. Compound nouns fuse concepts into single unambiguous units. Datenbankverbindungspoolverwaltung is one word, one concept, and the structure tells you precisely what belongs to what. The English equivalent, "database connection pool manager", are four words that leave you guessing whether the manager manages the pool, the connections, or the database. Add a case system that encodes relationships without prepositions, plus a vocabulary that prefers specific terms over vague umbrellas, and in theory you get fewer words for the same instruction.
Fewer words, fewer tokens, cheaper and sharper prompts. Beautiful theory.
A hardware wallet built keys from a random number generator it never once called. For five years. The source code was public the entire time.
In a 25-minute window, someone swept roughly 594 bitcoin - about $38 million - out of some 500 unrelated wallets. No phishing. No malware. No supply chain tampering. No 5$ wrench.
Every one of those wallets was protected by a device sold on a single, admirable promise: keys generated offline, on isolated hardware, using a true hardware random number generator, Bitcoin-only to shrink the attack surface, no cloud, no companion app, and open-source firmware you can verify yourself.
The hardware RNG was on the board. Powered. Functional.
For roughly 1,900 days, the firmware never asked it for a number.
The bug is one character wide
The vendor did something entirely sensible: they switched off MicroPython's built-in random path with a build flag, because they had written their own wrapper around the microcontroller's true RNG. Textbook embedded hygiene.
Then a cryptographic support library checked that flag with #ifndef - which asks "does this macro exist?" rather than "is it set to something other than zero?"
The macro existed. Its value was zero. So the library concluded hardware entropy was available and happily bound itself to MicroPython's random function. MicroPython, having read the same macro correctly, had compiled a non-cryptographic software fallback instead of the hardware peripheral.
Many moons ago, back when I was an apprentice, a large shoe manufacturer walked into our software shop with a beautifully simple request: make our sole production more efficient.
Their process at the time: punch shoe soles out of the raw material in neat, ordered rows. Like cookies. All facing the same direction, with generous gaps in between. The gaps became scrap, the scrap became cost, and the cost became our project. The ask: write software that arranges the sole shapes in a randomized, compressed, rotated layout - Tetris for footwear - so almost nothing goes to waste.
Technically? A fun little optimization problem. A junior could have shipped it in a week.
But our senior developer did something that took twenty seconds and changed the entire meaning of the project. He picked up a piece of the raw material, squinted at it, and asked:
"Excuse me - I know nothing about shoemaking. But the fibers in this material seem to run in one direction. If we punch soles out at random angles, against the grain... could that hurt the quality of the shoe?"
The customer, without a millisecond of hesitation: "Absolutely. Every sole cut against the fiber flow will be subpar. Those shoes will most likely start leaking early."
A while back I met an old colleague for cocktails. We do this every so often - two people who have seen enough server rooms and steering committees to know that the best incident reviews happen over a Negroni.
He was in a great mood. His company's vibe coding (quickly developing software using AI like Claude without writing (or sometimes even understanding) the code itself) adoption was through the roof. And not just among developers - consultants, architects, support engineers, basically anyone with a pulse and a Claude license was building tools. Management was celebrating. They threw around numbers like trophies: one engineer burned through 100 dollars a day in tokens. Applause. High fives. Slide decks.
And honestly? Fair enough. If a 100-dollar-a-day token bill produces a tool that saves ten hours of engineering time per week, that's the cheapest employee you ever hired. I am not here to rain on token budgets. Fun fact on the side: "vibe coding" went from a casual Karpathy tweet to Collins Dictionary Word of the Year within roughly twelve months. That's faster adoption than most companies manage for a new expense tool.
But while my colleague was celebrating, I was doing what 20+ years in support trenches trains you to do: listening for the alarm underneath the applause.
For months we've been told the same story in every LinkedIn post, all-hands, and glossy keynote: AI is going to 1000x software engineering. CEOs are high on their own supply, promising 1000x efficiency, vibe-coded features, and a future where humans are mostly optional. Just prompt it, ship it, profit.
Six months later the dashboards look suspiciously familiar. No 100x. No 10x. Not even a polite 2x that anyone can show without footnotes the size of a small novel.
Funny how that works.
The promise was beautiful: AI writes the code, humans sip coffee, and velocity goes parabolic. The reality is a bit more... human. Vibe coding is genuinely delightful for knocking out a quick 40-line script. But the moment you scale to anything enterprise-shaped - with strict requirements, security audits, scalability, platform support, regression testing, governance, and the whole boring adult checklist - the magic evaporates.
Hallucinations? Still very much a feature, not a bug. Debugging overhead? Massive. Security risks? You're basically playing Russian roulette with production data. And the models start to degrade on complex contexts faster than a free trial on the last day of the month.
But the real killer isn't the AI itself. It's the organizational layer that still moves at 2005 speed while the code generation moves at 2026 speed. Here's the conceptual truth nobody wants to say too loudly in the strategy off-site: the bottleneck was never the developers. It was the organizational overhead sitting on top of them. Processes. Bureaucracy. Decision latency. The six-week email chain to "align on requirements." The three layers of sign-off before anyone can change a single scope item. The safety nets that still exist because regulators and customers have this inconvenient habit of expecting things not to explode in production. AI didn't magically dissolve any of that. It just made the old friction more visible - and a lot more expensive. You still need:
TrenchOps 🐎 
