Lars Faye's "Agentic Coding is a Trap" makes several arguments worth taking seriously. He is right that AI coding tools can create distance between the developer and the code. He is right that bad teams can generate more code than they can responsibly review. He is right that juniors still need friction, debugging, and direct contact with implementation if they are going to become strong engineers.

But I think the larger frame is wrong.

Agentic coding is not a trap. It is creative destruction.

That distinction matters because creative destruction always looks dangerous from inside the craft being reorganized. It destroys some forms of expertise, creates others, compresses old apprenticeship paths, widens access to production, and punishes institutions whose processes were already weak. The discomfort is not evidence that the technology is uniquely corrupting. It is what technological change feels like when it reaches a previously scarce capability.

Every major automation wave has changed what it means to be skilled. Electrification did. Telephony did. Automobiles did. Mass production did. The spreadsheet did. The internet did. Software itself did.

The early twentieth century absorbed electrification, telephones, automobiles, new manufacturing methods, new logistics networks, and new energy systems in overlapping waves. Those changes did not merely alter how workers performed familiar jobs. They reorganized cities, household life, agriculture, manufacturing, retail, communication, and the geography of opportunity.

By comparison, agentic coding is disruptive, but narrower. It is changing software production and adjacent knowledge work. That matters. But it is not obviously more severe than replacing animal transport with automobiles, hand and mill power with electricity, and slow communication with dense telephone networks inside the same historical window.

The question is not whether this changes work. Of course it changes work. All automation does.

The better question is: what gets destroyed, what gets created, and whether the new equilibrium expands human capability.

Skill Atrophy Is Part of the Bargain

One of Faye's central concerns is skill atrophy. Developers who rely too heavily on agents may lose the ability to reason deeply about code. Juniors may have fewer opportunities to struggle directly with implementation. Senior engineers may lose the sharp mental model that comes from living close to the work.

That concern is reasonable. But it is not unique to AI.

Skill atrophy is another way of saying that labor-saving technology worked.

Drivers no longer know how to handle horses. Factory workers no longer understand line-shaft power. Most business software developers cannot write assembly. Many modern engineers do not manually manage memory, rack servers, tune kernels, or operate physical networks. Accountants no longer spend their days doing ledger arithmetic by hand. Designers no longer need to typeset pages manually.

Some old skills decay because the production system no longer rewards them at the same scale.

That is not automatically a failure. It is the normal bargain of automation.

The real question is not "will some skills atrophy?" They will. The real question is whether we preserve enough expert capacity to understand, repair, audit, and improve the automated system.

A healthy software industry still needs deep experts. It still needs people who can debug the hard thing, reason from first principles, understand performance, security, architecture, and failure modes. But it does not follow that every person who creates useful software must travel the old path in the old way.

The old world produced more people who understood the machine.

The new world may produce more people who can use the machine.

A healthy society needs both.

The Capacity Gain for Novices Matters

The article focuses heavily on what may be lost from the traditional apprenticeship path. That is important, but it underweights what is gained when novices become vastly more capable.

A founder, analyst, operations manager, researcher, designer, or small business owner can now prototype software that would previously have required a technical cofounder or a small engineering team. They can inspect APIs, write scripts, build internal tools, automate workflows, and test ideas that would otherwise never make it out of a notebook.

Will all of that software be good? No.

Was all pre-AI software good? Also no.

The relevant comparison is not between AI-assisted novices and idealized senior engineers. It is between AI-assisted novices and the world where those people could not build the thing at all.

This is the democratizing side of creative destruction. It does not produce only beauty. It produces volume, experimentation, awkward early work, and new entry points. The early web looked like that too. So did desktop publishing. So did spreadsheets. So did cheap digital video.

Professional standards still matter. But the existence of amateur production is not an argument against the tool. It is evidence that the tool expanded access.

Bad Process Is the Problem, Not Speed

Faye argues that LLMs accelerate the wrong parts of software work. He worries that they optimize for generating more code faster, when the real priorities should be understanding, alignment, concision, and maintainability.

I agree with the concern. I disagree with where the blame lands.

The problem is not speed. The problem is bad process.

Much of the software world already has crazy and bad process. Teams ship from unclear requirements. They write tickets that are either vague wishes or fake precision. They treat code review as a rubber stamp. They lack meaningful tests. They have no architecture record, no real ownership, no rollback discipline, and no shared definition of done. They perform agile rituals while preserving the same broken incentives underneath.

AI does not create that dysfunction.

AI accelerates it.

If a team already rewards output over outcomes, agents will help them produce more output. If a team already writes weak tests, agents will generate code that passes weak tests. If a team already has shallow review, agents will flood shallow review. If management already confuses motion with progress, agents will create more motion.

That is not an argument against agentic coding. It is an argument against bad software process.

Automobiles were dangerous, too. The answer was not to reject engines. It was roads, brakes, traffic laws, licensing, maintenance standards, insurance, signage, and eventually seatbelts. The technology forced society to build a control system around a new capability.

Software needs the same move.

Agentic coding requires smaller scopes, better specs, stronger tests, clearer ownership, observable systems, rollback paths, and reviews focused on behavior rather than vibes. It requires teams to stop pretending that "the AI wrote it" changes who owns the result.

Speed is morally neutral. Fast garbage is garbage. But fast learning is leverage. Fast prototyping is discovery. Fast test generation can improve safety. Fast migrations can pay down debt that no one could previously afford to touch.

