Geisel Software, Inc.

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

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

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?

Your AI prototype works perfectly. Pop the ch*****ne. You're 12% done.

That flawless demo? Step 1 of 8. What Geisel calls the Life of an AI Prototype, and the curve goes down before it goes up for a reason.

Watch it fall.

Step 2: run it in the real world. Step 3: the edge cases show up, the ones that were never in the demo because the demo picked its own inputs. Step 4: it dies on the actual hardware. Step 5: nobody can explain why.

That's the floor. And look where the bracket sits on the chart: most demos stop right there. The graveyard is full of AI that worked once, on a laptop, on a good day.

Now watch it climb.

Step 6: instrument, test, harden. Make every failure visible, then make it impossible.

Step 7: it behaves the same way every single run. Same input, same result, run number 1 or run number 10,000, calm day or worst day. Step 8: it ships to production. And it keeps running.

Here's the part worth sitting with. Getting to step 1 has never been faster. AI writes the demo in an afternoon. But the curve does not care how fast you reached the top. The entire drop and the entire climb are still waiting for you, and that valley is where the real engineering lives.

Step 1 is easy now. Step 8 is the whole job.

Which step is your team stuck on right now?

Thirty-seven seconds after ignition, Ariane 5 lost guidance.

Seconds later, the rocket was gone.

The failure began in software. Its reused inertial reference code encountered a condition it had never been qualified to handle. Once the rocket responded, there was no patch, reset, or rollback.

That is the difference when software controls something physical.

Five engineering habits separate code built for real-world deployment from code that merely works under the right conditions.

1. Design the safe state before the happy path.

Before defining what the system does when everything works, define what it does when something fails.

Communications drop. A sensor returns bad data. Power dips. What state protects the machine, its environment, and the people around it?

Build that behavior first. Everything else answers to it.

2. Handle failure where it enters the system.

Every external input can disappear, arrive late, or be wrong.

Catch stale readings, dropped connections, and out-of-range values at the point they enter the system, not three layers later after they have already influenced a physical action.

3. Make behavior deterministic under load.

The system has to behave predictably on its worst day, not just its average one.

That means bounded timing, controlled resource use, and no surprise code paths that appear only under conditions you never tested.

“Fast enough most of the time” is not a specification.

4. Test the failure, not just the function.

Disconnect the sensor. Cut the link. Starve the CPU. Corrupt the input.

A test suite that only proves the system works skips the conditions most likely to determine whether it is ready to deploy.

For high-consequence systems, fault injection is part of the job.

5. Build like the first run is the only run.

There is no staging environment for the moment software takes control of a physical machine.

Simulate it. Dry-run it. Stress it. Review it against the conditions it will actually encounter.

The first time your software meets the real world cannot be the first time it meets reality.

In high-consequence software, correctness isn’t one metric. It’s the whole job.

The cloud is powerful. But your robot still can't wait for it.
Imagine an autonomous machine detects an obstacle.

>Frame captured.
>Data sent to the cloud.
>Model runs.
>Response comes back.
>Robot reacts.

That architecture might look perfectly reasonable on a diagram. Until network latency spikes. Or connectivity disappears.

For many autonomous systems, the question isn't simply:
“Can our AI model make the right prediction?”
It's:
“Can it make the right prediction HERE, on THIS hardware, within THIS time constraint?”

That's the challenge of Edge AI.

Moving intelligence closer to the device can reduce latency and dependence on connectivity but it requires engineers to think about compute, memory, power consumption, thermal limits and model optimization.

AI doesn't live in isolation. Eventually, it has to meet hardware.

And that's when things get interesting.

There’s a particular kind of pressure in building software for an operation that happens once, somewhere no one can intervene in real time.
Our work on NASA’s CADRE mission is a good example of what it means to engineer beyond the conditions you can fully test.

Your AI-built prototype works. So why does every fix break something else?

Welcome to the part of vibe coding nobody puts in the demo.

Hardcoded secrets.
Untested critical workflows.
Vulnerable dependencies.
Fragile architecture.
No CI/CD.

It’s like a whack-a-mole game. Fix one. Two more pop up.

That’s why we created Geisel Software’s Prompt-to-Production Sprint.

Give us one working AI-built application. In 3 weeks, our senior engineers will assess it, harden it, build the testing foundation, set up CI/CD, and give you a clear path to production.

And this isn’t an audit where we hand you a list of problems.

We fix them.

One application.
Three weeks.
$25K fixed fee.

You proved the idea works. Now prove it won’t break.

👉 Schedule a 30-minute Viability Review to find out if your application is a fit.

https://buff.ly/tH9HUCP