On this page
I have been programming for as long as I can remember. My parents let me use a computer from an early age, and yes, I was also the kid who spent endless hours playing computer games. But I was also the kid who wanted to know how things work inside. How does this thing work? How are programs actually made? My father had the answers, and he taught me my first steps: Turbo Pascal, BASIC, whatever we could run on our machine.
In elementary and high school, I went to programming competitions. In high school, I earned my first money by building websites and their backends. Programming was never a career plan. It was a hobby. A passion. The career came as a side effect.
The peak
When I started my first job, I could not believe it. People were paying me for something I loved, something that was easy for me. My curiosity did all the work. Honestly, I did not understand my colleagues who did not spend their evenings learning new languages, design patterns, architecture, or system design. What do you mean, you don’t do this for fun?
Over the years I went deep: Domain-Driven Design (the one area where I would call myself an expert), event sourcing, CQRS, scalability. I even went back to studying math, group theory included, just to properly understand functional programming. It paid off. Today I am a strong FP programmer in Scala. That is how far curiosity can take you when nobody has to push you. At the peak of my career, before AI, I was running a distributed PHP application on more than 600 Kubernetes pods without any issues, building backends that handled millions of euros every month. I gave talks about how we built it, what problems we faced, and why we chose to build highly distributed systems in the most unfortunate language possible: PHP.
Was I done with learning? Of course not. When you scale and maintain systems like that, you have to learn all the time. And I loved it. That was the whole point.
Then AI dropped in
At first? I was not impressed. The early chatbot era was a strange time. Stupid models with no wider context and a knowledge cutoff one year in the past. Good for playing around, chatting, and testing the limits of the thing. A toy.
Then AI got smarter. It stopped being just a brainstorming toy and started writing code. First, simple apps with no real design. Then it became a truly useful companion, a buddy who is never tired, never in a bad mood, never annoyed by your questions. It needs only two things from you: your money and your time.
And this is exactly where my relationship with AI started to change.
Let me be clear before anyone calls me an “AI skeptic”: I use AI every day. Personal projects, client work, everything. I’m on a team whose job is covering the whole SDLC with AI — the skills, harnesses, and all the agentic tools you need to start spec-driven development properly. I watch it being built from the inside and use it daily; on my side projects, I build this stuff myself. I even kind of like it.
And I still think we have all gone crazy.
The silver bullet nobody asked questions about
Every company now “needs AI.” AI is the silver bullet for all their problems. Companies are firing engineers and blindly trusting AI to build their products and ship their features. Not helping engineers. Replacing them. On pure faith.
And here is where my passion started to die: we don’t write code anymore. We generate markdown. Mountains of it. Plans, specifications, tasks, roadmaps. Almost all of it is generated by AI, consumed by AI, and, let’s be honest, only rarely reviewed by humans. AI writes documents for AI to read, while humans skim the summary and click approve. This is what we call software development now.
We gave developers a fantastic tool for building applications and fixing bugs. Great. But at the same time, we stopped caring about the continuous learning of developers in every other part of software development. Yes, fine, nobody needs to learn a new language anymore. Pick any language you like (Python, PHP, Scala) and the AI will happily write it. But that means we need to teach developers more about system design, software architecture, DDD, and the non-code parts of the SDLC. Not less. More.
Instead? We push thousands of lines of generated code every single day. It is hard to review. It is often hard to even understand. And we have all decided this is fine.
It is not fine. There are consequences, and they have names: stability goes down. Scalability goes down. Because now even the most junior developer can ship a big feature in no time, with one simple prompt, and nobody in the building can fully explain what was just merged.
Skill atrophy is real, and it is coming for you
Here is how it works, and it is brutally simple. Your work used to be: thinking, building POCs, reading source code, reading documentation, fighting with a problem for hours. If all of that shrinks down to reading replies from an AI, without a single question to clarify anything, your brain starts to shut down, little by little. You forget what you learned. And then you forget something worse: what you actually liked about programming. And that was never typing. It was solving hard problems. The same applies to system design and architecture.
Don’t take my word for it. This was one of the loudest themes at DDD Europe 2026.
Michael Feathers called it by its name: skill atrophy, the loss of skills when you stop using them. We already see it happening everywhere else. Long-form reading is dying, math skills are dying, all lost to a culture of fast, shallow information where nobody is rewarded for remembering anything. What is really at risk is systematic thinking itself. He gave three warning signs that you are losing skills while using AI. Read them and be honest with yourself:
- You can’t explain it. You cannot walk through and explain the AI-generated code you just shipped.
- You keep asking for the same thing. You ask the AI for the same task again and again instead of learning it.
- Your systems are brittle. The AI-generated system is too complex to change step by step. Every small change needs a complete rewrite.
Sounds familiar? I see all three in real projects. Every week.
Martin Fowler made the point that connects everything: AI is a magnifying lens. If your process is bad, AI amplifies the friction. If your process is good, AI amplifies the benefits. The bottleneck in software was never typing speed. It is communication between developers and domain experts, and AI amplifies that bottleneck too. Clear writing is becoming the “new code” for instructing AI, and it is a thinking tool as well. That is exactly why giving your writing, and with it your thinking, to an LLM is so dangerous. DDD and adaptive planning do not become less relevant in the AI era. They become more relevant. What humans need and what machines need is almost the same circle. AI did not remove the cost of ignoring good practices. It just hid the bill.
What AI is stealing from us
I am not an AI skeptic. I am a heavy AI user and I will stay one. But I still want to sometimes write code with my own hands. To go down the rabbit hole. To spend a whole day with a debugger, or dig through terabytes of logs to find one issue and kill it. That feeling, the pure joy of solving a really hard problem, is what AI is quietly stealing from us. Not taking. Stealing. Because we never agreed to give it up; we just stopped noticing that it was gone.
Meanwhile, LinkedIn is full of brand new AI gurus with little experience and unlimited confidence, and junior developers are skipping exactly those years of struggle that build engineering judgment. The struggle that made any of us worth hiring in the first place.
The tool is not the problem. What we do with it is. If we let AI replace not just our typing but our thinking, if we stop reading code, stop questioning outputs, stop learning architecture and design, we will not just lose skills.
We will lose the reason we fell in love with this craft in the first place. And no prompt will bring that back.
The way back
Here is the good news: skill atrophy works in both directions. Skills come back the moment you start using them again. Passion too.
So this is what I do now, and what I would tell any developer who feels the same. Never merge what you cannot explain — that one rule protects more of your brain than any other. Once a week, go down the rabbit hole on purpose: the debugger, the logs, the source code of your dependencies. Let AI do the boring 70 percent, and guard the 30 percent where the engineering — and the joy — actually lives.
AI killed the default version of my passion, the one that survived on autopilot. The deliberate version is still here. That one is mine to keep, and no company-wide AI mandate can take it — unless I let it.