The bottleneck is no longer writing software.
The bottleneck is deciding what software should exist.
Agentic development has dramatically compressed the time and cost of design, development, testing and deployment.
As a result, the constraint has moved.
The hardest problem is no longer how to build.
It’s what to build — and for whom.
Product discovery, not software delivery, is now the rate limiter.

Last month, 48% of visitors to documentation sites across Mintlify were AI agents—not humans.

Claude Code, Cursor, and other coding agents are becoming the actual customers reading your docs. And they read everything.

This changes what good documentation means. Humans skim and forgive gaps. Agents methodically check every endpoint, read every guide, and compare you against alternatives with zero fatigue.

Your docs aren't just helping users anymore—they're your product's first interview with the machines deciding whether to recommend you.

That means:
→ Clear schema markup so agents can parse your content
→ Real benchmarks, not marketing fluff
→ Open endpoints agents can actually test
→ Honest comparisons that emphasize strengths without hype

In the agentic world, documentation becomes 10x more important. Companies that make their products machine-understandable will win distribution through AI.

Make Your Docs Agent-Ready

All the essential API, platform, and AI reads delivered straight to your inbox every Tuesday. Join over 200k+ already subscribed.

In the previous issue, I began applying my evaluation framework to the Synergetic Blueprint (SB), covering the API Adoption dimension (User-Centric APIs and Workflow Orchestration) and the Operational Efficiency dimension (API Reuse and API Evolution). In this issue, I continue with the Innovation dimension — specifically, the Faster Time to Market criterion.

Criteria question: Without sacrificing API design quality, how long does it take to go from the approval for a new business capability (or from a new API request for an existing business capability) to an approved API design?

There are two metrics to this question. The first is what I call the Capability to Design Approval Lead Time (CDA). This is the time elapsed from when a new business capability is approved for build to when the API design for it is approved by the relevant stakeholders.

CDA = API Design Approval Date − Business Capability Approval Date

For the Synergetic Blueprint, I would count this from Step 4 — Gathering Business Requirements with Domain Storytelling, in Phase II (Strategic Design). The assumption here is that in Phase I (Enterprise Design), approval has already been given to develop the business capability.

The second metric is the Request to Design Approval Lead Time (RDA). This is the time elapsed from when an API request is submitted for an existing business capability to when the API design for it is approved by the relevant stakeholders.

RDA = API Design Approval Date − API Request Submission Date

For the Synergetic Blueprint, this would be the time from Step 7 — Definition of Interfaces using the API Product Canvas, in Phase III (Tactical Design).

The CDA includes the RDA, but also the time required for upstream activities such as capability definition and prioritization, domain modelling, Event Storming, user journey mapping, and architectural review.

I'll first talk about how I think the SB reduces the CDA (with a focus on the Strategic Design parts) compared to processes that skip those ceremonies. Then I'll talk about how the SB reduces the RDA.

The workshops involved in the Strategic Design phase of the SB — Domain Storytelling, EventStorming and Context Mapping — involve human stakeholders thinking and discussing to flesh out users' goals, understand existing business process workflows, and elicit requirements. A lot of the outcomes here are actually in the heads of the participants: getting them to understand and align on what needs to be done and what the constraints are.

If this phase is skipped, teams can actually go to market faster. But the probability that they will need to rework their solution — because it does not meet the actual business requirements or user goals — is higher. So in the short term, it may appear that the extensive brainstorming in these workshops slows down time to market, but in the long term it creates solid architectural and requirements foundations for faster delivery.

It is worth mentioning that these Strategic Design aspects of SB, which are based on Domain-Driven Design, work best in complex domains with rich domain models. Simple, CRUD-heavy domains would find these to be overkill. And clearly, SB and DDD would not work in organizations where deep domain collaboration between teams or departments is not culturally or politically possible.

I have to acknowledge that the SB, with its multiple workshops for Domain Storytelling, EventStorming, and Context Mapping, can be heavyweight for some organizations. A product manager writing user stories plus an architect sketching an API contract in a couple of hours or less is a much lighter-weight approach, and could still avoid major rework if done well. The rework-avoidance benefit is really proportional to the domain complexity (as I mentioned above for simple domains). But even for moderately complex domains (not just the simple CRUD ones), the cost-benefit trade-off may be unclear.

Another thing worth mentioning here is the coordination costs. As the authors note in their book [1], these workshops involve different stakeholders and require strong facilitation by a good facilitator or Scrum master. Scheduling Domain Storytelling and EventStorming sessions with product owners, domain experts, architects and developers can introduce significant calendar-driven delays that add to the time to market.

