Agentic Coding Is a Trap

At the end of a call this week, a developer said something to me that I haven't been able to stop thinking about.

We'd been talking for over an hour. He's two and a half years into his first commercial job, came out of a bootcamp, working in a messy PHP codebase — god classes, raw SQL, no dependency injection, global state pulled from superglobals instead of injected. The kind of codebase that's basically impossible to test. The kind of place where you can spend years getting better at navigating chaos without ever learning how to build something clean.

Before the call, he didn't have a name for what was wrong. He just knew something was.

We spent the hour mapping it out — where he is in the phases, what the gaps actually are, what the straight-line path forward looks like. By the end, he had a clear picture. A specific set of things to build. A real sense of what "caught up" actually means.

And that's when he said it.

"I feel like I'm way too far behind."

I told him to keep his head up. That he's got it. That 16 weeks from now, this is a solvable problem.

But I've been sitting with that line since.

Because I think what he was feeling wasn't hopelessness. It was the particular weight of finally seeing clearly. Before the call, the anxiety was vague — a low hum of something's wrong, I can't keep up. After the call, it had a shape. A name. A path.

That's not a bad place to be. That's actually the beginning.

If you're Code-First right now, you should feel like you're behind. Because in a real sense, you are. But that's not a verdict on your ability. It's a diagnosis. And a wrong diagnosis leads to the wrong prescription.

What's Actually Happening Out There

Cal Newport just covered an essay by a developer named Lars Fay that's been making the rounds.

The essay is called "Agentic Coding is a Trap."

It opens with a description of the new workflow most developers have adopted — describe what you want, pull the lever, let agents iterate until it's done. All the while putting a "growing distance between the orchestrator and the code that is being generated and committed."

Fay's core argument: only a skilled developer thinking critically and operating at the architectural level can spot issues in thousands of lines of generated code before they become a problem.

And the irony he points out — the one that got me — is that AI tooling has been proven to negatively impact the very critical thinking skills you need to use it effectively.

Reddit is full of it.

"Losing my ability to code due to AI."

"Letting AI do 100% of my coding fried my brain."

"Every time I use AI I feel like I'm becoming a worse professional."

Someone in my community said he had to take a short break because he was getting close to what he called "LLM psychosis."

I laughed. And then I didn't.

Newport explains that in CS education there's a known phenomenon called the junior year wall. Students let AI handle their foundational coursework. Junior year hits — the hard stuff — and they have nothing to fall back on. Fay thinks this is now happening across the entire industry.

A 30-year veteran developer Cal interviewed said it plainly: "On a personal level, I absolutely feel the effects of skill atrophy. This used to be my source for deep work. It no longer is."

Four years ago I was shouting this from the window.

Learn the skills. Learn the skills. Learn the skills.

I'm still shouting.

But Here's the Part Fay Doesn't Cover

Fay's essay is important. But it's written for a specific type of developer.

And I think one of the most important things I've learned — one of the things I try hardest not to screw up — is this:

You cannot give advice from a lower paradigm to someone at a higher one. And you cannot give higher-paradigm advice to someone who hasn't built the foundation yet.

Both will miss. Both will confuse. Both will waste time.

So let me be more precise about who this applies to, and who it doesn't.

If You're Code-First

The Phases of Craftship exist because the path is real. The sequence matters.

Code-First means you can build things. You can ship features. You know a language, you've worked on a codebase. But when it comes to explaining why you made an architectural decision — why that boundary exists, why that dependency points that direction, why that abstraction was worth creating — you go quiet.

That's not a character flaw. It's a phase. You just haven't integrated the essentials yet.

And here's the subtler thing that's hard to explain until you've lived it: the problems that push you into the next phase haven't hit you yet.

Think about testing. When you're Code-First, you haven't yet been slapped in the face by flaky E2E tests. You haven't wrestled with switching between environments and watched your test suite go from green to red for no obvious reason. You haven't had to design a testing strategy from scratch — one that actually holds together as the codebase grows — and felt it fall apart. You haven't spent three hours debugging a test that was testing the wrong thing entirely.

These problems live in Best Practice-First. And until they've found you, you don't really need what they teach you. You don't feel the gap because you haven't hit the wall yet.

But this is exactly why you can't skip the phases.

Judgement — real technical judgement — isn't something you read your way into. It develops through encounter. You hit a problem. It humbles you. You find the solution. You integrate it. You move forward with a scar that's actually a map.

That's the path. And there are no shortcuts because the shortcuts just defer the wall.

This is also, by the way, why interviews are getting harder.

It used to be enough to say "I know JavaScript" or "I've worked with React" or "I've used Postgres." That's the Code-First credential. And for a while, it was sufficient. But it's increasingly not. Because agents can already execute at the Best Practice-First phase — spec-driven development, contract-first design, structured test generation — with developers who know how to direct them. Which means the bar for what counts as "skilled" just jumped a phase.

Saying you've used a tool is Code-First. Knowing why the tool exists, what problem it was designed to solve, and when not to use it — that's Best Practice-First. That's what the market is starting to price in.

And here's the thing: AI agents are now operating at roughly that level. Spec-driven design, contract-first approaches, structured workflows — the tooling is getting better at it fast. Which means if you're Code-First and you're using AI to do your work for you, you're not accelerating. You're outsourcing the very struggle that would build your ability to evaluate what the AI produces.

That's Fay's point. That's the junior year wall. That's what's happening.

Fay's prescription still holds: don't throw the tools away, but demote their role. Write code yourself. Use pseudo code to think before you generate. Make a hard rule — never ask an LLM to implement something you couldn't do on your own.

And my prescription: get your foundations rapidly. The gap is widening every month. The developers who have integrated the essentials are getting faster. The ones who haven't are getting more lost, not less.

If You're Value-First

Now, here's the conversation I had this week in the Abstractionist Mastermind.

One of the developers — Value-First, been that way for a while — walked me through something interesting.

He's become genuinely good. The kind of good that makes other people uncomfortable.

His colleagues have started to notice. And instead of being celebrated for it, he's running into friction. Resistance. People getting territorial around his ideas.

And so we talked for a while about what his actual work is right now.

It's not more coding. It's not catching up on AI tools. It's not integrating more patterns or frameworks.

It's patience. It's leadership. It's learning how to usher change slowly enough that others can follow without feeling threatened. It's developing the emotional intelligence to operate at a high level inside a system that isn't quite there yet.

That's a personal development problem. Not a technical one.

And this is true across pretty much everyone in the Mastermind. They've crossed the threshold. They're not asking "how do I get better at this technically?" anymore. They're asking "how do I operate at this level inside an imperfect world with imperfect people?"

For someone in this position, Fay's essay is almost irrelevant. Not because AI doesn't affect them — it does — but because they can already look at what the AI produces and know whether it's right. They have the foundation. The critical thinking isn't atrophying because it's actually being exercised.

The question for a Value-First developer isn't "should I be coding more?"

It's "am I developing the patience and the leadership to actually use what I know?"

So Which One Are You?

If the Reddit posts landed somewhere uncomfortable — if "skill atrophy" resonated — you're probably Code-First. Catch up rapidly. Build the foundation. Do it now, while the gap is still closeable.

If you read this and thought I already know this stuff, my problem is something else entirely — you're probably further along. And your work now is less about code and more about who you're becoming in relation to the people and systems around you.

The phases are real. The sequence is real.

And the advice changes depending on where you are.

To Mastery,
Khalil

If you're Code-First and ready to catch up rapidly, The Software Essentialist Mentorship is where we do that work together.