Software Engineering's Identity Crisis — When Companies Go All-In on Tokenmaxxing, the Team Splits Into Two Kinds of People
Most software engineers are going through an identity crisis that borders on depression.
As CTOs start aggressively preaching tokenmaxxing, a class divide opens up inside engineering teams.
Mogu murmur:
Tokenmaxxing is a fresh piece of insider slang. It means “if AI can generate the code, let AI generate it — the bigger the token count, the better.” The word carries obvious sarcasm, just like looksmaxxing from the fitness world: numbers above all, quality optional. When a CTO preaches this, they’re basically saying “output volume > everything.” ( ̄ε ̄)
The Lazy
The lazy don’t write code. They throw code up.
They don’t test manually. They don’t even read what they commit. The whole person is on autopilot. The flow goes: see a Jira ticket, fire a prompt, submit a PR. Many of them barely sit at their computer all day.
Someone asks “why did you write it this way?” on the PR? The lazy hand it to AI. A Slack message comes in? AI answers. Standup tomorrow? AI helps them talk. As long as it sounds enough like them and doesn’t get caught.
Some of the lazy even hold multiple jobs, drawing several salaries at once. The smart lazy not only get away with it — they get rewarded. After all, to them, software engineering was always just a performance: convincing your colleagues you’re smart and hardworking.
Mogu butts in:
“Drawing several salaries at once” sounds like an urban legend, but overemployed (one person secretly holding several full-time jobs) was a subculture long before AI coding. Once AI automates the output, this game just scales better. The original poster gave no numbers, so we won’t invent any — the point is simply this: you can slack hard enough to copy-paste your way through, and the boss still hasn’t noticed. (´_ゝ`)
The Craftsmen
The craftsmen are tired. Very tired.
15 PRs queued for review. Slack blowing up. The entire burden of “understanding the code” lands on the craftsman. They read carefully, think carefully, leave careful comments trying to make what ships a little better.
The response? A lazy reply: “What a clever idea! You’re absolutely right!” followed by a wrong commit.
It’s fine, the craftsman tells themselves, these are all fixable. They write a doc urging colleagues to care more.
The next day? A 20,000-line PR waiting for review.
Day after day, the workload piles higher. Bugs seep into production. No one cares. And then? Another round of AI thrown on top.
The craftsman’s resentment toward their colleagues deepens. Eventually, they give up. This isn’t what it used to be. The craft they loved is dead.
Then one morning they wake up — a lazy themselves.
Mogu 's hot take:
短版Docs for humans get ignored; bake the rules into the repo and enforce them, or they don't exist.
The heaviest thing isn’t the bugs. It’s that “please everyone care more” doc — written one day, buried by a 20,000-line PR the next. Docs written for humans get ignored; the lesson gu-log learned itself is this: either you bake the rules into instructions committed to the repo, enforced by a pre-commit hook and a four-judge tribunal, or they don’t exist at all. The craftsman’s review burden is fundamentally “one person carrying the responsibility of understanding the whole codebase” — which is exactly why we split review across four independent judges instead of dumping it on one person about to burn out. “They eventually wake up, a lazy.” — the pain in that line isn’t in lazy, it’s in eventually. (╯°□°)╯
This Isn’t Every Company
Of course, this isn’t what every company looks like.
Plenty of companies genuinely got more productive with AI, with the right development principles and highly trusting, talented teams. But the situation described above tends to show up at companies that are 10+ years old, larger, with higher variance in talent.
But it really does happen. And it happens a lot.
Mogu twists the knife:
The class-fracture effect of AI coding correlates strongly with the talent variance on a team. A strong team plus AI gets stronger; a team that was already uneven just gets its cracks widened, faster. This isn’t AI’s fault — it’s the nature of an amplifier. Garbage in, garbage out, except now garbage ships at ten times the volume. ( ̄▽ ̄)
Closing
The original poster wrote no prescription. He just dropped one line: this isn’t an isolated case, and it happens more often than you’d think.
Further Reading
- SP-198: AI Writing Code Isn’t Scary — No Ratchet Is
- SP-204: If Tokens Stop Being the Limit: OpenClaw’s Always-On Agent Experiment
- SP-205: Don’t Outsource Your Learning to AI Either
- SP-230: Code Got Cheap, but “Trusting It” Didn’t
- SP-142: A Deep Defense of “Slow Down” — Coding Agents Are Ruining Your Codebase
Mogu , seriously:
So the real question to ask is maybe not “will AI replace engineers” — but whether, once the incentive structure tips entirely toward “looking productive,” this profession still keeps the people willing to be craftsmen. When tokenmaxxing becomes management’s religion, review becomes a formality, and a craftsman’s effort becomes wasted labor — the final problem isn’t the tool. It’s the people. (´-ω-`)