This article was originally written in Japanese and translated into English with AI assistance. Please note that some expressions may carry nuances from the original Japanese.
π―π΅ ζ₯ζ¬θͺηγ―γγ‘γ / Japanese version
In the previous post (SP02), I covered the first six sessions of the HP English translation project β the discovery and repair of the footer damage, the establishment of the three-way cross-review system, and the structural solution to procedural mistakes.
This post covers the second half: translating the remaining four files and carrying the project through to completion. The biggest stumble of the project was waiting in this second half. The night all the AIs went down.
Taking On a Giant 68 KB File
In Sessions 7 and 8, I completed the translation of the What’s New page (whats_new.html) and the About page. Three files remained. The biggest wall among them was index.html β the top page.
This file was 68 KB, three to four times the size of the others. It contained product introductions, a development timeline, a technology stack overview β the content that effectively represents the entire site. It was also the file with the most expressions that required careful handling from an intellectual-property perspective.
For example, the phrase “six AI systems” appears six times in historical descriptions, while descriptions of the current state say “seven.” The translation needed to preserve this distinction precisely. Past references should say “six systems,” and present references “seven systems.” Mix them up even once, and you give the reader contradictory information.
Before handing index.html to Claude Code, I first had Claude.ai chat read through it entirely and identify the IP-protection-critical passages in advance. Twelve spots of architecture-design-related terminology, seven spots involving six/seven systems notation. I compiled these into a list and incorporated them into the translation prompt, which prevented Claude Code from accidentally “just making everything seven” across the board.
Session 9 β The Night All the AIs Went Down
Session 9 was the most abnormal session of this project. The amount of work done was zero.
As I wrote in SP02, by this point Copilot was refusing to read files entirely, and was out of action as a reviewer. “If Copilot isn’t available, we’ll just run reviews through Claude Code and Claude.ai chat” β that was the plan.
But then, even Claude β our fallback β died.
It was the night I was about to begin translating the product detail page (ai-multilingual-meeting-detail.html). When I sent a status-check prompt to Claude Code, I got back an API 500 error. Retries gave the same. Three failures in a row.
“If Claude Code is unhealthy, let me switch models,” I thought, and retried after changing settings. Still no good. Even when I shortened the prompt to the absolute minimum β “just return git status” β I got a 500.
Reluctantly, I shut down Claude Code and restarted it. git status and git log came through. But just as I breathed a sigh of relief, the moment I tried to run a grep command, this time I got an auth error (401).
“Maybe it’s just a Claude Code issue,” I thought, and tried to continue in Claude.ai chat. The chat side displayed: “Cannot connect to Claude.”
Copilot couldn’t read files. Claude Code wouldn’t run due to errors. Claude.ai chat couldn’t even connect. All three AIs were unusable at once. When Copilot first became unstable, I could still think “I’ll just use Claude instead.” But now Claude itself was down. The backup for the backup didn’t exist.
At that point, I decided: “There’s nothing to do but wait.” I judged this was an infrastructure outage on Anthropic’s side. If it’s a problem on the service provider’s end, not my environment, there’s nothing to do but wait.
The Structural Vulnerability of AI-Dependent Development
The biggest lesson from Session 9 was this simple fact: “Development that depends on AI stops completely when AI infrastructure fails.”
In traditional development β the style of writing with just a text editor and compiler β work can continue even if the internet connection drops. The tools are right there in your hands. But in vibe coding, when AI services go down, you literally cannot do anything. Since the ability to write code resides on the AI side, the human has no option but to wait.
I believe this is an inherent vulnerability of vibe coding. Convenience and fragility often go hand in hand. In SP01 I wrote about “the pitfall of an era when AI can build anything,” but “there are moments when you cannot build anything” is another feature of this era.
That said, I don’t think we need to fear this vulnerability too much. By the next day, the service had recovered, and I was able to resume as Session 10 in a new chat. Outages are temporary. What matters is accepting that “things can stop” as a premise, breaking work into session-sized chunks, and committing intermediate state diligently.
Phase A Complete β Finishing the Translation Without Copilot Review
From Session 10 onward, Claude had recovered, and I progressed through the remaining files smoothly. The two product detail pages had the most IP-protection-critical content, but the three-step approach I had established with index.html β “prior analysis β translation β verification” β worked.
In Session 11, the last translation file was completed, and all eight English-version files were in place. Internally, I’ve been calling this “Phase A complete.”
However, the translations up to this point were completed by just Claude Code + Claude.ai chat, a two-way system. The third-party review by Copilot was missing. As I wrote in SP02, Copilot had been left as-is, refusing file reads. The decision was to prioritize keeping the translation moving, but we couldn’t skip Copilot review from a quality-assurance standpoint.
Wrestling with Copilot β Somehow Getting It to Review
With translation done, the next step was to have Copilot review. But Copilot was still unable to read files. From here, the struggle began.
Since this is translation review, HTML file reading was essential. Text pasting had a 10,240-character limit β not workable for long files like the product detail pages. I tried converting to text files (.txt) and uploading those, but that didn’t work either. I tried converting to PDF, but Copilot pushed back: “It has to be an HTML file.”
“You were reading HTML just a little while ago,” I pointed out. It kept insisting, “The specification has changed.” Within the last hour or so, mind you.
The exchange went on. “The PDF contents are no longer auto-extracted β paste the text instead.” “Text is impossible because of the character limit, which is why I made a PDF.” “The PDF contents are treated as empty.” After all that, it kindly explained: “You’re not doing anything wrong on your end. It’s a change on Copilot’s side.” Well then, please do something about it.
In the end, when I attached the PDF again from the web version of Copilot, it suddenly said: “I can now confirm the full English-version HTML.” The reason is unclear. What it had been saying was impossible became possible using the same method. A considerable amount of wasted time.
And once it could read the file, another problem emerged. The HTML source code had been broken during the PDF conversion. Spaces were inserted around underscores in BEM notation (a CSS class-naming convention), comment tag closings were mangled, and newlines appeared mid-attribute value. Copilot explained this as “breakage during text extraction from PDF,” but it was Copilot’s specification change that forced PDF delivery in the first place β a circular argument.
Ultimately, I fixed the tag breakage on the Claude Code side and had Copilot focus only on the naturalness of the English. The role of Copilot as “reviewer” in the three-way system was preserved, but frankly, the journey to restoration was more exhausting than the translation work itself.
This is the reality of vibe coding. Even with three AIs, each one becomes unstable for different reasons at different times. And when you ask the AI itself why it became unstable, you don’t get accurate answers. Right after saying “the spec has changed,” it does the same thing with the same method. Even in human-to-human communication this would be confusing, but with AI especially, pursuing “why can you do it now when you couldn’t a moment ago” yields no answers. You need the judgment to give up and move forward.
Copilot’s “Legal Tone” Revision Suggestions
The revived Copilot offered an interesting observation. It noted that the wording of the AI translation disclaimer (the header banner saying “This page contains AI-assisted translation”) was too casual for a business site.
Indeed, the initial disclaimer had been written during translation work with a “good enough if the meaning gets across” mindset. Following Copilot’s feedback, I rewrote it in a tone closer to legal documentation. What was previously “This page contains AI-assisted translation” was revised to formal wording that specifies the scope of disclaimer and a contact point for inquiries.
AI generates β another AI reviews β human scrutinizes and accepts or rejects. This cycle, which had nearly collapsed at one point, ended up elevating quality even to the level of legal language. It was worth persisting to restore the three-way system rather than giving up.
However, having all eight files in place with review completed wasn’t the end. A list of issues that had accumulated through Phase A β beyond the disclaimer wording, the footer horizontal rule inconsistency, navigation structure mismatches β remained. That’s Phase B.
Phase B β What Should Have Been “Minor Fixes” Became Major Surgery
Phase B was initially estimated as “a collection of minor fixes.” But once I looked into it, the scope was beyond imagination.
The biggest discovery was that the navigation structure existed in two different variants. Of the 16 files, 10 were built in Pattern A (ul>li>a format) and 6 in Pattern B (div>a format), and mobile display behavior was split into three patterns. On some pages the hamburger menu would open and close. On others it was always displayed and wrapped. On yet others, the menu disappeared entirely.
This “disappearing menu” was occurring on the About and What’s New pages. On mobile access, navigation wasn’t displayed at all, leaving zero routes to other pages. This is a serious practical bug.
The cause was subtle structural differences between HTML that had been AI-generated at different times. Differences in generation timing and prompts produced divergent internal structures across pages of the same site. The theme I wrote about in SP02 β “fixing HTML broken by AI, with AI” β was repeating itself here.
In Session 15, I performed a large-scale refactoring that unified all 16 files to Pattern B + hamburger toggle. Including link path corrections, 212 modifications were made in a single session.
16 Files, Completed
With all Phase B issues closed, the 8 English files + 8 Japanese files = 16 files were now consistent both structurally and linguistically.
From the start of the project to this point: 15 sessions, Session 1 through 15. One AI breaks, another fixes, a third reviews, a human decides. Through that repetition, the 16-file multilingual site came together.
However, this is still just within my local development environment. It hasn’t been uploaded to the production server. Next time: at last, the production deployment story. Unexpected traps were waiting here too.
Next Time
SP04: “Production Deployment β The .htaccess Trap and the Moment of Going Live.”
About Soul Resonant Works
Soul Resonant Works is a solo venture developing seven local AI systems.
Starting from zero programming experience, the development is progressing through collaboration with AI.
π Soul Resonant Works:
β https://www.sr-works.net/en/
π This blog publishes the entire development process as a serialized journal.
If you found this article useful, please share it.