You cannot trust AI to code, its lazy.
I have been using AI to write code extensively for the last 10 months and was aware it took shortcuts, like if you asked it to fix an undefined variable error in a method, it would give the variable a default if it was undefinded instead of tracing where the source of the error really was.
Just today I was confronted again with a lazy AI, well the AI would say it was being efficient with token use, but it looks like laziness to me.
I was asking for modifications to a pfodWeb's code generator (drmpf/pfodWeb_src) to add informative comments to var_1 var_2 etc.
The first few passes at adding these comments to various places in the code went fine. Then I asked for one more fix for some vars and the AI made some more changes to the generator code and re-generated the output and checked it.
When the AI found some requested comments I requested were missing
IT JUST STARTED EDITING THE OUTPUT DIRECTLY TO ADD THE MISSING COMMENTS THE CODE GENERATOR MISSED.
If I had not noticed that going on and just looked at the generated code I would not have known the AI had fugged the result.
I stopped it and said
"do NOT make cometic corrections to the output, fix the generator"
to which the AI replied
"Understood — I'll make the regeneration pipeline fully faithful instead of hand-patching, so the output can be used directly with no manual touch-up."
Bear in mind, for the whole session the AI had been making the code comment fixes by changing the code generator as it was originally asked to do. So don't trust your AI to do what you actually asked for, even if it was doing it correctly just a moment ago.
21 comments
Solar/Battery/EV/HW Forecast, Monitoring and Control with an ESP32
The code (ESP32 firmware, forecasting/control logic, and the Python shading-model tooling) was written with Claude Code, including the display UI itself.
see code and docs on github
2 points
Solar/Battery/EV/HW Forecast, Monitoring and Control with an ESP32
An ESP32 (FireBeetle 2 ESP32-E) that forecasts, monitors and controls three existing home power systems as one: an Enphase solar array + battery, a solar-charged hot water tank, and a Hyundai Inster EV charger/V2H (vehicle-to-home) controller. Each system keeps its own independent control and can override the ESP32 at any time. (github code and docs)
The ESP32 downloads forecast solar irradiance from Open-Meteo, adjusts it for local tree/hill shading, and combines it with the 5-day average consumption to forecast today's and tomorrow's Enphase battery state of charge. That forecast drives EV and hot-water charging priority and when (if ever) to discharge the battery back to the grid.
Aim: minimise grid dependence — ideally zero grid draw from 2pm–8pm (when demand charges apply), no exporting surplus solar except a small window 8pm–9pm, and EV charging prioritised over hot water.
The docs include:-
- esp32_control_structure.md — how the BatterySolarMonitor firmware is structured; a function-by-function reference.
- solar_shading_model.md — how the Open-Meteo irradiance forecast is adjusted for this site's tree/hill shading, per sun position.
- solar_shading_stats.md — the back-solved per-angle shade factors behind that model (1200+ days of Enphase production vs. Open-Meteo GTI).
- quarterly_update_process.md — the process (quarterly_update.py) for refreshing the shading model from the latest historical data every 3 months.
- data_sources.md — external APIs the py_programs/ scripts depend on (Enphase IQ Gateway, hot water controller, EV charger).
The code (ESP32 firmware, forecasting/control logic, and the Python shading-model tooling) was written with Claude Code, including the display UI itself.
11 points · 4 comments
Mentions
You cannot trust AI to code, its lazy. I have been using AI to write code extensively for the last 10 months and was aware it took shortcuts, like if you asked it to fix an undefined variable error in a method, it would give the variable a default if it was undefinded instead of tracing where the source of the error really was. Just today I was confronted again with a lazy AI, well the AI would say it was being efficient with token use, but it looks like laziness to me. I was asking for modifications to a pfodWeb's code generator (drmpf/pfodWeb_src) to add informative comments to var_1 var_2 etc. The first few passes at adding these comments to various places in the code went fine. Then I asked for one more fix for some vars and the AI made some more changes to the generator code and re-generated the output and checked it. When the AI found some requested comments I requested were missing IT JUST STARTED EDITING THE OUTPUT DIRECTLY TO ADD THE MISSING COMMENTS THE CODE GENERATOR MISSED. If I had not noticed that going on and just looked at the generated code I would not have known the AI had fugged the result. I stopped it and said "do NOT make cometic corrections to the output, fix the generator" to which the AI replied "Understood — I'll make the regeneration pipeline fully faithful instead of hand-patching, so the output can be used directly with no manual touch-up." Bear in mind, for the whole session the AI had been making the code comment fixes by changing the code generator as it was originally asked to do. So don't trust your AI to do what you actually asked for, even if it was doing it correctly just a moment ago.
Solar/Battery/EV/HW Forecast, Monitoring and Control with an ESP32 The code (ESP32 firmware, forecasting/control logic, and the Python shading-model tooling) was written with Claude Code, including the display UI itself. see code and docs on github
Solar/Battery/EV/HW Forecast, Monitoring and Control with an ESP32 An ESP32 (FireBeetle 2 ESP32-E) that forecasts, monitors and controls three existing home power systems as one: an Enphase solar array + battery, a solar-charged hot water tank, and a Hyundai Inster EV charger/V2H (vehicle-to-home) controller. Each system keeps its own independent control and can override the ESP32 at any time. (github code and docs) The ESP32 downloads forecast solar irradiance from Open-Meteo, adjusts it for local tree/hill shading, and combines it with the 5-day average consumption to forecast today's and tomorrow's Enphase battery state of charge. That forecast drives EV and hot-water charging priority and when (if ever) to discharge the battery back to the grid. Aim: minimise grid dependence — ideally zero grid draw from 2pm–8pm (when demand charges apply), no exporting surplus solar except a small window 8pm–9pm, and EV charging prioritised over hot water. The docs include:- - esp32_control_structure.md — how the BatterySolarMonitor firmware is structured; a function-by-function reference. - solar_shading_model.md — how the Open-Meteo irradiance forecast is adjusted for this site's tree/hill shading, per sun position. - solar_shading_stats.md — the back-solved per-angle shade factors behind that model (1200+ days of Enphase production vs. Open-Meteo GTI). - quarterly_update_process.md — the process (quarterly_update.py) for refreshing the shading model from the latest historical data every 3 months. - data_sources.md — external APIs the py_programs/ scripts depend on (Enphase IQ Gateway, hot water controller, EV charger). The code (ESP32 firmware, forecasting/control logic, and the Python shading-model tooling) was written with Claude Code, including the display UI itself.