calvinx Blog
Change management frameworks were built for a world where the destination was known. ADKAR - Awareness, Desire, Knowledge, Ability, Reinforcement - assumes you are moving people from a defined current state to a defined future state. That works for an ERP rollout. It breaks when the thing you are changing to keeps changing.
The Governance Speed Problem addressed how fast governance can move. This post addresses a more fundamental question: what does readiness mean when the system being governed was not written by a human and is not maintained by a human? The Other Dimension series assumed a human authored the AI-assisted output and a human maintained it. At Sau Sheong's Levels 3 and above — autonomous agents and…
Readiness at Portfolio Scale argued that governance is a finite resource and must be triaged by consequence. This post confronts the next constraint: even well-triaged governance can become a bottleneck when the delivery pace is set by agents, not humans. Sau Sheong Chang identified decision speed as the binding constraint in AI-augmented development. The readiness framework tells you what to…
Shaping, Not Just Shipping closed the series with a one-page self-assessment and three questions for a leadership team. That works when you are looking at one workflow. It breaks when you are looking at forty — each at a different point on the scope-readiness grid, each owned by a different team, each evolving at its own pace. This post asks what readiness discipline looks like when the unit of…
Less Queue, More Craft argued that when agents handle implementation throughput, human work shifts toward judgment - strategy, coherence, and the bridge from prototype to production. The Other Dimension gave that judgment a structure: four readiness components sitting alongside capability as a second dimension. This post asks what craft actually is in that frame - and why shaping is a better word…
How Confident Should You Be? covered calibration - how much to trust outputs when the system is nominally healthy. This post covers recovery design: when outputs are wrong, how quickly does your organization notice, route the pain to the right owner, and convert the incident into learning that changes the system? Without that loop, "organizational memory" is just storage.
Try to Break It First was about knowing where the system fails. This post is about confidence - how much to trust outputs when the system is nominally "working," and how that trust should change when the context changes. It is the readiness component people skip because green builds feel like permission.
Rethinking Assumptions argued that when agents write most of the code, the assumptions behind our tooling break what does that shift mean for teams? Product and engineering don't just use the tools - they are organized around the same assumptions. If we don't update how we work together, we'll keep forcing agent-era output through human-era structures and blame the wrong thing when it hurts.
The open source AI assistant space has exploded in the past few weeks. What started with a single breakout project (Clawdbot, later Moltbot, now OpenClaw) has spawned an entire ecosystem: full-featured frameworks, minimal rewrites, Python alternatives, Go and Rust implementations for embedded hardware, and shell-script-as-a-service. The projects share a common promise - an AI agent that runs…
The Other Dimension introduced the four readiness components - ownership clarity, failure-mode awareness, confidence calibration, and recovery design. The Invisible Line focused on ownership. This post builds the first of the three that remained: failure-mode awareness - not as a testing checkbox, but as an organizational habit.
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.
Most dev tooling was built on assumptions that no longer hold: humans write code with effort and expertise; changes are scarce and valuable; linear workflows make sense. When agents write 90% of the code, those assumptions break. The tools we rely on - tickets, PRs, sprints, branching - were designed for a different world. It's time to re-examine them from first principles.
Less Queue, More Craft argued that when agents handle the queue, the bottleneck moves to judgment - strategy, coherence, and the bridge from prototype to production. This post names the place where that judgment is most urgently required: the moment something stops being an experiment and starts being relied on - and nobody can point to who decided, or who owns what happens next.
When agents generate code, the volume of changes can overwhelm human reviewers. Line-by-line diff review doesn't scale - and for many changes, it's the wrong level of abstraction. What reviewers often need is: what did this change accomplish, logically? Intent-based review surfaces that instead of (or in addition to) the raw diff.
People in sales, marketing, operations, and communications could benefit from custom tools - dashboards, scripts, automations - but lack the programming skills to build them. AI agents change that. With an agent as a collaborator, non-engineers can describe what they want in natural language, iterate with the agent, and ship. The design challenge: how do you build products for builders who don't…
Autonomous agents can execute high-risk operations systematic gates for designated actions, with lightweight feedback that doesn't stall the entire workflow.
Agents increasingly work with large files, large tool catalogs, and large context. Loading everything upfront wastes tokens, degrades performance, and overwhelms both model and user. Progressive disclosure - revealing detail only when needed - is a design principle that applies to more than traditional UI. It applies to how agents encounter and use information.
AI agents can pursue wrong directions for a long time before producing output. By the time you see the result, significant time and tokens are wasted. The alternative - exposing the agent's reasoning in real time - adds cognitive load and can feel noisy. The design question: when should users see the agent's thinking, and when should they be able to interrupt?
A background agent completes 90% of a task. The remaining 10% needs human judgment - a nuance the agent missed, a decision that requires context the agent doesn't have. If the handoff from "agent working" to "human editing" is clunky, you've just negated the benefit of automation. The transition is a design problem.
The "assistant" model -sitting in a sidebar, watching an agent work, ping-ponging back and forth -optimizes for the wrong thing. As models become capable of autonomous work for 45 minutes or more, the human becomes the bottleneck. The future of agent tooling isn't a better sidebar. It's a factory: spawn multiple agents, let them run, check in periodically.