AI Is Making Me Faster. I Don’t Want It to Make Me Worse.

I use AI constantly when I code and when I write. I use it to research ideas, plan code, debug, explore unfamiliar APIs, review architecture, generate tests, explain weird behavior, and write chunks of code faster than I could manually.

I also think it can make you worse at programming.

Those two statements are not contradictory.

The problem isn't that AI writes code. The problem is that AI can remove the exact parts of programming that force us to remember, reason, struggle, and form mental models. If we outsource those parts often enough, our skills get rusty.

So I've been thinking a lot about a question that feels much more useful than arguing about whether developers should use AI:

How do we use AI heavily without letting our own abilities decay?

I don't think the answer is using less AI. The best approach is to use AI deliberately.

The Dangerous Part Isn't Generated Code

Developers have always used abstractions and tools. One could argue that libraries degraded our ability to write everything from scratch without boilerplate. But we regularly use autocomplete, documentation, Stack Overflow, linters, frameworks, debuggers, IDEs, and code review built by people smarter than us.

Nobody expects a web developer to manually implement TCP before they're allowed to use fetch(). AI is just another abstraction.

But there's one critical difference: Most traditional tools remove mechanical work. AI can remove thinking.

Consider the difference between these two interactions:

Version A (Manual Debugging)

1. You encounter a bug and read the error.
2. You inspect the relevant code and form a hypothesis.
3. You test it—and you're wrong.
4. You inspect the state again.
5. You eventually discover that an asynchronous callback inside a forEach() loop isn't being awaited.

That process might take 20 minutes. But by the end of it, you've built a durable mental model of how asynchronous execution works in JavaScript.

Version B (Delegated Debugging)

1. You paste the function into an AI model: "Fix this."
2. Five seconds later:

const users = await Promise.all(
  ids.map(async id => {
    const response = await fetch(`/api/users/${id}`);
    return response.json();
  })
);

1. It works. You move on. You didn't spend time digging through three-year-old Stack Overflow posts trying to figure out why your code was failing.

In Version B, productivity increased dramatically—but learning may have approached zero. I've been guilty of this myself, getting far too comfortable with Ctrl+C & Ctrl+V.

The Tradeoff: Friction wasn't always wasted time. Some of the annoying parts of programming were secretly forcing your brain to retrieve and manipulate information.

10 Deliberate Strategies to Stay Sharp

If convenience and learning aren't always aligned, the solution isn't to make programming artificially miserable again. It's deciding which friction is valuable and actively preserving it.

1. Make a Prediction Before Asking AI

This is the simplest habit to build. Before sending a bug or stack trace to an AI model, stop for 30 seconds and ask yourself: What do I think is happening?

Example: "I think this state update is re-triggering the effect because the dependency array changes reference on every render."

Now when you prompt the AI, you aren't passively receiving an answer—you're testing a mental model against evidence. Recognition is much easier than recall; without a prediction, it's easy to read a confident explanation, think "Yeah, that makes sense," and immediately forget it.

2. Ask for Explanations Before Solutions

Instead of prompting:

❌ "Fix this code."

Try prompting:

💡 "Explain what is causing this bug. Don't fix it yet."
💡 "Give me three likely causes and tell me what evidence would distinguish them."
💡 "Walk me through how you would debug this without changing the code."

This transforms the AI from a code vending machine into a debugging partner.

3. Don't Immediately Copy Generated Code

Copying is fast, but when a concept is important, read the generated solution, close the AI tab, and then implement the idea yourself.

If the AI suggests introducing a state machine, extracting a service, or adding a memoization layer, reimplementing it forces you to translate the core concept into your own mental model. That’s harder than copy-pasting—which is exactly why it works.

4. Use AI as a Reviewer, Not an Author

One of the most effective workflows:

1. You write the implementation.
2. AI reviews it.
3. You decide which feedback matters.

Review this function for correctness, readability, edge cases, and unnecessary complexity. 
Don't rewrite it unless necessary.

This keeps you responsible for generating the solution while using the AI as an automated second pair of eyes.

5. Make Yourself Explain the Generated Code

Take a piece of AI-generated code and ask yourself: "Could I explain every line of this in a peer code review?"

If the answer is no, you are taking on technical debt you don't understand. Ask follow-up questions:

• Why is this specific dependency needed?
• What invariant does this check protect?
• What happens if two network requests execute simultaneously?

Keep going until the implementation stops feeling like magic.

6. Keep Some Tasks AI-Free

You don't need to quit AI cold turkey for a month. But short, unassisted intervals are revealing:

• Write a utility function without autocomplete.
• Debug a minor issue yourself using console.log or a breakpoint debugger.
• Sketch an architecture on paper before asking a model what it thinks.

Think of it like testing a backup. You don't want the first time you discover you can't code without AI to be during a live interview, an outage, or a critical system failure.

7. Ask AI for Exercises Based on Your Weaknesses

When you notice yourself repeatedly asking the AI about the same topics—like async/await, SQL joins, React lifecycles, or Git rebasing—use that data to train yourself:

"I've needed help with async JavaScript state several times. Give me three increasingly difficult exercises that test whether I actually understand it. Don't give me the answers unless I ask."

Now your assistant becomes a personalized tutor rather than a crutch.

8. Separate "I Can Understand This" From "I Can Produce This"

There are multiple levels of mastery:

1. Recognizing a correct solution.
2. Understanding a solution when it's explained.
3. Modifying an existing solution.
4. Producing a solution with documentation.
5. Producing a solution from memory.
6. Teaching the concept to someone else.

AI makes levels 1 and 2 effortless, creating an illusion that we've reached levels 4 or 5. Realizing where your actual capability boundary lies prevents overconfidence.

9. Don't Outsource Architecture Too Early

If the first thing you do when starting a feature is prompt "How should I architect this?", you skip the critical initial design phase. Answer these questions first:

• What owns this state?
• What boundaries need to exist?
• What's the simplest implementation that works?

Once you have a draft, bring AI into the loop: "Here is the architecture I'm considering. What edge cases or structural flaws am I missing?"

10. Keep Responsibility on Your Side of the Keyboard

If you ship AI-generated code, it is still your code.

The model doesn't get paged when production breaks at 2 AM. It doesn't defend the architecture to stakeholders. It doesn't maintain the repository six months down the line. You do.

When you hold yourself accountable for everything you ship, generated code stops being an absolute answer and becomes a proposal to be critically evaluated.

Conclusion

The future doesn't belong to developers who refuse to use AI, nor does it belong to developers who blindly delegate every thought to it.

The real skill lies in knowing where to automate and where to think.

Let AI eliminate boilerplate, search unfamiliar territory, explain complex concepts, and review your work. But occasionally, make your brain do the heavy lifting: predict, recall, debug, design, and explain.

Tools increase our output, but understanding increases our capability. The goal isn't just to build things because AI can build them—it's to build things we couldn't build before, while understanding more than when we started.