How I Engineer with Foundation Models on a Safety-Critical Robot
A look at the development system I built around an AI coding workflow — not the prompts, but the pipeline, the gates, and the judgment.
There are two crowds in software right now: people who use foundation models (FMs) as autocomplete, and people who do hard systems work. The interesting place is the intersection — engineers who orchestrate models and ship real-time code that runs on a real machine. That intersection is where I work.
For the past several months I've been leading a multi-year migration of a legacy ROS 1 robot stack to a modular, middleware-agnostic ROS 2 (Jazzy) platform in C++20 — safety-critical software with real motion authority. I used foundation models to move fast on it. But "used AI" undersells what actually made it work. What made it work was the engineering system I built around the models. Here's how it fits together.
1. The problem: speed without losing quality
A safety-critical rewrite is exactly where naive AI use is dangerous. A model that confidently produces plausible-but-wrong motion code is worse than no model at all. So the goal wasn't "write code faster" — it was ship a multi-year migration at a high cadence with no quality regressions. That reframing drove every decision below.
2. The pipeline, not the prompt
Instead of prompting ad hoc, I run a multi-agent development pipeline: an orchestrator coordinates specialized sub-agents (one for review, one for auditing, others for focused tasks), with workflow loops and context isolation per task. The unit of work isn't "a chat" — it's a structured task with defined inputs, a verification step, and a record of what happened.
The lesson I'd share: architect AI pipelines, not prompts. A repeatable pipeline is what turns a clever one-off into something a whole team could rely on.
3. Automated gates that make AI safe to ship
Every commit is auto-reviewed before it can merge. Merges are gated on two independent checks: an AI code review pass and runtime sanitizers (ASan/UBSan/TSan) in CI. Neither alone is enough; together they catch a large share of the memory, concurrency, and undefined-behavior bugs that a fast pace would otherwise let through.
This is the part that lets me actually trust the velocity. The gates don't care how the code was written — human or model — they only let through code that passes.
4. A platform, not a one-off workflow
The pieces above are reusable: custom skills, event hooks, command overrides, tool integrations, and cross-session memory. I treat my AI development setup as a small internal platform with its own standards, not a pile of personal shortcuts. That's the difference between "I'm good with AI" and "I built something repeatable that survives me."
5. The judgment: knowing when not to trust the model
This is the senior signal, and it's the hardest to fake. Three habits:
- Verify before claiming. Model output gets grounded against real-robot behavior before I accept a fix. On-robot localization failures, for example, are debugged against the actual machine — not against the model's confident story about them.
- Deliberate model selection by task. Reasoning-heavy architecture work and high-fan-out mechanical tasks call for different models, chosen for reliability, not just cost.
- Govern my own usage. I ran a logged self-audit of my FM usage across multiple tools — model/cost tiering, and closing security-hygiene gaps. FMOps applied to my own stack, with receipts.
Anyone can prompt. Judgment about where models fail is what separates a senior FM engineer from a power user.
What I'd tell another engineer
You don't differentiate on "I use AI." Everyone does now. You differentiate on the system you build around it: the pipeline, the gates, the platform, and the judgment to know its limits. Build those, measure them honestly — including the rough edges — and you'll have something far more credible than "great with AI."
I'm a robotics software engineer working at the intersection of ROS 2 / C++20 systems and AI-native development. More of my open-source robotics work: github.com/kjungmo