The question is not whether code appears quickly. The question is whether the organization has a process that converts speed into learning instead of waste.

Vendor Dependency Is Not New

The article also raises vendor lock-in. If teams become dependent on Claude, OpenAI, Cursor, GitHub Copilot, or whatever comes next, what happens when prices rise, models regress, or outages hit?

That is a practical concern. But "vendor lock-in" is the wrong frame.

External dependency is the normal condition of modern production.

Most businesses cannot operate without electricity. They cannot operate without internet service. They depend on banks, payment processors, cloud providers, phone networks, email providers, device vendors, package registries, shipping companies, and insurance markets. A modern company is not an island of pure self-sufficiency. It is a bundle of managed dependencies.

The goal is not independence. The goal is resilience.

For AI coding tools, that means fallback providers, graceful degradation, budget controls, portable practices, local competence, and an honest understanding of what happens when the tool is unavailable. It means not designing an engineering organization so fragile that a model outage paralyzes everyone.

But there is nothing categorically new about outside dependency. It is a hallmark of integrated industrial society.

If a business cannot operate without its ISP, we do not say the internet is a trap. We say the business needs a continuity plan.

AI should be treated the same way.

"Never Ask AI To Do What You Cannot Do Yourself" Is Too Narrow

Faye says he avoids asking an LLM or agent to implement something he has never done before or could not do himself, except perhaps for educational purposes.

As a personal discipline, that is defensible. As a general rule, it is too narrow.

We use tools all the time to accomplish things we could not do unaided. A founder can use Stripe without being able to implement payment rails. A developer can use Postgres without being able to write a database engine. A designer can use a rendering tool without understanding every layer of graphics programming. A writer can publish online without understanding TCP/IP.

The standard cannot be "only use tools to do what you could already do manually."

The better standard is: do not ship what you cannot evaluate.

That preserves responsibility without requiring mastery of every layer. You may not know how to implement every dependency, compiler, model, database, or framework you use. But you should understand the failure modes that matter for your context. You should know how to test the result, how to inspect it, how to recover from failure, and when to bring in deeper expertise.

That is not abdication. That is how modern production works.

Expertise Will Change

A recurring fear in the article is that we will not produce the next wave of senior engineers. I think that is the strongest argument in the piece. The apprenticeship problem is real. If juniors only review generated code and never wrestle with implementation, many will fail to develop durable technical judgment.

But there are two separate claims here.

The first is that the old apprenticeship path may weaken. I agree.

The second is that expertise itself will therefore disappear. I do not.

Expertise will change. Future seniority may be less defined by hand-authoring every line and more defined by system decomposition, interface taste, test design, security judgment, debugging across human and AI boundaries, model evaluation, architectural stewardship, and knowing when to stop automation and take direct control.

That is still expertise. It is just not identical to the previous craft identity.

The industry should absolutely preserve direct coding practice, especially for people still developing judgment. But preserving practice is different from freezing the profession around the old production function.

We should be asking better questions:

• How do juniors learn when agents are everywhere?
• What work should be done unaided?
• What work should be paired with AI?
• What review habits preserve comprehension?
• What tests actually protect us?
• What failure modes are introduced by generated code?
• How do we create experts who can operate both with and without agents?

Those are institutional design questions. They are not reasons to declare the whole thing a trap.

The Right Response Is Industrialization

The conclusion I draw is almost the opposite of Faye's.

He argues for demoting AI's role. Use it as a secondary process. Keep yourself close to implementation. Generate only what you can review. Preserve your own skill.

That may be good advice for an individual engineer managing his own craft.

But at the industry level, the more important move is to industrialize the workflow around agentic coding.

Treat agents like a production technology: powerful, dangerous in sloppy environments, transformative in disciplined ones.

That means humans own architecture and acceptance criteria. Agents produce small, inspectable changes. Tests are first-class artifacts. Critical paths get stricter review. Generated code is not exempt from ownership. Teams measure defect rates and cycle quality, not token usage. Managers stop treating AI as a headcount replacement fantasy and start treating it as a process redesign challenge.

The organizations that win will not be the ones that let agents spray code everywhere. They will be the ones that rebuild software process around the new capability.

That is what happens in every serious technological transition. The tool arrives first. The institutions adapt second. During the gap, everything looks chaotic.

Creative Destruction, Not Decline

Agentic coding will destroy some things. It will make some skills less common. It will make some old career paths narrower. It will expose bad process. It will create new dependencies. It will let people ship software who probably should not be shipping production software without help.

But that is not the whole story.

It will also let small teams do more. It will let novices build useful things. It will make experimentation cheaper. It will reduce the cost of internal tools, migrations, tests, prototypes, and integrations. It will move some software creation closer to the people who understand the business problem. It will create new forms of expertise that we are only beginning to name.

That is not a trap.

That is creative destruction.

The task is not to preserve the old workflow because it made us comfortable. The task is to decide which human capabilities are worth preserving, which forms of friction were only waste, and what new disciplines are required now that the cost of producing code has fallen.

Agentic coding is only a trap if we pretend it is magic.

If we treat it as creative destruction, the job becomes familiar: preserve the expertise that matters, automate the work that should be automated, redesign the process around the new production function, and stop confusing discomfort with decline.