Recently, I came across two interesting pieces of content. One was an article by DeepSeek engineer Liu Shengyu, describing how AI programming caused him to lose the “romance of handwriting code.” The other was an interview between Matt Pocock and Uncle Bob (the author of Clean Code and a software engineering legend). Uncle Bob has started using AI for his mutation testing and is still having a blast with it. The interview also mentioned that in the era of AI programming, fundamental coding skills remain crucial. These two things somehow connected in my mind.
We have had similar feelings during our recent recruitment process at the company. As AI coding becomes the primary mode of programming, we no longer test LeetCode-style handwritten code or traditional rote knowledge (the so-called “eight-legged essays”) during interviews. On the other hand, we have realized that “old-school programming” experience is still indispensable for software maintainability. Therefore, we find ways to assess a candidate’s old-school experience. We are less inclined to hire engineers with only 2–3 years of experience—those who grew up entirely within the boundaries covered by AI coding.
These two points might seem contradictory, but they are actually two sides of the same coin. That coin is: How exactly should we build our software today? AI can write code, review code, write documentation, and assign tasks. In this process, what role does the engineer play? This is a vital question in current software development.
Thinking about this, my mind wandered back to a “Software Quality Assurance” course I took in university. The professor discussed whether an architect needs the ability to write specific code. My view was affirmative because, after all, the overall architecture is assembled from detailed code. To build a large Lego set, you obviously need a clear understanding of the individual pieces. However, the professor disagreed, arguing that an architect only needs to consider the system from a macro, abstract dimension without worrying about specific code details.
Looking back, both views were correct. They correspond exactly to the two sides of current AI-driven development. The current way humans collaborate with AI essentially turns every engineer into what was formerly the role of an architect. Thus, the question once asked of architects is now being asked of everyone. By adopting the perspective of a former architect, one can understand the conflict inherent in this issue.
Should an architect master code details? Translated to today: in the era of AI coding, do we still need fundamental coding skills? Currently, you don’t need to know the specific syntax of a language or the exact steps of certain processes to complete a task successfully. After all, modern Agents are powerful enough to do it for you. This is the “architect doesn’t need to write code” side. But on the other hand, you must have a general understanding—knowing which language or architecture to choose, the pros and cons of each technical solution, and how to make trade-offs based on actual scenarios. If these aren’t clear, you likely won’t make the right decisions, even with Fable or Astra assisting you.
You will find this is a continuation of a long-standing debate, evolving from whether architects should write code to whether engineers should have the ability to hand-code. Perhaps if you open those classic software engineering books from 20 years ago, you will find the answer.
However, from another perspective, the path to becoming an architect and acquiring architectural skills might be different today than it was in the past. Previously, becoming an architect was fraught with difficulties. You had to do enough work, overcome distrust regarding your seniority and ability, break through the “cog-in-the-machine” division of labor within a company, and push through daily trivialities. Most importantly, you had to participate in projects that actually helped you grow and improve your skills.
Today, this has become much simpler. AI can help you handle many trivial tasks, giving you more time to think about macro decisions. The speed of project advancement also allows you to see the lifecycle evolution of an architecture very quickly.
But none of this comes without a price. The biggest problem in the AI programming era is that you can easily outsource your thinking. You can let AI do everything for you—any part you don’t understand, you can let the AI explore, decide, and automatically find the right path. Humans tend to follow the path of least resistance. AI not only helps you complete specific tasks but also handles all the thinking and judgment. Even the documentation you write might end up as weird, distorted sentences in the style of Opus 4.8. You become a megaphone for the AI, an approval machine, a tool within an Agent Loop.
If you truly want to become a sufficiently good engineer (or architect), you need to be able to grow. Perhaps you rely on AI exploration the first time you perform a task. But you need to understand how the task was completed, what key decisions were made, and what the system actually looks like. You need to understand these things first so that you can do the next task better and with more confidence.
You will find that this is actually your daily work. That’s right—you only need to consider how to better complete your normal work to continuously improve your architectural skills. As long as you keep up with the stages of AI coding development, you will naturally let AI handle specific tasks while you focus on macro and abstract dimensions. As AI capabilities evolve, it will be able to handle even more specific tasks, allowing you to move toward even more macro and abstract dimensions, thus continuously advancing.
In the era of old-school programming, the most “flow-state” thing I could do was write a flawless code module: high cohesion, low coupling, passing all unit tests. I think this is qualitatively close to what LSY called operator development. Writing such things can be deeply engaging; you can write all day without meetings or distractions until you are exhausted. But strangely, the pleasure remaining after finishing the code was never quite as strong as the feeling during the process.
I think perhaps it’s because such work is “linear.” It is largely a matter of putting in time and following a predetermined optimal path. For a code module, this optimal path is the SOLID principles. Of course, achieving SOLID is excellent enough—many mediocre engineers can’t do it in a lifetime. The operator optimization Liu Shengyu did is certainly more difficult and requires more IQ and experience, but to some extent, it still falls within this category of work.
The emergence of AI gave us all a slap in the face, telling us that such work is entirely “simple” work. For tasks with deterministic optimal solutions, AI can use reinforcement learning to rapidly approach and evolve to a point where no human needs to do it manually anymore. It tells me: don’t spend all day writing a flawless module. Consequently, people have begun to cry out that their past talents have been buried.
I have also buried my past talents. Since Claude 3.7, I have started letting AI create those perfect modules, even if writing them myself would be more interesting. This is because I can free up time to experience more things I find interesting. A gentleman is not a tool (Junzi bu qi). I don’t want to be constantly obsessed with writing code modules that have deterministic optimal solutions, nor do I want to write a vague “excellent coding ability” on my resume and then have to prove it. I hope to gain a sense of achievement just by doing my job well every day. I hope to be like Uncle Bob, always having the interest to tinker with the things I love, whether using old-school programming or AI programming.
As an engineer living in this era, it is undoubtedly confusing. The times are like a thick fog; you don’t know which direction to take next or what is certain to develop.
But for developers who love software engineering and software architecture, there is nothing more exciting than this era. The last exciting era might have been 40 years ago. Indeed, software engineering has, to some extent, been stagnant for 40 years. You can see that the classic theories of software development were all proposed by predecessors in the 70s. At that time, software engineering was a cutting-edge subject, but research in the field since then has mostly been about patching things up or scraping bits out of the cracks between bricks.
We are fortunate to see generative AI lead software engineering into a brand-new era. Standing here today feels like returning to the 70s—that era of turbulent software engineering theories where new methodologies were constantly being proposed. From Harness Engineering to Loop Engineering, you name it. There are no definitive answers or absolute truths because the boundaries of AI’s capabilities are constantly shifting. You can participate, use your own practice to feel the subtle points, affirm or deny any methodology, or even invent one yourself and wait for it to become a recognized viewpoint.
The problems of software engineering have existed for a long time, and the turning point for software engineering is happening right now. After all, getting to experience the feeling of being an architect is really quite nice, isn’t it?