The Township Office and the Bathhouse

We know far too little about rural life. Architects are not problem solvers. Our job is to care for people’s lives and organize them spatially. This is especially true of public buildings. You have to ask the people who will use them.

Watching this clip made me think about the role of a Product Engineer. Just as an architect should look first at the lives of the people who will use a building, shouldn’t a developer look first at the lives of the people who will use a product, before looking at the code?

This question led to this essay. The metaphors of the “township office” and the “bathhouse” will recur throughout, so I hope everyone reading will first watch this clip, which is just over a minute and a half long.

I also hope this essay gives developers—and perhaps society at large—a chance to reflect on how we can build “bathhouses” rather than “township offices.”

There are countless “township offices” in our lives and in society. I became aware of them quite a long time ago. I imagine that anyone reading this can confidently name at least a few examples of their own.

The first “township office” in my life was probably during high school, when schools were officially prohibited from requiring students to attend evening self-study sessions. The stated purpose of the policy was to free students from an educationally harmful practice created by competition over admissions and grades, and to let them decide how to spend their own time after school.

But the reality I witnessed was far removed from that purpose. Competition over college admissions did not, of course, disappear along with nighttime self-study. It could never have done so in the first place. Students whose families were relatively well-off were already leaving school for cram schools or private tutoring. For students who could not afford private education, school was a place where they could eat dinner at relatively little cost and study safely until late at night.

When they got stuck on a problem during self-study, they could also ask a teacher who was still at school. When nighttime self-study was abolished, dinner support ended with it. Some students skipped dinner; others had to buy a more expensive meal outside school. Naturally, they also had fewer opportunities to ask teachers questions.

I am not arguing that nighttime self-study should have remained mandatory, nor am I trying to condemn the policy at the time. I am saying that the alternative might have looked different if policymakers had considered the evening meals, the places to study, and, more broadly, the daily lives of those who depended on that system. To do that, they would have had to meet those people in person.

Developers, too, are constantly exposed to the trap of reversing ends and means. It is natural to want to design a good architecture and write more elegant code. I also find value in doing those things. But the ultimate reason we are paid to sit at our desks is to create the change that the people using our products need. Development is a means to that end, and we need to remain conscious of that.

There is one caveat: I am not saying that code quality has become less important. If anything, the opposite is true. High-quality code must be the baseline. If every basic technical problem consumes all our energy, we have no room left to think about the product. If we cannot review the code an AI agent writes or predict the impact of a small change, the added speed may only help us build the wrong product faster.

We still need to train and strengthen our fundamentals. What matters is the expansion of the role. The ability to write good code has not become less important; it is simply no longer where the role ends. We need to treat solid code as the floor, then think beyond it about the user’s problem and the direction of the product. That broader scope is the responsibility now added to the developer’s role, and overlooking it is also the trap we so often fall into.

Keeping users close does not just mean launching an elaborate research program or developing advanced data analysis skills. It can begin with reading a single customer inquiry or sitting beside someone as they work through a task. We should ask whether an automation built to reduce operating costs has removed someone’s last way to speak with a support agent. We should check whether a step we removed for convenience contained information that someone still needed. We should spend more of the time AI agents give back to us on questions like these.

Time saved by AI agents does not automatically become something valuable. We can use it to build more features, or we can use it to look more closely at lives we have not seen before. The extra dimension developers now need might come from new technology, but it might also come from philosophy, the humanities, or psychology—a wider perspective for understanding people. What matters is not simply becoming different from everyone else, but whether we can look at the same problem again through the lives of the people it affects.

AI agents let us build township offices far faster and make them look far more convincing than before. Precisely because we can now build faster, we need to remember to ask the people who will use them.