DeepSeek v4 and Gemini 1.5 both failed to fix my ESP-IDF component paths

Stop blindly pasting entire files from LLMs when refactoring directory structures. I spent two days trying to move project files into a components folder for an ESP-IDF project, and every single model I used—from Gemini 1.5 Flash to DeepSeek v4 Pro—hallucinated the dependency names in the CMakeLists.txt files. The fix ended up being a single line of text that I had to find via a manual Google search because the AI kept insisting on the wrong header requirements.

Why Gemini 1.5 and DeepSeek v4 kept failing

I started by using Gemini 1.5 Flash to map out which files to move and how to rewrite the includes. I followed the instructions exactly, but my editor immediately flagged the #include lines with red squiggles. I tried escalating to Gemini 1.5 Pro and then swapped over to DeepSeek v4 Flash and Pro, but the result was always the same: the code looked syntactically correct, but the build failed.

The common failure point was the CMakeLists.txt configuration. The models kept suggesting REQUIRES or PRIV_REQUIRES tags that didn't actually match the component names in the ESP-IDF framework. Because the AI doesn't "see" the actual build error in real-time (unless you feed it the exact compiler log), it just kept guessing synonyms for the required component.

Where GitHub Copilot fell short

I tried GitHub Copilot as a last resort, thinking its integration with the IDE would give it better context. It spent about 30 minutes "processing" the task and gave me a green checkmark, claiming the refactor was complete. In reality, it just mirrored the same mistakes as the web-based LLMs. The project still wouldn't compile, and the header errors remained.

How I actually solved the build errors

The breakthrough happened when I stopped treating the AI as an autopilot and started using it as a reference. Instead of copying the whole file, I manually edited the #include paths and wrote the CMakeLists.txt files myself.

When the errors appeared, I stopped asking the AI "why is this broken?" and started asking "what is the exact name of the requirement for this header?" Even then, the AI gave me the wrong string. I eventually had to leave the chat and search the ESP-IDF documentation to find the specific string required for the REQUIRES section. One single word change in the CMake file fixed everything.

My key takeaways for anyone doing embedded work with AI:

• Avoid full-file replacements: When moving files into components/, the AI often misses the relative path changes or the specific build-system requirements.
• Verify the CMakeLists.txt manually: LLMs are notorious for hallucinating component names in ESP-IDF. If the build fails with a "header not found" error, don't trust the AI's suggested REQUIRES fix immediately.
• The "Loop of Death": If you've tried three different models and the error persists, stop prompting. The AI is likely stuck in a pattern of hallucination based on the project structure you provided.

This was a humbling reminder that for specialized frameworks like ESP-IDF, a 30-second manual search is often more effective than four hours of prompting.