AI can write a working login route in 10 seconds. That’s amazing, and also a little dangerous. If the tool always writes the code, you stop practicing the one skill the code depends on: understanding what it does and why it breaks.
I’m an engineering student who uses AI tools regularly. [One line on which tools you use and for what.] Here are the rules I follow to keep the speed without losing the skills.
The Problem: Code You Can’t Explain
The first warning sign is code that works but that you couldn’t rewrite. [Your example: a time AI-generated code ran fine, then broke, and you couldn’t tell why.]
When something fails, the AI can’t tell you whether the code matches what you meant. Only you can, and only if you understand it.
- Attempt First, Then Ask
Spend 10 to 15 minutes on the problem before opening the tool. Even a failed attempt shows you where you actually get stuck, and it helps you judge the AI’s answer because you know what the question was.
- Ask for Explanations, Not Just Code
Instead of “write a JWT logout route”, try “explain how logout works with stateless JWTs and what my options are.” Then write the code yourself. Use the tool as a tutor first and a code generator second.
- Never Paste What You Can’t Explain
Before accepting generated code, explain every line to yourself, or to a rubber duck. If a line is a mystery, ask about that line. The test: could I recreate this tomorrow without the tool?
- Read the Diff, Not Just the Result
“It runs” is not the same as “it’s correct.” Check these every time:
What happens on bad input, empty values, or a failed network call?
Did it add a dependency you didn’t need?
Does it match the conventions of the rest of your codebase?
Is anything hardcoded that shouldn’t be, like secrets or URLs?
AI is great at the happy path and often skips the rest.
- Keep a No-AI Practice Habit
Pick one slot, such as one small project a month, where you work with no assistant. Think of it as gym time for your brain. It keeps your syntax recall, debugging and design instincts sharp.
- Debug With Your Own Eyes First
Before pasting an error into a chat, read the stack trace and add logs or breakpoints. Reading errors is one of the most valuable skills you can have, and it’s the first to fade when you outsource it.
- Verify Against the Docs
AI can confidently invent function names, options, and API behavior. When something looks unfamiliar, check the official documentation. [Optional: a time the tool gave you something that didn’t exist.]
Weekly Self-Check
Ask yourself:
Could I explain my last three changes to a teammate?
Did I fix my last bug by understanding it, or by retrying prompts until it vanished?
Could I build this feature without the tool, even if slower?
If any answer is “no,” slow down for a bit.
Final Thoughts
AI is good at producing code and bad at knowing what you need. That judgment is what makes you an engineer. Use the tool to move faster, but stay the person who understands the result.
What rules do you follow? Drop them in the comments.
Top comments (3)
The "Could I recreate this tomorrow without the tool?" test is the ultimate litmus test for AI dependency. It's so easy to fall into the trap of accepting a 50-line solution just because it passed the test, only to realize you have no idea how to debug it when a new edge case appears.
I'd add one more rule to your list: always ask the AI for the simplest possible implementation. Models are trained on enterprise-grade codebases, so they naturally reach for complex abstractions, factories, and design patterns when a simple if statement would do.
Your point about keeping a "No-AI practice habit" is genius. Treating manual coding like gym time for your brain is exactly the right mindset—you don't lose the fundamental understanding, you just build the muscle memory for when you really need it.
Thanks! Great addition. “Ask for the simplest version first” is a rule I’ll add. AI often reaches for a pattern when a plain if would do. And yes, treating no-AI coding as gym time is exactly how I see it.
Exactly! It's like the AI is afraid of writing a simple if statement without wrapping it in a Strategy Pattern.
Adding that rule really does change the output quality. Once you force it to start with the simplest possible version, you can always refactor it later if the complexity is actually needed. Keep up the great writing!