The Competence Trap: Why I’m Turning Off the Autopilot

As an engineer, my job isn't just to ship code—it’s to understand the systems I’m building. Lately, I’ve noticed a shift in the industry: we are becoming incredibly efficient at generating solutions, but dangerously passive at understanding them.

This is the Competence Trap. It’s what happens when you mistake an AI-generated output for your own mastery.

The Problem: The Path of Least Resistance

AI agents are designed to remove friction. In software development, friction is usually seen as the enemy—something to be optimized away. But in learning, friction is the mechanism. When you hit a wall, search through documentation, read source code, and struggle with a bug, you are engaging in a process known as the Generation Effect.

Cognitive science tells us that information is encoded more deeply when you generate the solution yourself rather than when it is presented to you. By offloading that struggle to an LLM, you aren't just saving time; you are bypassing the very process that builds your professional intuition.

What I Noticed

I’ve started tracking my own "AI-first" sessions. I noticed a pattern:

1. I hit a bug.
2. I prompt an agent.
3. The agent provides a fix.
4. I verify it works.
5. I move on.

But if you asked me to explain the underlying mechanics of that fix three days later, my retention is abysmal. I didn't solve the problem; I merely acted as a conduit for an AI’s probabilistic prediction. I’ve become an excellent "prompt engineer" but a mediocre system debugger.

Where AI Fits

AI is a high-stakes performance tool, not a tutor. If you use it to bypass the "boring" parts of your job without understanding the fundamentals, you are creating a fragile knowledge base. As Dan McKinley famously argued in Choose Boring Technology, the technology you choose (or the code you write) should be something you can manage when things go wrong. If you rely on AI to write code you don't fully comprehend, you aren't managing a system—you’re just hoping the black box stays closed.

My Working Approach: The Friction Principle

I’ve implemented a new rule in my development workflow: The 30-Minute Threshold.

If I’m stuck on a complex architectural issue or a deep library bug, I am forbidden from using AI for the first 30 minutes. I must use that time to read the library’s source code, check official documentation, or sketch the system flow on paper.

This forces my brain to engage with the problem at the "source of truth." If I still need an agent after that, I’m using it to sharpen my understanding, not to provide a shortcut.

Practical Example

Last week, I was integrating a third-party authentication library. The error logs were opaque. My initial instinct was to paste the stack trace into an LLM. Instead, I forced myself to walk through the library’s internal dependency tree.

I realized the AI would have suggested a "patch"—a workaround that would have masked a deeper configuration mismatch. By spending 45 minutes manually tracing the execution path, I not only fixed the bug but gained a mental map of how that library handles tokens. That knowledge is now part of my "internal stack"; an AI-provided patch would have been forgotten by morning.

What I Would Avoid

• Avoiding "AI-First" Development: Don't let the agent drive the architecture. If you can't explain why a piece of code is written the way it is, you don't own that code.
• Avoiding "Verification Bias": Don't just check if the code runs. Check if it fits your architectural standards. AI is often "correct" in syntax but "lazy" in design.

Try This Next

Pick one core area of your stack—the part you touch every day. For the next week, resolve to write every line of code in that module without AI assistance. If you find yourself struggling, that’s not a failure; that’s you identifying a gap in your knowledge that the AI was previously hiding.

If you want to stay relevant, you need to ensure your internal "source code"—your brain—is just as sharp as the code you push to production.