Coding with AI Without Rotting Your Brain

A Working Set of Principles for Students and Self-Taught Developers

Why this matters

Most published advice about coding with AI is written for engineering managers optimizing team
velocity. Their metric is “how much code ships per sprint.” That metric is fine for shipping
production work; it is the wrong metric for a student or self-taught developer trying to build durable
skill. The right metric here is learning velocity: how much capability did you build in your own
head this week. These two metrics often optimize in opposite directions. Productivity advice says
delegate boilerplate, tests, and documentation to AI. Learning advice says do the parts that are
hard for you, slowly, sometimes inefficiently, because the struggle is what creates the memory.
The risk is not that AI will write bad code. The risk is more insidious. You will understand AI’s
code in the moment you read it. You will not be able to reproduce it in an interview six months
later. Comprehension in the moment fools you into thinking you have learned, when what you have
actually done is comprehended-and-forgotten. Reading is not the same as encoding.
The principles below are organized around that distinction.

1 Core principles
1.1 Read every line, but try to write it first
The discipline is not “review later.” It is: when AI suggests code, ask yourself whether you could
have written it from scratch. If no, type it yourself with AI guidance on what to type, rather
than accepting the Tab completion. This is the difference between learning a language and using a
translator.

1.2 Productive struggle has a 20-minute minimum

When stuck, work the problem yourself for 20 minutes before asking AI. Read the stack trace. Form
a hypothesis. Look at the docs. The cognitive struggle is where memory forms. Pasting the error
into AI within 30 seconds skips that step entirely. You will solve the problem; you will not learn
from it.

1.3 Periodically code without AI

One block per week, at least two hours, with AI off or restricted to syntax lookups. Build something
small from scratch. This is the muscle-memory equivalent of running drills, and it surfaces what
you have actually internalized versus what you have merely been comprehending in real time.

1
1.4 Explain it back, without AI present
After each meaningful feature ships, write a one-page explainer in your own words with the AI
window closed. If you cannot, you have not learned it. Treat the blank cursor as the test. Save
these to a docs/explainers/ folder; future you, and future interviewers, will benefit.

1.5 Maintain a decision journal

Every meaningful design choice gets a short record: alternatives considered, why you chose this
one, what you would revisit. Architecture Decision Records (ADRs) are the canonical format, but
anything that forces articulation works. This document doubles as interview material when someone
asks you to “tell me about a hard technical decision in this project.” If you cannot answer that
question without notes, you do not own the project.

1.6 Match AI to the layer just above your current competence

Vygotsky’s “zone of proximal development” concept applies directly here. Useful help is one layer
above what you can do alone. Three layers above is not learning; it is dependency. If you do not
understand SQL well, do not let AI write SQL for you. If you understand SQL but not query
optimization, AI can help with optimization while you write the base queries yourself. The goal is
always to pull your competence up one layer, not to skip the climb.

2 The pre-acceptance checklist

Before accepting any block of AI-generated code, run through these questions. They take less time
than they look like they will.

ˆ Do I understand what this code does, line by line?

ˆ Could I write it again tomorrow without AI?

ˆ Have I tested an edge case I picked myself, not one AI suggested?

ˆ Does it match the conventions already in this codebase?

ˆ Is the error handling appropriate, or did AI silently swallow failures?

If any answer is no, slow down. Either rewrite the block yourself, or ask AI to explain it until you
can answer yes.

3 Mechanisms to keep yourself honest

Principles without enforcement decay. These are concrete habits that put the principles into the
workflow rather than leaving them as aspirations.

The pre-commit question

Before every git commit, ask: “Could I explain every line of this commit to an interviewer without
notes?” If not, sit with the code until you can. This single rule does more work than any other on
the list. It puts the review at the latest moment where there is still time to fix it, and it creates a
clear gate that catches accept-Tab-accept-Tab habits.

