Most software gets a second chance. A request times out, you retry. A page crashes, you refresh. A model gives a bad answer, you ask again. We build on the quiet assumption that failure is recoverable.

At DRDO, I worked on software that doesn't get a second chance.

I spent an internship on FADEC — Full Authority Digital Engine Control — the real-time system that keeps a military aero gas-turbine engine inside its safe operating envelope. It's the software standing between "controlled thrust" and "very expensive fireball." That experience rewired how I think about engineering, and I've carried it into every AI system I've built since.

---

When a millisecond is the spec

In web development, "fast" is a feeling. A page loads in 200ms or 800ms and users mostly shrug.

In engine control, time isn't a feeling — it's the spec. The control loop has to run on schedule, every single cycle, forever. Read the sensors, compute the correction, command the actuators — and do it again before the deadline, no exceptions. Being late isn't slow. Being late is wrong. A control output that arrives a beat too late can mean the engine surges, stalls, or flames out.

That reframed "performance" for me permanently. It's not "how fast on average." It's "what's the worst case, and is the worst case still safe?" Averages comfort you; tails kill you. I now ask that question of everything — including LLM pipelines, where the p99 latency, not the median, is what an actual user feels on a bad day.

---

You earn trust by assuming things will break

The defining mindset of safety-critical work isn't optimism. It's disciplined paranoia.

Every signal is suspect. A sensor can fail, drift, freeze, or lie. So you don't trust an input — you validate it: Is this reading physically possible? Does it agree with its neighbours? What's the safe thing to do if it's garbage? The system is designed to degrade gracefully under conditions you hope never happen, because "I assumed that couldn't happen" is how things actually fail.

I think about this constantly now. When I build a document pipeline that hands work to an LLM, I treat the model's output exactly like a sensor reading: possibly wrong, to be validated, never blindly trusted. Schema checks, sanity checks, a safe fallback when confidence is low. The jet engine taught me that the interesting engineering isn't the happy path — it's everything you do for the unhappy one.

---

Modeling before building

You don't just write FADEC code and flash it onto an engine to see what happens. You model the control algorithms in MATLAB and Simulink, simulate them against scenario after scenario, and validate the behaviour long before anything touches real hardware. The simulation is the work; the deployment is almost an afterthought once the model holds up.

That patience felt slow to me at first — I came from a "ship it and iterate" web mindset. But it's the right instinct in any domain where iterating in production is expensive or dangerous. It's exactly why I now build evaluation harnesses for AI systems before I trust them with anything real: I want to watch the thing fail safely in simulation a hundred times before it can fail expensively in front of a user.

---

The translation to AI

People assume aerospace embedded systems and AI engineering have nothing to do with each other. I think the embedded work made me a better AI engineer, precisely because the cultures are so opposite.

The AI world moves fast, tolerates flakiness, and treats "mostly works" as shipped. The aerospace world moves deliberately, assumes failure, and treats "mostly works" as not working. The truth I try to live in is the overlap: move fast on the parts where failure is cheap, and bring full safety-critical paranoia to the parts where it isn't. A demo can be scrappy. A system a business runs on cannot.

A jet engine can't be careless, and it can't ask for a retry. Holding that standard — even when the stakes are far lower — is, I think, what separates code that works from code you can actually trust.

And trust, in the end, is the whole job.

---

Tags: Embedded Systems, Real-Time, Engineering, Aerospace