The industrial revolution in reverse engineering.

What changed in August 2026

Before this reconstruction work, I had done a lot of manual reverse engineering. The familiar loop was to inspect instructions, follow references, form an explanation, test it, and revise it. Progress depended on how much of that loop I could carry out myself, and how well I could keep the growing picture in my head.

In August 2026, I began exploring agent-driven RE seriously. I wanted to see how far an agent could go when it had access to the program, ordinary development tools, and feedback from real checks. Touhou reconstruction became the place where I could pursue that question through a substantial project.

The early progress was startling. Tasks that I would have budgeted around my own time and attention could keep moving while the agent investigated, tried source formulations, compiled them, and examined the result. My work increasingly involved choosing the direction, improving the tools and checks, and deciding what the accumulated evidence meant.

That changed which projects seemed reasonable to attempt. A large executable began to look like a collection of investigations we could organize and keep advancing. Recovering source, making it readable, and eventually using it for a port became parts of an achievable project.

The numbers first got my attention. The more interesting question was what made that progress possible—and whether the process could improve as it worked.

TH08: building on human work

TH08, Imperishable Night, began for me as a continuation of GensokyoClub's reconstruction. Their public work already contained source, names, build knowledge and a contribution history. It gave the continuation a foundation. That foundation matters when discussing everything that followed.

I preserved the imported history through the public 10 August checkpoint. The independent continuation began on 13 August. By 19 August, the project's ledger recorded source for all 1,107 identified game functions. A playable Linux reconstruction port was committed on 24 August, roughly eleven days after the continuation began. A Web edition followed, then a native Linux 64-bit release on 30 August.

Those dates made the change in pace tangible. What interested me most was that the work extended beyond producing plausible C++. It included comparisons, build repairs, recovery of meaningful names and types, and the work needed to turn reconstructed pieces into a program people could run.

This also exposed the importance of feedback. A function can look correct and compile correctly while its place in the whole program is wrong. Two functions can accidentally use separate copies of state that should be shared. A port can hide a problem that appears when the historical build runs. Each failure adds something useful if we can reproduce it and keep the check.

Over time, more of the project lived outside any one conversation: source, evidence, comparison scripts, regression tests, and focused notes about what to do next. A fresh agent could inspect that state and continue. The repository was becoming the project's working memory.

A successful batch gave us both recovered code and a better environment for the next batch.

Two different ideas of reconstruction

There is a real disagreement around this work, and GensokyoClub's public README expresses it directly. Its notice announces that further development will happen privately until completion. One passage reads:

The rise of grifters (AI decompilations and ports) in this space taking from our work paints a bad image for future decompilation efforts…

The notice also describes the psychological toll on the maintainers. Their contribution policy excludes pull requests produced primarily with AI. These are people putting their free time into difficult work, and their published work helped make my continuation possible. That effort deserves respect. The disagreement I want to discuss concerns how reconstruction is done and how contributions are evaluated.

In the manual RE workflow I knew, expertise and execution were closely connected. The person developing an understanding of a function also carried out much of the investigation and reconstruction. Personal knowledge, careful authorship and trust in contributors were central to the project.

Manual projects already preserve knowledge in code, build tools and tests. What changed for me was having an agent use that accumulated knowledge to investigate, implement and test the next change.

My continuation takes an agent-led approach. Agents carry out the new engineering; the human sets direction and release decisions. Understanding has to be retained in source and evidence, while comparisons, builds and runtime experiments test the results. A contribution can be useful even when an agent performed most of the work, provided its reasoning and result can be examined.

This creates a difficult transition for communities built around the earlier model. Open source makes existing work available for continuation, and agents can change the pace of that continuation dramatically. Years of careful work may become the starting point for something that moves much faster. Recognition, provenance and the standards for accepting new work become more important in that situation.

The industrial analogy helps me make sense of the disagreement. A craft contains skill, judgment and accumulated knowledge. When machinery changes how execution happens, those skills find new roles in designing the process, detecting defects and deciding what should be produced. Different communities can reasonably choose different ways to organize that work.

My choice is to develop this continuation openly, preserve its sources and history, and make the new work reviewable. The technical question I want to pursue is how far agent-driven reconstruction can go with strong evidence and a process that keeps improving.

Source: GensokyoClub's README notice, checked on 10 October 2026, and its contribution policy. The quotation is a shortened excerpt. TH08's credits and provenance record the continuation boundary.

TH095: experience starts compounding

TH095, Shoot the Bullet, made the accumulated experience much easier to see. Its new repository began on 29 August with zero confirmed game functions in the reconstruction ledger. It already had a way to work: identify the target, bring up analysis and comparison tools, keep tasks manageable, preserve evidence, and leave checkpoints another session could use.

