Zero Hallucinations in AI Development! Practical Data on Completing Code & Test Creation in [Approx. 6 Hours] Using an Isolated Workflow
Introduction
Introduction: For those struggling with 'code that doesn't work or never ends' in AI development
There is a practical template download at the end of this article. Please make use of it.
In recent years, system development utilizing generative AI such as ChatGPT and Claude has spread rapidly. While it is expected to be a means to supplement programming knowledge and significantly improve development speed, I hear the following concerns very often in practical settings.
「AIにコード作成を指示したものの、エラーばかりで全く動作しないプログラムが出来上がった」
「修正を繰り返すうちにAIが迷走し、いつまで経っても開発が完成しない」
「試行錯誤に時間を取られ、結局はプロのシステム開発業者に高額で依頼することになった」Many people have likely had the experience of trying to build apps or tools after hearing that 'you can easily create them if you use AI,' only to find they didn't get the results they wanted and ended up wasting time and money instead.
In fact, the biggest cause of such failures is not a lack of AI performance, but 'context pollution' (confusion of the AI due to the accumulation of conversation history).
If you cram all processes—such as 'specification formulation,' 'production code generation,' 'automated test code creation,' and 'debugging (fixing)'—into a single chat thread, the AI will drag along the context of past incorrect code and trial-and-error. As a result, 'hallucinations' (generating fake code) frequently occur, where the AI generates code based on non-existent functions or past memories. Target audience of this article (Recommended for the following people)
For engineers, individual developers, and business professionals who have the following goals
AIを活用してプログラミングやシステム開発の効率化を図りたい方
AIが生成するコードのエラーやハルシネーションに悩まされ、開発がストップしている方
高品質な「本番コード」と「自動テストコード」をAIで安全かつ確実に作成したい方
開発現場で今すぐ使える、再現性の高い実践的なAIワークフローを知りたい方Benefits of reading this article
ハルシネーションを極限までゼロに近づける「隔離型ワークフロー」の概念と具体的な構築手順
「本番コード生成」と「テストコード作成・実行」のスレッド分離技術による、AIの回答精度の劇的な向上
ローカル開発環境（IDE）での安全なテスト実施手順と、最新のエージェント型AI（Claude Code等）を活用した自律的デバッグ手法
約6時間でコード作成からテスト完了まで完走した、実際の取材データ・実践ノウハウYou will be able to break away from development where you are at the mercy of AI and master a 'reproducible process for building systems that work reliably and speedily.' [Limited Bonus] We are giving away the 'Practical Work Procedure Manual' actually used for free!
This time, I have compiled the 'AI Isolated Development Workflow/Practical Procedure Manual (with templates and prompt collections)' as a bonus so that anyone can reproduce the development process explained in the article in their own environment without getting lost.
It covers the step-by-step concrete procedures that I personally verified through repeated trial and error, completing the tests in about 6 hours. You can obtain it completely free of charge from the end of this article (or the download link), so please make use of it in your own development environment.
Now, I will explain the specific methods to prevent context pollution and maximize the potential of AI development.
An 'Isolated' Workflow to Prevent Context Pollution
The most effective approach is to completely separate the context (threads) for 'production code generation' and 'test code creation/execution'.
1: Procedure for automated testing and code creation
Production code generation thread (new creation)
Pass the specifications and have it output only the necessary production code (in units of classes or methods).
Place the completed code in your local development environment.
Test Code Generation Thread (New Creation)
Do not reuse the thread used to output the production code; instead, start a new chat thread.
Pass only the "production code definitions (interfaces and method names)" generated in step 1, and provide instructions as follows.
Prompt Example (Test-Specific Thread): "Please create unit test (UT) code for the following function. Include cases for normal, abnormal, and boundary value testing." (Paste the code created in step 1)
By doing this, the test code creation thread contains only the "context necessary for test creation," preventing the AI from being distracted by unnecessary intermediate reasoning and resulting in high-precision test code output.
2: Procedure for Executing Tests
There are broadly two approaches to having the AI "execute tests." Please choose the one that fits your development style.
Pattern A: Execute in a Local Environment (Safe and Reliable)
In this method, the AI is responsible only for outputting the test code, while execution is performed in your local development environment (such as Lazarus or VS Code).
Placing the Test Code
Place the test code generated by the AI into the project's test directory.
Execute Locally
Run the tests using the IDE's test runner or the command line.
Ask the AI Only If It Fails
If the tests pass, you are done.
If an error occurs, pass only the three items: "production code," "test code," and "error log" to a new thread and have it provide a fix.
Pattern B: Use an Agent-Based AI (e.g., Claude Code)
If you are using a CLI tool (such as Claude Code) or an agent-based AI with local execution permissions, it is possible to have the AI execute the tests itself.
Have the AI create the "production code" and "test code."
Have the AI execute the test command in the terminal.
If a test fails, the AI autonomously reads the logs and self-corrects the code (iteration) until the test passes.
Why does this method prevent hallucinations?
Amount of context
Traditional approach (single chat): Specifications, trial and error, and revised code accumulate and become massive.
Isolated workflow (recommended): Can be kept to a minimum for each phase (code generation / test creation / correction).
AI focus level
Traditional approach (single chat): Influenced by bugs and incorrect specifications from past conversations.
Isolated workflow (recommended): Can focus solely on generating tests for the single piece of code provided.
Hallucinations
Traditional approach (single chat): Outputs fake code based on non-existent functions or past memories.
Isolated workflow (recommended): Drastically reduced because it only looks at the signature of the input code.
The decision to 'avoid doing this for fear of context contamination' is a very sensible judgment. By adopting the practice of 'splitting threads for each step (=disposable)' from now on, you can smoothly create and execute automated tests while completely avoiding hallucinations.
Practical template
Please download it here.