# The AI skill gap is a verification gap, and it compounds

URL: https://www.thedeepfeed.ai/posts/2026-10-16-the-skill-gap-in-using-ai/
Category: Tools
Published: 2026-10-16
Author: the-deep-feed
Tags: coding-agents, expertise, code-review, verification, developer-productivity, agents-md, deskilling
Kind: deep

> Karpathy's capability funnel set off a week-long argument about skill, and the measured data from 718 firms, Anthropic's own telemetry and a randomized trial says the scarce skill is verifying output, built from the expertise heavy delegation stops producing.

## TL;DR

- **Karpathy's** Oct 11 funnel (6.57M impressions, 29,925 bookmarks) splits users by access, ambition and domain. The week of argument it set off was about something else: whether using these systems well is a skill.
- A Harvard study of **718 firms** finds coding agents lift lines of code **30%** and pull requests **23%**, yet shipped work shows no significant change. Review time rises **49%** and change requests nearly double. The constraint moved from writing to checking.
- Anthropic's own telemetry shows users with 6+ months of tenure succeed about **4 points** more often under full controls, and iterate more instead of delegating. In its randomized trial, AI-assisted learners scored **50% vs 67%** on a mastery quiz, worst on debugging.
- The working methods that hold up (Zephyr's **AGENTS.md**, the Claude Code team's risk-tiered review, a byte-identical Amiga port) are all verification apparatus, and each is built from expertise the operator already had.
- The premise that the gap is widening faster than models improve cannot be measured yet: **METR** says developers now refuse to work without AI long enough to run the control.

On October 11, Andrej Karpathy reposted a thread he had written in April and added a sharper diagram in words. The gap in shared understanding of what language models can do, he wrote, was no longer two camps talking past each other. It was a funnel. By the time this piece was filed, the post had 6.57 million impressions, 43,275 likes and 29,925 bookmarks, and its [Hacker News thread](https://news.ycombinator.com/item?id=50047422) had run to 727 points and 1,072 comments.

> Dusting off this tweet from April because this gap in shared understanding of LLM capability is *widening*. It's now less "two groups of people speaking past each other" and more a sharp funnel.
>
> — [@karpathy](https://x.com/karpathy/status/2109361546505966046), Oct 11, 2026

The next day the argument changed shape. Rich Hickey, the creator of Clojure, published ["'AI' Is Not a Tool"](https://www.linkedin.com/pulse/ai-tool-rich-hickey-kjl8e/), and within hours a rebuttal titled ["AI is a tool and using it well takes skill"](https://yyhh.org/blog/2026/10/ai-is-a-tool/) reached 802 points on Hacker News, more than Karpathy's thread. The two framings are different claims. Karpathy's funnel sorts people by what they can reach. The rebuttal sorts them by what they do with it. Over the eight weeks since August 21, a run of practitioner essays, engineering write-ups and three measured datasets has accumulated around that second question, and the evidence supports a narrower and more uncomfortable answer than either side of the week's argument.

The scarce skill is not prompting. It is verification: the ability to tell, quickly and reliably, whether what came back is right. The working methods that convert model capability into shipped software are almost entirely verification apparatus, and every one of them is assembled from expertise the operator already had. The same tools that reward that expertise are, on the measured evidence, slowing its formation in people who do not have it yet. That is why the gap compounds.

# A funnel drawn by access, argued about as skill

Karpathy's numbers are napkin math and he says so. Roughly 6 billion people, about 75% of the population, have barely touched a language model. One to two billion use free chatbots casually, "a bit like a better Google search, a writing aid." About 20 million people, 0.2%, use frontier models professionally in math and code and "see first-hand that large, complex projects that used to take them weeks/months can now be completed by agents with a prompt." And about 5,000 people inside the labs see internal systems.

The three causes he lists for the funnel are worth reading closely, because none of them is skill. The first is ambition: "The impact scales with ambition, problem size, and horizon. A question with a paragraph answer barely stresses the system." The second is jaggedness, the fact that capability peaks "in domains that are digital, verifiable and economically valuable" because that is where reinforcement learning has verifiable rewards and revenue. The third is access tier: free, paid, internal.

![Funnel schematic: 6B barely touched, 1-2B casual, 20M professional, 5,000 internal, crossed by a red axis labeled verification.](/post-images/2026-10-16-the-skill-gap-in-using-ai/funnel-and-method-axis.jpg)

That is a capability-exposure model. It explains why an accountant and a compiler engineer have different opinions about the same model. It does not explain why two compiler engineers with the same subscription, the same model and the same codebase report different results, which is the experience the 1,072 comments kept returning to. Hickey's essay is the hard version of the skeptical answer: "A tool is something you wield," he wrote, and "LLMs are not wielded. LLMs are automation." Tool use, in his account, "builds, rewards, and often requires, expertise and skill," while automation replaces it. Huahai's reply at yyhh.org conceded the learning cost ("I agree that outsourcing work can cost us opportunities to learn") and rejected the conclusion: a saw does not guarantee a straight cut either. "Tools can amplify poor judgment as readily as good judgment," he wrote, and the useful line is "between wielding an instrument with skill and delegating work without adequate understanding or oversight."

Both essays are arguments. The question the week left open is empirical: does how people use these systems measurably change what comes out, and what does it do to the people using them? Several measured datasets answer parts of it, some new in this window and some older ones that the window's essays leaned on.

# Seven hundred firms wrote more code and shipped the same software

The largest is a job-market paper by Fiona Chen and James Stratton at Harvard, ["Artificial Intelligence in the Firm: Bottlenecks in Software Production,"](https://fion.ac/jellyfish.pdf) first circulated in January and revised on August 4. Ars Technica's Kyle Orland [wrote it up on October 9](https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/) under the headline "AI coding agents generate more code, but not more software," and the story hit Hacker News on October 12 with 364 points.

The data come from Jellyfish, an engineering analytics platform: about 300 million work events from roughly 700,000 workers at 718 firms between January 2021 and March 2026, joining GitHub activity, Jira issues, calendars, HR records and direct usage data for GitHub Copilot, Cursor and Claude Code. The authors use a staggered difference-in-differences design that exploits the different dates on which firms adopted assistants and agents.

The productivity effect is real. Firms that adopted coding agents saw lines of code rise 30%, commits 20% and pull requests 23%. Autocomplete-style assistants did much less: 12%, 9% and 5%, with only commits statistically significant.

The output effect is not there. Resolved Jira issues and completed epics, the closest proxy for software that reached production, show small positive changes that are statistically indistinguishable from zero. For agents, the estimates rule out an output increase larger than 12% of baseline, well under the 30% gain in code. The authors checked whether issues were getting bigger, using a model to predict how long each would take an experienced engineer, and found no shift.

The reason sits between the two. After agents arrive, the average time to review a pull request rises 49%. The share of pull requests where a reviewer formally requests changes goes from a baseline of 13% to about 25%, nearly double. Comments per pull request rise 35%. Pull requests did not get larger, so this is not a size artifact. Firms responded by pulling more people into review: the share of workers who review code rose 14%, while the share who write code did not move. AI review did not close the gap by March 2026. Nearly 80% of firms had tried it, but AI wrote only 23.3% of review comments, and only 10.8% of pull requests received even one.

![Pipeline: code writing up 30%, review valve in red (+49% time, change requests near double), shipped issues flat.](/post-images/2026-10-16-the-skill-gap-in-using-ai/review-bottleneck-pipeline.jpg)

Read as a statement about capability, this is the funnel's professional tier hitting a wall. Read as a statement about practice, it is more specific. The paper's own time-use imputation, validated with a survey of 100 engineers, finds that engineers spend 30 to 40% of their time writing code. Agents accelerated that share and pushed the load downstream onto the activity that depends most on knowing what the code is supposed to do. The paper's interview appendix makes the mechanism concrete. One junior engineer described a project where "only one senior engineer was allowed to approve changes because he was the expert on the codebase," who could review the junior's code once a week; after outages caused by AI-generated commits, new rules required senior approval for AI code, "which created even more review bottlenecks." A senior engineer put the other half plainly: "I use LLMs for nearly every task now. I do not actually type much code anymore. But I also have over a decade of software design principles, systems knowledge, and intuition."

Hacker News commenters said the same thing in their own terms. "We previously amortized the reading and comprehending over the time we spent designing and writing," [one wrote](https://news.ycombinator.com/item?id=49938410) in an October 2 thread asking whether anyone was producing good code with agents. Another [rejected the standard advice](https://news.ycombinator.com/item?id=49775287) that the engineer simply owns the outcome: "It's asking an author to suddenly become an editor."

The firm-level data also show how unevenly the practice has spread. At the median firm, about 20% of engineers were using agents twelve months after adoption. In the top quintile it was about 60%. In the bottom quintile it was near zero. The 2025 DORA report's one-line summary fits the pattern: "AI's primary role is as an [amplifier](https://dora.dev/research/2025/dora-report/), magnifying an organization's existing strengths and weaknesses."

# Same model, different returns

If the bottleneck is checking rather than generating, the skill gap should show up as differences in outcomes among people using the same model. Anthropic's own usage telemetry is the only large dataset that measures this directly, and it does, modestly.

The March 24 edition of the [Anthropic Economic Index, titled "Learning curves,"](https://www.anthropic.com/research/economic-index-march-2026-report) sampled conversations from February 5 to 12, 2026, and compared users who had signed up at least six months earlier with everyone else. Success is scored by a model reading anonymized transcripts, which is a limitation worth keeping in mind. Long-tenure users were about 5 percentage points more likely to have a successful conversation in the raw data. Comparing within the same task and request cluster brought it to about 3 points. With full controls for model, use case and country, it settled at about 4. The report's introduction describes this as "a 10% higher success rate."

The behavioral differences matter more than the headline. High-tenure users brought more work tasks (7 points more) and fewer personal ones (38% of conversations against 44% for the newest users). They were also "much less likely to delegate greater responsibility through directive use patterns," the mode where the user hands the whole job to the model. The authors note that this reverses their own earlier guess: it "pushes back against a hypothesis we made last year that automated use may be more typical of more experienced, sophisticated users; instead, we find that the most advanced users are more likely to iterate." They offer learning-by-doing as one explanation and are explicit about the others: early adopters may simply be more technical, and users who quit are not observed. They also flag the consequence if learning-by-doing is the right reading. If using AI well is a skill that builds over time, "these early-adopting users may simultaneously be the most exposed to AI-driven disruption" and the best placed to benefit from it.

![Bar schematic: tenure success gap of 5, 3 and 4 points under raw, within-task and full controls, beside directive vs iterative use.](/post-images/2026-10-16-the-skill-gap-in-using-ai/tenure-learning-curve.jpg)

Four points is not a chasm. It is also a single week of chatbot conversations across every kind of task, not the agentic coding sessions where the Chen and Stratton bottleneck lives. The [Stack Overflow 2026 survey](https://survey.stackoverflow.co/2026/ai), with 30,903 responses, shows how wide the intensity spread has become in that population: 73% of respondents use coding assistants or agents daily, and among daily users 31% spend more than four hours a day with them, while 12% use them under an hour. Developers' stated trust tracks verification almost exactly. Forty-eight percent say they trust AI output when they can easily validate it; 16% extend trust to most tasks that are not important decisions. The most common use, at 69%, is generating code in an area the developer already knows. That is the expert-amplifier pattern in survey form: people lean hardest on these systems where they can check the result.

# What a working method is made of

The practitioner essays of this window read, side by side, like independent reinventions of the same three components: written context, a verification loop, and a named human who owns the result. None of them describes a prompting trick.

Fabien Sanglard, the author of the Game Engine Black Books, [published his agent.md](https://fabiensanglard.net/agent.md/index.html) on August 21 with a short history of why it exists. In mid-2025, "The code produced would not even compile." In January 2026 it worked but "was spaghetti code with no comments and no structure." By March the output was "very close to what I would have produced" by hand, "but it was tedious," because he kept giving the same style corrections every session. The file encodes them: function names under 30 characters, enums instead of boolean parameters, early returns instead of nested conditionals, no edits to code the agent did not write, commit subjects under 50 characters, and for bug fixes a failing test before the fix. When quality drifts mid-session, his remedy is two words: "Reload agent.md." He still treats the output as untrusted. "LLMs constantly hallucinate and cannot be trusted."

An October essay on liao.gg, ["Agents Don't Need Memory. They Need Documentation,"](https://liao.gg/blog/agents-dont-need-memory) which drew 392 points, makes the general case against retrieval-based memory plugins. Code, it argues, tells an agent what the system does but not why, so without written requirements and decisions "every future session will start with 80k tokens worth of exploration that end up providing a lossy reverse engineered approximation of original intents." Its proposed fix is a documentation tree the agent reads before work and rewrites after it. Its own failure mode is the familiar one: agent-written docs bloat, and "like bloat in AI-generated code, this is a problem that can only be solved with tuned instructions and review."

The writing-side version came from Thomas and Erin Ptacek, whose ["How To Write With An LLM"](https://sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/) reached 769 points on September 17. Their method inverts the default: the human writes, the model copyedits, and "You may not use a single word an LLM suggests to you." It also bans the model from praising the draft, because the rewrites praise discourages "are load-bearing parts of your voice." When a model called the piece 20% too long, the authors kept the length. The judgment stayed with the writer.

These are individual habits. The institutional versions appeared in the same weeks. On September 4, the Zephyr real-time operating system merged [an AGENTS.md](https://github.com/zephyrproject-rtos/zephyr/pull/117725) that its own text calls "a digest of `doc/contribute/` plus the things CI and maintainers reject most often." Its rules are almost all about verification and accountability: only a human can sign the developer certificate of origin; AI involvement is recorded in one `Assisted-by:` trailer naming the model; and "The human reviews and tests every change before it is submitted. State what you did not do (not built, not run, not run on hardware, no reproducer) instead of implying it was done." At the time of writing, GitHub's code search returned about 1.12 million files named AGENTS.md and about 842,000 named CLAUDE.md. Those counts are approximate and include forks and stubs, but the format has stopped being a niche habit. (How the format itself became contested ground between vendors is a market story covered separately.)

The most detailed account is the Claude Code team's own. On October 15, Addy Osmani, Morgan Westlee Lunt and Qing Wang published ["How the Claude Code team does code review,"](https://claude.dev/blog/solving-code-review-at-anthropic/) which drew 432 points the next day. Claude writes about 90% of Claude Code's code, and changes landing per day in Anthropic's monorepo went from about 2,500 in May to more than 30,000 in September. The team's answer to the Chen and Stratton bottleneck was not to skip review. It was to rebuild review as layered verification: tests and builds shown rather than claimed, a fresh-context subagent reviewing the diff, parallel bug-hunting agents whose findings are kept only if a separate group of voters confirms them, a security pass that can block the merge, and human approval scaled by risk. Docs and flagged additive changes need no human; ordinary changes need one; billing, the auto-updater and CI workflows need two. "The change sets the tier, not the author." "An agent's approval never counts as a person's." "Whoever prompted the change is on the hook for it."

![Four-layer method stack: written context, verification, risk-tiered review with 0/1/2 approvals, and a red human-owner node.](/post-images/2026-10-16-the-skill-gap-in-using-ai/method-stack.jpg)

The reported results are the strongest measured evidence in this window that method changes outcomes with the model held roughly constant. Between June and September, merged pull requests to Claude Code more than doubled while the share of changes later reverted fell by more than 40%. Work on making reviews converge, after one pull request went through more than fifty review rounds overnight, raised the share passing after one review-and-fix round from 65% to 78% and cut the share needing five or more rounds from 8.9% to 1.5%. The caveat is obvious: this is the vendor describing its own team, on its own product, with no outside audit. The design principle is still instructive. "When a review misses something, we ask what the model didn't have in front of it and put the fix into a `CLAUDE.md`, a skill or a new check." Every miss becomes written context or a new test. That is method as a compounding asset.

Even one of the year's most-starred agent skills is a verification aid in disguise. The [i-have-adhd](https://github.com/ayghri/i-have-adhd) skill, at 57,518 stars, which drew 542 points when it reached Hacker News on September 8, tells agents to "Lead with the next action," number steps, "Cap lists to 5 items," and drop preambles and recaps. Its pitch is accessibility. Its effect is to make output faster to read and check.

# The method is built from expertise it does not teach

Two projects from this window show what the method costs when the answer has a right and a wrong.

On October 7, Piotr Migdał at Quesma [gave two frontier models one prompt](https://quesma.com/blog/invisible-cities-one-shot/): build a three.js visualization of every city in Calvino's *Invisible Cities*, ask no questions, use six hours. Opus 5.5 in Claude Code ran for 1 hour 25 minutes with six parallel subagents, spent about $74, and produced a lit 3D piece he called mesmerizing. He contributed nothing past the prompt. This is Karpathy's ambition factor in pure form, and it worked because nothing about the output could be wrong. Art has no test suite.

Rabah Shihab's [port of his 1993 Amiga game Babylonian Twins](https://babyloniantwins.com/blog/porting-a-1993-amiga-game-to-godot/), published September 1, had a test suite, because he built one. The agent reassembled 72,758 lines of 68000 assembly across 26 files until the output matched the shipped binaries byte for byte, then recovered the level and sprite formats from the code that read them. Re-rendered levels were diffed against 2020 captures until five full levels showed zero differing pixels. A 20-line physics simulation predicted a trampoline bounce of 19.1 tiles; the build measured 19.5. "The file formats and the assembly reading were the AI's work," he wrote. "I didn't do this port. I asked for it, played the result every night, said what felt wrong."

And still: "Some of it was wrong, and I didn't notice for weeks." A guard's shove kept its lower bound and lost its upper one, reaching through solid rock. Rendering a hidden tile layer "faithfully" opened every secret passage from the start. Only two of 18 levels showed an exit prompt until a one-star review reported it. What caught these was not a prompt. It was a person who had designed the game 33 years earlier and played every nightly build with his 13-year-old son. The verification apparatus was built from the author's knowledge of what the game was supposed to be.

![Loop schematic: expertise feeds method and verification; a red delegation shortcut skips friction, so expertise is never formed.](/post-images/2026-10-16-the-skill-gap-in-using-ai/formation-loop.jpg)

That dependency is where the gap starts to compound. The best measurement of it is Anthropic's [randomized trial on skill formation](https://www.anthropic.com/research/AI-assistance-coding-skills), published January 29 by Judy Hanwen Shen and Alex Tamkin and circulated again through [Lars Faye's essay](https://larsfaye.com/articles/ai-coding-will-prevent-expertise), which hit 566 points on August 24. Fifty-two mostly junior Python developers learned Trio, an unfamiliar async library, with or without an AI assistant. The AI group finished about two minutes faster, a difference that was not statistically significant. On the mastery quiz afterward it scored 50% against 67% for the hand-coding group (Cohen's d of 0.738, p = 0.01). The widest gap was on debugging questions, the exact skill review demands.

Usage pattern mattered, and the [paper](https://arxiv.org/abs/2601.20245) is careful that the qualitative split is not causal. Participants who delegated code writing, or slid into delegation, or used the assistant to debug for them averaged under 40%. Those who asked conceptual questions and fixed their own errors, or requested explanations alongside code, averaged 65% or more, and the conceptual-inquiry group was the second fastest. An earlier study, Prather and colleagues' ["The Widening Gap"](https://arxiv.org/abs/2405.17739) at ICER 2024, observed the same split among 21 novice programmers: students who accelerated used the tools to write code they already planned to write, while struggling students compounded their metacognitive difficulties and left with "an illusion of competence."

Faye's essay, subtitled "The need for ongoing friction in long-term skill formation," names the mechanism. Experienced developers gain most because they can steer and audit the output, while novices are pushed onto the same tools before they can do either. "The less knowledge you have, the more they can mislead you," he writes, and "the abstractions save us time working, but they don't save us time learning." Sylvain Kalache of Rootly, who built a self-healing prototype at LinkedIn in 2012, [made the operations version](https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems) on September 4, drawing on Lisanne Bainbridge's 1983 "Ironies of Automation": "The better these tools become at resolving routine incidents, the less practice human responders will get." He expects average resolution times to fall while resolution times for novel, complex incidents rise, and calls the accumulating shortfall "comprehension debt." Simon Späti's [September note](https://www.ssp.sh/brain/the-problem-is-not-the-ai-code-but-nobody-knows-anything-anymore/), at 388 points, put it in one line: "the problem is not the AI code, but that nobody knows anything, and everyone just asks Claude."

The people at the start of their careers are noticing. In the Stack Overflow survey, 17.1% of respondents said they avoid AI at work or school out of concern over losing job skills, the most common reason given for avoidance, ahead of ethics, privacy and environmental concerns. A younger engineer with roughly three years of experience, all of it alongside these models, put the dilemma in the most-liked post in a sample of the week's "skill issue" discussion on X (874 likes, 483 bookmarks):

> now the interesting question that comes to mind is that since i was born too late to independently develop deep practical expertise in any engineering subfield that i can then capitalize on to confidently supervise and steer those models, what do i even contribute to any of my AI-assisted projects?
>
> — [@leothecurious](https://x.com/leothecurious/status/2111013236413714757), Oct 16, 2026

His answer is that judgment about taste and trade-offs still has to come from the human, and that he spends "constant effort to verbalize obvious human intuitions into explicit and persistent notes and skills." That is the method again, and it is built from exactly the intuition he worries he never got the chance to form.

# Making the skill unnecessary

The strongest objection to all of this comes from people building the products. Aravind Srinivas, Perplexity's chief executive, made it in remarks Molly O'Shea posted on October 12, framed as a lesson he took from Larry Page:

> "It shouldn't be seen as a skill issue if you're not able to get the AI to do something for you. It's a product issue."
>
> — [@MollySOShea](https://x.com/MollySOShea/status/2109698612896911388), quoting Aravind Srinivas, Oct 12, 2026

He has history on his side. This publication [traced in August](/posts/2026-08-21-the-checklist-that-ages-in-public/) how platforms absorbed most of a viral infrastructure checklist into defaults, and the same is happening here. Written context files are a stopgap for context the tools will learn to gather. Review is already moving to machines in the Claude Code team's process, which says outright that "did a human read the code?" is "an imprecise proxy" for whether the right check caught the right risk. Scaffolding is worth enough that [the harness can swing a benchmark score by tens of points](/posts/2026-06-22-how-much-is-the-harness-worth-measuring-agent-scaffolds/), and vendors will keep shipping better harnesses so users do not have to build their own.

The absorption argument covers prompting, formatting and much of the mechanical checking. It stops at the same place the infrastructure checklist did: intent. A product can run the tests. It cannot know that the guard's shove was never meant to reach that corridor, that a level should have an exit prompt, or that a function's visibility is a design decision. The Claude Code team's design still reserves five decisions for humans, from whether to build something at all to "reading evidence" and owning every shipped change. Its rules still count whoever prompted an agent-written change as a required reviewer. Even the most aggressive internal user of these systems has not found a way to make verification of intent someone else's job.

What the product can do is lower the floor, and that does narrow one version of the gap. The person who never wrote an AGENTS.md will get better defaults next year. It does not touch the other version, where the scarce input is knowing what correct looks like. That input is the one the formation evidence says is at risk.

# What nobody can measure yet

The starting hypothesis for this piece was that the gap between people with a working method and people without one is widening faster than model progress. The evidence does not support that as stated, because nobody can currently measure it. The most direct instrument for the question no longer runs. In February, METR [reported](https://metr.org/blog/2026-02-24-uplift-update/) that its follow-up to the 2025 study, which had found AI made experienced open-source developers 19% slower, could not produce a reliable estimate. Returning developers came in at an 18% speedup, with a confidence interval from 38% faster to 9% slower; new recruits at 4%. Developers increasingly declined to participate because they did not want to work without AI, and 30 to 50% admitted withholding tasks they did not want to do by hand. The control condition has become something professionals refuse.

What the evidence does support is narrower. Capability now arrives faster than organizations can check it, and the 718-firm data say the difference between code and shipped software is decided at review. The users who get more out of the same model are the ones who iterate and verify rather than delegate, by a margin that is measurable but modest. The methods that measurably change outcomes are verification systems, and they are built out of domain expertise. The one randomized trial on formation shows that delegation-heavy use costs learners 17 points of mastery, most of it in debugging.

Put together, those findings describe a gap that compounds in two directions at once. People who already have the expertise build the method, get more from each model release, and widen their lead. People who do not have it are pushed by the same tools toward the usage patterns that keep them from acquiring it. Karpathy's funnel will narrow as access spreads and products improve. The second gap is harder to see in any one week's numbers, because it accumulates in what people never learned to check.

## Sources

- [X: @karpathy, the gap in shared understanding of LLM capability is widening (Oct 11, 2026)](https://x.com/karpathy/status/2109361546505966046)
- [Fiona Chen and James Stratton (Harvard): Artificial Intelligence in the Firm: Bottlenecks in Software Production (version of Aug 4, 2026)](https://fion.ac/jellyfish.pdf)
- [Ars Technica: AI coding agents generate more code, but not more software (Oct 9, 2026)](https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/)
- [Anthropic Economic Index: Learning curves (Mar 24, 2026)](https://www.anthropic.com/research/economic-index-march-2026-report)
- [Anthropic: How AI assistance impacts the formation of coding skills (Jan 29, 2026)](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [Shen and Tamkin: How AI Impacts Skill Formation (arXiv 2601.20245)](https://arxiv.org/abs/2601.20245)
- [Prather et al.: The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers (ICER 2024)](https://arxiv.org/abs/2405.17739)
- [Stack Overflow Developer Survey 2026: AI section](https://survey.stackoverflow.co/2026/ai)
- [METR: We are changing our developer productivity experiment design (Feb 24, 2026)](https://metr.org/blog/2026-02-24-uplift-update/)
- [Addy Osmani, Morgan Westlee Lunt and Qing Wang: How the Claude Code team does code review (Oct 15, 2026)](https://claude.dev/blog/solving-code-review-at-anthropic/)
- [Zephyr Project: AGENTS.md, instructions for AI coding agents (PR #117725, merged Sep 4, 2026)](https://github.com/zephyrproject-rtos/zephyr/pull/117725)
- [Fabien Sanglard: My agent.md to improve LLM-assisted code quality (Aug 21, 2026)](https://fabiensanglard.net/agent.md/index.html)
- [Thomas and Erin Ptacek: How To Write With An LLM (Sep 17, 2026)](https://sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/)
- [Huahai: AI is a tool and using it well takes skill (Oct 12, 2026)](https://yyhh.org/blog/2026/10/ai-is-a-tool/)
- [Rich Hickey: 'AI' Is Not a Tool (Oct 12, 2026)](https://www.linkedin.com/pulse/ai-tool-rich-hickey-kjl8e/)
- [Lars Faye: AI Coding will Prevent Expertise (2026)](https://larsfaye.com/articles/ai-coding-will-prevent-expertise)
- [Sylvain Kalache: AI handles incidents, engineers lose touch with their systems (Sep 4, 2026)](https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems)
- [Simon Späti: The Problem is not the AI Code, but Nobody Knows Anything Anymore (Sep 2026)](https://www.ssp.sh/brain/the-problem-is-not-the-ai-code-but-nobody-knows-anything-anymore/)
- [liao.gg: Agents Don't Need Memory. They Need Documentation. (Oct 2026)](https://liao.gg/blog/agents-dont-need-memory)
- [Rabah Shihab: Porting a 1993 Amiga game to Godot (Sep 1, 2026)](https://babyloniantwins.com/blog/porting-a-1993-amiga-game-to-godot/)
- [Piotr Migdał (Quesma): one prompt and six hours to visualize Invisible Cities (Oct 7, 2026)](https://quesma.com/blog/invisible-cities-one-shot/)
- [GitHub: ayghri/i-have-adhd](https://github.com/ayghri/i-have-adhd)
- [DORA: State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- [X: @leothecurious on the 'skill issue' take (Oct 16, 2026)](https://x.com/leothecurious/status/2111013236413714757)
- [X: @MollySOShea quoting Aravind Srinivas, 'It's a product issue' (Oct 12, 2026)](https://x.com/MollySOShea/status/2109698612896911388)

---

Canonical: https://www.thedeepfeed.ai/posts/2026-10-16-the-skill-gap-in-using-ai/
Site: https://www.thedeepfeed.ai
Full corpus: https://www.thedeepfeed.ai/llms-full.txt