By 7 September, all 697 identified game functions had source. By 8 September, 696 of them were accepted as exact comparisons. The whole program linked on 9 September, and the Windows i386 reconstruction was marked playable on 10 September, about twelve days after initialization.

I found this more exciting than the first project's speed. TH095 began with the process and experience developed during TH08 and the other reconstruction work. We could approach a new target with better questions, better checks and fewer assumptions left implicit.

For example, matching individual functions had taught us to pay attention to the assembled program early. Does the source build together? Do different parts of the game use the same state? Does the reconstructed executable survive the transitions we need to exercise? Those questions became part of how the next project was organized.

This is what I mean by knowledge compounding. A lesson that stays in my head helps while I am present. A lesson retained as a test, a script or a precise evidence note can help every later session. A failure becomes valuable when the next agent can recognize it without repeating the whole investigation.

The method becomes part of the starting material for the next game. As that material improves, we can spend more attention on what is new about the target.

This compounds across people as well as projects. Someone joining later can rerun a check, inspect the reason for a source choice, or continue from a recorded unknown. The project can make use of experience without requiring everyone to reconstruct its entire history from scratch.

TH04: the workflow survives a different architecture

TH04, Lotus Land Story, took the work into the PC-98 DOS era. We moved from 32-bit Windows games to a 16-bit environment with four cooperating programs and hardware behavior that had to be understood on its own terms. Existing ReC98 work provided valuable knowledge and source material here too.

The DOS reconstruction is now working, including complete Normal routes, endings and saves from my manual testing. The current work is a native 64-bit port. These are distinct phases: first establish a working reconstruction on the original platform, then carry its behavior into a new environment.

TH04's architecture changed the evidence we needed and the tools used to collect it. It did not require inventing a different way to organize the work. We could still isolate a question, inspect the original behavior, reconstruct it, compare the result and retain the lesson.

The difficult parts became concrete experiments. Which part of startup establishes a piece of state? What happens when gameplay hands control to an ending? Which hardware effect must the reconstructed code preserve? With observations and a useful check, an agent could work through these questions in the same iterative way as it did on the Windows titles.

That is why TH04 matters to the larger argument. The process generalized across a substantial change in platform. Architecture determined the subject of the investigation; it did not become a fundamental barrier to the workflow.

The 64-bit port now gives that work another use. We can revisit the recovered behavior, separate it from old platform services and test new implementations against what we learned. The reconstruction supplies both source and a growing body of knowledge about how the game should behave.

Project state as of 10 October 2026: DOS reconstruction and manual testing · 64-bit port. The port remains in development.

What makes this an industrial shift

These projects changed my view of the bottleneck. As more investigation and implementation can be carried out by agents, the working environment becomes increasingly important. The agent needs access to the target, tools it can compose, feedback it can act on, and memory that survives its current session.

REA fits into that picture by making reverse-engineering tools available through interfaces an agent can use. It can inspect code, follow relationships and return evidence for the next question. Reconstruction projects add their own compilers, comparisons and runtime checks. Together, these give an agent a way to move from an explanation to an experiment with an observable result.

Fast execution makes good feedback more valuable. A bad assumption can produce a large amount of plausible source. A useful check can reject that assumption early and point to the next investigation. Improving a check improves many later decisions, which is why tooling and verification deserve as much attention as the recovered code.

The work also needs continuity. A conversation can end while the campaign continues. Its result should leave the repository in a state another agent can understand: what changed, what was tested, what remains uncertain, and where to continue. This lets a large reconstruction proceed through many small experiments without relying on one uninterrupted session.

The Touhou Reconstruction Factory grew out of these experiences. It gives the projects shared ways to retain evidence, run checks and carry useful lessons between games. The point is to make the next investigation easier to execute, easier to judge and easier to resume.

This is the industrial shift I see: expertise increasingly lives in a working process that can be reused and improved. Human judgment shapes the process. Agents supply much of the execution. Verified results and accumulated lessons make the process more capable over time.

The projects we can now consider

The pace matters because it changes the cost of beginning. When I imagined doing every investigation manually, I also imagined committing my own attention to each one. A sufficiently large project could be interesting and still remain something I would never realistically attempt.

An agent with access, feedback and project memory changes that calculation. Recovering a game, making its source readable, building a port, or exploring a mod can become a sustained engineering effort with a practical way to keep going. The work still involves difficult questions, but there is now a process for giving those questions sustained attention.

TH08 showed me what an agent-led continuation could achieve on top of human work. TH095 showed how the experience could carry forward. TH04 showed that the method could cross into a very different platform. Together, they made the industrial analogy feel concrete.

I now look at an unfamiliar program and ask: what access, feedback and accumulated knowledge would let an agent work on this reliably?

That question opens up projects I would previously have left alone. Each one can add code, checks and experience that make the next more approachable. That is the future of reverse engineering I want to keep exploring.

More articles · Explore a TH04 investigation