Coding With AI Without Outsourcing Thinking
The way we write code might change, but principles of coding stay the same.
Think, write, check, repeat.
I recently spent a few weeks coding with AI using Claude.
As I went through the process, I wrote a few notes to capture how my perspective on it changed.
If I had to summarize the experience in one sentence:
Don’t let productivity overshadow developer principles.
The productivity gains are real, there is no doubt about it. But it also brings a lot of challenges. AI can’t take responsibility for what you produce using it. You have to accept responsibility, validate every output, and use it in a way that allows you to still be proud of your work.
AI gives us the chance to spend more time on actual software development instead of only writing code.
The question is whether we will use that opportunity to think more deeply - or stop thinking altogether.
In this first article, I’ll go through the main ideas I realized while working with AI. The next one will be more practical.
So let’s start with the biggest problem - you’re not writing code anymore.
The First Note: The Flow State Problem
One of the beautiful things about writing code is being in the “zone” (Flow State).
In simple words - you get lost in what you are doing.
Writing code was always like that for me.
The problem is that with AI it looks more like this:
- you write down your request
- you wait for output
- you validate it (or go yolo)
- you review the generated code (as you should)
- you iterate or switch to the next task
This creates a constant context-switching loop. Achieving a flow state in these conditions becomes difficult. The brain simply doesn’t work that way.
I shifted from solving one problem deeply to coordinating many smaller ones. Is that still a real “zone”? I don’t know yet.
It feels closer to what managers do than what developers do. You assign a task, move on, come back later, validate, switch context, and at some point you lose track of what you were doing.
Unlike traditional coding, there is a lot of generated output
you need to read and evaluate.
Writing code is cognitive work - you read, think, and write.
With AI, more of that work shifts toward reviewing.
Maybe development is slowly moving from writing toward directing and validating.
Despite all of this, the tool itself worked remarkably well for many of the use cases I tried.
The Second Note: Building on What You Already Know
Things are never just black or white.
I don’t know all Java annotations, all libraries, or the newest coding trends.
And I also don’t spend that much time writing code.
That’s where AI really helps.
It doesn’t replace thinking - it extends it.
You build on your existing knowledge. AI can explain or use things you might not know yet. That allows you to write cleaner code while learning at the same time.
I even worked with PHP again.
I knew it conceptually, but I don’t use it actively.
Now I can go deeper into it while still producing something useful.
The same applies to legacy code. You still need to understand it if you want to change it, but you get to that understanding much faster.
The dangerous part is not using AI - it’s disengaging from the work entirely.
The Third Note: How Easy It Is to Stop Thinking
We all hear about developers who implemented 50 features in 2 days.
And we also hear about systems where AI was used without validation and caused production issues.
There is a common pattern - it becomes easy to stop thinking.
At one point, I felt the temptation myself:
just let AI do everything, don’t read it, don’t validate it.
But once you cross that line, it’s hard to go back.
So I introduced some constraints for myself:
- Think first - how would I approach this myself?
- Don’t accept answers blindly - ask, verify, understand
- Stay involved in each step
- Review generated code to build a mental model
Even then, if you ask me for function names or DTO details, I might struggle. But I retain the mental structure, and that improves with repeated reading of the code.
Some tasks are clearly repetitive - generating boilerplate, copying structures, mapping data. Those are good candidates for automation.
But it always comes down to how you approach the tool as a developer - and what trade-offs you accept.
The Final Note: Thinking Is Still the Job
I can’t ignore it anymore.
What it offers is undoubtedly great. Nobody knows what it will cost - yet.
My response is simple: trade-offs.
I might not take full advantage of what AI is capable of, but I will keep thinking about what I am doing. Developer value was never just code production.
I might produce less code than possible, but still more than without it - while maintaining quality.
I will make things intentionally harder for myself, even if it slows me down at first. My growth matters more. This is how I keep my brain in shape.
I need to stay curious.
I keep coming back to one question:
how can I make sure AI produces code I can trust without constant checking?
The point is not to choose between being for or against AI in development. It is to do what developers have always done - stay curious and use the tools available.
AI might be the new IDE for developers.
But thinking is still something we have to do ourselves.