For my first year learning to code, I refused to use AI - I believed real developers solved problems themselves, so I spent roughly 10 hours per bug on Stack Overflow instead of seconds with ChatGPT. That year built debugging and research instincts AI still can't replace. It's exactly why I use AI heavily now, just carefully - following 4 rules.
TL;DR
- A year of debugging without AI built the fundamentals that make me good at using AI now.
- AI writes in its own architectural style - review every change before it joins your codebase.
- Treat AI like a teammate you onboard daily: shared instructions and reusable skills beat one-off prompts.
The year I decided AI didn't count
When I started learning full-stack development, everyone around me had ChatGPT open in a second tab. Every bug, every "how do I do this," straight into the chat. I hated it. My honest belief back then: if you can only write code with AI, you don't deserve to call yourself a developer or an engineer. A real engineer fixes the bug himself and writes it better than AI would.
So I didn't touch AI for my first year. I used Stack Overflow, docs, and whatever forum thread Google surfaced at 1 a.m. Some bugs took 10 hours. Not because the fix was complicated - because I had no idea what I was looking for, and finding out was the entire point.
What did a year without AI actually teach me?
Not that avoiding AI was the right call forever. What it actually built:
- The instinct to read an error message properly instead of pasting it somewhere and waiting.
- The habit of forming a hypothesis before testing it.
- The patience to research instead of guess.
Those are the exact skills that let me use AI well today - I can tell when its answer is wrong, because I know what right looks like. That's the part most people starting out now skip entirely. If the Claude Code limit runs out, the work day is over. Not because there's no more work - because there's no more ability to do it without AI holding the pen.
None of this means avoiding AI. The opposite - it's exactly where AI earns its place. Tests, localization, responsive breakpoints, anything repetitive and non-logic-heavy: I hand all of it to AI now, and it's genuinely faster than doing it by hand. The 4 rules below aren't about avoiding automation. They're about knowing which parts of the work are safe to automate and which parts are still yours to own.
Rule 1: fix it yourself before you open Claude Code
This is the rule I broke the least, on purpose. Before I let AI touch a bug, I give myself a real attempt:
- Read the terminal error and stack trace (Node or tsc output).
- Check the obvious places.
- Form a theory.
Most of the time that alone gets me 80% of the way there, and AI just confirms or finishes it. The reason this matters more than it sounds: I've watched AI "fix" a bug and quietly break something else two files over, because it optimized for the symptom I described, not the system around it. If you didn't build the mental model of that system yourself first, you won't catch the second break until it's in production.
Why doesn't AI's code ever quite match yours?
Every developer has a coding signature - how you name things, structure folders, handle state, split logic. AI has one too, and it's not yours. Depending on the model and version, it'll default to its own architecture unless you constrain it hard, and that default rarely matches the codebase it just joined.
I've seen this most clearly auditing vibe-coded sites for SEO and AI visibility as part of my own work - the design is often genuinely good, but the underlying code and search visibility are usually rough: missing semantic structure, weak metadata, the kind of thing nobody checked because nobody was checking, they were just clicking allow. I wrote about a related discipline problem in my commit message audit - same root cause, different symptom: nobody reviewed the output before it became permanent.
Rule 3: treat your AI like a new teammate, not a search engine
I run Claude and Copilot side by side, which used to mean maintaining two separate sets of instructions:
- Before: a
CLAUDE.mdand acopilot-instructions.md, duplicated - drifting apart every time I updated one and forgot the other. - Now: both
.claudeand.githubreference the same skills folder through a symlink instead of a copy, so there's one shared source of truth.
The single skill I use every day: a pair I call update-llms and create-llms. They keep an llms-style context file current after every commit, so when I - or anyone else - pulls the repo, their AI already understands the project's logic instead of re-deriving it from scratch. That alone cuts a real amount of token spend on investigation, and the answers that come back are noticeably better once the AI isn't guessing at context it should've already had.
Rule 4: how do you actually check code you don't understand?
You ask it to paraphrase itself. Not "explain this code" - that usually gets you a wall of technical restatement that's just as hard to parse. Ask AI to explain the logic in simple words, like you'd explain it to a teammate who's never seen the file. If it can't simplify its own output into something you actually understand, that's a signal to slow down before you accept it, not after it ships.
The habit is small, but it's the difference between accepting code and understanding what you just shipped.
The real test isn't whether you use AI
It's whether you still could, if you had to. Next time you're about to accept a suggestion, pause for five seconds and ask whether you actually understand it well enough to have written it yourself, just slower. If the answer's no, that's not a reason to reject the code.
It's a reason to slow down before you own it in production - because once you commit it, it's yours, not AI's.
AI can fix your bug. It can't teach you why it was there.
Ogtay Iskandarov
Designer and full-stack developer running klauzzdcode, a one-person studio in Baku. Freelance since 2023, I ship products from Figma to deploy and write down what survives contact with production.