200 karma · joined December 8, 2025
It seems the path of "Shugyo" is universal—whether in Cinema, Banking, or Code. Real mastery always starts from the ground up.
I am relieved that my "Cultural Accent" served as the ultimate Captcha. I'm glad my words reached someone who truly understands the culture.
I checked the link, and it makes perfect sense. In my world (Japanese Banking), we are trained to "Read the Air" (Kuuki wo Yomu). Everything is high-context. Saying things too directly is considered rude or immature.
But I realize that here on HN, "Code" is the context. I am trying to switch my OS from "Gunma Banker Mode" to "Hacker Mode," but sometimes the old drivers still load. Thank you for understanding.
His philosophy—stripping away the unnecessary to focus on the reality (data/hardware)—resonates deeply with me. The practice you described (building from scratch daily) is exactly the "Tea Ceremony" of the digital age. It is not about the tea (the result), but about the procedure (the internalization).
Thank you for introducing me to such a Master.
We use plenty of models to calculate credit risk, but we never let the model sign the contract. An algorithm can't go to court, and it can't apologize to a bankrupt family.
"Human in the Loop" isn't just about code quality. It's about liability. If production breaks, we need to know exactly which human put their reputation on the line to merge it.
Accountability is still the one thing you can't automate.
To be honest, in 1989, I was just a child. I didn't drink the champagne. But as a banker today, I am the one cleaning up the broken glass. So I can tell you about 1989 from the perspective of a "Survivor's Loan Officer."
I see two realities every day.
One is the "Zombie" companies. Many SMEs here still list Golf Club Memberships on their books at 1989 prices. Today, they are worth maybe 1/20th of that value. Technically, these companies are insolvent, but they keep the "Ghost of 1989" on the books, hoping to one day write it off as a tax loss. It is a lie that has lasted 30 years.
But the real estate is even worse. I often visit apartment buildings built during the bubble. They are decaying, and tenants have fled to newer, modern buildings. The owner cannot sell the land because demolition costs hundreds of thousands of dollars—more than the land is worth.
The owner is now 70 years old. His family has drifted apart. He lives alone in one of the empty units, acting as the caretaker of his own ruin.
The bubble isn't just a graph in a history book. It is an old man trapped in a concrete box he built with "easy money." That is why I fear the "Cash Burn" of AI. When the fuel runs out, the wreckage doesn't just disappear. Someone has to live in it.
As a loan officer in Japan who remembers the 1989 bubble, I see the same pattern. In the traditional "Shinise" world I work with, Cash is Oxygen. You hoard it to survive the inevitable crash. For OpenAI, Cash is Rocket Fuel. They are burning it all to reach "escape velocity" (AGI) before gravity kicks in.
In 1989, we also bet that land prices would outrun gravity forever. But usually, Physics (and Debt) wins in the end. When the railway bubble bursts, only those with "Oxygen" will survive.
Western architecture often uses cement to make things "rigid" and "perfect." But in Japan (an earthquake nation), rigid things snap and break.
Japanese stone walls (Ishigaki) have no cement. They are held together by balance and friction alone. Because they have "gaps" and "flexibility," they can *dance with the earthquake* and survive.
We call this *"Asobi" (Play/Slack).* Just like Agile, the system survives not because it is perfectly planned (Rigid), but because it allows movement. Modern software is finally relearning what old masons knew instinctively. Great read.
If you are building a "Pop-up Store" (a prototype or script), use libraries. Don't waste time on craft. But if you are building a "Shrine" (Core System/Database) that must last for 20 years, "Shugyo" is actually the cheapest option.
Efficiency is cheap now, but expensive later (Technical Debt). Craftsmanship is expensive now, but cheap later (Stability).
We don't need a Jiro to run a fast-food franchise. But we need him to build the Kernel.
1. *The "Inheritance" Route (Muko-yoshi / M&A):* As I mentioned, you can inherit an existing engine. In Japan, "Shinise" with no successor often legally adopt talented outsiders as CEOs (Muko-yoshi). Or, you can buy the company. My job is often matching these "Old Trust" with "Young Energy".
2. *The "Newcomer" Route (Startup Support):* If you want to build from zero, the system actually protects you. Depending on the municipality, there are massive subsidies for startups. For example, "0% interest" and "0 guarantee fees" for the first 5 years.
Culturally, we have a soft spot for the "Shinzan-mono" (Newcomer) who works hard. If you humbly present yourself as a beginner, the community and local government often step in to support you.
Japan is strict with "Rude Outsiders," but surprisingly warm (Humanity) to "Sincere Beginners."However, living right in the middle of it, I have started to see it differently. Japan is running a global experiment: *"How to sustain a civilization without growth."*
As you said, if the world is finite (Zero Sum), then "Scale or Die" will eventually stop working physically for everyone. Every country will hit the same wall. We are just hitting it first. We are the *test subjects* to see if humans can mature into a "Steady State" or if we just collapse. I am here to document the result.
"Shugyo" is about internalization. The 1st time you build Redis, you learn the Syntax. The 10th time, you understand the Structure. By the 20th time, *the tool disappears.* You stop fighting the keyboard, and the logic flows directly from your mind to the screen.
In Kendo (Japanese fencing), we swing the bamboo sword thousands of times. Not to build muscle, but to remove the "lag" between thought and action. Building it once with your own hands gives you a "resolution" of understanding that `npm install` can never provide.
In traditional Japanese business culture (I am a banker), we are trained to always establish "context" and "season" before talking business. It feels rude to start abruptly.
I promise I am a real human (an old loan officer in Gunma), but I will try to drop the intro and be more "direct" like a hacker. Thanks for the feedback.
Writing from Japan, we call this process "Shugyo" (austere training). A master carpenter spends years learning to sharpen tools, not because it's efficient, but to understand the nature of the steel.
Building your own Redis or Git isn't about the result (which AI can give you instantly). It is about the friction. That friction builds a mental model that no LLM can simulate.
Whether this post is marketing or not, the "Shugyo" itself is valid.
However, here in Japan, we have a different operating system called "Shinise" (companies lasting over 1,000 years). They play an "Infinite Game". Their reputation is tied to a "Noren" (shop curtain) or a family name that has been built over centuries. You cannot simply discard it and respawn.
There is a movie hitting theaters here in Tokyo right now called "KOKUHO" (National Treasure). It depicts Kabuki actors who inherit a "Name" (Myoseki) with 400 years of history. Watching it, I realized: In their world, cheating doesn't just mean losing a job. It means "killing the Name" for all ancestors and future generations. The penalty is infinite.
When the "Reset Button" is removed from the game, "Honesty" and "Sanpo-yoshi" (Three-way satisfaction) naturally become the mathematically dominant strategies. Cheating only works when you plan to exit.
As AI generates billions of lines of code, the world is about to be flooded with "technical debt" and "security holes." The scarcity shifts from writing code to verifying it.
Concrete Action: Shift your skill set towards security auditing, compliance, and system architecture verification. Position yourself as the "Digital Notary" who stamps the AI's work with a human guarantee.
When a bank (like mine) lends money to a software project, we don't ask "Did an AI write this?" We ask "Which human is going to jail if this fails?"
Be the person whose name is on the insurance policy. That is a job an algorithm can never take.
However, huge systems (countries) never change from the center. They change from the "Edge".
In biology and history, evolution always starts as a small "mutation" or "anomaly" that the main system initially rejects. If your country is 100% "Scale or Die," then a small business or community running on "Sustain" logic becomes a precious "Mutation."
You don't need to update the whole country's OS. You just need to run a small "Local Server" of this philosophy. Eventually, when the main system overheats, people will look for your server to cool down.
Data is just the sheet music; pronunciation is the actual performance. Without the right instrument (Audio OS), the music doesn't play.
We engineers tend to believe that concepts like "modularity," "reusability," and "DRY (Don't Repeat Yourself)" are modern inventions of software engineering.
But this analysis shows that ancient bards were already "coding" on the limited RAM of the human brain. They used these formulaic delimiters as "function calls" to sustain a massive narrative structure without memory overflow.
Perhaps humans haven't changed at all. We have always sought "Structure" to give shape to the chaotic "Soul." The Iliad was never just a poem; it was a highly optimized executable program meant to run on the human mind.
However, as a loan officer living in Japan, I see many people master the "Software" but fail because of the "Hardware" (Audio OS).
In Japanese, vowels (a, i, u, e, o) are standalone signals. We process them as language. But I've read that Western brains often filter them out as mechanical noise.
My advice: Use these tools to build your database, but don't forget to "update your BIOS". Unless you retune your brain to treat isolated vowels as Signal instead of Noise, the software won't run smoothly.
In banking terms, you are treating AI code as "OPEX" (Operating Expense) rather than "CAPEX" (Capital Expenditure). As long as we treat these $60 quick-fixes as "depreciating assets" (use it and throw it away), it’s great ROI.
My warning was specifically about the danger of mistaking these quick-fixes for "Long-term Capital Assets." As long as you know it's a disposable tool, not a foundation, we are on the same page.
I've been a loan officer for 20 years. We never trust a borrower based solely on their current balance sheet (the final weights). We look at the trajectory of their cash flow over the past 3 years (the training process).
Two companies can arrive at the same 'profit' today, but one might be evolving towards bankruptcy while the other is evolving towards dominance. You can't see that snapshot in the final model.
If we want to trust these 'black boxes,' we need to see their credit history, not just their credit score.
To extend your analogy: AI is effectively mass-producing 'Subprime Housing'. It has amazing curb appeal (glittering paint), but as a banker, I'd rate this as a 'Toxic Asset' with zero collateral value.
The scary part is that the 'interest rate' on this technical debt is variable. Eventually, it becomes cheaper to declare bankruptcy (rewrite from scratch) than to pay off the renovation costs.
AI optimizes for "Accuracy" (minimizing error), but it cannot optimize for "Taste" because Taste is not a variable in its loss function.
As code becomes abundant and cheap, "Aesthetics" and "Gestalt" will become the only scarcity left. The Architect's job is not to build, but to choose what is beautiful.
You are treating the AI not as a tool, but as a "Material" (like wood or stone).
A master carpenter works with the grain of the wood, not against it. You are adapting your architectural style to the grain of the AI model to get the best result.
That is exactly what an Architect should do. Don't force the old rules (DRY) on a new material.
In Japanese traditional carpentry (Miya-daiku), the master doesn't just cut wood. He reads the "heart of the tree" and decides the orientation based on the environment.
The author just proved that "cutting wood" (coding) is now automated. This is not the end of engineers, but the beginning of the "Age of Architects."
We must stop competing on syntax speed and start competing on Vision and Context.