I Bought Almost Every Clean Code Book. Now I Read Less Code.

I bought almost every well-known book on Clean Code and Clean Architecture I could find.

I used to love reading them. Naming, function size, separation of responsibilities, dependency direction—I wanted to understand every principle and apply it to my own code. After finishing a piece of work, I would look at the neatly organized result and feel satisfied. I had shaped it myself. I knew why it looked that way.

Knowing those principles by heart made me feel capable.

But now I read less code. I leave more implementation to AI, and I spend less time refining every line. That made me wonder: do those books, and all the time I spent with them, still matter? Is Clean Code dead?

The moves may be retired. The training stays.

There’s a martial arts analogy that captures how I feel.

You spend years mastering a palm technique. Then you get a machine gun, and you no longer need that technique for every fight. But the internal strength you developed through training is still there.

The books I read, the messy code I refactored, and the bugs I chased don’t disappear when the tools change. Over time, those experiences become part of my judgment. I don’t always need to recall a particular book or principle to use them.

When AI proposes a solution, I still ask: why split it here? Who owns this state? If the process fails halfway through, will the system remember the unfinished work? When it reports success, which step actually succeeded?

I didn’t suddenly learn to ask these questions after getting access to AI. Years spent working with code taught me where things tend to break. They also gave me reasons to ask one more question when an answer looks complete.

The road I took wasn’t wasted. I just don’t need to perform the whole routine every time anymore.

I always knew I should look at the system. I often ran out of time.

Using AI doesn’t remove the need to care about authorization, transactions, retries, or data consistency. Of course it doesn’t. Those things mattered before AI, too.

The difference is how much time I used to spend getting the foundation ready. Does the code run? Is the structure reasonable? Are errors handled? Are the tests finished? By the time those things were in place, much of my energy was already gone.

I knew I should look further up. Does the whole flow make sense? Will the services interfere with each other once connected? What does the user experience when something fails?

Knowing I should investigate those questions and having time to do it were two different things.

With AI handling part of the implementation, I finally have more room to shift my attention upward.

During an MQTT authentication incident, I focused on how CPU pressure, database connections, timeouts, and device retries formed a cycle. When working with Kafka, I asked what a reported success actually meant: had the message entered a queue, reached the broker, or completed the work downstream?

Those questions still lead back to code. But my starting point has changed. I follow a system problem, then read the parts of the implementation that need checking. What I learned before helps me decide where to look.

Have I lost some of the fun? Yes.

One of my favorite things used to be looking at code I had made tidy.

I would break up a long function, replace vague names, and put responsibilities and dependencies where they belonged. Reading it again afterward felt good. I could see my own craft in it, along with my understanding of what made code good.

Now, much of the code wasn’t written by me, line by line. Even when the result works, the satisfaction isn’t quite the same. Sometimes I move on to the next problem before I’ve had a chance to enjoy a small piece of implementation.

I do miss that.

My focus has also changed. With AI agents, more work can happen around a single goal: research, comparing approaches, implementation, testing, and reviewing results. Some tasks I once had to complete in sequence can now move forward together.

I spend more time deciding what to do, which tasks can run together, which depend on earlier results, and what evidence would show that the work is actually finished. Watching those pieces come together—and seeing a goal that once felt difficult begin to take shape—brings a different kind of enjoyment.

More parallel work also brings new problems. Every agent may report completion while their results fail to fit together. One might have worked from outdated information. Another might have tested a different revision. I have to check what each one actually did, rather than collect a few statements saying the tests passed.

Those books are still part of my judgment.

I rarely finish a piece of code and go through the Clean Code principles one by one anymore. I also don’t think every part of the implementation deserves the same amount of polishing.

But I don’t regret buying those books.

They helped me develop a way to understand software. Now that implementation moves faster, I can bring that experience to questions I previously ran out of time to explore. When I need to dig into the code, I still know how to find my way.

I still appreciate beautiful code, and I miss the feeling of shaping it myself. But there are more things that excite me now. I want to see how far I can take a project with the experience I’ve built—and the tools I have today.