Jakob Wolman
The Ise Jingu is a complex of Shinto shrines close to the city of Ise in Japan. Parts of the complex are over 2000 years old, but still built of materials like wood and silvergrass. Every 20 years, a ceremony takes place to rebuild the Shogu, the divine palace. It is rebuilt as a replica of the current palace, on a site adjacent to the current one. The ceremony, called Shikinen Sengu, takes around eight years to complete and includes everything from cutting new timber, transporting it, and constructing the palace. The first ceremony was conducted in the year 690, and the latest in 2013.
After the devastating fire of Notre Dame, France swore to rebuild its once magnificent cathedral. The initial fear was that it would be almost impossible to find craftsmen who knew how to perform the task. Much of the woodwork had been made with medieval techniques and tools that are rarely used. However, as the French came together to restore Notre Dame, they were able to find enough people to rebuild the cathedral in less than six years. A big contribution was the French apprenticeship system that has passed on knowledge from older, more experienced builders to the younger. French and German organisations, like Compagnons du Devoir, have acted for the preservation of these skills since the Middle Ages. People who have learnt these skills are available, but increasingly hard to find, as they seldom have to use them. The process knowledge of building cathedrals is slowly evaporating.
Cathedrals are constructions built to last. The Ise Jingu are temporary structures with ceremonies designed to transfer process knowledge across generations. The Japanese shrines will outlive the rigid buildings.
As AI is eating the software engineering world, we are learning new processes, new levels of abstraction, and new ways of building. We now have tools available that promise to make us faster and achieve things that we thought were impossible. As we move up the abstraction ladder, we tend to forget that the applications we build still rely on the same technology. This has been true from assembly coding to object orientation to web technology. Some process knowledge is already lost. Few people can effectively debug machine code. With the amount of code and complexity of current applications, these are often unreasonable tasks. But we are already seeing challenges in more junior developers not knowing how to read logs or debug more complex systems. Human cognition has its limits as Laura Nolan described in her 2024 talk:
In the current whirlwind of AI-assisted and agentic coding, I wonder what process knowledge will get lost along the way. Will it be debugging? Will it be the understanding of concepts like design patterns, object orientation, separation of concerns, or algorithm complexity? I am betting that garbage collection optimization is already a dying art. With fewer examples to learn from, will our AI models also become worse at these tasks as complexity increases from AI slop?
Perhaps there are lessons to learn from the Japanese ceremonies of rebuilding shrines and the French apprenticeship systems. Even if we CAN build everything ourselves with swarms of AI agents, we are losing the value of teaching and learning process knowledge. Software starts becoming legacy the moment you stop actively coding. Not only do software packages need to be updated, but the world around the software keeps changing. The domain develops, the demands of the users change, and the underlying infrastructure develops. AI unlocks new possibilities, not only in terms of speed. When developing big and complex systems, I have always reached for methods from extreme programming (XP). They are just as relevant today as they were 30 years ago. Using AI in XP makes some of these procedures even easier, while keeping the learning.
Pairing
Now you have a constant pair. You can always have an AI at your side, take turns driving, and learning from each other. Don’t let it replace pairing with a human. Instead, use this new opportunity to do MORE pairing.
Test-driven development
I always loved having tests, but did not love writing them as much. AI is great at helping you write tests. It is also a good opportunity to encode the specs you have already discussed with your agent.
Refactoring
Just as the Shinto worshippers use simple materials to be able to constantly renew, we should always be refactoring our code. With AI capabilities, we can do this even more. Spend time improving, updating, and making your code less complex. This gives you the ability to start with something simple (even something AI sloppy) and gradually invest in improvements. In the AI era, there is some disagreement on this point. Many people claim we will stop reviewing code, and that abstraction has moved beyond syntax. Perhaps we will, but I do not believe we are there yet. At least not for production-ready and more complex products.
The AI race truly makes this an interesting time to be engaged in software development. But as we see more and more tasks being automated and delegated to machines, we have to make deliberate efforts to hone our skills in process knowledge.
As ☕ J. B. Rainsberger once told me when discussing testing strategies.
It won’t make you faster, but it will make you drive on four wheels instead of two.
This post was inspired by a passage in the book Breakneck by Dan Wang.