I spent four years inside semiconductor capital equipment, on the machines a fab uses to decide whether its silicon is clean enough to build on. Precision stages, motion control, optical alignment, validation campaigns, and the failure investigations that start when a multi-million-dollar tool stops working in a customer's cleanroom at 2am.
The software started there. I was not trying to change careers. The diagnosis I needed did not exist: the logs were there, the failure signature was sitting in them, and nobody had written the code to pull it out. So I wrote it, and it saved 50 hours of downtime per incident. Every piece of software I have built since began the same way, with a machine or a process that was worse than it needed to be.
Both sides of the machine
I am a hardware engineer who also ships production software, and most of my useful work happens where those two overlap. I can design the enclosure, specify the sensor, write the motion control, build the backend that ingests the data, and put a usable interface in front of it. The more valuable half of that is knowing which layer a given problem lives in.
Most of the bad engineering decisions I have watched get made came from people who could only see one layer.
On building with AI
I use AI agents heavily, and I would rather say so than pretend otherwise. The interesting question is what surrounds them. On my projects that means a written rulebook the agent has to work inside, documentation that is checked against the code rather than assumed to match it, a log of decisions with the reasoning attached, and a short list of approvals no agent is allowed to make.
Generating code is cheap. Deciding what to generate, then proving it is correct, takes up most of my time. That is why every project here carries a record of how it was built.