API-design-first approaches range from creating API definition files by hand (writing YAML), using a visual development tool (Stoplight, SwaggerHub and so on), coding a programmatic API definition language by hand (like TypeSpec or Airtasker's Spot, to feeding API design requirements into an AI tool that generates an API definition file (like OpenAPI or AsyncAPI) using an AI chat interface. The Synergetic Blueprint helps reduce the RDA for this last technique by providing a structured, higher-quality prompt context for AI generation than ad-hoc requirements documents do. That structured input produces better first-draft contracts with less iteration.

The SB collects the requirements fleshed out in the previous phases into a visual canvas that stakeholders can collaborate on, share and store. The visual structure of the canvas reduces the transactional cost involved in communicating design decisions to other stakeholders — architectural or API design review teams, for example.

From an API design perspective, getting a reviewed and approved design is probably a good end point. But it does leave the open question of what the end-to-end software development workflow would look like if the API design were integrated into a spec-driven agentic workflow where the developer is reviewing the outcomes — the final working software, not the intermediate artifacts.

One thing I would also have liked to see, which the Synergetic Blueprint method did not mention, is using AI to critique the API Product Canvas. Are there important requirements or operations left out in a filled-in canvas? Using AI as a judge to find gaps, review, and possibly update the API Product Canvas is valuable, I think.

API design is rarely a linear pipeline, and the authors [1] acknowledge that the different phases and steps may involve iteration. But one question that arises is: if a team has invested three days in workshops to arrive at context maps, what happens if consumer feedback reveals a fundamental modelling error? Is the only alternative to rerun the workshops with stakeholders to iron the issues out? This can have a direct impact on time to market. Perhaps a lightweight re-alignment session, rather than a full workshop, could address localized modeling errors without the overhead of reconvening all stakeholders. I would like to see more of this addressed by the SB.

A question that runs across both the CDA and RDA is: how much of the Synergetic Blueprint's design process can be accelerated with AI agents?

On the Strategic Design side, given the domain stories, process documentation and other artifacts, AI agents can generate first drafts of candidate domain events, suggest commands and aggregates, and enumerate alternative workflows and edge cases. They could help in proposing fixes to the domain language or grouping bounded contexts. However, the core parts — surfacing disagreements and tacit knowledge, prioritizing requirements and releases, deciding on scope cuts, and deciding which teams own which parts of the business process or bounded contexts — remain outside the ability of LLMs to automate.

On the Tactical Design side, the SB currently involves a human taking all the outputs of Step 6 — the domain stories, context maps, visual glossary, aggregates and entities — and creating the API Product Canvas. Could an AI agent be created to do this and further reduce the RDA? I would like to see this explored.

Taken together, there is clear potential for AI to compress both lead times, but the highest-value human activities — stakeholder alignment, domain judgment, and scope decisions — will remain manual. The Synergetic Blueprint provides a structured process that is well-suited as a foundation for this kind of selective automation.

For the criterion of Faster Time to Market, I give the Synergetic Blueprint a score of 3 — Moderate Support. The method's structured approach to requirements gathering and domain modelling creates a solid foundation for faster delivery, and there are clear avenues for further acceleration through agentic automation. However, the coordination costs involved in running the different workshops with multiple stakeholders can introduce significant time costs. And this can be cumulative if the API design needs to be revised when a modelling error is discovered later on.

In the next issue, I will continue the review with Faster Experimentation, Documentation Completeness, Security, Privacy and Performance Requirements, and the remaining criteria.

[1] A. Junker and F. Lazzaretti, Crafting Great APIs with Domain-Driven Design: Collaborative Craftsmanship of Asynchronous and Synchronous APIs, 1st ed. Berkeley, CA, USA: Apress, 2025.

Thoughtworks Future of Software Engineering Retreat Report [PDF]. Thoughtworks submits that AI is radically reshaping software engineering, shifting rigor from hand-crafted code into specifications, tests, constraints, and risk tiering, and creating a new “middle loop” of supervisory engineering work between coding and delivery. Senior practitioners see emerging fault lines around agent topologies, self-healing systems, security-by-design, and knowledge graphs as the new foundations for safe, domain-aware, agentic architectures. The report argues that roles, practices, and governance must adapt fast—reframing developer experience as “agent experience,” redefining staff and PM roles, and confronting cognitive debt and organizational bottlenecks as agents outpace human decision-making.

SDK code mode shows SotA accuracy and performance for agents using APIs: Pierce Clark and Kevin Whinnery examine "SDK code mode," a novel approach to enhancing how AI agents interact with APIs via the Model Context Protocol (MCP).

Announcing Arazzo UI: Visualize API Workflows: Frank Kilcommins introduces Arazzo UI, an open-source tool designed to transform complex Arazzo YAML or JSON documents into human-readable diagrams and documentation.

The 2026 MCP Roadmap: David Soria Parra, Lead Maintainer of the Model Context Protocol (MCP), outlines the strategic direction for the protocol in 2026, shifting from a release-based schedule to a focus on decentralised Working Groups.

API Security Best Practices: A Developer’s Guide to Protecting Your APIs: The article stresses that as organizations pivot toward "API-first" models, security must "shift left"—integrating protection into every stage of the API lifecycle rather than treating it as a final production hurdle.

AI Input vs. Output: Why Token Direction Matters for AI Cost Management: Dan Temkin explains that while input processing is efficient and parallelised on GPUs, output generation is a sequential, recursive process that consumes significantly more compute power.

Solving the Problems That Accompany API Sprawl With AI: The article argues that as organizations scale their digital services, they often lose track of thousands of endpoints, leading to security risks such as "shadow APIs" and underutilised assets.

Show Me the ROI: Turning API Governance into Profits [YouTube]. In this Treblle webinar, Mark Boyd from Platformable reframes API governance from a bureaucratic cost center into a profit driver, showing how availability, performance, experience, and cost (AEX) directly impact revenue, risk, and developer productivity.

Apidays Singapore: apidays Singapore will share insights on API monetization, security, AI-driven automation, and more. Date: 14 - 15 April 2026. Location: Marina Bay Sands, Singapore.

Apidays New York: Location: Convene 360 Madison, New York, Date: 13 - 14 May 2026

API Conference London 2026: The Conference for Web APIs, API Design and Management Date: May 11 – 15, 2026, Location: Park Plaza Victoria London, UK.

APIOps Helsinki Conference 2026: An API gathering in Finland for two days of focused strategy sessions, hands-on clinics, and peer-led community building. Date: June 2-3, 2026 | Location: Epicenter, Helsinki.