惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
P
Proofpoint News Feed
L
Lohrmann on Cybersecurity
S
Secure Thoughts
Attack and Defense Labs
Attack and Defense Labs
人人都是产品经理
人人都是产品经理
Stack Overflow Blog
Stack Overflow Blog
W
WeLiveSecurity
O
OpenAI News
SecWiki News
SecWiki News
博客园 - Franky
NISL@THU
NISL@THU
Microsoft Azure Blog
Microsoft Azure Blog
T
Tor Project blog
Microsoft Security Blog
Microsoft Security Blog
aimingoo的专栏
aimingoo的专栏
Security Latest
Security Latest
H
Hacker News: Front Page
Google Online Security Blog
Google Online Security Blog
P
Privacy & Cybersecurity Law Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
D
Darknet – Hacking Tools, Hacker News & Cyber Security
月光博客
月光博客
李成银的技术随笔
Spread Privacy
Spread Privacy
F
Full Disclosure
F
Fortinet All Blogs
T
The Exploit Database - CXSecurity.com
Vercel News
Vercel News
AWS News Blog
AWS News Blog
WordPress大学
WordPress大学
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
V
Visual Studio Blog
J
Java Code Geeks
博客园 - 三生石上(FineUI控件)
G
Google Developers Blog
云风的 BLOG
云风的 BLOG
博客园 - 司徒正美
Engineering at Meta
Engineering at Meta
Last Week in AI
Last Week in AI
P
Palo Alto Networks Blog
宝玉的分享
宝玉的分享
T
True Tiger Recordings
N
News and Events Feed by Topic
酷 壳 – CoolShell
酷 壳 – CoolShell
Cisco Talos Blog
Cisco Talos Blog
N
News | PayPal Newsroom
S
SegmentFault 最新的问题
Jina AI
Jina AI

DEV Community

