NASEBANAL runs its Contract-Driven Development pipeline on Specmatic, and at apidays India 2026 I had the chance to sit down with Naresh Jain, the person who built it. On the 40,000-microservice estate where Specmatic was born and why the no-code constraint was the essential one; on MCP as an intentional boundary rather than a mirror of your API; and on why, by analogy with Sakichi Toyoda's self-stopping loom and Jidoka, what AI coding agents need is not more fences but a harness. His answers, and what each one changed in how I think about my own pipeline.
I attended apidays India 2026 in Bengaluru. This year's theme was \"NextGen APIs: Powering Humans and Agents Alike\" — the premise that APIs can no longer be designed for human developers alone, and now need to account for a second class of consumer: AI agents. This post covers the 1,000+ person venue and, out of 88 speakers from 11 countries, the sessions that stood out to me most, each tied back to what it means for NASEBANAL. My interview with Naresh Jain, Founder & CEO of Specmatic and the organizer of this event, will be published as a separate post.
I went to KubeCon + CloudNativeCon Japan 2026 in Yokohama. The main conference ran two days, with a co-hosted event the day before; I made the co-hosted day and day one of the main conference, and missed day two for a personal commitment. Going in, my view was that Kubernetes is a tool for organizations that need flexibility to absorb large-scale traffic — and therefore has nothing to do with a fledgling app developer like NASEBANAL. What I found instead were insights that connect directly to my own business. This post covers the four biggest lessons — Kubernetes as a test harness, the architecture debate around agents and what to expect of them, NVIDIA's take on using agents for root-cause investigation during incidents, and the FinOps of running agents themselves as argued by Cast AI and Kimchi — each tied back to what it means for NASEBANAL.
At the end of my last post I said the next step would be mobile — and I'm now building it. NASEBANAL Growth Mobile bundles the Target, Recorder, and Stopwatch apps into a single client, built by taking the existing Web UI as the baseline, designing the screens with Figma MCP from inside Claude Code, fine-tuning the Figma stills by hand, and then auto-generating the app from those screens plus the OpenAPI Spec. Along the way, dark mode — which came almost for free on mobile — gave me the nudge to bring Light / Dark / System to the Web apps too; because a shared component package (bundling the UI foundation and the color palette as design tokens) and the API spec are factored out as shared packages, that stayed a light change. To close, I lay out why this whole flow is exactly the approach I've been shaping for in-house-development support.
In my previous post I promised a closer look 'next time' at our work on Contract-Driven Development (CDD), so here it is, laid out afresh. Why CDD helps reconcile spec clarity with quality assurance, why I chose Specmatic over Pact — the flagship of CDD — (the limits of Consumer-Driven contracts, and how well an OpenAPI-spec-as-contract approach fits), and the pipeline I built by running NASEBANAL's Spec, backend, and frontend through a full loop, plus what I took away from it. This is where my hypothesis stands — putting the OpenAPI spec at the center as a shared guardrail for a future where in-house, outsourced, and AI-agent development coexist.
Alongside the launch of our developer-facing site [NASEBANAL API Specs](https://api-specs.nasebanal.com/en), I'd like to share the concern behind it and the work it has prompted. AI coding accelerates feature implementation, but our understanding of that implementation struggles to keep up, making it hard to see what state the code is in after each PR and Merge. This post lays out two efforts aimed at that challenge of 'making the state of development visible' — laying the groundwork for Contract-Driven Development (CDD), starting with splitting the API reference into its own site, and making development visible through DORA / Code metrics and token consumption — and reflects on the role of the OpenAPI spec in a future where in-house, outsourced, and agent development coexist.
Why we built a versatile data tracking tool. A Tokenization-inspired approach to security, predefined category tags, and OGP graph images for SNS sharing.