Pallas Advisory logo

Developers using AI are 19% slower—but believe they’re 20% faster. That 40-point perception gap reveals why AI job-loss predictions (which range from 9% to 47% using the same data) are missing the point entirely. The real insight: AI adoption is a management problem, not a technology problem—and the skills that make it work are ones…

AI Can Complete Your Tasks. It Can’t Do Your Job. Here’s the Difference.

Why the panic about AI replacing knowledge workers is missing the point—and what SMB owners should focus on instead

A DeepMind researcher recently said he feels “like a horse” in the age of cars—”defeat is inevitable.” An Anthropic employee admitted he’s “trying to figure out what to care about next.” A verified FAANG engineer’s Reddit post about “paralyzing, complete, unsolvable existential anxiety” went viral with 700+ upvotes.

Meanwhile, in an actual controlled study, experienced developers using AI tools took 19% longer to complete their work than those coding without AI.

But here’s the twist: those same developers believed AI had sped them up by 20%.

The perception-reality gap is almost 40 percentage points. And it tells you everything about why the current panic about AI and jobs is built on a fundamental confusion.

Tasks Are Not Jobs

The anxiety flooding tech circles comes from benchmark studies showing AI can now complete software tasks that take humans several hours. Two years ago, AI could only reliably handle nine-minute tasks. The trend line looks terrifying.

But the researchers producing these benchmarks flag limitations that the doomers conveniently skip. The tasks are mostly coding tasks. Success rates hover around 50-80%—”somewhat reliable,” not actually reliable. And there’s no established method for translating “AI can do X% of tasks” into “Y% of jobs will disappear.”

This isn’t a minor methodological quibble. Predictions using the same underlying data range from 9% to 47% job loss, depending on how researchers draw the line between tasks and jobs. As Harvard Data Science Review noted this fall, every major job-loss prediction with a deadline that has passed “appears to be wrong—some by massive amounts.”

The confusion is understandable. Tasks are measurable. Did the code compile? Did the test pass? Jobs are not. A job is context, judgment, organizational politics, implicit requirements, and a thousand micro-decisions that never show up in any benchmark.

When the Benchmark Meets Reality

The METR developer study is worth sitting with. These weren’t novices fumbling with new tools. The 16 participants averaged five years and 1,500 commits in their repositories. They used frontier AI tools—Cursor Pro with Claude 3.5/3.7 Sonnet. The tasks were real issues from their own codebases: bugs, features, refactors.

And they got slower.

The researchers identified several factors: developers may have been overoptimistic about when AI would help and used it on tasks they’d have done faster alone. The repositories had high quality standards and implicit requirements—documentation norms, testing coverage, formatting rules—that took humans years to learn and that AI kept violating. The AI generated code that looked right but required extensive cleanup.

In other words: AI crushed the task. The developers still had to do the job.

I’ve lived this. On a client attribution project, Claude calculated a beautiful 1.90 ROAS. The math was technically perfect. Executives would have loved that number.

There was just one problem: the calculation included all revenue—organic, direct, and paid—against only paid advertising spend. The business logic was nonsense. Real ROAS: 0.14.

I caught it because the number felt too optimistic compared to industry benchmarks. I asked Claude to walk through the calculation step by step. That’s when the logical flaw became obvious. We relabeled the metric, explained the limitation upfront, and shipped something executives could actually trust.

The task—calculate ROAS—was completed flawlessly. The job—catch business logic errors before shipping wrong numbers to stakeholders—required human judgment the AI couldn’t provide.

Why SMBs Have an Advantage (Really)

Here’s what the AI-insider panic misses: the work that’s hardest to benchmark is exactly the work that defines most SMB operations.

The impressive AI benchmarks come from well-scoped software problems with clear success criteria. Did the code pass the tests? Did the pull request merge? Enterprise software development—with its documented requirements, established codebases, and algorithmic evaluation—is uniquely suited to task-level measurement.

Your work doesn’t look like that.

