The Other Dimension
Rethinking Assumptions argued that our dev tools were built for a world where humans were the scarce resource - tickets, PRs, and linear workflows made sense when changes were expensive. This post breaks a parallel assumption: that capability in AI-assisted software work is the same thing as readiness to operate safely at that level. It is not. You need a second dimension.
Maturity is not which level you reached. It is whether the decision you automated can bear the consequence of being wrong.
Capability is not the same as readiness
Sau Sheong Chang, among others, has described AI adoption in software development as levels of deployment scope - from in-context assistance toward autonomous software factories. That map is useful. It tells you what the tooling can do. It does not tell you whether your organization can absorb that scope without creating institutional risk. Treating the levels as a ladder you climb in order is a maturity model by accident. Maturity is not "we reached level three." Maturity is whether the decision you are automating - not the org chart on the letterhead - can bear the consequence of being wrong.
Maturity is a property of the decision, not the org chart
I learned that at ION Mobility as CTO. We built an integrated bike-to-cloud system - firmware on the vehicle, analytics in the cloud, roughly twenty-nine engineers across disciplines. The firmware team and the dashboard team could ship in the same sprint, same week. They were not "more" or "less" mature as teams in the abstract. They were operating under different thresholds because the decisions being automated had different blast radii. A firmware mistake with a rider at speed is a physical safety event. A stale chart on a dashboard is an inconvenience. Maturity was never a property of "ION." It was a property of the specific system and the specific decision - and the organization had to govern each accordingly.
Earlier, at Esco Micro, I led a multidisciplinary group shipping an ultra-low temperature freezer from zero to a commercial line. The prototype hit its temperature target. That was not the product gate. The product gate was validated confidence in how the system failed - compressor cycles, seal wear, edge temperatures - because the customer does not experience your average case. They experience the day the boundary breaks. "It works" and "we know how it fails" are different claims. Software organizations adopting AI are rediscovering the same distinction under a different vocabulary.
ION's Series A process drilled the same lesson in investor language. Scalability was not a slide - it was repeatability under conditions we did not control. Real roads, real weather, real edge cases. A demo proves you can build once. Readiness proves you can operate when the world stops cooperating. That is the investor-side mirror of readiness: not "can the agent write code?" but "will the system behave acceptably when inputs drift?"
Scope and readiness: defining the second dimension
Readiness, in this series, means organizational readiness - independent of which vendor or model you use. It has four components, and you can be strong on one and weak on another: ownership clarity (is there a named human who understands what the system does and accepts responsibility for its outputs?), failure-mode awareness (has the team deliberately stressed the system and documented how it breaks?), confidence calibration (does the organization know how much to trust outputs - and how that trust changes with context?), and recovery design (when something is wrong, does the right person find out fast enough, and does the correction propagate?). The Invisible Line unpacked the first - this post names the full set and shows how they combine with scope.
Scope - the first dimension - tracks how much autonomy the AI has in the development and delivery path: assistance in the editor, multi-step agents, ticket-to-deploy pipelines, and beyond. The five-level framing is a compact way to talk about that progression. I take it as given and additive; the argument here is not "the map is wrong." The argument is that map times readiness is what determines governance posture.
Four quadrants, four postures
Picture two axes. On one dimension, scope runs from low to high - how much of the software lifecycle the AI is allowed to touch for a given workflow. On the other, readiness runs from low to high - how strong you are across ownership, failure modes, confidence calibration, and recovery for that workflow. The four quadrants are where strategy lives.
Horizontal: scope (low → high). Vertical: readiness (low → high).
High scope, high readiness
High scope, high readiness is governed autonomy: you can run heavier automation because someone owns it, the team knows the failure surface, confidence is matched to use, and errors route to learning. This is the only quadrant where the higher levels of Sau Sheong's map are responsible defaults for consequential systems.
Low scope, high readiness
Low scope, high readiness is safe to expand - you are under-using capability relative to how well you have built discipline. That is where deliberate experiments belong: turn the dial up where the blast radius is contained and you have the feedback loops to learn.
Low scope, low readiness
Low scope, low readiness is accumulation risk. Any one deploy looks small; dozens of unowned experiments create brittleness nobody can diagram. This is where a lot of "vibe coding" lands - not because the tools are frivolous, but because the organization never converted curiosity into ownership.
High scope, low readiness
High scope, low readiness is the danger zone. Capability has outrun judgment. It does not feel like failure in the moment; it feels like velocity - until the wrong output hits something that matters.
The mistake is treating "we adopted Copilot" or "we are moving to agents" as a single organizational transition. Adoption is per system, per workflow, per consequence class. Your internal experiment with an agent that rewrites SQL might sit in a different quadrant than the agent that touches customer PII - even if both use the same vendor badge.
At GoNetZero, confidence in carbon outputs was not a footnote; it was the product. At Hedera, aBFT was not "recovery" in the ITIL sense - it was continuity through failure for correctness. Those experiences shape how I read the quadrant chart: the same company can sit in different quadrants for different systems at the same time. The unit of analysis is the decision, not the org.
Same company, same week, different quadrants - because the unit of analysis is the workflow, not the org chart.
A readiness profile, not a single score
Self-assessment should produce a profile - four bands, not one number. For each component, ask four questions honestly.
Ownership. Who is named? Can they explain failure modes? Will they pick up the phone? Did they accept accountability before go-live, not only after an incident?
Failure-mode awareness. Have we tried to break this deliberately? Do we know the plausible-but-wrong outputs - the ones that look fine? Is the failure surface documented before production?
Confidence calibration. Under what conditions is this output reliable? What degrades it? How do we communicate that to someone who did not build the system?
Recovery design. When something is wrong, what is the path from output to responsible human to fix? Is feedback reaching the people who can change the system - or only the people who feel the pain?
Weakness anywhere moves you left or down on the chart for that workflow - regardless of how "advanced" your toolchain is.
Why profiles beat a single maturity score
Why separate the four components instead of collapsing them into "maturity"? Because organizations can fake averages. A team can have strong ownership on paper - a name in the workflow - while nobody has actually tried to break the system; confidence can be assumed rather than tested; recovery can be documented but not exercised. Profiles reveal the gaps. They also help you decide where to invest: if ownership is the only weak signal, you need a human chain, not a new model. If failure modes are unknown, you are not ready for higher scope regardless of how confident people feel.
The next three posts in this series go deep on failure-mode awareness, confidence calibration, and recovery design - the three components that The Invisible Line left for later. Ownership is the door you walk through first; these are how you earn the right to higher scope.
The Other Dimension · Part 2 of 6 · Previous: The Invisible Line · Next: Try to Break It First