It is funny how things work out. You can let AI tools try to fix a code problem for days, but nothing works until you finally step in and do it yourself.
I was working on my ESP-IDF project and wanted to organize it better. My goal was to use the standard practice of keeping different pieces of code in a folder named components.
Try #1: Gemini 3.6 Flash
I don't pay for AI, so I use the free web versions. I used a tool I built called ReptClip to copy my project structure and files. Then, I asked the AI which files to move and what new code to put inside them.
I did exactly what the AI said without questioning it. Suddenly, red error lines popped up in my code editor. Soon, the whole file was covered in errors. I told the AI about it.
It gave me new steps, and I just followed them again. It still didn't work.
I did this over and over for hours. I got very mad, called the AI stupid, and reset my working directory to start all over from scratch. I do not know why it failed at such an easy job.
Try #2: Gemini 3.1 Pro
I thought the Pro version of the AI would do a better job. I tried the exact same steps and trusted it completely again. But I ended up with the exact same errors.
Tries #3, #4, #5, ... #n
I lost count of how many times I tried this. I tested Gemini Flash Extended, Gemini Pro Extended, DeepSeek v4 Flash, and DeepSeek v4 Pro. For some reason, absolutely nothing worked. I wasted two whole days doing this.
Try #n + 1
Next, I decided to try GitHub Copilot. I gave it instructions, and it spent about 30 minutes on the task. It finally gave me a nice ✅ emoji and said it was done. I thought my problems were over.
I tried to build my project, but it failed. I looked at my code files, and there were error squiggles everywhere, just like before.
I gave up and left the project alone for a few days.
Try #n + 2
After a break, I came back with a new plan.
I went to gemini.google.com and chose the Pro model. I asked the same question. But this time, I stopped blindly pasting the whole file the AI gave me. Instead, I decided to edit the #include directives and type the CMakeLists.txt files by myself.
When I moved my code into the components folder, I noticed errors on the #include lines. I realized right away that the #include paths were the real issue. I told the AI that I could not add those specific headers. The AI said I needed to add the dependency components in REQUIRES or PRIV_REQUIRES in CMakeLists.txt. Adding those fixed a few headers, but some specific headers still failed.
Finally, I searched on Google to find out exactly which components have the definitions for those specific headers that were causing the issue. The answer was slightly different there.
I changed that one single line of code, and it finally worked! The ONLY problem was that all the AIs put the wrong component name in REQUIRES, and none of them could figure out that was the issue. It is hard to believe I wasted weeks on such a tiny problem.
I skipped over a fair bit of the debugging rabbit hole in this post because I honestly couldn't remember every single twist and turn 😅
Top comments (8)
ESP-IDF build issues usually come down to how CMake resolves component dependencies. When headers live in a separate component, the compiler path needs the component name declared in REQUIRES or PRIV_REQUIRES. If the build fails on headers outside the core framework, that target name is usually what the tool missed.
That makes total sense! I'm still pretty new to ESP-IDF and CMake. Since the root and main CMakeLists.txt files didn't need those REQUIRE fields, I didn't think much of it when individual components needed them 😅
Yes, we have tried the same and it works.
The pattern underneath this: the agents failed for days, you fixed it in one session, and the difference wasn't intelligence - it was that you had a THEORY of the system and they had a text window into it. A folder restructure in ESP-IDF is the kind of task where the build system's invisible contracts (component naming, CMake discovery order, include paths baked into forty files) matter more than any individual edit, and the agent edits files while you're debugging the contracts. The useful skill is the one you demonstrated without naming it: knowing when to take the wheel back. Watch the cost curve - when each agent attempt costs you a review and the reviews stop converging, the human session is already cheaper. The mistake is treating "the AI should be able to do this" as a reason to keep paying that curve.
Thanks for your comment! You just pointed out the exact mistake I made.
I thought the AI would handle this effortlessly in one go. After all, it was just moving a few files and updating a couple of
CMakeLists.txtfiles. The AI kept patching local errors without understanding the root cause, and ended up making the problem far worse.Maybe it's partially my fault too. I just discovered (while I was writing this paragraph of this reply) that the code written by all AIs was correct, but only for ESP-IDF v5.2 and older. While the agent could have asked me which version I was running, providing that context upfront would have saved a lot of headache.
I hit a similar wall building a website recently. The AI kept generating outdated code for getting the session because I was on the latest release of Next.js & Better Auth. Even after I explicitly put the updated syntax in
AGENTS.md, it kept reverting to the old patterns 😅For anyone reading this post right now, I no longer use ReptClip. I created a VS Code extension that gets the job done much faster:
ReptClip for VS Code
Some comments may only be visible to logged-in visitors. Sign in to view all comments.