You’re managing vendor relationships where the real negotiation happens in what’s left unsaid. You’re making hiring decisions based on cultural fit no algorithm captures. You’re catching scope creep before it becomes a $12,000 problem. You’re pivoting strategy based on a customer conversation that revealed something the data never showed.

And unlike enterprises trapped by legacy systems and sunk costs, you have what I call architectural freedom. You’re not trying to bolt AI onto decade-old workflows designed for different technology. You can redesign from scratch, building processes around what AI actually does well rather than forcing it into roles it can’t fill.

A manufacturing client learned the cost of skipping this step. They adopted four AI tools for content creation—ChatGPT, Jasper, Copy.ai, Canva’s AI features. Software costs tripled. Output increased 400%. Their marketing manager started working until 8 PM instead of 5:30.

Why? They’d automated content creation when the actual bottleneck was content approval and posting. Two hours weekly on creation, eight hours weekly on workflow management. They spent six months optimizing the wrong problem because nobody did the job of identifying where the friction actually lived.

The Reframe: It’s a Management Problem

Wharton professor Ethan Mollick put it perfectly in a LinkedIn post this week:

“When you see how people use Claude Code/Codex/etc it becomes clear that managing agents is really, unsurprisingly, a management problem. Can you specify goals? Can you provide context? Can you divide up tasks? Can you design checkpoints? Can you give feedback? These are teachable skills.”

Read that list again. Specifying goals. Providing context. Dividing tasks. Designing checkpoints. Giving feedback.

That’s not a new AI competency. That’s management. And if you’re running a business, you already do this—with employees, contractors, vendors. The skillset transfers.

Look at every failure I’ve described through this lens:

The METR developers got slower because they couldn’t specify when AI would actually help versus when they’d be faster alone. They lacked checkpoints to catch AI output that violated implicit repository standards.

My ROAS catch? I had a checkpoint: “Does this number make business sense?” That single question—a management instinct, not a technical skill—prevented shipping garbage to executives.

The manufacturing client? They failed at the first step: specifying the goal. They assumed the bottleneck was content creation. Nobody divided the workflow into components to see where time actually went.

This is what I’ve called the shift from task-doer to AI director. You’re not competing with AI on task execution. You’re managing it. And management is a skill you can improve—through practice, through frameworks, through better questions.

Mollick also flagged something important about where this is headed: the current tools aren’t designed for this. Command-line interfaces built for coding aren’t great for managing dozens of asynchronous tasks over long timelines. A big question for 2026 is whether AI labs will rethink the experience to support delegation beyond software development.

But you don’t have to wait for better UIs. The management fundamentals work now. Specify the goal. Provide context. Design checkpoints. Give feedback. These aren’t features to be shipped. They’re skills to be practiced.

The Actual Anxiety

The Reddit post that sparked this panic included a revealing line: “The anxiety comes from treating uncertainty as a problem to be solved instead of a condition to be lived with.”

That’s the real issue. Not four-hour coding tasks. Not benchmark trend lines. The anxiety is about ego—about being the smartest thing in the room.

But your job was never about being the smartest thing in the room. It was about applying judgment in conditions of uncertainty. Building relationships that survive mistakes. Making decisions when the data is incomplete and the stakes are real.

Those capabilities aren’t on any benchmark. And they’re not going anywhere.

The people panicking loudest are the ones whose identity was built on being the smartest. The rest of us have work to do.

Where This Gets Practical

The manufacturing client spent six months automating the wrong bottleneck. Most businesses I work with have a version of this—friction they’ve normalized, workflows they’ve never mapped, AI tools layered on without a management structure underneath.

If you’re not sure where your actual bottlenecks are, or whether your current AI setup is helping or just creating the feeling of productivity, that’s the work I do. No pitches, just a conversation about where the friction actually lives.


Sources and Further Reading

Leave a Reply

Discover more from Pallas Advisory

Subscribe now to keep reading and get access to the full archive.

Continue reading