Geisel Software, Inc.

10/29/2026

Every engineering manager in Q4 planning is staring at the exact same problem: eleven roadmap items, three engineers.

The math just doesn’t work, and everyone in the room knows it.

The standard play is to rank the eleven, fund the top three, and push the rest to Q1. But then Q1 shows up with its own list of eleven.

There’s a third option that rarely gets talked about. Look for the standalone pieces—things like a sensor driver, a test harness, or an operator UI—and hand them off entirely. Keep your core team focused on the main product, but let someone else ship the isolated work.

Honestly, how many items on your current roadmap could someone outside your team build if you just gave them a clear spec?

(That exact kind of spec-to-ship build is what we handle for teams at Geisel.)

10/27/2026

Copy-paste quietly killed off refactoring in 2024, and nobody voted on it.

Look at what GitClear is seeing across hundreds of millions of changed lines. Moved code—their proxy for actual refactoring—cratered from 21% of changes in 2022 to a brutal 3.8% in the first half of 2026. Meanwhile, copy-pasted lines climbed from 9.4% to 15.7%.

Honestly, that's just what happens when generating a plausible block of code is faster than tracking down where the existing one lives. The model will happily write the fourth copy of a function. It has zero stake in the other three.

But every copy is one more place the next fix has to land. Miss just one, and you're paying for the exact same bug twice.

Side note, because people constantly mangle this research: GitClear originally projected that code churn would double, which didn't happen. What they actually measured was churn climbing from 3.3% of changed lines in 2021 to 5.7% in 2024. That’s a 73% jump. It's smaller than the viral headlines made it out to be, but it's the real number you need to budget your rework against.

None of this fixes itself. Somebody still has to draw a line in the sand and pick which copy is canonical. Once you make that call, sure, AI can grind through the actual refactor fast.

So how are you catching duplication before it hits review? Or are you just letting it slide?

10/22/2026

AI doesn't fix an engineering team. It just makes you more of whatever you already were.

DORA's 2024 numbers were brutal. Every 25% bump in AI adoption lined up with a 7.2% drop in delivery stability. Even throughput slipped a bit.

When the 2025 report landed, throughput bounced back—mostly because teams finally figured out how to use the tools. But stability stayed in the gutter.

DORA’s take is that AI simply amplifies the system it lands in. If you already have rock-solid version control, fast feedback loops, real test coverage, and a code review culture that people actually respect? The tools supercharge your production work.

If you don’t? You still get a speed boost. It just goes toward duplicating code, piling on unvetted dependencies, and letting your architecture drift a little further every sprint.

The real kicker is what the failures look like now. You get fewer obvious breaks, and way more confident, plausible mistakes that sail right through a quick code review because they look completely correct.

And no, pointing a second model at the first one to check its work won't save you. They usually miss the exact same bugs.

The only variable that actually matters is what you hand the tool in the first place—the context, the constraints, and the specs. That part is entirely on the team.

Honestly curious: what is the absolute first thing you would lock down before giving agents access to more of your repo?

10/20/2026

METR basically admitted it can't measure AI coding speed anymore. Honestly? That's the most useful thing they've put out.

Their follow-up study was massive compared to the original—57 devs tackling over 800 tasks across 143 repos using late-2025 tools like Claude Code. Returning devs clocked in around 18% faster, and new recruits hit 4%. But both numbers are buried so deep in the statistical noise that you can't tell them apart from zero. It was messy enough that METR went right back to the drawing board on the whole study design.

The kicker is why the data broke down. The power users flat out refused to code without an agent, completely tanking the control group. Meanwhile, the devs who did stick around quietly hoarded the easiest 30 to 50% of their tasks, waiting to let the AI crush them.

Talk about a filtered signal. The study accidentally blinded itself.

Inside an actual company, you hit the exact same wall. Once a team integrates these tools, they change how they work entirely. Your neat "before and after" baseline turns to complete mush. And don't bother with sentiment surveys—those just end up measuring vibes, not shipping speed.

If you want numbers that hold up, you have to look at the metrics that don't care how anyone feels about the tech: production cycle time, change failure rate, and how much code gets aggressively rewritten within two weeks of a merge.

Has anyone actually found an internal metric for this that survived a skeptic poking holes in it?

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