The Coders Block: Why AI-Assisted Engineers Forget How to Start

There's a specific flavor of paralysis engineers don't have vocabulary for yet.

You open your editor. You know what you want to build. You have the context. You have the requirements. And you can't write a single line. Not because you don't know the syntax. Not because you're tired. But because the act of starting — of breaking a problem open and deciding where the first cut goes — feels like trying to push a car from the inside.

You turn to AI. You paste the requirements. The scaffold appears. And now you're off — editing, adjusting, shipping. The middle of the project is fine. The beginning is the trap.

This is coder's block. And it's one of the least-discussed consequences of AI-assisted programming.

The Initiation Paradox: AI Makes Finishing Easy and Starting Impossible

Here's what's quietly happening every time you reach for AI to start a project.

Writing code has two distinct cognitive phases: initiation and execution. Initiation is the problem-decomposition phase — reading requirements, identifying components, deciding on data structures, sketching the architecture, breaking the problem into buildable pieces. Execution is the actual writing of the code.

AI coding tools are extraordinarily good at execution. Paste a prompt, get working code. Paste a spec, get a scaffold. The execution loop has been compressed to near-zero friction.

But initiation — the act of genuinely thinking through a problem before touching code — is exactly what AI eliminates. And that's where the damage happens.

Every time AI writes your initial scaffold, you lose a rep of the practice that builds decomposition skill. Over months and years of AI-assisted work, your execution loop gets stronger while your initiation loop atrophies. You become excellent at modifying and completing code you didn't start, and increasingly unable to start code from scratch.

The cruelest part: execution confidence looks like competence. When AI generates a working scaffold, you ship faster. That feels like mastery. But it's not — it's delegation. And the initiation skill that underlies real software engineering is quietly going dormant.

Why Problem Decomposition Is the Real Skill

Fred Brooks distinguished between the "essential" and "accidental" difficulty of software. The essential difficulty is the problem itself — the domain complexity, the conflicting requirements, the uncertainty about what the system should actually do. The accidental difficulty is everything else: syntax errors, tool friction, implementation noise.

AI has eliminated almost all accidental difficulty. That should have made engineering easier. Instead, it revealed that most of what engineers do that looks like coding is actually problem decomposition — the cognitive work of taking ambiguous intent and turning it into buildable specifications.

This is the skill that doesn't transfer to AI. You can't prompt your way through a problem you don't understand. Someone has to think it through first. And if AI is doing that thinking — generating the scaffold, suggesting the architecture, naming the modules — you're not building that skill. You're building the skill of reviewing AI output and iterating on it.

These are different cognitive muscles. And one of them is getting very strong while the other goes soft.

The Three Initiation Skills AI Is Quietly Erasing

The third one — ambiguity tolerance — is the most insidious. Ambiguity is uncomfortable. That's by design. The discomfort of not knowing exactly what to build is precisely what forces the deep engagement with the problem that leads to good architecture.

AI removes the discomfort by instantly resolving ambiguity into a concrete scaffold. That feels like relief. But the relief is purchased with the skill development that the discomfort was designed to produce. You get the answer without doing the cognitive work that builds genuine understanding.

Why Senior Engineers Feel It Most

You might expect junior engineers to be the most affected — they started in an AI-rich environment and never fully built these skills. But the data and the stories suggest something different: senior engineers feel it more acutely.

Here's why. Junior engineers never fully developed the initiation loop in the first place. They learned to code in an AI environment, so they have a different relationship with problem decomposition — one where AI assistance is the default starting position.

Senior engineers, by contrast, had those skills. They built them over years of starting projects from scratch, wrestling with requirements in text editors at 2am, making architectural decisions with incomplete information. They know what it feels like to genuinely initiate a project. And they can feel — with specific, painful clarity — that the skill is degrading.

This is the expertise reversal effect again, working in the initiation domain. As Kahneman and Klein described: expertise in one area can make you more vulnerable to automation in adjacent areas. Senior engineers' deep experience with the execution side of coding makes them especially sensitive to the initiation atrophying that AI causes.

There's also a second-order effect: velocity pressure. Senior engineers are the ones most often given ambiguous, high-stakes problems to initiate. They carry the architectural weight of teams. When their initiation skill degrades, the consequences are organizational. They feel responsible for starting things they can't start anymore.

The Velocity Trap: Why AI-Mandated Workflows Amplify Coder's Block

On teams where AI tool use is mandated — where every sprint expects AI-assisted velocity — coder's block becomes a compounding crisis.

The pressure is constant: velocity metrics assume AI is in the loop. Slow starts aren't tolerated because they break the sprint assumption that a certain amount of work can be completed in a certain time. So when you hit the blank page and can't initiate, the incentive is to reach for AI immediately. No waiting. No sitting with the discomfort. Just prompt-and-proceed.

This is exactly the pattern that causes the skill atrophy. The "wait before AI" phase — where you'd normally decompose the problem, sketch the architecture, think through the data model — is precisely the practice that rebuilds initiation skill. And that phase is being systematically eliminated by velocity pressure.

The result is a negative feedback loop: the slower you get at initiating without AI, the more pressure you feel to use AI immediately, which prevents the practice that would restore your initiation speed, which keeps you slow without AI, which increases AI dependency.

