Writing Software Next to Atoms

Most software fails politely. A web request 500s, someone retries, life goes on. Software in a semiconductor fab does not fail politely. A bad deployment near a production tool doesn't cost you a request: it can cost you a lot of very expensive wafers and very real time on machines that are booked around the clock.

Working in that environment rewires how you think about engineering.

Blast radius is a design input

Before any feature discussion, the first question is: what happens when this is wrong? Not if. When.

That question changes designs. You add shadow modes, where new logic runs silently beside the old system before it's trusted. You make rollback a one-step operation, tested as often as deployment. You log enough context that a 3 a.m. incident can be understood without reproducing it.

Boring is a compliment

The fab taught me to love boring technology. Postgres over the exciting new store. Schemas enforced at the boundary. Idempotent jobs. Explicit state machines instead of implicit ones scattered across services.

Exciting infrastructure is a liability when the cost of surprise is measured in scrapped silicon.

Why this makes better AI engineers

The AI industry is currently learning lessons manufacturing learned decades ago: that models are components in systems, that reliability is a feature, that human trust is earned through predictability.

Coming from an environment where software meets physics turns out to be excellent preparation for building AI that has to work, not just demo.