AI coding tools are incredibly good at making a developer feel productive.
You describe a component.
It appears.
You describe an API.
It appears.
You describe a database schema.
It appears.
For a while, this felt like unlocking a new level of programming.
Then I noticed something uncomfortable.
I was becoming better at describing software than understanding software.
That was the moment I started taking AI-assisted development more seriously.
The productivity illusion
When an AI tool generates 500 lines of code, the diff looks impressive.
But the size of the diff is not the size of the learning.
I could generate a complete page without being able to explain why one component needed to be client-side.
I could generate a database query without understanding why a policy blocked it.
I could generate an API route without fully understanding its failure behavior.
That is dangerous because generated code still becomes your responsibility.
AI did not create the gap. It revealed it.
The uncomfortable truth is that AI did not make me weaker.
It made some of my existing weaknesses easier to hide.
Before AI, not knowing something slowed me down visibly.
With AI, I could sometimes work around the gap.
That made it easier to continue without fixing the underlying understanding.
The solution was not to stop using AI.
The solution was to use it differently.
My new rule: never outsource the explanation
I can ask AI to generate a solution.
I can ask it to suggest alternatives.
I can ask it to debug an error.
But before I consider the task finished, I want to be able to explain:
- what the code does
- why it works
- what assumptions it makes
- what can fail
- where the data moves
- what trade-offs the implementation creates
If I cannot explain it, I do not really own it yet.
AI is excellent at the boring parts
There are many things I happily delegate:
- boilerplate
- repetitive types
- test case generation
- documentation drafts
- syntax conversions
- initial component scaffolding
- exploring an unfamiliar API
These are acceleration opportunities.
But architecture, product decisions, security boundaries, data models, and failure handling deserve deeper attention.
AI can help me reason about them.
It should not silently decide them for me.
The biggest change: asking better questions
My prompts changed over time.
Instead of:
“Build this feature.”
I increasingly ask:
“Give me three architectures, explain the trade-offs, identify the failure modes, and then implement the smallest reasonable version.”
That turns AI from a code generator into a reasoning partner.
It also forces me to think before accepting the first answer.
The fundamentals came back
The more AI I used, the more valuable fundamentals became.
HTTP matters.
Databases matter.
Operating systems matter.
Networking matters.
Data structures matter.
Type systems matter.
Security matters.
Architecture matters.
If I only know frameworks, AI can generate framework code faster than I can.
If I understand systems, I can judge whether the generated code belongs in the system at all.
That distinction is becoming increasingly important.
I stopped being embarrassed by not knowing
One side effect of AI-assisted development is that it becomes easy to hide uncertainty.
I now prefer the opposite approach.
If I do not understand something, I want to name the gap.
“I do not understand why this RLS policy recurses.”
“I do not understand why this native module fails on this platform.”
“I do not understand why this state becomes stale.”
Once the problem is stated clearly, learning becomes possible.
My current workflow
A workflow that works better for me now is:
Understand → Plan → Ask AI → Read → Run → Break → Debug → Explain → Ship
The “break” step is important.
Happy-path code can create false confidence.
I want to know what happens when the network fails, data is missing, the user repeats an action, the database rejects a request, or a dependency behaves differently than expected.
The lesson
I do not think AI will eliminate the need to learn software engineering.
I think it will make shallow understanding easier to expose.
The ability to generate code is becoming cheaper.
The ability to make good technical decisions remains valuable.
So I am not trying to compete with AI at typing.
I am trying to become better at thinking.
That means learning fundamentals, reading code I did not write, debugging systems I did not design, and finishing projects instead of merely generating them.
AI can help me move faster.
But I still want to know where I am going.