Pretty normal Flutter MCP Toolkit v3 Google Just Shipped Gemini 3.5 Flash. Here's What Developers Actually Need to Know. 🔐 Working with Private Symfony Recipes Rate limiting in web apps: what to protect before picking a library Rate limiting en aplicaciones web: qué proteger antes de elegir una librería What Are Lakehouse Catalogs? The Role of Catalogs in Apache Iceberg What It Really Takes to Become a Senior Software Engineer Microservices Were Never About Technology JS Crime Scene: The Misleading Array Project-as-code for a Directus v9 backend When the API literally burned your database after a typo COOKIES DPRK Hacking Trends 2026: AI‑Powered Supply Chain and Developer Environment Attacks Phone control for AI coding sessions is not a tiny terminal PayPal and Crypto Are Not Equals: How I Built a Gumroad Alternative for Restricted Countries Exploring Tech as a Content Writer I Raised Gemma 4's Token Cap. The Dense Model Stopped Refusing. React Server Components Don't Make Your App Fast by Default Multi-Stage Builds for a Next.js App — Reduce Image Size by 70% I Built a Chrome Extension That Teaches Vocabulary While You Browse Why I Walked Back from Next.js and RSC to a Plain SPA and a Separate Backend NeuralPocket: Private On-Device AI with Gemma 4 — Android & Web Github Speckit: Revolucionando o Desenvolvimento com SDD Cloud Cost Elasticity I Built a Payment System for Bangladesh—Heres Why Stripe Failed Us Polyglot Persistence in Microservices: Choosing the Right Database for Each Service Centralized Authentication for a Multi-Brand Laravel Ecosystem How I made a perfect recording button. Simple yet complex thing. Mumbli – my personal Wispr Flow Getting Paid Should Not Be a Geopolitical Nightmare: My NOWPayments Integration Story Four Layers of Validation in Kubernetes with Claude Code Prompt Flow — a visual side project for flow design, trace, and integration steps (looking for feedback) AI Citation Registry: Temporal Gaps in Government Publishing Cycles ShowDev: I built a 100% local, zero-upload PDF editor using WebAssembly JavaC Written by an AI Pipeline, Verified by Three Models. Is It Slop? Part1 Vulkan: Drawing Triangle 1 Why I Stopped Using useEffect to Sync State — and What I Use Instead Por qué dejé de usar useEffect para sincronizar estado y qué uso ahora Migrating a Long-Running WordPress Site to Payload CMS (And All The Chaos That Came With It) Hidden Partitioning: How Iceberg Eliminates Accidental Full Table Scans Azure DevOps Structure Explained: Organizations, Projects, and Repos Without the Mess A Simple React Hook for localStorage State, Expiry, and Sync I sold you on /scratchpad. Then I migrated to /note. Fixing WSL Errors on Windows 11 Your app is not Netflix. Stop building like it is. Resolving inter-service communication issue I built an email cleaner. CSV parsing took longer than the actual validators. How I Would Learn Full-Stack Development in 2026 If I Started From Zero Partition Evolution: Change Your Partitioning Without Rewriting Data What Google Play's I/O 2026 Updates Look Like From a Solo Indie Puzzle Developer Forgetting the Myth of "Ease of Integration" When Selling Digital Products with Bitcoin My 4-Step Regex Debugging Workflow (That Actually Saves Time) Stop Scraping Betting Sites: How to Build a Real-Time Sports Tracker in Python Civic Identity and Responsibility in Modern Democracy OLTP vs OLAP Are binaries really executable code ? The lie of the 80%: why software progress charts don't work What a Datacenter in Space Actually Buys You: Three Server Racks Is AI Actually Citing Your Site? How to Measure What Google Rankings Can't Accessibility - This looks like a job for a developer advocate! I built a Mac app that turns web pages into live widgets How to Teach Source Evaluation When Your Students Use ChatGPT More Context Does Not Mean More Trust RAG Series (24): Code RAG — Teaching AI to Understand Your Codebase Past the JVM Design decisions behind my “Irregular German Verbs” iOS app WordPress 7.0 "Armstrong" Is Live — Post-Release Deep Dive 🎺 Performance and Apache Iceberg's Metadata I Shipped a Bug to Production That Cost Us 3 Hours of Downtime 程序人生:在代码与时间之间 The Wrong Way to Think About XRPL Event Infrastructure What I Learned About MND, Voice Banking, and Why Assistive Tech Is Personal $1.50/Month Email Infrastructure That Beats Your $20 SendGrid Plan Cloud Unit Economics: The Metrics DevOps and FinOps Teams Actually Need Bypassing Payment Platform Restrictions Was The Best Decision I Ever Made For My Digital Product Business The Hidden Life of a Container: A Complete Lifecycle When a port is already in use, there is no interactive way to find it — so I built `port-peek` Como Sumir com o Barulho do Teclado Mecânico no Ubuntu Usando o NoiseTorch Google I/O 2026 dropped a bomb on Android tooling, and nobody's talking about it (or maybe they are 😅) Mentoring Junior Developers: What Actually Works How I Prevented Claude Code from Breaking My Architecture with 18 Tests That Run in 0.4 Seconds I Controlled an ESP32 Drone Using Only My Voice vite HMR is silently the reason ur laptop fan wont stop AI Agents Security for Developers: Don't Let Your Agents Become a Liability Single List Keyboard Handling 9 SaaS development companies worth knowing (a technical look) Material Nova — The Best VS Code Theme of 2026 Inference Routing Is Becoming an Infrastructure Placement Problem I just build a League MBTI Analytics Why I Built My Own Site with Astro, Not WordPress when I use WordPress for a Living Hello! I'm a balloon artist who started 3D modeling 7 Next.js 16 Caching Bugs That Compile Fine and Break Silently in Production I got tired of writing READMEs so I built a tool that generates them from your GitHub URL FrontGate: a Lightweight Package Proxy for Supply Chain Security Why Your Expense Tracking Architecture Keeps Breaking Stop your AI trading agent from hallucinating technical analysis Breaking the Monorepo Barrier in a Crypto Store for Digital Products Imposter Syndrome Is Something We All Struggle With at Some Point in Our Careers
Both Camps in the 'Left Behind' Argument Are Right About Each Other
Arthur · 2026-05-21 · via DEV Community

There's a small, angry post on a bear blog called migraine brain that's been on Hacker News for a few days now. The whole post is three paragraphs. It opens: "'People who don't use AI will be left behind,' they say. I can't emphasize enough how much I hate it when I hear/read shit like that because I'm pretty sure, in fact, that what will happen is the exact opposite."

The author's argument is brisk: AI-reliant people are the ones who will be left behind. They'll forget how to think, how to write, how to do a simple reliable search, how to tell fact from fiction. They'll forget — in the original phrasing, with a stronger word for emphasis cleaned for republication — "how to freaking LEARN" [the original used a four-letter intensifier in that slot; the linked post has the unmodified line]. "What a beautiful thing it is just to learn stuff."

