AiBook · ISBN 9798173134660 · PDF

AiBook · Jeremy Schoemaker · 2026 · ch-55.html

You Don’t Have to Hire Assholes Anymore

(Spine Ch. 55.)

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” Upton Sinclair, I, Candidate for Governor: And How I Got Licked (1935)

Nine systems told me everything was fine. The database dump came back 4KB. The binlog shipped truncated. A health check said “Up 6 seconds” on a container that was doing nothing at all. Every dashboard was green, every job reported success, and 576 records were gone. It took me most of a day to work out what the dumps, the binlog and the dashboards all had in common, and when I finally had it, the answer was also the thing wrong with an engineer I once kept for four years. Green report. Empty table.

He rolls in at noon. Two-hour lunch. Gone at five. Somewhere in that window he writes the payment retry logic nobody else understands, and when support forwards him a bug report he replies that the users are too stupid to read the form. You keep him for four years. You lose two people who were nicer, cheaper, and would have stayed.

Bottom line: AI did not kill jobs for good, kind, responsible engineers. It killed the ones you put up with because they were so damn good. Coding knowledge got leveled. The thing that used to buy a jerk immunity, knowing the incantation nobody else knew, is now a $20/month subscription. What did not get leveled is architecture, networking, and the basics (does he know what a function is, can he parse the JSON, does he understand an array versus an object). What went up in value: addressing a human being, admitting a mistake out loud, being kind to the person who has to use the thing.

When it bites

The pattern

Robert Sutton wrote The No Asshole Rule in 2007. It sold, everyone quoted it in a management offsite, and almost nobody enforced it, because enforcement had a price: the guy.

Netflix ate the cost anyway. Reed Hastings put “no brilliant jerks” in the culture doc and made it a firing benchmark rather than an HR poster. Brendan Gregg wrote in November 2017 that in over three years at Netflix he worked with zero brilliant jerks, and laid out what they cost everywhere else: attrition, demoralization, lowered technical IQ, hostile work environment. Rob Bowley wrote it again in October 2024 after one toxic engineer evaporated a department’s culture.

By 2026 the tradeoff got cheap.

The retry logic is not a moat anymore. Claude and Cursor and Copilot will write it, and they will explain it to the person who did not write it. The specific knowledge that made a jerk load-bearing (this codebase’s weird conventions, this framework’s undocumented behavior, the exact incantation for the deploy) got commoditized first. What did not: knowing the retry belongs in a queue and not a cron, knowing your MTU is wrong, knowing what a 502 from the load balancer means versus a 502 from the app.

That commoditization is what I watch happen in my own repos, week after week. No named company is on record saying the tools took its one expert off the critical path. Take this as my belief: the load-bearing specialist is already gone in most shops and the org chart has not noticed.

The productivity story does not say what the LinkedIn version says. METR ran a randomized controlled trial in July 2025 with experienced open-source developers on their own repos. Using AI tools made them 19% slower, though they believed they were faster. The real claim is narrower: the floor came up. Somebody with solid fundamentals and no encyclopedic memory of your codebase can now get to a competent patch. That does not make them fast. It makes them viable, and viable plus decent beats brilliant plus corrosive over any horizon longer than a quarter.

The other half of the market is uglier. Stanford’s digital economy work, cited December 2025, found junior developer employment for ages 22 to 25 down nearly 20% from its late-2022 peak. Forbes, August 9, 2026: 33 consecutive months of decline for juniors. A 2024 SHRM survey found 70% of hiring managers thought AI could do intern work, 57% trusted AI’s output over an intern’s.

That is the real opportunity and almost nobody is taking it. The junior you would have hired in 2019 and spent two years teaching should get productive in a fraction of that now, because the tooling closes the syntax gap. Should. The macro numbers are real; I found no published case of a junior with AI matching the specialist she replaced, so that sentence is a bet, not a finding. What she brings that the tooling does not: she will tell you when she broke something.

One worked example

airank, August 8, 2026. I wrote a post called “Everything Reported Success.”

