In this blog post, I demonstrate a hands-on example of using AI tools with a legacy technology system to build the foundation for a modern software solution.

This is the SpecOps method in practice.

https://spec-ops.ai/blog/posts/reverse-engineering-legacy-app/

Using AI to Reverse-Engineer a Legacy Application into a Modern Software Specification

How we used AI to extract a complete specification from a 25-year-old Microsoft Access application, producing 13 modular documents in roughly 4–5 hours of collaborative work.

@mheadd I'm interested in whether you'll be able to demonstrate multiple test-passing versions based on different stacks from the same spec. And from there, I'll be very interested in the usability of the resultimg implementations, and how/if that can also be tackled with AI and incorporated into the spec, with the downstream versions regenerated.

Also: Has it occurred to you yet that this is "what if waterfall, but the cost of development/change was zero"? 😉

@mheadd Also way more informative would be to publish the actual session logs of the prompting you did to get to this point over those 4-5 hours. In a format something like this:
https://pi.dev/session/#d4ce533cedbd60040f2622dc3db950e2
Session Preview – pi.dev

@mogul Why wouldn't you be able to? I'm a bit confused by the waterfall reference.

I'm advocating for human-led, iterative work with an AI coding agent and I tried to emphasize that in the post. I know there are some folks talking about AI only, but it's not how I work with these tools. I also talk at length (and ad nauseam) about the critical role that human oversight, review, and verification play in the process. In fact, once you have a decent spec to work from, there's no AI requirement

@mheadd Right, I understand the concept/ambition, just want to see the fully worked proof that the spec generated this way is "enough" to then generate and iterate in downstream implementations.

(Re: waterfall, it's the " document all your specs and verification up-front" aspect, not the lack of iteration. I'm just yanking your chain.)

@mogul I talk a lot in the book about iterative use of the SpecOps approach. There is some discussion of that here, but its expanded on in the book (I can send a copy if you like).

https://github.com/spec-ops-method/spec-ops/discussions/2

I don't do hands off, one-shot, YOLO development with AI tools and I don't recommend that others do so either. Particularly not for replacing existing legacy systems.

Isn't SpecOps Just Waterfall? (Spolier alert: No) · spec-ops-method spec-ops · Discussion #2

The Observation "SpecOps seems to require documenting everything upfront before you can start building. Isn't that just waterfall methodology with a new name? We've moved past that for good reasons...

GitHub

@mheadd Right, I get it, and I understood the difference immediately. It's more about recognizing that AI makes this more practical than in the past by bringing the cost of iteration down. I'm glad you're being explicit about that.

(That said, the AI-generated text there is exhausting to read... Endless bulleted lists, and generated headings like "The [noun]: [phrase]".)

@mogul That's fair. I opted for letting it embrace thoroughness and then focused on distilling it downstream.