The post is short, the language is cleansed of nuance on purpose, and it landed 255 comments deep on the same Hacker News front page where, on any given week of 2026, several other posts are running the inverse argument: that you adapt or die, that the productivity multiplier is real, that two years into agentic coding the people who refused to learn the workflow will be the ones explaining themselves at every job interview.

Both camps are right. They are right about each other. The whole conversation has been an argument about which kind of left behind is the worse failure mode, conducted by people who don't agree on which failure mode is real.

The competence-erosion case

The blogger's case is more interesting than its delivery. It is not, mechanically, an argument against AI tools. It is an argument that the practice of using them — particularly the agent-style, hand-it-the-task delegation pattern that 2026 software development has converged on — atrophies the underlying skill, and that in a non-trivial fraction of cases the underlying skill was the actual job.

The Hacker News thread runs heavy on testimony for this side. "It is easy to shut off your brain when using AI and then get overwhelmed by the amount of code it produces," one commenter wrote. "I have seen a lot of really bad AI code. I can spot and repair it. Others can not." That distinction — I can spot and repair it, others can not — is the whole game. The bad-AI-code-spotting skill is the one that erodes when you stop reading code, and reading code is the one thing the agent will do for you if you let it.

Another commenter framed it physiologically: "Just as many people leading sedentary lifestyles have to make a deliberate effort to exercise, because inactivity is really bad for our bodies, I think we're going to realise that a similar process is necessary for our minds. Coding used to kind of give you this exercise for free, but you can go really far with just your System 1 nowadays — literally get things done while scrolling Reddit." The get things done while scrolling Reddit part is the indictment. The agent has reduced engineering for some fraction of tasks to skim-and-approve, and the skim-and-approve loop trains a different set of muscles than the read-and-build loop did.

The sharpest version of the competence argument in the thread came from a reply to a productivity-pitch line — that "a person working with a bunch of agents is a lot more productive than just a person." The reply: "A tool being smarter than me but inconsistent is useless. I can work with people who are smarter than me, because I can trust them, and I can trust them to own up or be held accountable for screw-ups. For a calculator, I can only hold myself accountable. However I cannot hold myself accountable for not knowing something I don't know." That's the argument that the blogger is making, expressed as accountability rather than as anger. The competence loss is not just about the tasks the AI does for you; it's about the meta-skill of would I have caught that if it were a human peer's mistake. That meta-skill comes from doing the work yourself, and it depreciates if you don't.

The competence-erosion case has a real failure mode it's pointing at, and the failure mode does not require you to believe that AI is bad or fake or hyped. It only requires you to notice that the human cognitive system, like the human muscular system, defaults to atrophy without practice. In 2026 the supply of practice is rapidly contracting.

The productivity-displacement case

The opposing case is at least as well-defended in the thread, and at least as concrete.

It runs roughly: the agent-driven workflow is real, the productivity gains are real, and the people who refuse to learn the workflow will become unhireable in the same way that someone who refused to learn to use a compiler — preferring to stay in assembly because it kept the skill — would have made themselves unhireable in the 1990s. "I mean, that works for you since you're retiring," one commenter replied to a senior engineer's farewell-to-the-industry post. "But for people still working in the industry, you adapt or die. As it's always been."

The productivity-displacement camp's strongest argument is not the multiplier claim. It's that the skill of delegation itself — knowing when to hand the agent a task, what context to give it, when to trust the output, when to pull the work back — is a real and emerging skill. "Understanding the optimal work flow for what to delegate and what to do yourself is difficult. Understanding the need for precision in the language used, and learning how to elegantly phrase things that were previously just abstract thoughts is absolutely a talent that can be refined."

This is not a fake skill. The same loop that erodes the read-and-build muscle in the competence-erosion frame is, in this frame, building a different muscle — one that is closer to architectural review than to line-level coding. There is a non-trivial population of working engineers, two years into AI tooling, who report that their judgment about what is worth building has sharpened precisely because the cost of building is no longer the gating factor.

The most direct reply to the blogger's "I love learning" framing in the thread also came from Simon Willison. Quoting the blog's exact line back, he wrote: "I love learning. My life of self-education is so much richer with LLMs to help me. There are dozens of other arguments for not engaging with AI. If your reason is 'I love learning' I recommend at least dipping your toes in before you declare that AI is a hindrance, not a help, to people who love to learn new things." This is the inverse of the competence-erosion argument from someone who has been running the experiment longer than almost anyone publicly. The blogger and Willison are not actually arguing about the same thing — the blogger is talking about learning as discipline, Willison is talking about learning as access — but Willison's reply is the version of the productivity-pitch that doesn't reduce to "adapt or die." It's "the door is wider; come in."