I built every one of those nine checks myself. Jeremy Schoemaker, Lead Linux Security Engineer at a bank before some of my staff could drive, wired up nine green lights that all measured whether a process exited zero. Nine for nine. Total n00b move, twice in one career.

I got them back by checking effects instead of reports. Not “did the job say it worked,” but “is the row there.”

That is the brilliant jerk. He reports success: commit count fine, tickets closed, standup crisp and technical and slightly condescending. The report is green. The effect is that your best mid-level engineer took a recruiter call last Tuesday, support stopped filing bugs against his service, and nobody on that team has proposed a risky idea in eleven months.

So hire the way I recovered those 576 records. Do not measure brilliance, which is a report. Measure effects. Who stayed. Who got better while sitting next to him. Who is willing to say “I broke it” in a channel where other people can see.

The counter-case, same house. In commander-in-chief, my Godot game project, CODE_OF_CONDUCT.md opens with “Be excellent to each other, and to the sim,” and carries a real enforcement ladder: correction, warning, temporary ban, permanent ban. The defect file in that same repo, re-triaged 2026-07-28, wears two badges at the top: open 54, resolved 68. The 54 break out as 2 major, 37 minor, 15 cosmetic, and zero critical.

Fifty-four open findings is not a flex. It is me publishing a badged list of 54 things wrong with my own game. Nobody got humiliated in a code review to produce that list, and the reason is boring rather than noble: it is a test-first deterministic codebase, so the standards live in the tests instead of in one guy’s head. One small project, so take it as a demonstration.

PAR Program, 2012 to 2015. Twelve people, six in the office and six remote. One of them was the four-year guy at the top of this chapter, and he is mine: I hired him, I signed his checks, I read his tickets. He owned the payment retry logic. I told myself that code was too expensive to re-learn, which is the sentence a CEO says right before he loses somebody good, and I lost at least two of them, both nicer and both cheaper. I kept the one who could write the payment code and ran off the two who could have written it. That is CEO math, performed by a CEO, at $12M-exit velocity (GoSocial, November 2015). No HR file, no exit interview, no write-up in any repo I own, so take it as recollection and not a record.

And nobody has published the before-and-after. I went looking for two numbers around a toxic engineer’s exit date, tickets per week or departures per quarter, and found none. Gregg in 2017 and Bowley in 2024 describe the damage; neither counts it. This chapter is an argument with receipts on the edges, not a measurement.

The quiet failure

The loud failure is the guy screaming in a code review. Everyone sees it and HR gets an email.

The quiet failure:

You do not fire him. You stop hiring anyone who would have to work with him.

The team stays small because a bigger team means more exposure. You have built the entire org chart around one man’s temperament and called it focus in the board deck. I have written that deck.

Second quiet failure: you replace the wrong skill. You look at AI closing the coding gap and conclude you need fewer people. What you need is a different intake filter. The fundamentals have to be there, and if they are not, the model will happily help someone produce confident garbage at volume. Past that bar, the ranking changed. In 2015 I would have taken the sharper engineer. In 2026 I take the one who will call the customer back.

Third: you mistake conflict for standards. Some of the best engineers I know will tell you your design is wrong in front of people and are not assholes: they are arguing about the work and update when you show them a measurement. The jerk is the person whose disagreement is about rank. Anyone who spent 1998 on Usenet can tell the two apart in one post: “your benchmark used the wrong MTU” versus “RTFM, this has been covered.” Same technical content, one of them is recruiting for a war.

Do / don’t

Do

Don’t

Where this sits in the book

Ch. 54 is what the work became once the model does the typing; this chapter is the staffing consequence: if typing is commodity, you hire for judgment and character, not talent bundled with contempt. Ch. 60 aims the same argument at the candidate’s side of the table. Ch. 15 is the mechanical cousin of “Everything Reported Success”: a report is not an effect, whether it comes from a health check or a performance review.

Sources and receipts

Thesis is Jeremy’s (AI leveled coding knowledge, so tolerating brilliant jerks lost its excuse): argument, not citation.

Verified:

What I could not verify: