Will AI Reliance Collapse Coding Expertise?

Coding expertise is going to collapse from AI reliance is an August 2026 developer essay by Lars Faye about what happens when programmers lean on AI for the thinking parts of programming. It deals with a blunt question: if agents write, explain, and debug the code, where does human expertise come from next? The useful answer is not “ban AI” or “trust the agent”; it is to design work so engineers still predict, inspect, and explain the system. Agentic coding is the practice of giving an AI coding tool a goal and letting it plan or perform multi-step code changes, usually with a human reviewing the result.

Why the post hit a nerve

Faye’s essay landed because it names a fear many developers already feel in their hands. Modern AI coding is no longer just autocomplete. In Cursor, Anysphere’s AI code editor, the Agent can inspect files, propose changes, and work through a task across a repo. That is useful. It also changes which muscles get exercised.

The essay’s strongest point is not that AI-generated code is always bad. The sharper claim is that expertise comes from friction. You learn a codebase by getting lost in it, making bad guesses, reading the call chain, and slowly building taste.

A lot of the debate pushed back with an old pattern: people said the same kind of thing about calculators, compilers, high-level languages, and IDEs. BASIC, Pascal, assembly, Turbo Pascal, garbage collection, Stack Overflow, and now coding agents all moved work away from direct manual effort. Yet software did not stop needing judgment.

That analogy is partly right. A compiler did not remove the need to understand data structures, state, or failure modes. But it also is not a perfect comparison. A compiler is deterministic and narrow. A coding agent can produce a persuasive answer, invent a plausible explanation, and touch parts of a repo the developer did not read.

That is why developers cared. The post is really about whether AI coding governance should protect learning, not just production. The question belongs on the same shelf as code review guardrails, MCP boundaries, and repo rules, not as a moral panic about tools.

Argue both sides without cheating

The pro-AI side has a strong case. Software has always climbed the abstraction ladder. Most working engineers do not write x86 assembly for web apps, and that is fine. The important skill is often not typing syntax; it is shaping the problem, naming the concepts, spotting edge cases, and deciding what should not be built.

AI can help with that. A good agent can generate a first draft, search a codebase, write tests, or explain a strange migration. For a senior engineer, that may mean more time on architecture and review. For a junior engineer, it can mean faster access to examples that used to require waiting on a busy teammate.

The concern side also has a strong case. If an engineer asks an opaque model for an answer and stops there, they may get speed without understanding. They may ship code they cannot debug. Worse, they may lose the habit of constructing a view from docs, source, tests, and conflicting opinions.

This is the real fault line. The danger is not “AI wrote code.” The danger is “nobody can say why this code is correct.”

Here is the debate in one table:

Claim developers are arguing about	Strongest version	Trap to avoid
AI will collapse coding expertise	Expertise is built through struggle, and agents remove too much of that struggle too early.	Treating all tool use as outsourcing thought.
AI is just another abstraction	Developers have always used tools to avoid lower-level work, and the valuable skill keeps moving upward.	Pretending agents are as predictable as compilers.
Junior engineers are most at risk	Early-career programmers need repeated contact with errors, traces, and design tradeoffs.	Blocking juniors from AI instead of teaching review habits.
Senior engineers are safest	Experienced developers can use agents as accelerators because they already have taste and suspicion.	Letting confidence replace evidence.
The labor market will correct “vibe coding”	If some people only paste prompts and cannot maintain systems, their value will be exposed.	Confusing salary resentment with an engineering argument.

That last row is uncomfortable, but it came up for a reason. If a developer is paid for judgment and only produces unreviewed agent output, the market may eventually notice. But the better engineering question is simpler: can this person maintain the code when the agent is gone?

Test the question in a real Cursor workflow

You can settle part of this locally with a small experiment. Pick one real change in a repo: not a toy task, not a rewrite, and not something production-critical. A good example is “add pagination to the admin audit log” or “move this webhook parser behind a typed boundary.”

Run the work twice. First, ask Cursor Agent to implement it normally. Then have the engineer close the chat, read the diff, and write a short handoff receipt from memory: what changed, why it is safe, what could break, and what test proves it. The score is not whether the agent succeeded. The score is whether the human can explain the system after the agent helped.

Use a repo rule to make that expectation visible. This is a small .mdc rule you can put in .cursor/rules/ai-learning-boundary.mdc:

---
description: Preserve human understanding when Cursor Agent changes core code
globs:
  - "src/**/*.ts"
  - "packages/**/*.ts"
alwaysApply: false
---
When Cursor Agent makes a non-trivial change:

- State the invariant or user-facing behavior that must stay true before editing.
- Prefer small diffs that a reviewer can inspect in one sitting.
- Add or update a test that would fail without the change.
- After editing, produce a handoff receipt with:
  - files changed
  - why each change exists
  - risk areas
  - exact test command run
- Do not merge code the human reviewer cannot explain without the chat transcript.

A simple command flow keeps it honest:

git checkout -b ai-reliance-test
# Use Cursor Agent for the chosen change.
npm test -- --runInBand
git diff --stat
git diff > /tmp/agent-change.diff

Then ask the human reviewer to write this, without asking the agent again:

Handoff receipt

Change:

Why it is correct:

Files I inspected:

Test evidence:

What I would debug first if this breaks:

This is not a ban. It is a learning check. If the engineer cannot fill in the receipt, the next step is not shame; it is reading the diff, tracing the call path, and asking the agent narrower questions.

The same pattern works with AGENTS.md boundaries, custom subagent notes, or a reusable team skill. Keep the artifact small. A 12-line rule that changes review behavior beats a 90-line policy nobody reads.

If you want the broader frame for this kind of review work, keep it near the related training topic. For a nearby story about reviewing agent output instead of trusting the transcript, see Simon Willison on Coding Agent Review.

Keep the agent powerful but bounded

The practical tradeoff is that strict review slows down the shiny part of agentic coding. That is okay. Speed that cannot be audited is not the kind of developer productivity most codebases need.

The boundary matters more once MCP enters the picture. The Model Context Protocol connects agents to external systems like issue trackers, document stores, databases, and internal tools. That makes agents more useful, but it also raises the cost of vague permission boundaries.

A safe first boundary is boring: read-only context before write access. Let the agent read issues, docs, and code search. Make writes explicit, reviewable, and scoped. The trap is giving the agent broad credentials because the demo feels smooth.

This is where the Faye essay becomes useful even if you disagree with its title. It reminds us that expertise is not just stored in a person’s head. It is also stored in habits: reading diffs, naming risks, checking tests, and refusing to accept fluent answers without evidence.

Try one change this week

Pick one real Cursor Agent diff and ask the human reviewer to explain it without the chat transcript. If they can, AI helped; if they cannot, the next task is rebuilding understanding before adding more autonomy.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Cursor?

  Start by writing down one visible team rule for Cursor, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “Will AI Reliance Collapse Coding Expertise.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• Coding expertise is going to collapse from AI reliance — source
• Model Context Protocol — specification
• Cursor — Agent
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.