One day a week, I code without AI

I've been writing code for more than 30 years. I started with embedded systems and went on to IoT, enterprise SaaS and GIS projects. I've seen a lot of tools in that time and got used to most of them. AI assistants became one of those tools, and to be honest, they have sped up my work considerably.

But for a while something felt oddly missing. I missed the old days. The days when I sat in front of a problem for hours and finally found the answer myself.

After thinking it over, I made a simple decision: one day a week I write code without AI. No chat assistant, no autocomplete in the editor. Documentation, man pages and the libraries' source code are allowed. In short, whatever we had years ago.

It turned out far better than I expected.

What I felt at the end of that day wasn't just tiredness. My mind felt like it had worked out. On top of that there was a kind of happiness that's hard to describe. I wondered where it came from and dug into it a bit.

#The formula for that feeling

My conclusion: four things together create it.

• Flow. When the difficulty of the work matches your skill, time disappears. AI drops the difficulty to almost zero, so it breaks that balance without you noticing.
• Competence. The feeling of "I solved this." At my age it comes with "I can still do it", and that is not a small thing.
• Ownership. Code where you wrote every line is truly yours. Like a carpenter looking at a finished table.
• Completion. Something finished and working at the end of the day. Unfinished work wipes out everything else.

I think of it as multiplication, not addition: Flow × Competence × Ownership × Completion. If one of them gets close to zero, so does the result. However smoothly the day goes, if you have nothing finished in the evening, the satisfaction doesn't come.

#Training, not a whim

I didn't want this to stay a few weeks of nostalgia. So I made myself a simple plan.

I start the day with pen and paper. I write down the problem and, more importantly, define the point where I'll say "done for today". Then I put the phone away for an uninterrupted block of two or three hours. At lunch I get away from the screen completely. The afternoon is for finishing, testing and tidying up. The last ten minutes go to a short note.

I rotate topics on a four-week cycle:

• Week 1: Algorithms and data structures. Pure thinking.
• Week 2: Systems and protocols. What actually happens underneath?
• Week 3: Building from scratch. A small parser, a simple database, a rendering engine.
• Week 4: Debugging with nothing but a debugger and logs.

I care about the fourth week in particular, because I think debugging is the muscle that wastes away fastest in the age of AI. Each cycle I raise the difficulty a notch so the flow doesn't fade.

At the end of the day I score the four components from 1 to 5 and ask myself one question: what couldn't I recall from memory today? That list gives me a map of where AI has made me lazy. It's nothing to be ashamed of; it's the real output of the exercise.

#What I watch out for

• Not letting the scope grow. While writing "a small parser" I can catch myself designing a programming language. The definition of "done" I write in the morning exists for exactly this.
• Not splitting the day. If something urgent comes up, I cancel the day and move it. A half-finished day is worse than one that never happened.
• Not punishing myself. When I find something I've forgotten, I add it to the list and move on instead of feeling bad.

#So am I against AI?

No. I keep using it on the other days and will continue to. What I really noticed is this: an engineer who keeps their mind sharp on the no-AI day reviews AI-generated code much better on the other days. To spot what's wrong, you have to be able to do the work yourself.

One day a week isn't a step back for me; it's a maintenance day. For my mind, and for my love of this craft.

If you want to try it, my one suggestion: start small, give the day a single task you can finish, and notice how you feel in the evening.