Geisel Software, Inc.

The readiness gap our engineers close.

Every demo I've ever seen ends the same way. Clean lab, good lighting, the robot does the thing, everybody claps. Then someone asks "so when can we ship it?" and the room goes quiet.

Here's the thing nobody wants to say out loud: Physical AI readiness is not a model problem. It is a deployment problem.

The model is usually the part that already works. It's everything wrapped around the model that decides whether your program lives or dies.

Three failure modes we see over and over between the prototype and the field:

The model never saw the edge case. So it does what models do when they're uncertain. It guesses. Confidently. With the same swagger it had when it was right.

The compute that hummed along happily on a workstation in the lab does not fit the power and latency budget at the edge. Turns out "real time" and "eventually" are different products.

Nobody owns the failure path. The system is wrong at 2am, there's no human in the loop, and the org chart has a hole exactly where the accountability should be.

Accuracy gets the headlines. Deployment is where the postmortems get written.

None of this shows up in a benchmark. All of it shows up in production.

So I'm curious which one is biting your team hardest right now.

One operator. A fleet of robots. One tablet.

Teledyne FLIR needed a single interface to command their entire UGV program, and the U.S. Army deadline behind it wasn't going to move. They called us.

The hard part isn't the UI. It's everything under it. One operator driving multiple ground robots and aircraft from one device means multiplexing several live video and telemetry streams onto a handheld without blowing the control-latency budget, because teleoperating a manipulator near live ordnance is not where you tolerate lag.

It means a control architecture that stays deterministic when links degrade and vehicles drop in and out, and status reporting that keeps the operator's picture of every asset current when bandwidth is the scarce resource. Picture-in-picture video, real-time control, full status telemetry, and preset poses for rapid manipulator positioning, all sharing one radio link and one screen, all held to the reliability and security standards a defense program demands.

Six months, start to ship, with our engineers embedded onsite alongside Teledyne FLIR’s team.

It shipped on time. Then they brought us back for their next robot program.

"They felt like an extension of our own team and put in the extra effort needed to hit our incredibly tight deadline." — David Weatherwax, Director of Software, FLIR Systems

Building a multi-vehicle autonomous platform on a deadline that can't slip? Let's talk.

AI made junior output look senior. It did not make junior engineers senior.

That gap is the staffing problem sitting in front of most engineering orgs right now, and it does not surface in velocity metrics until the people who can catch a bad diff have already moved on.

On Solving for Tomorrow, Brian Geisel talks with Tony Campbell, VP of SRE and Platform Engineering at iManage, about what that does to a team. Tony's career runs through Google, Microsoft, and HubSpot, and his read on the AI talent gap has less to do with tooling than with the reps that used to produce senior engineers in the first place.
Worth the listen if you run a team:

Pull requests as a collaboration surface, not a gate. Review is where judgment transfers. Treating it as approval throughput trades mentorship for cycle time.

Code review as the mentorship channel that actually scales. Most orgs already run the ritual. Few use it for the thing it is best at.

Why the strongest developers think like musicians. Iteration and refinement over first-take correctness, which is precisely the habit generated code discourages.

The collision: the senior engineers required to review AI output are produced by the work AI is now doing.

Episode 07, Solving for Tomorrow: https://buff.ly/2D8LuT4

AI, Software, and the Hard Truths About Building the Future In this insightful episode, Brian chats with Tony Campbell, Vice Pr...

AI tools are rapidly changing the software development workflow. Brian's latest video shows what that looks like in practice: one Claude Code session, from a blank screen to a live website. An interesting look at how quickly ideas can become reality.

Claude Code Built and Deployed a Website From One Prompt (AWS) I gave Claude Code a single voice prompt and let it run. No stoppin...

Stay informed. Stay ahead.

Disruptive Development, Geisel Software's monthly newsletter, helps software leaders cut through the noise with curated content that matters.

Each issue features:
1. Links to the biggest news stories of the month for software leaders
2. Insights on AI, robotics, embedded systems, cybersecurity, and emerging technologies
3. Engineering perspectives on the trends shaping the future of software development
4. Resources to help you make better technology decisions

