Micah Stubbs' Weblog

The Good Enough Signal

8th January 2026

I had a conversation recently with a colleague who commented that a certain model from mid-2025 was “good enough” for a code review use case. That got me thinking. What does “good enough” really mean?

Here’s the thing: if a last-gen model is “good enough” for some part of our work, that’s not the pat on the back you might think it is. We’re not done here.

It’s a warning light. It means the work just crossed the line from "hard" to "mechanical." And mechanical work doesn’t stay expensive.

In software, “good enough” is usually the moment a task becomes a commodity. Once the quality is acceptable, the cost collapses. Not instantly, but inevitably. The teams that win are the ones who treat that moment as the starting gun.

Here’s the rule:

When a non-frontier model is good enough to do a task with light supervision, we should assume the fully automated version is close and start building it immediately.

This is less about AI hype than about leverage. Human attention is our scarcest resource. Compute is not. If we spend human hours doing work that is now cheap to buy, we’re burning the only thing we can’t easily replace.

The mistake most companies will make is to stop at “AI as a faster employee.” They’ll keep the same workflows and just have people type less. That’s a temporary advantage. The durable advantage comes from changing the shape of the work: turning repeated human loops into software loops.

Competitors don’t need to be smarter than us. They just need to be more automated than us. Once a workflow can be done by a model, someone will do it with a model. That’s what “software eats the world” looks like in 2026: not more apps, but fewer humans in the middle of the same processes.

So what should our humans do?

Work on the frontier. The frontier isn’t “new tech for its own sake.” It’s the set of things the business needs that machines can’t reliably do yet: deciding what to build, talking to customers, setting strategy, designing systems, handling edge cases, and—most importantly—building the machines that do the rest.

The company should not be a craft shop. A craft shop is proud that humans touched everything. A software company should be proud that humans touched only the parts that still require judgment.

The core KPI that captures this is time to closed loop: the time between “a human can do this repeatedly” and “a machine does this automatically with monitoring and fallback.” Shorter is better. It’s the difference between using AI and becoming an AI-native organization.

What I’m asking my team to do:

• Treat “good enough” as a trigger: when we hear it, we open an automation project, not a celebration thread.
• Build the loop, not the demo: define an acceptance test, instrument it, and ship it into production with guardrails.
• Move humans up the stack: as soon as a loop is stable, remove humans from the path and redeploy them to the next unsolved problem.
• Track time to closed loop: for our top workflows the way we track revenue or uptime.

If we do this, we won’t just be using better models. We’ll be turning better models into a compounding advantage.