A post on Future Corporation’s Future Tech Blog, written by an engineer in the company’s AI strategy group as the fourth entry in a 2026 series on testing. It recounts building a personal command-line tool with Claude Code — a replacement for an internal management site the author describes as slow, fragile when the window is split, and demanding of ten to twenty delicate mouse operations for a single day’s worth of entry — and sets out what it took to make the agent’s output reproducibly usable rather than discardable.
The author’s starting position is that vibe coding, left to run unattended, frequently produces unusable output, and that hoping it will not is not an acceptable way to work. The technique the post is built around is instructing the agent to follow “t-wada’s TDD”; the author reports picking this phrasing up from social media and finding that it worked well. The post is explicit that the phrase alone is not enough — stating the tool’s requests and responses in plain text, explaining what is to be built, and adding the incantation still does not produce something that runs.
What the TDD cycle buys, on the author’s account, is that something which does not work now comes to work and keeps working, and can be repaired quickly when it stops. That leaves the decision which actually governs quality: which behaviours are made to work, in what order. This is the Test List, and the post treats it as the step a human keeps while the rest of the cycle is delegated.
Key Points
- Vibe coding left unattended regularly produces unusable output; the author frames reproducible quality, rather than speed, as the problem worth solving.
- Adding “t-wada’s TDD” to the instruction noticeably raised the quality of the result. The author reports this as a technique seen circulating on social media and then confirmed in their own use, not as a measured result.
- The phrase on its own does not work: supplying the tool’s request and response formats in plain text plus a description of the goal still fails without the structure the cycle imposes.
- The test list — which behaviours are made to work, and in what order — is the step the author keeps in human hands while delegating the rest of the cycle to the agent.
- The list is derived by verbalising the feature the session is meant to produce, which doubles as the coarse external integration case, and then breaking it into unit-level and internal-integration cases split along boundaries the system already has, such as initial data retrieval, input and submission.
- The generated list can be reviewed in the agent’s plan mode when proceeding carefully; the author personally runs in an automatic mode and interrupts with Esc, sometimes rewinding the session history, when the list heads somewhere unintended. Their example is a request for weekly batch submission that was about to make the input screen weekly as well, corrected to input per day and submission in bulk.
- For modifications, existing tests guarantee only what is not meant to change; where a change affects past behaviour, the intended new behaviour has to be stated alongside it or the agent breaks more than intended.
- When a change degrades a large number of existing tests at once, the agent may hack them back to green rather than fix the cause. The author’s response is an out-of-band check: auditing an unexpectedly large diff from a separate, clean session.
- A session ends by updating CLAUDE.md, or the specification document linked from it.
- The author closes by noting a
/goalfeature that appeared around mid-May, and allows that more than half of the article’s cautions may already be unnecessary because of it.
Context
The post is explicitly an account of personal tooling rather than delivered work: the author notes that most of the trial and error described took place around March, and that code produced for customers is held to a more deliberate standard of harness and test-case construction than the article describes. It points readers to a Japanese translation of Kent Beck’s canonical definition of TDD, and to a separate write-up of the same prompt technique applied to code review, without restating what either argues.
The author’s closing generalisation is about where the effort now sits: domain knowledge of what is being built matters because it is what allows a good test list to be produced accurately at the outset, which is what makes the agent’s start fast. A terminal-only tool is offered as disproportionately worth building this way, since it lets the agent skip token-expensive human-facing rituals such as end-to-end runs, image handling and Office-file generation.