The useful part of this story is not that a social post spread quickly. It is that AI workflows are moving from developer tools into everyday office tasks, where adoption depends on reliability, oversight, and measurable time savings.
- Workplace AI impact is usually task-by-task, not a simple replacement story.
- Companies need measurable productivity gains, policy clarity, and worker trust.
- The strongest analysis separates adoption signals from short-term hype.
For more context, see the AI at Work section.
The vibe: “This feels like February 2020”
— Matt Shumer (@mattshumer_) February 10, 2026
Shumer frames the moment with a pandemic-style analogy: a period where most people hear the warnings, shrug, and keep living normally—until a fast cascade makes “it’s probably fine” look naïve in hindsight.
The point isn’t the exact comparison. It’s the psychological pattern: weak signals, social disbelief, then rapid normalization.
He says he’s writing for “non-tech friends and family” because the polite cocktail-party version of AI (“useful tool, sometimes wrong”) no longer matches what power users are seeing in paid, frontier models.
In his telling, the perception gap is the real risk: people can’t prepare for what they refuse to notice.
His big claim: coders weren’t singled out—coding was the on-ramp
Shumer argues that AI labs prioritized coding first for a strategic reason: code is both a domain and a lever. If models get good at writing and debugging software, they can accelerate the creation of the next generation of models, tooling, and infrastructure. In other words, coding wasn’t merely a lucrative use case—it was the shortest feedback loop.
That loop, he suggests, has now matured. And once “AI that can ship software” exists, the natural next step is to apply the same playbook—benchmarks, tooling, product integrations, and agentic workflows—to other white-collar work.
Not “in a decade,” he insists, but within a small number of years.
What changed (in his words): from helper to finisher
The most provocative part of the thread is experiential rather than theoretical. Shumer describes a shift from “AI as autocomplete” to “AI as an end-to-end worker.” He claims that instead of iterative back-and-forth, he can describe a product in plain English, step away, and return to something close to a finished result: architecture choices made, UI flows defined, code written, and even basic testing/iteration performed.
He goes further and claims something that used to be treated as a boundary: not just correctness, but “judgment” and “taste.” Whether you agree with that interpretation or not, it captures what’s actually unsettling about modern systems: they increasingly look like decision-makers, not just calculators.
The “you tried AI and it was mediocre” rebuttal
Shumer anticipates the most common pushback: many people tested AI earlier, found hallucinations and shallow answers, and mentally filed it under “impressive demo, unreliable tool.” His counter is that the timeline matters.
He claims that the delta between older public experiences and current frontier experiences is so large that it makes casual skepticism dangerously outdated.
He also emphasizes an adoption detail that often gets ignored: most people judge AI through free tiers, default settings, or lightweight prompts. Power users, he argues, are running the best models available, pushing them with real documents and real workflows—contracts, spreadsheets, memos, structured decisions— and seeing capabilities that don’t show up in quick “ask it a question” tests.
Speed: the “task length” idea (and why it’s more intuitive than benchmark scores)
One of the more concrete concepts in the thread is about autonomy measured in time: how long a task (as measured by expert human effort) a model can complete successfully end-to-end without help. Shumer references the idea that this “time horizon” has been increasing—minutes to hours—and that the slope appears to be steepening.
The exact numbers matter less than the mental model. If systems can reliably finish multi-hour tasks, they can begin to swallow roles that are largely composed of chained, screen-based tasks: research → synthesize → draft → revise → produce deliverable → sanity check → ship.
That’s a lot of modern office work.
“AI is helping build the next AI” (his acceleration argument)
Shumer highlights a second accelerant: using AI to improve the process of building and deploying AI. This is the recursive loop that makes people reach for phrases like “intelligence explosion.” Even without sci-fi assumptions, the practical version is straightforward: if models make researchers and engineers meaningfully more productive, progress compresses.
His conclusion is that we should expect faster iteration cycles, faster deployment, and faster diffusion into products. Whether you find the leap convincing or not, the directionality is hard to dispute:AI is already part of the tooling stack used to create software, documentation, tests, analysis, and operational workflows.
Jobs: not “one skill at a time,” but broad cognitive substitution
Shumer’s employment warning isn’t about a single task category. He argues that the disruptive nature of AI comes from generality: reading, writing, summarizing, analyzing, and deciding are cross-domain primitives.
If those primitives get cheaper and better, the surface area is massive—law, finance, accounting, consulting, content, research, customer support, and internal operations.
Importantly, he doesn’t claim every job disappears overnight. His thread reads more like: junior work gets hollowed out first; “assistant-level” throughput rises; and headcount needs shift as one person plus AI can output what a larger team once did.
His practical advice: get ahead of the curve, not paralyzed by it
Shumer ends with prescriptions. A few themes repeat:
Use AI like a coworker, not a search engine. Feed it real inputs from your work, ask it to produce real deliverables, and iterate until you understand what it can and can’t do.
Don’t protect your ego. He argues that status doesn’t help if the workflow is changing; experimentation does.
Build basic financial resilience. Not because collapse is guaranteed, but because volatility is likely.
Move toward what’s harder to replace. Trust-based relationships, physical-world work, regulated responsibility, and roles where accountability can’t be fully offloaded.
For younger generations, optimize for adaptability. He suggests the “safe career ladder” advice may age poorly in a world where tools and job definitions mutate quickly.
The counterweight: where his thread may overreach
The reason this post sparked controversy is also obvious: it’s written in a “wake up now” register. That can blur an important distinction between capability and deployment. A model doing something in a controlled workflow is not the same as an industry adopting it at scale, integrating it safely, assigning liability, updating regulation, and changing budgets and org charts.
There’s also the reliability problem: “good enough to amaze” is not always “good enough to replace.” Many domains—medicine, law, finance—aren’t just about producing plausible text. They require verifiable correctness, stable behavior under edge cases, auditability, and clear responsibility when errors occur.
Still, even critics tend to concede the thread’s central usefulness: it forces a shift in framing. Not “AI will get better someday,” but “AI is already changing workflows, and the next wave is about moving the coding playbook into other forms of knowledge work.”
Shumer’s thread is less a forecast with perfect timestamps and more a signal about direction: coding was the proving ground because it offered the tightest loop between models, tools, and measurable output.
Now that loop is being recreated elsewhere, and the practical question becomes personal: are you treating AI as a novelty you occasionally test, or as a force you deliberately train with—before your competitors do?