If you're leading engineering teams, developing innovative products, or keeping an eye on what's next, Disruptive Development is designed for you.

Subscribe today and get the latest issue delivered straight to your inbox. https://buff.ly/Nt3Mlwq

95% of enterprise AI initiatives produced no measurable business value last year. The models weren't the problem.

MIT's Project NANDA looked at more than 300 enterprise AI initiatives. Despite tens of billions in investment, most stalled before delivering meaningful results. The common failure wasn't model performance. It was integration. Systems couldn't retain feedback, adapt to changing conditions, or hold up once they encountered real operational workflows.

The models worked. The deployments didn't.

In robotics and other physical systems, that gap gets even wider. Clean datasets become noisy sensors. Controlled environments become unpredictable ones. Suddenly you're working within hard latency budgets, handling edge cases, and building systems that have to behave correctly the first time, every time. A robot that collides with a pallet or a medical device that requires a recall doesn't get fixed with the next software update.

That's the problem forward-deployed engineering is meant to solve. It's not a new idea. Palantir introduced the term more than a decade ago. The model is simple: experienced engineers work alongside your team, on your hardware, under your operating constraints, and stay accountable through deployment. The people designing the solution are the same people responsible for making it work in production.

One finding from Project NANDA stood out: organizations working with external engineering partners were about twice as likely to succeed as teams relying solely on internal development.

The teams getting systems into production aren't necessarily spending the most. They're bringing in people who've already solved the kinds of problems that don't show up in a demo.

Brian Geisel breaks down what forward-deployed engineering actually is, how it differs from consulting or staff augmentation, and the signs that tell you when it's the right approach.

Link in the comments.

Perception gets the demos. The decision layer gets the postmortems.

Here's the thing that layer has to do, all at once: decide fast, decide in a way you can explain, and stay safe when it's working from a picture of the world that's incomplete. Each of those is manageable on its own. Together, in the same control loop, they fight.

Take safe-under-uncertainty first. The planner is acting on a fused estimate from sensors that disagree, with a confidence that's usually rosier than it should be, because nobody models the tails honestly. So the right move often isn't the one that looks best on the current picture. It's the one that keeps you recoverable if the picture turns out wrong. Plan for the expected case and bolt a safety check on afterward, and that's exactly the gap that bites you.

Now add fast. Not good average latency, worst case. A planner that's quick on average and ugly at the tail will blow the loop on the one cycle that mattered, and that's the cycle you'll be explaining later. The moment you harden the worst case, you're usually giving up decision quality to do it. That's the tradeoff, right there.

Now add explainable. When the safety review asks why it braked, "the model decided" is not an answer anyone signs off on. So you keep the decision logic inspectable on purpose, which constrains how much you can lean on a policy you can't trace. A layer you can't explain is one you can't certify, however good the numbers look.

None of these is hard in isolation. The engineering is that a real deployment demands all three in the same loop, at the same time, and they trade against each other directly. That's the layer where strong programs stall, usually in integration, usually later than they wanted.

Developers do not love engineering because they enjoy pressing keys.
They love understanding difficult problems, exploring trade-offs, and building elegant solutions.
That distinction matters as AI becomes part of everyday development.

A healthy AI culture should not simply maximize how much code gets generated.
It should protect the parts of engineering that create real value.

⌨️ Boilerplate, repetitive implementation, and routine transformations can often be automated.
🧠 System design, problem framing, and technical reasoning should remain visible and valued.
🛠️ Good engineering still depends on simplicity, judgment, debugging, modeling, and thoughtful trade-offs.
🔍 As generation accelerates, validation becomes more important, not less.

AI can increase output while quietly reducing ownership, creativity, and satisfaction.
If engineers spend their days prompting, checking, and correcting machine-generated work, productivity may rise while the craft deteriorates.

The goal should not be to preserve manual coding for its own sake.
It should be to use automation without removing the deep thinking that makes engineering meaningful.

Protect the craft.
Not the typing.