| ▲ | all2 5 hours ago | |
I've found success using the following process: 1. get the LLM to generate a spec from the code (the spec is your new source code). Take your time here, make sure it is correct. Split out implementation details unless they are critical to the business logic. 2. Using the spec, begin crafting an ARCHITECTURE.md -- you put all your non-critical implementation details here. If you need to track requirements, require the LLM to reference the paragraph number(s) of the spec file as it writes the architectural spec. Take your time here as well (this is the second layer of your new source code). 3. Create a high level TODO from the architecture doc. 4. Create a mid-level TODO from the architecture doc (you'll know if this is necessary, perhaps chunk work up by function, feature, or architectural layer). 5. Create a granular level TODO where each task is very tight in scope (write this function, create a translator for this JSON de-serializer to create the app-level model for this object, etc.) Then let a model go to town. In the mean-time, you should also require testing. If you have the opportunity, you should have an LLM inspect, spec, and write comprehensive tests for the old code on the external API/interface. You'll be able to use this to test your new implementation to ensure all the corner cases and functionality are covered. | ||