AI Is Splitting Development Teams: The Joyful “Lazy” vs the Broken “Craftsmen”
The article argues that AI‑driven “tokenmaxing” is polarizing software teams into a carefree “Lazy” faction that outsources all coding to AI and a overburdened “Craftsmen” faction drowning in massive, low‑quality PRs, eroding mentorship and long‑term engineering skills.
The Lazy’s Celebration
Deedy Das describes a new class of engineers he calls the “Lazy” (or “托管派”). Their workflow is entirely AI‑driven: they glance at a Jira ticket, hand the description to Claude, generate code with a single click, and submit a pull request without testing, refactoring, or even reviewing the changes. When senior engineers raise concerns, they simply forward the question to the AI, paste the answer back, or let the AI draft a polished stand‑up report. In their view, software engineering has become a performance to prove they are “smart and hardworking” by offloading everything to AI.
The Craftsmen’s Collapse
The opposite group, the “Craftsmen” (or “守夜人”), bears the cognitive overload of maintaining and debugging the AI‑generated code. Their PR queues contain dozens of reviews, and they spend hours dissecting hidden bugs in 20,000‑line PRs produced by the Lazy. After they propose thorough fixes, the Lazy discard the advice, ask the AI to rewrite the code, and merge the new, still‑buggy version. This creates a vicious loop where massive, low‑quality code (“Slop Cannons”) repeatedly floods the codebase, leading to system instability and eventual collapse.
The Cost of Tokenmaxing
Management promotes “Tokenmaxing” – the belief that more tokens (AI usage) and higher LOC growth equate to higher productivity. They even deploy AI‑powered code‑review bots to evaluate AI‑written code, creating a feedback loop where models audit themselves. In large, bureaucratic firms, this metric drives impressive PPT charts of doubled commit volumes, while months later the system crashes under the weight of hundreds of thousands of lines of opaque, “black‑box” code.
The Vanishing Mentorship
Traditional mentorship—code reviews, design discussions, and painful debugging—has eroded. Junior developers no longer seek guidance from seniors; they request instant patches from Claude without understanding the underlying mechanics. This accelerates skill atrophy: after a few years, engineers who rose from junior to senior can only write prompts, lacking the ability to diagnose network issues, deadlocks, or memory leaks.
Conclusion: Reclaim Craftsmanship
Das warns that without a conscious effort to restore craftsmanship—insisting on reading, testing, and understanding every change, rejecting blind AI‑generated code, and preserving human judgment—software development risks becoming a “technical hell” of black‑box code. The article calls for engineers to reclaim ownership of their code and rebuild the spirit of craftsmanship.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
TonyBai
Tony Bai's tech world (tonybai.com). Not satisfied with just "knowing how", we strive for mastery. Focused on Go language internals, high-quality engineering practices, and cloud‑native architecture, exploring cutting‑edge intersections of Go and AI. Gophers who pursue technology are welcome—follow me and evolve with Go.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