Breaking out requires an intervention that the sprint doesn't budget for.

The Phenomenology: What Coder's Block Actually Feels Like

You know it's coder's block and not something else when these descriptions resonate:

• The blank editor feeling: You open your editor and the cursor blinks on an empty file. You know what you want to build. You paste requirements into an AI prompt and the scaffold appears. Then the paralysis lifts — until the next project starts and you're back at the blank file.
• The "I can't even outline" moment: You try to write a README, an architecture doc, even a project plan. The blank document is as blocking as the blank editor. The problem isn't writing — it's deciding what to write before you write it. AI resolves this instantly. And you feel the tiny loss of whatever thinking that resolution replaced.
• The scaffold dependency: You can only really work once AI has generated the first cut. Before that, you're staring at the problem, not working on it. You know this about yourself and it bothers you, but not enough to change the behavior because the AI solution works.
• The Sunday night dread, specifically for starting: It's not "I don't want to work" — it's specifically "I don't know how to start this." The execution is fine. The initiation is terrifying.
• The architecture blindness: You can read a requirements doc and evaluate an AI-generated architecture. But when you try to sketch an architecture yourself, before seeing what AI would produce, you draw a blank. Not because you don't understand the domain — because you've stopped practicing the generative part.

How to Tell Coder's Block From Burnout, Laziness, and Imposter Syndrome

These four conditions can look similar from the outside. Here's the practical distinction:

If the pattern that fits is "I want to start but I can't find the door" — that's coder's block. The fix is different from burnout recovery, imposter syndrome reframing, or motivation coaching. This is a skill disruption, and it requires skill rebuilding.

The Fix: Rebuilding Your Initiation Loop

Skill atrophied through disuse can be rebuilt through deliberate practice. The initiation loop is a skill — it degrades without practice and strengthens with it. Here's the protocol:

1. The Blank Page Ritual (Daily, 15 Minutes)

Before you open AI for any new project, spend 15 minutes in deliberate initiation practice. This is non-negotiable if you're rebuilding the skill:

• Open a blank editor. No AI. No autocomplete. No code snippets.
• Write the file names you'd create. Don't implement them — just name them and write a one-line description of what each file does.
• Draw (literally sketch) how data flows through the system. It can be terrible. It doesn't matter.
• Write the three hardest problems in the requirements and your initial approach to each. You don't have to be right. You're practicing origination.

This is uncomfortable. That's the point. The discomfort is the signal that you're doing the cognitive work that AI normally does for you.

2. The 30-Minute No-AI Initiation Window

For every new project or feature, enforce a 30-minute AI-free initiation window:

• Week 1-2: 30 minutes of pure initiation (decomposition, architecture sketch, module breakdown) before AI enters the picture
• Week 3-4: Extend to 45 minutes
• Week 5+: Aim for 60 minutes of initiation practice before scaffold generation

Track this in a simple log: date, project, initiation duration, what you produced. The log is your progress marker and your accountability mechanism.

3. The Explanation Requirement for AI Scaffolds

When you do use AI for initiation (because you will, and that's fine), apply the Explanation Requirement: before accepting any AI-generated scaffold, write a one-paragraph explanation of why that architecture makes sense for this specific problem. Why those modules? Why that data model? Why that decomposition?

If you can't write the explanation, that's data: you accepted an architecture you don't actually understand. That gap is the skill you're building.

4. The Quarterly Full-Build Challenge

Once per quarter, build something small — genuinely from scratch, no AI scaffolding. It doesn't have to be useful. It doesn't have to be impressive. It just has to be started and finished without AI taking the initiation load.

A weekend side project. A CLI tool for something you do every day. A small web app you actually need. The domain doesn't matter. The reps matter.

5. Rebuilding Ambiguity Tolerance Intentionally

Since ambiguity tolerance is the most eroded initiation skill, rebuild it directly:

• Read requirements docs and don't resolve the ambiguity — make yourself sit with multiple possible interpretations before choosing one
• When you feel the urge to paste into AI immediately, pause for 5 minutes and write your own initial approach first
• Practice the specific discomfort of "I don't know exactly how this should be structured yet" without fleeing to AI resolution

Ambiguity tolerance is not a personality trait. It's a practice. Like any practice, it strengthens with reps and weakens without them.

What Managers Need to Understand

If you're a tech lead or EM watching your senior engineers lose initiation capacity, here's what you need to know:

Velocity metrics are hiding the cost. When AI is in the loop, sprint velocity looks fine. The code ships. The story closes. What doesn't show up in metrics is the quiet skill degradation happening underneath — the senior engineer who's now dependent on AI to start anything.

The scaffolding tax is invisible until it comes due. An engineer who can't initiate without AI is a single point of failure for architectural work. AI can scaffold execution tasks. It cannot scaffold the judgment call about which architectural direction to take. That judgment requires initiation practice. And that practice is being systematically removed from AI-mandated workflows.

The fix requires protected time that sprint planning doesn't include. Rebuilding initiation skill requires deliberate no-AI practice. That time is not a story point. It's not a sprint task. It's a skill rebuilding investment, and it needs to be treated as one. Consider allocating 10-15% of sprint capacity to genuine initiation work without AI — a protected space for the practice that keeps architectural judgment sharp.

Frequently Asked Questions

Continue Exploring