AI was involved in this project for months, but probably not in the way people imagine when they hear “AI-designed hardware.”

It did not spit out a finished PCB, firmware file, mobile app, and enclosure while I sat back and watched.

It was much closer to having a very fast technical sounding board available whenever I crossed into something I did not understand yet.

That happened a lot.

My background gave me a decent troubleshooting foundation, but I was constantly moving into unfamiliar areas:

ESP32 hardware.

RS232 electrical signaling.

Component datasheets.

PCB layout.

EasyEDA.

JLCPCB manufacturing requirements.

C++ firmware.

TCP networking.

React Native.

Expo.

iOS builds.

3D enclosure design.

Every time the project crossed into another one of those areas, I could ask a very specific question and keep moving.

That was incredibly useful.

It was also dangerous if I stopped thinking.

AI can give an answer with a lot of confidence even when the answer is wrong, incomplete, or based on an assumption that does not apply to the hardware sitting in front of you.

I ran into that more than once.

Sometimes the answer was exactly what I needed.

Sometimes it got me 90 percent of the way there.

Sometimes it sent me in completely the wrong direction.

That is where I think my PLC background helped.

In industrial troubleshooting, I am already used to separating what someone says should be happening from what the machine is actually doing.

The same rule worked here.

If AI said a pin should be high and I measured it low, I did not keep arguing with the meter.

If a datasheet contradicted an explanation, the datasheet won.

If a PCB looked correct but packets were not getting through it, the board was not correct yet.

If a case looked perfect in CAD but the snap broke when I assembled it, the snap was too weak.

The physical system always got the final vote.

There was another benefit I did not really expect.

AI made it easier to keep the entire project connected.

Normally a hardware problem, firmware problem, mobile-app problem, and enclosure problem can feel like four separate projects.

Here they were all affecting each other.

Changing how the firmware behaved could affect the app.

Changing the PCB could affect the enclosure.

Changing a connector location could affect manufacturing and case geometry.

A communication problem could be software, TCP, UART, the MAX3232, the DB9 wiring, or the ECU on the other end.

Being able to reason across those layers without starting from zero every time was probably where AI helped me the most.

But I would not describe the process as replacing engineering knowledge.

If anything, it constantly showed me how much I still needed to learn.

AI could explain what a MAX3232 does.

I still had to probe the board.

AI could help review a schematic.

I still had to order it and find out whether it worked.

AI could help write React Native code.

I still had to connect it to a real ECU and make sure it did not do something stupid.

AI could suggest a snap-fit change.

I still had to wait seven hours for the printer to tell me whether it was a good idea.

I think that is the part of AI-assisted engineering that gets lost in a lot of the conversation around it.

When the output is a physical product, eventually the prompts stop mattering.

Something has to power on.

Something has to communicate.

Something has to fit.

And somebody has to prove it.

For me, AI made it possible to get into a lot of technical areas much faster than I otherwise would have.

But the most important sentence from the whole project is still the same one:

The board on my bench was the final authority.