Geisel Software, Inc.

10/15/2026

The gap between a robot that works in simulation and one that works reliably in the real world is where some of the hardest engineering begins.

Our founder and CEO, Brian Geisel, will join SK Gupta of GrayMatter Robotics and Sparsh Gautam of Tesla at RoboBusiness 2026 to talk about what breaks outside the lab and what it takes to build Physical AI systems that are ready for the real world.

A robot that works perfectly in simulation has proven one thing: it works perfectly in simulation.

The real test starts when the environment changes, a sensor gives you a bad reading, compute is limited, or the robot encounters something the training team never anticipated.

I’ll be at RoboBusiness next week for a panel on why Physical AI fails in the real world. I’m looking forward to joining SK Gupta, co-founder and chief scientist at GrayMatter Robotics, Sparsh Gautam, Computer Vision Engineer at Tesla, with Mike Oitzman of The Robot Report moderating the conversation.

We’ll talk about what it takes to close the gap between a promising model and a robot that can operate safely and predictably outside the lab, including the hard problems across perception, decision-making, and manipulation.

If you’re attending, join the conversation on October 21 at 10:45 a.m. in Room 204.

10/13/2026

That "55% faster" coding stat everyone cites? It comes from building a single HTTP server from scratch.

Look, the GitHub Copilot study is legit. They took 95 developers, gave them one bounded greenfield task, and the AI group wrapped up 55% faster.

But then METR ran a randomized trial with 16 experienced devs working on repos they’d actually maintained for years. Across 246 real-world tasks, the devs using AI were actually 19% slower. The kicker? Afterward, those same devs estimated they’d been 20% faster.

That massive gap between felt speed and actual measured speed is wild.

Fresh, bounded greenfield code and a mature, legacy codebase are just completely different jobs. The tools pay off differently because writing code and shipping it run on different clocks.

So the real question for planning is narrower: Where does AI actually delete work, and where does it just dump more code on someone's lap to read, test, and sign off on?

Where are you actually seeing real gains? Is it still just greenfield, or are tools actually helping with tests and refactors yet?

Link in comments for a breakdown of both studies. 👇

10/08/2026

The dashboard said 61°C all night. The bearing hit 94°C.

Here's a scenario that plays out more often than it should:

A maintenance team uses an AI coding tool to build a bearing temperature monitor for their CNC line. It reads the spindle sensors, plots the trend, and texts the on-call tech at 85°C. It runs clean against a month of historical data and goes live in a week.

At 1:52 a.m., one sensor's network connection drops.

The code was written against a CSV with a few gaps, so it handles missing values a common way and carries the last good reading forward. For historical data, that's a reasonable choice. On a live machine, the dashboard holds at 61°C while the bearing climbs past the threshold, and the text never goes out. The machine's local log, pulled the next morning, shows 94°C by 3:40.

The AI made a sensible call for the data it was given. What it was never asked to decide is what a silent sensor means on a running line. That condition needs its own state, its own timeout, and its own alert.

Every prototype that moves onto a plant floor runs into questions like this:
>What happens when the gateway reconnects and replays an hour of backlog?
>Where do the credentials live?
>Who owns the code when the person who built it is out?

AI got this team to a working monitor in days, and that speed is worth keeping. Making it trustworthy on the floor takes someone deciding what the system does when the data goes quiet.

The AI Coding Reality Check walks through seven places where AI-built software meets production, and what it takes to close each one. The free brief is linked in the comments.

.

Comment: Get your copy of the AI Reality Check at https://buff.ly/ObP9i6g

10/06/2026

The planner thinks in seconds. The controller thinks in milliseconds.

Agentic AI and Physical AI get used interchangeably, and they describe different things. Agentic is about autonomy: how much a system sets goals, plans, and adapts on its own. Physical is about where it acts: in the real world, with noisy sensors, imperfect actuators, and contact.

A robot that takes "clear the table," breaks it into steps, and hands each step to a vision-language-action model is both. A fleet scheduler dividing jobs across ten robots is agentic and never touches a motor. A learned locomotion policy keeping a quadruped upright on gravel is physical AI with no goals of its own.

Inside a robot that is both, the useful split is by layer. The task layer holds goals, breaks them into steps, and replans when something goes wrong, using LLM-based planners, classical task planners, or tool-calling agents. The ex*****on layer turns sensor data into a state estimate and turns commanded motion into actuation that survives friction, payload changes, and contact.

The real engineering work is at the boundary between those layers. Four things show up there:

Timescale. An LLM planner can take a second or more to return a plan. Joint controllers commonly run at 1 kHz or faster. The world keeps moving while the plan is generated, so the ex*****on layer has to treat every plan as possibly stale.

Feasibility. The planner works from an abstraction. "Pick up the cup" assumes the cup is reachable, graspable, and still where it was last seen. Something has to check that against the current state estimate and the robot's real limits before motion starts.

