| | 63 | === Extracting valid features from semi-failed experiments === |
| | 64 | |
| | 65 | When you are making large changes and, despite many attempts, you can't get the code to work perfectly, you might find yourself in a "loop" where new iterations fix one thing but break previous functionalities. This often leaves the codebase in an unusable state with unknown side effects. |
| | 66 | |
| | 67 | Instead of pushing forward blindly, follow this recovery pattern: |
| | 68 | |
| | 69 | 1. **Create a temporary history:** Commit your various attempts (even the broken ones) into a temporary branch or a series of local commits. |
| | 70 | 2. **Generate a global diff:** Create a single diff or patch of all the changes happened, not as a final one but as an "all of them". |
| | 71 | 3. **Reset to a clean state:** Revert your working directory to the last known stable point. |
| | 72 | 4. **Targeted implementation:** Provide the AI with the global diff as context and ask it to: '''Based on these differences, implement EXCLUSIVELY the following specific feature/logic.''' |
| | 73 | |
| | 74 | {{{#!sh |
| | 75 | git log -p origin/main..main > global-patch.diff |
| | 76 | }}} |
| | 77 | |
| | 78 | This approach allows the AI to act as a filter, extracting only the useful logic fragments that actually worked during your experimentation while ignoring the "noise" and bugs introduced during the failed iterations. You can then rebuild your feature step-by-step, ensuring each piece is solid before moving to the next. |
| | 79 | |
| | 80 | === Using Reference Diffs for API Porting === |
| | 81 | |
| | 82 | When porting a complex system (like a filesystem) to a newer environment with a different API (e.g., a newer Linux Kernel), you can use a "reference implementation" to guide the AI. |
| | 83 | |
| | 84 | For example, to port the ''ReiserFS'' (v3) filesystem which was deprecated around kernel 6.x into a new kernel version: |
| | 85 | |
| | 86 | 1. **Identify a reference:** Choose a similar, well-maintained component (ideally smaller) in the target environment (e.g., the `fs/ext4` directory in the kernel) and start from a version on which the previous code of target (reiserfs) was fully working. |
| | 87 | 2. **Generate a reference diff:** Create a diff of that reference component between the old and new versions. This patch acts as a "visualizer" of the API changes. |
| | 88 | 3. **Analyze the patterns:** In this diff, you might see systematic changes, such as functions or variables previously named `page` being renamed to `folio`. |
| | 89 | 4. **Guided Adaptation:** Provide this reference patch to the AI and ask it to edit your own files (e.g., ReiserFS source files) to adapt them to the new API, using the reference patch as inspiration for the required transformations. |
| | 90 | |
| | 91 | This technique provides the AI with concrete examples of how the environment has evolved, making it much more accurate at applying those same patterns to your specific codebase. |
| | 92 | |
| | 93 | Examples: |
| | 94 | |
| | 95 | {{{#!sh |
| | 96 | git diff v6.10...HEAD -- fs/ext4/ > patch.diff # this diff is too long for AI, so let's make it shorter: |
| | 97 | |
| | 98 | git diff -U0 --minimal --no-renames --no-prefix v6.10...HEAD -- fs/ext4/ # that's much better, let's make it even more smaller, to not consume so many tokens: |
| | 99 | }}} |