2
Weekly explain-back doc
Pick the most substantive thing you built that week. Open a fresh markdown file. Close AI. Write
one page explaining what it does and why, in your own words. Save to docs/explainers/. The
first few will be painful and expose what you do not really understand. That is the point.

Decision records
A docs/decisions/ folder with one ADR per major choice. Standard format: context, options
considered, decision, consequences. Three to five paragraphs each. Date them. This is small
overhead with large compounding returns; you will reread your own ADRs more than you expect.

The blank-page check

Every two or three weeks, open a blank file and try to write a core function from memory. Not
the whole feature, just one important function. If you cannot, you have not learned it. Go back,
re-read, re-write. This is the single best diagnostic for whether your skills are actually growing or
just appearing to grow.

Read books, not just code

For any concept genuinely new to you, read a chapter or two of a real text before letting AI generate
the code. AI explanations are calibrated to sound right; textbook explanations are calibrated to
teach. They are different optimizations. AI is a faster reference after you have the conceptual
scaffolding, not a replacement for getting that scaffolding in the first place.

4 Partitioning work between yourself and AI

The same project can support learning or undermine it depending on how you split work. A reliable
framework:

Code yourself, slowly and deliberately

The conceptual core of the project. The parts that are unfamiliar territory. The parts where the
math or the systems thinking is the actual learning. The parts an interviewer will ask you to walk
through. If you delegate these to AI, you have not built the thing; AI has built it on your behalf
and you have typed approval signatures.
Indicators that something belongs in this bucket:

ˆ You cannot currently write it from scratch.

ˆ It encodes a non-trivial design choice you should own.

ˆ Understanding it requires concepts you want to internalize.

ˆ It is what you would highlight on a resume or in an interview.

Pair-program: you drive, AI suggests

The middle territory. Code that uses skills you mostly have, but where AI speeds you up by handling
syntax, boilerplate inside familiar patterns, or proposing structure you then refine. You read every
line, but you are not copying it out by hand. The test is whether you could rewrite it from a

3
description in plain English; if yes, this bucket is correct.

Let AI handle the toil

Implementation work that has high effort and low learning value: scaffolding in a framework you
already know, generating tests for code you fully understand, writing standard configuration files,
formatting fixes, repetitive CRUD endpoints, styling. The skill here is recognizing what truly is toil
versus what feels like toil because it is hard. Hard-and-unfamiliar is in the first bucket, not this one.

High-gotcha zones
A separate category from the three above. These are places where AI output looks right and is
subtly wrong in ways the model cannot detect. Examples that recur across projects:

ˆ Anything involving time, time zones, or causality between events.

ˆ Probability and statistics, where the code can run cleanly and still be off by a factor that does
not surface until production.

ˆ Concurrency, race conditions, and shared mutable state.

ˆ Security boundaries: input validation, authentication, secrets.

ˆ Anything where the consequence of a silent bug is invisible rather than loud.

For these, AI is a brainstorm partner at best. Verification cannot be delegated. Write explicit tests
that try to break the invariant, not just tests that confirm the happy path.

5 The senior/junior framing

A useful frame, borrowed from common advice: treat AI as a capable junior developer. The frame
works if you remember which side of it you are on. You are the senior. The senior does not let the
junior do all the work, because the senior is responsible for the result and the senior is the one who
needs to grow into the architect. A senior who hands every task to the junior stops growing. A
senior who reviews, instructs, and occasionally takes over the hard parts grows.
You are the senior here, even when you feel like the junior. Especially when you feel like the junior.
The feeling of being out of depth is the feeling of the work that will teach you the most. Do not
outsource it.

6 A short closing thought

The honest test of whether AI is helping you or replacing you is the empty cursor at the start of an
interview whiteboard. If, at that moment, you can write the core function of the project you spent
three months on, then AI was a multiplier. If you cannot, AI was a substitute. The principles in
this document are all variations on the same idea: keep yourself on the side of the multiplier.