The productivity-displacement case is also right that the dual failure mode — people who use AI badly — is real. "Some people who do use AI will also be left behind," one commenter put it, "those who use it to replace their skills without developing new ones themselves, and those who use it to do the same or worse work more cheaply. They will be left behind in a competitive world where others will work out how to use it to do more or better work with no reduction in effort." That's not the blogger's argument. But it's not far from it.

The "is it a skill" dispute

The single most-concrete disagreement in the thread is the one that decides which of these cases lands harder. Some commenters argued that AI tooling is essentially a weekend learning curve. "Any engineer can 'learn to use AI' in a couple of days," one wrote. "It's not rocket science; there's no chance of left behind. If you haven't used LLMs at all, a weekend would be enough to be on par with everyone else in the industry."

The most credentialed reply in the thread came from Simon Willison — handle simonw, an almost-daily LLM user for nearly three years, and one of the most prolific public chroniclers of working-developer LLM use: "Firmly disagree. Learning how to use these tools effectively is unintuitively difficult. They're great at some stuff and terrible at other stuff in ways that are very hard to predict. I'm figuring out new and better ways to use them in a daily basis, and I've been an almost daily user for nearly three years."

This isn't really a contradiction. It's two different answers to two different questions. "Can you sit down at ChatGPT and produce something that looks like work?" is a weekend curve. "Can you reliably tell which work the model is good at and which work the model is going to make worse?" is a multi-year curve, and according to the person who has spent three years on it, the bottom of the curve is not visible yet.

The skill-curve question is also where the two camps' arguments collide most usefully. The competence-erosion frame is largely pointing at people on the early part of the curve — people for whom AI has reduced the practice of judgment to approve / approve / approve. The productivity-displacement frame is largely pointing at people on the later part of the curve — people whose judgment about when not to use the agent is itself the productive skill. Both populations exist. They're not the same engineers.

The asymmetric failure modes

The strongest single move in the thread came from a commenter early in the discussion: "Some people who don't use AI will be left behind. Some people who do use AI will also be left behind." That isn't a hedge. It's the actual structural answer.

Both camps are arguing that you can lose your seat at the table. They disagree only about which seat-loss is worse, and they disagree because they're standing in different places. The competence-erosion camp is mostly people in mid-to-late-career engineering roles where the value of the work is the judgment, and the judgment can be eroded faster than you can replace it. The productivity-displacement camp is mostly people in industry-facing or early-career engineering roles where the table is already moving, and refusing to move with it has a velocity cost that compounds.

The blogger and the productivity-pitch are both correct in their own population. They are both wrong about the other population. The actual question — which one each individual reader should be optimizing against — is answered by where you sit, not by which slogan won this week's HN front page.

What this asks of us

The reason the conversation is exhausting in 2026 is that both "AI will leave you behind" and "AI will leave the people who use it behind" are operating as identity claims at this point. The slogan you repeat marks which side of the argument you're on. The argument is not actually about AI. It is about which kind of agency-loss you are most afraid of.

Agency-loss to a tool that is smarter than you but inconsistent — the "cannot hold myself accountable for not knowing something I don't know" problem — is a real fear, and don't use the tool is a defensible response. Agency-loss to the labor market — the table moved without you — is also a real fear, and learn the tool, including its boundaries is a defensible response. Both are responses to real threats. The wrong move is pretending the other person's threat is fictional.

The migraine-brain blogger's daily practice of writing without an LLM, of doing a search the slow way, of holding "What a beautiful thing it is just to learn stuff" as a load-bearing value — that is one valid answer to which agency-loss they're protecting against. Simon Willison's daily practice of three years of careful, public, contradictable LLM experimentation is another, for a different agency-loss. Both practices are honest; neither is a slogan.

The slogan "people who don't use AI will be left behind" is not workable; it is what you say when you do not want to do the work of figuring out which agency-loss is the one you are actually optimizing against. The blogger's response that "the exact opposite" will happen is not workable either, for the same reason. The harder question — which agency-loss is the one you are working to prevent, and what daily practice does that imply — is the one that doesn't fit on a LinkedIn post. Both slogans on the front page of the industry conversation are refusals to ask it.