I pointed AI at decoding an 8-in-1 soil sensor. It had the raw bytes in under an hour, then chose to reverse-engineer the obfuscated Android app and burned hours down a dead end of native code and hidden constants, insisting we were close the whole way. Speed is not strategy.
Setup
Pointed AI at decoding an 8-in-1 BLE soil sensor that only talks to its own closed app
Measured
Raw bytes in under an hour, then hours lost reverse-engineering the obfuscated app to a dead end
Verdict
VERDICT: MISSED THE POINT
Claude moved very fast. I followed the wrong direction. This is what hacking a soil sensor taught me.
I pointed the AI at the problem and it came back fast, confident, and completely wrong.
The device is an 8-in-1 soil sensor. It only talks to its own phone app, which is cheap, closed, and mostly useless. I wanted the readings inside my own system so I could monitor the sensor properly.
Reading the signal was the easy part. Within an hour, we had the raw bytes.
Then we hit the wall. The bytes were not the readings. The real conversion formula was hidden inside the app.
Checkpoint #1: AI was extremely fast at guessing, preparing the setup, and getting me moving.
That made it very tempting to keep following.
Then Claude suggested the obvious move: reverse-engineer the app and extract the formula. So we went deep for hours.
Claude moved fast through the app. It generated tools, explained paths, iterated confidently, and kept saying we were close. Hours of digging through:
Dead end. We had nothing usable.
And because I lacked some Android reverse-engineering knowledge, I believed the confidence longer than I should have.
Checkpoint #2: The execution was impressive. The direction was wrong.
That is part one of the story.
Do not let AI drive the solution. Use it as an engine, not as the steering wheel.
Next, I will write up what happened when I changed the approach. I had the AI learn the formula from data instead. It scored 98% in validation but was not usable. Then it wrote into git that we had reached a dead end at 6 of 8 measurements. A few commands from me later, the solution became 8 of 8
Read the original on LinkedIn →
Fadi Labib runs this field lab. 15 years in automotive, robotics, and embedded systems; ESMT Berlin EMBA. I give AI real engineering problems, then check its work. More about the lab →
Keep reading
Reverse-engineering an 8-in-1 soil sensor, my AI decoded 6 of 8 channels, declared the last two 'not decodable,' and wrote that verdict into version control. I rejected the false ceiling and pushed. Seven hours later the same repo said 8/8. A flawless executor and a shaky judge.
Claude trained a gradient boosting model mapping raw soil-sensor bytes to readings on 2,347 points: pH 0.98, EC 0.99, temperature 0.999 R² in cross-validation. On 59 held-out points from real soil, EC crashed to -0.56 R², worse than predicting the mean. The model overfit the rig, not the world.
I asked Claude and ChatGPT to design a hunting game with a gun controller. I got an €86 bill of materials, a 16-month plan, and a €237,000 launch budget. In 1984, Nintendo solved the same problem with a photodiode, a comparator circuit, and a screen flash. One model even name-checked Duck Hunt in its first sentence, then designed a Wii anyway.