Before Building Claude Code, Boris Cherny Lived in Nara Making Miso

Last month, the Claude Code team came to Japan for Code with Claude Tokyo. Boris Cherny, the creator and current lead of Claude Code, was there as well. It was only after hearing him speak that we learned that, before joining Anthropic, he had lived in Japan for more than two years. And not in an international metropolis like Tokyo, but in Nara, the ancient capital in the Kansai region.

Curious, we looked through Boris's social media posts from that period. Unlike his feed today, which is filled with technical updates, nearly every post was about another batch of miso, finally growing his own daikon after several attempts, or receiving 18 fresh oysters from Hokkaido through Japan's hometown tax donation program.

When people think of software engineers, Silicon Valley is often the first place that comes to mind. In tech circles, you also hear a common refrain: if you want to produce influential work, you need to move there. The argument is that Silicon Valley is the center of the software industry, with the greatest concentration of information and professional connections. Boris's experience suggests otherwise. Even in an ancient city known for temples, deer, and history, he found a way to make a meaningful impact.

On Boris's personal blog, there is a post called Learning to Work (Very) Remotely, written a year and a half after he moved to Japan. Before Anthropic, he was an E8 principal engineer at Instagram, part of Meta. At that level, contributions and influence across teams matter enormously. Yet his unusual time zone made it difficult to attend meetings with colleagues in Silicon Valley, New York, London, and elsewhere.

At a large company, being unable to join meetings can easily lead to being sidelined and losing the opportunity to have the impact expected of your role. Boris did run into that problem at first. He was removed from the critical path of several important projects, an experience he said was even a little hurtful.

But missing meetings also gave Boris a great deal of time back. He tried several different approaches, including exploring new product ideas with engineers in the Tokyo office and mentoring engineers in Singapore. Even when the time zones aligned, however, these efforts were harder than expected. He could work Singapore hours, for example, but lacked context about what was happening there, which made it difficult to be a genuinely effective mentor.

With his calendar no longer packed with meetings, Boris finally had time to write code again. There is a familiar saying in the industry: the further engineers advance, the less time they spend coding. This is especially true for an E8 principal engineer, whose expected influence spans organizations. Even as an individual contributor, their calendar can be overwhelmed by meetings. Boris joked that his inability to attend them had effectively turned him back into an intern, spending more than 80 percent of each day coding.

He began identifying pain points in Instagram's codebase. He cleaned up code, improved infrastructure so other engineers could be more productive, and fixed problems that others found especially difficult. Over time, he earned a reputation inside Instagram as someone who knew the codebase deeply and exercised sound technical judgment. Somehow, his days making miso in Nara also turned him into one of Instagram's top one percent of engineers by number of code commits.

Boris changed how he led projects, too. Instead of always standing at the front, he began leading from behind the scenes. He broke larger initiatives into multiple projects and found engineers in the United States and across Europe, the Middle East, and Africa to lead them. When a project generated substantial communication or coordination work, he handed those responsibilities to other engineers. By shifting from doing everything himself to delegating, he helped senior engineers who were still growing become the public faces of their projects.

Although he was no longer personally leading every effort, his reputation at Instagram continued to grow. Engineers and managers across the organization not only knew what Boris was doing, but also valued the opportunities he created for others and the impact the work had on Instagram.

At the same time, he adapted how he communicated. Rather than forcing his old working habits onto a new environment, he began taking advantage of his unusual time zone. Boris stopped relying on rapid back-and-forth chat. Instead, he processed the messages that had accumulated overnight each morning and spent the first hour of his day writing longer, more complete responses. He anticipated what the person on the other end was really asking, how they might respond, and what other information they would need. By investing time in better replies, he saved both sides from long, costly exchanges.

Since attending meetings was difficult, he also began using Meta's internal version of group posts to share ideas, start discussions, and make announcements. This made communication friendlier to people in other time zones. It was also more inclusive of people who would not normally be invited to a meeting, or who might not feel comfortable speaking even if they were there.

Boris's story is a powerful reminder that impact can come from anywhere. For software engineers in particular, the right approach can make it entirely possible to step outside an established mold and continue creating meaningful value.

Adapting his working style was not the only lesson Boris took from his time in Nara. In a later interview, he explained that making miso taught him to think on a longer time horizon. White miso takes three months to ferment; red miso can take two or three years. What you make today is not for eating today, but for some day in the future.

That same sense of time later shaped the development philosophy behind Claude Code. The team does not design and build new features for today's models. It builds them for the next generation.

As we worked through Boris's story, we found ourselves reflecting on our own habits. Today, anyone can easily call on multiple AI agents to implement an idea. Yet the ease of accessing that capability, combined with the current mood in the tech community, can make it tempting to optimize for speed rather than durability. Perhaps we can all learn something from making miso: use AI with a longer-term perspective, resist rushing out more disposable AI slop, and take the time to refine work that can keep creating value for years to come.