Governance means different things to different people. Governance in reality is an ongoing negotiation, but really just amongst those in power and who are in the know. For everyone else governance means guidance. In my experience, very few people actually give a shit about governance. Of those that do, most see governance as enforcement, and it is just minority who see it about education, empowerment, collaboration, and guidance. With Spotlight rules I’ve been exploring what is next for governance (guidance), doing the work to balance the old and new, while not being influenced by one or the other too much.
While I don’t fully understand how developers are working today, as most hold the realities of this close to their chest. The few that are open about how they actually develop are usually in the minority when it comes to the status quo. I don’t think that the developer workflow is being as disrupted as radically as many believe, I do think that the developer power that has accumulated within Git, pipelines, and the IDE is shifting hands right now. The intersection of multiple file standards injected into developers workflows is the only place I am finding interesting, and possessing any tea leaves I can use to understand where governance (guidance) might be going.
Guidance
I have been very interested in what I consider to be “inline guidance” since my time at Bloomberg—the practice of seamlessly injecting governance into the software development lifecycle exactly where it is needed as guidance. I’ve been doing this via IDE, CLI, and pipelines, but I am now also assessing the realities of doing this via copilot. I’ve been exploring the injection of Spectral or Vacuum rules, as well as API style guides into the developer workflow via MCP, but I know there is more opportunities if I can better understand the reality of developers in their local environment. The stories you hear range from multi-dimensional Kung Fu using agents to a glorified Stack Overflow with developers copying and pasting—I am guessing the reality is somewhere in between.
Skills
If you want an honest look at what is possible at this new dimension of API governance located at the intersection of Git, IDE, CLI, Copilot, and Agentic, the Agent Skills from Speakeasy provide a pretty compelling look at what is possible. I am less interested in the realities of what Speakeasy Skills enable within agentic infrastructure, than I am in how they translate many human processes into orderly machine-readable processes. I am team entropy when it comes to the de-evolution of our API landscape from XML to JSON to YAML to Markdown, and less team agentic when it comes to automation.
Collections
Speaking of API transactions, and what the modular and executable units of value are today, I was down in the weeds of the difference between Bruno Collection and OpenCollection. I have long given up on any resistance to new specifications and spend time to understand whatever comes along—within reason. I am fascinated how people’s business model and tooling model shapes how they see their artifacts. SDK people see it one way. Client people see it another. Docs people see it another. Which is why we have OpenAPI Overlays, which I am happy to begin to see being used to help us tackle the Wild West Venn diagram of the artifacts we use to declaratively define the transaction landscape.
Rules
I had a fascinating conversation with Anna Daugherty this week about the evolution of rules from a Spectral and Vacuum context to RULES.md at the coding assist level. The podcast will likely come out next week, but Anna’s experience with Spectral rules from her time at Stoplight, and now here focus on AppSec across the developer workflow with RULES.md is super relevant to what is next for governance (guidance). I love the entropy that exists in governance of OpenAPI, AsyncAPI, and JSON Schema using Spectral or Vacuum rules being applied in the IDE and via the CLI, but adding copilots into the mix turns the entropy volume up significantly. Hard to tell if its positive or negative entropy yet.
Automation
The fact that the the automation realm is currently fascinated with a reality TV meets coliseum approach to releasing thousands of agents onto a platform or your local machine says a lot about where we are with technology. I just can’t find a reason to have an agent when I have manual requests I can make, CRON jobs I can schedule, and events I can respond to. I just can’t wrap my head around why you’d want to unleash a swarm of agents on your operations, let alone open the door to swarms of agents from many of the startups you see across the landscape today. I don’t care how many rules and guard rails you put in place. I think AI definitely plays a massive role in our integration and automation landscape, but not like this.
Capabilities
Continuing to do my deep thinking about what a capability is, or could be, I answered a question for my team this week about how a capability can come to life. It is a great question, and an answer I think potentially differentiates your regular data or API integration from what is needed. Integrations are primarily engineer led. Capabilities are about ensuring those integrations with what business requires. When a capability is brought to life will depend on the Greenfield or Brownfield nature of a capability, and whether it is manually being defined or automated using a mix of deterministic and non-deterministic approaches to defining what you need across the services and tools you already use.
Hype
I do not find the hype cycles interesting. They seem silly and not really a good use of my time. However, I do get people who ask me for my thoughts, and I think there is value in doing a quick dive into these waters to remind ourselves why staying the course on our existing investments matters. I talked to an integration veteran at a large enterprise this week who wisely said, “know when it is time to get in on a new technology, and when to get out of a technology”, as we discussed Tibco, SAP, microservices, event-driven, and artificial intelligence technology side by side. Trying to code switch between the EDI and AI spectrum that exists across the technology landscape both gives me concern and hope in these times.
What Matters
To help ground myself this week I stopped and asked myself what I thought mattered most in today’s noisy landscape. I wrote in my notebook: discovery, tagging, keys, and composition. It is an interesting and uncertain time right now. I think some of the new specifications on the table like SKILL.md, AGENTS.md, and others have an opportunity to shake all the digital bits of our software development lifecycle like an etch-a-sketch, resulting in a pretty significant shift and disruption in the power that developers have accumulated over the years. I don’t think it will play out like you are currently hearing from the financialization of everything people who have the bullhorn right now.
I do see a power shift continuing to happen. I also see specifications and standards as key to this. For good and bad. I think SKILL.md and AGENTS.md can shift the interface polarization for both the producing and consuming of APIs. I think there is a huge opportunity to provide more guidance at this layer, but I am less sure we will be able to properly validate and govern at this layer. We were just getting a handle on the sprawling API landscape by using OpenAPI, AsyncAPI, and JSON Schema with Spectral and Vacuum rules. Now we have to consider the MCP, AGENTS.md, SKILL.md, RULES.md, and others as well. I think we can do it, but we are going to need someone shaping the repo folder landscape.
We've seen over time that countries that have the best economic growth are those that have good governance, and good governance comes from freedom of communication. It comes from ending corruption. It comes from a populace that can go online and say, 'This politician is corrupt, this administrator, or this public official is corrupt.' - Ramez Naam
