In my experience, good API design is often constrained by the cost of exploration, even in organizations that invest heavily in up-front design.
Exploring alternatives takes time. Producing design artifacts takes effort. Revisiting early decisions takes budget, patience, and political capital. As those costs rise, as timelines stretch, and as leadership grows uneasy about the lack of visible “progress,” teams shut down exploration and try to turn partial understanding into a production-ready API. They settle on fragile models because changing them further feels too expensive.
This challenge is the reason I continue to get requests for two of my workshop courses on AI and APIs. One focuses on designing new APIs, AI-Driven API Design. The other focuses on improving existing ones, Making Your APIs AI-Ready. Both use modern AI tools extensively.
Both courses are about making it practical (and affordable) to do more design work before committing to production-level code without blowing up your delivery timelines.
The hidden cost that shapes API decisions
Most API teams already know how to do good design work. We have stories, vocabulary lists, diagrams, design documents, specifications, documentation, tests, and security profiles. None of this is new.
What is less often acknowledged is how expensive it feels to use these tools as design artifacts rather than as one-time deliverables.
Every artifact carries a “design tax”. Writing down vocabulary feels slow. Maintaining diagrams feels brittle. Keeping documentation aligned with behavior feels endless. Tests and security reviews tend to arrive late, not because teams do not care, but because earlier work consumed the available attention and energy.
That design tax shapes behavior long before any code is written.
As the perceived cost of producing and maintaining artifacts rises, exploration starts to feel risky. Brainstorming is shortened. Existing patterns are reused without checking whether they actually fit the domain. Assumptions stop being questioned because revisiting them would mean touching too many downstream artifacts. Progress becomes defined by forward motion rather than improved understanding.
This is not a failure of discipline or skill. It is a rational response to cost pressure. When every design change threatens to ripple across stories, diagrams, specifications, documentation, and tests, teams naturally try to stabilize early, even when the model is incomplete.
The result is familiar. Partial understanding hardens into a production API. Fragile models survive not because they are good, but because changing them feels too expensive.
What this suggests is not that teams need to care more about design, but that the economics of design work are misaligned. If we want teams to explore longer and decide later, we need to reduce the cost of doing so. That requires shifting our design thinking earlier in the process, not by demanding more effort, but by making exploration cheaper.
A different kind of shift left
Traditional shift-left thinking focused on timing. Test earlier. Secure earlier. Review earlier. The intent was sound, but the execution often missed the point. Asking teams to do more work earlier in the lifecycle simply shifted cost forward, often before confidence was high.
The result was predictable. Design reviews felt premature. Security decisions felt speculative. Tests were written against models that were still in flux. Shift left became associated with friction rather than insight.
What is needed is a different kind of shift left, one that focuses on cost instead of schedule.
When the cost of producing and revising design artifacts is high, exploration feels dangerous. When that cost drops, exploration becomes routine. Designers can afford to examine multiple options without committing to any single one too early. Ideas can be written down, compared, revised, and discarded without triggering a cascade of rework.
This is where AI-assisted tooling changes the equation.
Lowering the marginal cost of producing vocabulary lists, diagrams, design documents, specifications, documentation, and tests makes it practical to think more before coding, not because teams are moving slower, but because they are moving with less risk. Design work stops feeling like a one-way door.
This shift left does not accelerate delivery by compressing decision-making. It improves delivery by allowing decisions to mature. Design conversations last longer because they are cheaper. Explicit modeling replaces hand-waving because writing things down no longer feels like a permanent commitment.
The net effect is subtle but important. Teams explore more, decide later, and commit with greater confidence. Not because they have more discipline, but because the cost structure of design work finally supports the behavior we have always claimed to value.
Better tools raise expectations
Lowering the cost of design work has an important side effect. It becomes harder to hide weak thinking.
When diagrams are easy to produce, vague elements stand out. When vocabulary is written down and shared, inconsistencies surface quickly. When documentation and tests can be regenerated without effort, missing behavior shows up earlier in the process rather than after release.
As the cost of producing artifacts drops, the tolerance for ambiguity drops with it. Design conversations become sharper because assumptions are visible. Reviews become more substantive because there is something concrete to examine. Disagreements move away from intuition and toward evidence.
Better tools do not excuse poor design. They expose it.
This is where the real value of AI-assisted design tooling emerges. By removing friction from artifact creation and revision, these tools raise expectations for clarity and coherence. Teams that once avoided explicit modeling because it felt expensive begin to rely on it as a routine part of design work.
The outcome is not faster APIs. It is clearer. APIs that are easier to explain, easier to evolve, and harder to misuse, not because the tools are clever, but because the thinking they support is more disciplined.
Why this is the focus of the courses
Both AI-Driven API Design and Making Your APIs AI-Ready are built around this idea of lowering the cost of exploration.
They are not about adding intelligence to APIs. They are not about replacing designers with automation. They are about making it economically feasible to do the kind of design work we already know leads to better outcomes.
One course starts when the domain model is still fluid and decisions are cheap to revise. The other starts when constraints already exist and change is more risky. In both cases, the goal is the same. Reduce the friction of producing and revising design artifacts so that teams can explore longer, decide later, and commit with greater confidence.
AI-assisted tooling makes this possible, but only if it is treated as support for thinking rather than a shortcut around it. Used well, these tools take on the repetitive and error-prone work that drains attention without improving understanding. That leaves designers focused on the hard parts of the job. Choosing names. Defining boundaries. Deciding what not to expose. Planning for change.
If there is a single claim underneath both courses, it is this. Improving API quality does not require smarter designers or stricter processes. It requires lowering the cost of doing good design work early, when it matters most.
That is the shift worth making.
