{"id":51,"date":"2026-06-24T19:15:19","date_gmt":"2026-06-24T10:15:19","guid":{"rendered":"https:\/\/sr-works.net\/blog-en\/?p=51"},"modified":"2026-06-24T19:15:19","modified_gmt":"2026-06-24T10:15:19","slug":"finishing-the-requirements-with-claude-opus-4-6-my-ai-switching-strategy","status":"publish","type":"post","link":"https:\/\/sr-works.net\/blog-en\/finishing-the-requirements-with-claude-opus-4-6-my-ai-switching-strategy\/","title":{"rendered":"Finishing the Requirements with Claude Opus 4.6 \u2014 My AI Switching Strategy"},"content":{"rendered":"\n
\n

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.<\/em><\/p>\n<\/blockquote>\n\n\n\n

\ud83c\uddef\ud83c\uddf5 \u65e5\u672c\u8a9e\u7248\u306f\u3053\u3061\u3089 \/ Japanese version<\/a><\/em><\/p>\n\n\n\n

\n\n\n\n

Series: DataMigrator Development Journal (Part 3)<\/p>\n\n\n\n

\n\n\n\n

Last time, I wrote about how I started writing Rev.0 of the requirements document together with a different AI, and \u2014 through repeated critiques and fixes while having Claude review it \u2014 reached Rev.5. This time is the continuation: the second half heading from Rev.5 toward Rev.7, and the story of deciding to “switch” AI in the process.<\/p>\n\n\n\n

The phrase “switching AI” doesn’t quite sit right with me, somehow. It’s not like moving house, where you cart your chat history and documents over in one big load, and since AI isn’t a physical thing in the first place, it’s not quite “buying a replacement” either. Still, in terms of actually getting the work done, it was a decision that felt nearly as concrete as that.<\/p>\n\n\n\n

As the Document Grows, the AI Can’t Keep Up<\/h2>\n\n\n\n

As I touched on briefly at the end of last time, around when I reached Rev.5, the other AI I’d been using started behaving more and more erratically.<\/p>\n\n\n\n

The typical symptoms went like this. While we were discussing the latter half of the document, it would forget something it had supposedly decided in the first half and propose, all over again, an idea that had already been rejected. When I pointed out “that approach was already settled in Chapter 7,” it would apologize \u2014 “you’re quite right, my apologies” \u2014 but a few turns later the same kind of forgetting would happen somewhere else. Or, when I added a new chapter, the consistency between that chapter and the existing ones would break down.<\/p>\n\n\n\n

This isn’t the AI slacking off, much less being malicious \u2014 it apparently comes from a technical constraint called the “context window,” as Claude explained to me. There’s an upper limit to how much information an AI can handle at once, and when a document grows too large, it exceeds that limit. The behavior then becomes something like dropping old information while taking in new information. As a result, it looks like it’s “forgetting the first half.” That’s the gist of it.<\/p>\n\n\n\n

Come to think of it, human short-term memory has a similar constraint \u2014 the thing where you forget what you decided thirty minutes ago in a meeting as the discussion heats up. The difference is that for AI, that limit is technically fixed, and it also varies with the version and the length of the conversation.<\/p>\n\n\n\n

By Rev.5, the requirements document already had nearly twenty chapters, and with the finer supplementary notes it reached tens of thousands of characters. That it had grown to a volume the AI couldn’t fully grasp was, objectively, obvious.<\/p>\n\n\n\n

Why I Moved to Claude<\/h2>\n\n\n\n

So, from the second half of the requirements work, I decided to move the center of the work in earnest to Claude, which had been playing the reviewer’s role. There were three reasons.<\/p>\n\n\n\n

The first is simply the size of the context window. Even handling a document of the same quality, Claude has a higher upper limit on how much it can handle at once and is less prone to forgetting the first half. I could feel this right away. When I pasted in the full text of Rev.5 and asked “please check whether there’s any contradiction between this chapter and that one,” I’d get back an answer that had properly surveyed the whole thing.<\/p>\n\n\n\n

The second is a feature called “Project Knowledge.” This is a mechanism where you register materials per project, and during the conversation Claude searches them for the information it needs and uses it. It’s like “the AI’s long-term memory,” so to speak, and you don’t have to re-paste the document every time. If you register everything from Rev.0 through Rev.5 of the requirements document, it becomes able to answer questions like “there should have been a discussion like this in some chapter of Rev.3 \u2014 what was the conclusion at the time?”<\/p>\n\n\n\n

The third is usability with the design and implementation phases in view. DataMigrator’s development doesn’t end when requirements end. After that come design, implementation, testing, and release. Being able to keep using the same AI through those phases makes the handoff of context smoother. Thinking it through, switching over early \u2014 even partway through requirements \u2014 should make things easier down the line.<\/p>\n\n\n\n

To be honest, there was a slight resistance to switching. From Rev.0 to Rev.5, I had spent a fair amount of time with that other AI. Resetting its conversation history, and the context it had (supposedly) remembered, to move to a new AI somehow brings up a feeling of “what a waste of everything I’ve built up.” But thinking calmly, the accumulation remains on the document side, so even if the AI changes, I’d have no trouble as long as I carried over that document. I talked myself into it that way and decided to make the move.<\/p>\n\n\n\n

From Rev.6 to Rev.7 \u2014 Crushing the Remaining Issues<\/h2>\n\n\n\n

In Rev.6, after moving to Claude, I crushed the issues that had remained from the Rev.5 review one by one. Concretely, things like: what grouping method to use for Quick mode, whether the positioning of Exploration mode could be made clearer, and how to design the screen transitions among the three modes.<\/p>\n\n\n\n

What struck me at this stage was that Claude posed its questions in a one-question-at-a-time format. The style was: “Please answer Question 1. Once you’ve answered, we’ll move on to Question 2.” For me as a human, having a lot of points thrown at me at once makes my head a mess, so this way of proceeding was a huge help. I hadn’t specified “please go one question at a time” myself \u2014 Claude naturally proceeded in this style on its own, and looking back, I think that was significant.<\/p>\n\n\n\n

In Rev.7, I further tidied up the document’s formal aspects: organizing chapter numbers, adding a glossary, rearranging figures and tables, and putting the appendices in order. By this point, the requirements document had become a document of over thirty chapters. When I started writing Rev.0, I had absolutely not imagined that someone with zero programming experience would end up writing a thirty-chapter document together with AI. I can’t quite recall whether I’d ever handled a document that long anywhere in my own work.<\/p>\n\n\n\n

Appendix C \u2014 “Cleanly Deferring” What Can’t Be Decided<\/h2>\n\n\n\n

Rev.7 of the requirements document has an unusual chapter called “Appendix C.” It’s a “list of issues that can’t be settled at the requirements stage.” There were eleven of them in all.<\/p>\n\n\n\n

For example: the thread configuration (how many worker threads to run), the method for detecting symbolic-link loops, the final organization of the mode structure, the method of exclusive locking for the project folder, the size of the partial hash, the concrete contents of the scan-exclusion presets, and so on. Every one of them is closer to the territory of design than of requirements.<\/p>\n\n\n\n

Why did I put this into the requirements document? Because I wanted to leave it as a memorandum: “to build this tool, these points absolutely must be crushed during the design phase.” If you force a conclusion at the requirements stage, you decide things without enough technical examination, and they get overturned in the design phase. But if you forget they exist altogether, you’ll panic once you’re in the implementation phase \u2014 “wait, what were we going to do about this?”<\/p>\n\n\n\n

The conclusion I reached while consulting Claude was a compromise: “don’t decide, but don’t forget.” Appendix C is that compromise given form. It was only later that I started calling this approach “cleanly deferring.”<\/p>\n\n\n\n

Looking back now, I feel this is close to the sense of production scheduling in theater. When you make a schedule leading up to opening night, rather than writing “TBD” for things that aren’t decided, it’s better to decide “we’ll decide this by such-and-such date” \u2014 and that way, you end up not in trouble on the night. That kind of sense. Less a style for developing with AI, and more a moment where my own past experience was, just a little, useful.<\/p>\n\n\n\n

The Idea of Splitting Sessions<\/h2>\n\n\n\n

One more thing that solidified during my exchanges with Claude around this time was the idea of “splitting sessions.”<\/p>\n\n\n\n

In a conversation with Claude, one “chat” becomes one work session. But if you keep one chat going endlessly, the context-window problem I mentioned earlier comes up. The longer the conversation gets, the harder it is for the first half’s information to reach the latter half. This is a constraint that even Claude can’t fully escape.<\/p>\n\n\n\n

So I started a practice of splitting one big task (for example, “the second half of the requirements work”) into multiple sessions. I’d set a clear goal for each session, and once that goal was reached, move on to the next session. When starting the next session, I’d compile the deliverables of the previous session and a summary of what had been decided so far into an “initial prompt,” and hand it over at the very beginning of the new session.<\/p>\n\n\n\n

Creating this initial prompt was, in fact, quite an important task. What to write and what to omit, how much detail to go into, how to instruct what I wanted done in the new session. Get this wrong, and the discussion in the new session wanders. Get it right, and the new session can get straight to the heart of the matter.<\/p>\n\n\n\n

The initial prompt itself, too, settled into a method where I’d ask Claude “please make an initial prompt for the next session,” have it produce a first draft, and then revise it myself. Claude itself would sometimes propose where to break the session, and I often went along with those proposals.<\/p>\n\n\n\n

The Feeling That Requirements Were Finally Done<\/h2>\n\n\n\n

By the time I’d written Rev.7, I honestly had a feeling of “is this really the end?” I couldn’t shake the sense that somewhere in this thirty-plus-chapter document there was an oversight, and I had the worry that once I started implementation, different problems would come gushing out.<\/p>\n\n\n\n

While asking Claude for a final check, I also had, within myself, a resignation: “no matter how much longer I dig in here, the problems that surface when I move to design and implementation will surface regardless.” A requirements definition is something you can keep aiming for perfection on, but unless you declare at some point “settled, as far as I can currently see” and move on, it may be a task that never ends in your lifetime.<\/p>\n\n\n\n

In the end, I treated Rev.7 as the finalized version of the requirements phase and moved on to the next, design phase. The eleven items of Appendix C carry over, as is, as homework for the design phase.<\/p>\n\n\n\n

Next Time<\/h2>\n\n\n\n

Next time is about clutching Rev.7 of the requirements document and stepping into the design phase. I split the design phase into three sessions: Session 1 for architecture, Session 2 for the DB schema and class design, Session 3 for the GUI and test design. What was it like to have AI write design documents on the scale of 20,000 lines? How did I crush the eleven pieces of homework left in Appendix C? From here, I step out of the world of requirements and into the world of “how to build it.”<\/p>\n\n\n\n

\n\n\n\n

About Soul Resonant Works<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

\ud83c\udf10 Soul Resonant Works:
\u2192 https:\/\/sr-works.net\/en\/index.html<\/a><\/p>\n\n\n\n

\ud83d\udcdd This blog publishes the entire development process as a serialized journal.<\/p>\n\n\n\n

\n\n\n\n

If you found this article useful, please share it.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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. \ud83c\uddef\ud83c\uddf5 \u65e5\u672c\u8a9e\u7248\u306f\u3053\u3061\u3089 \/ Japanese version Series: DataMigrator Development Journal (Part 3) Last time, I wrote about how I started writing Rev.0 of the requirements document together with a different […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-51","post","type-post","status-publish","format-standard","hentry","category-ai-development-journal"],"_links":{"self":[{"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/posts\/51","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/comments?post=51"}],"version-history":[{"count":2,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/posts\/51\/revisions"}],"predecessor-version":[{"id":54,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/posts\/51\/revisions\/54"}],"wp:attachment":[{"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/media?parent=51"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/categories?post=51"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sr-works.net\/blog-en\/wp-json\/wp\/v2\/tags?post=51"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}