Authority. When the plan and the physics disagree, the lower layer needs the final say on collision, force, and speed limits. The planner can request a motion. The control layer has to be able to reject it.

Failure reporting. "Grasp failed" gives the planner nothing to replan with. "Object slipped during lift" and "target not found in workspace" call for different recoveries, and the planner can only choose well if ex*****on tells it which one happened.

The task layer decides what is worth doing. The ex*****on layer finds out what is possible. Systems that hold up in deployment tend to define the contract between them explicitly: what the planner can ask for, what ex*****on guarantees, and what comes back when it can't deliver.

Where does that contract live in your stack: a behavior tree, a state machine, or a skill library the planner calls directly?

10/01/2026

How much can your robotics team test when every test needs a physical robot?

For one of the world’s largest mobile robotics operators, teams were sharing limited hardware and lab space. A failed test meant time spent resetting the setup before anyone could try again.

Geisel worked with the client to build a physics-based digital twin of its robots and warehouse systems. Now teams can run tests in parallel, learn from failures in simulation, and complete thousands of hours of testing in a single day.

Swipe through to see what changed when hardware stopped setting the pace.

Read the full case study: https://buff.ly/A7edXLt

09/29/2026

We can produce code faster than we can decide whether it’s any good.

That’s the shift AI coding tools are creating. A developer can get a feature running sooner, but someone still has to understand the decisions in that code, check what it depends on, test how it fails, and own what happens after release.

So what does the developer’s job look like when writing code takes less time, but reviewing and trusting it takes more?

We dug into the research for The AI Coding Reality Check: where AI is helping, where the evidence is less clear, and which parts of software engineering become more important as code generation speeds up.

The briefing includes a 22-point assessment you can use on an actual project. If your team is using AI to write software, it’s a useful way to talk about what “done” should mean now.

Get it here: https://buff.ly/ObP9i6g

09/24/2026

The demo took a few days. The launch date keeps moving.

Commit history, week one after the demo:

fix login
fix login (for real)
remove API key from repo
fix checkout, broke login
move launch to next month

Sound familiar? Geisel's Prompt-to-Production Sprint takes one AI-built app to a secure, tested, production-ready baseline in three weeks. Senior engineers fix the critical security and reliability issues, then add automated tests and a CI/CD pipeline so every change gets checked before it ships. You get it all in your own git, plus a roadmap to launch. $25K, fixed.

Start with a free 30-minute viability review:
https://buff.ly/onbACW7

09/22/2026

Most AI works with words and images on a screen. Physical AI has to act in the real world.

That means sensing its surroundings through imperfect hardware and moving real objects through real space, which is far harder than the polished robot videos suggest.

Four interactive demos on the Geisel blog let you work through it hands-on:

→ Switch off a robot's camera, depth, touch, or motor feedback and watch which failures start piling up.
→ Push payload weight and surface friction past the conditions the robot was trained on.
→ Run the same learned pick in simulation and on noisy real hardware, side by side.
→ Teach a robot a pick by dragging the gripper, then move the part and find out whether it learned the task or just your path.

Everything runs in your browser. Go try to break the robot:
https://buff.ly/4K36OMO

09/17/2026

Crops don't pause while you debug. Inside the autonomous process control software running ECO 1, the world's largest hydroponic vertical farm.

09/15/2026

There's a point in almost every robotics project when perception is solid, the planner is behaving, and every test run is green. It feels like you're nearly there. Then the robot gets deployed.

The problem isn't that the lab testing was wrong. It's that a controlled environment holds variables fixed that the field will not. Lighting is consistent, markers have good contrast, the network is stable, and obstacles appear where the test plan says they will.

Once the system is in the field, those assumptions start to break. Sunlight through an open bay door swings the camera exposure. A recoated floor comes back glossier than it was, and glare washes out the markers the robot localizes against. A warehouse reorganizes its racking, and a lidar stack that localized off natural features suddenly has a different room to match against. A pallet sits six inches off its mapped position, clearance still checks out against the map, and the forks catch the stringer instead of the pocket. A message arrives late, and the consumer keeps acting on the last value it received because nothing downstream checks how old that value is.

In each case, the software may be doing exactly what it was designed to do. The problem is that it has reached an operating condition nobody defined or tested.

When that happens, the answer isn't necessarily more happy-path testing. It's making the test environment less cooperative. Vary the lighting and sensor noise. Move landmarks. Introduce latency and stale data. You aren't trying to enumerate every condition the field will produce. You're trying to learn how the system behaves at the edge of the envelope, so the conditions you never thought of land somewhere survivable. Watch how confidence changes, whether degradation is gradual or sudden, and whether the system can recognize that it's operating outside its assumptions and get to a safe state.

The field will always introduce something you didn't expect. The goal is to find out how the system behaves when its assumptions break before production does it for you.

What real-world condition do you wish you had tested sooner?