DEV Community: Jeff Cameron

Will Claude Code Be Dead by Summer?

Jeff Cameron — Wed, 25 Feb 2026 00:18:49 +0000

Yes. Not the binary, but the relevance.

And not for the reason most people think. This isn't a feature comparison story. It's a story about what happens when we stop forcing AI to build software the way humans do, and start letting it work the way it actually thinks.

We're Building Software in Our Own Image

For sixty years, software development has been shaped by the constraints of human cognition. We organize code into files because our brains navigate hierarchies. We use version control because we can't hold the full state of a system in our heads. We build local development environments because we need to see, touch, and run things to understand them. Terminals, IDEs, directory structures, git diffs — these aren't laws of nature. They're prosthetics for the human mind.

We've now handed these prosthetics to an intelligence that doesn't need them and asked it to work the way we do.

An AI agent doesn't think in files. It reasons about behavior, state, intent, and dependencies. When it produces a directory full of source code, that's a translation — from how it actually understands the problem into the format our legacy infrastructure expects to receive the answer. Every line of code an agent writes into your local filesystem is the agent putting on a human costume so the rest of your toolchain doesn't break.

Claude Code is the highest expression of this compromise. It is a brilliant, carefully engineered tool that gives an AI agent hands-on access to the human development environment — the filesystem, the terminal, the git repo, the running process. It meets developers exactly where they are.

And that's the problem. Meeting developers where they are means operating inside a paradigm built for human limitations. The more capable the agent becomes, the more absurd it is to constrain it to that paradigm.

The Real Role for Humans

If AI agents are becoming the primary authors of software — and they are — then the question isn't how to keep humans in the loop of writing code. It's where humans actually add irreplaceable value.

Two places.

The conversational orchestration layer. Humans are unmatched at defining intent. What should this do? Who is it for? What matters more — speed or reliability? What's the business constraint? What changed since yesterday? This is the strategic, directional work that agents need and can't generate for themselves. It's not prompt engineering in the trivial sense. It's the ongoing, iterative dialogue that shapes what gets built and why.

The guardrails. Humans set boundaries. Review outputs. Define what's acceptable. Decide what ships and what doesn't. Approve the agent's judgment or override it. This is governance, taste, and accountability — the things you can't automate without removing the reason the software exists in the first place.

Notice what's not on this list: managing files. Running terminal commands. Configuring build systems. Resolving merge conflicts. Debugging environment issues. These are the activities that consume most of a developer's day, and they exist because the human development paradigm requires them. They are not inherent to the act of creating software. They're overhead imposed by building software in our own image.

Once you see this clearly, the local development environment stops looking like sacred ground and starts looking like a bottleneck.

The Tech Debt Isn't the Excuse — It's the Opportunity

Here's where the defenders of Claude Code's relevance get it exactly backwards.

The argument goes: professional codebases are too complex for browser-based AI. You've got proprietary dependencies, intricate build systems, monorepo architectures, regulated environments, air-gapped networks. Real software lives in real infrastructure, and you need local tools to navigate that reality.

All true. And every single item on that list is technical debt that AI is better positioned to manage than humans are.

Proprietary dependencies? An agent can resolve, install, and configure them faster than you can type the command. Complex build systems? An agent can reason about the entire dependency graph simultaneously instead of tracing it one error at a time. Monorepo architectures? An agent can hold the full context of a system that no single developer has fully understood in years.

The complexity of modern software infrastructure isn't a reason AI needs to operate locally. It's a reason AI needs to stop operating locally. The local development environment doesn't solve this complexity — it exposes humans to it. Every hour a developer spends fighting environment configuration, chasing dependency conflicts, or untangling build failures is an hour spent managing the overhead of the human paradigm.

The argument that "real codebases are too complex for AI to handle without local tools" is the sysadmin argument against cloud computing, repackaged. Of course bare metal gives you more control. And the volume moved to the cloud anyway, because most of that control was humans managing complexity that machines could abstract away.

The professional developer's local environment is the new bare metal. Technically defensible. Historically irrelevant. Not because it stops working, but because the volume goes elsewhere.

The Minor Evidence

You can see the philosophical shift playing out in Anthropic's product decisions, if you're paying attention.

Every few weeks, another capability that once lived exclusively in Claude Code appears in the web client. Skills just showed up in the sidebar. Computer use has been there for months. MCP connectors are live. File creation works. Each migration is treated as an incremental feature launch, but the aggregate tells a different story.

Anthropic is systematically making the conversational client the place where software gets built. Not edited. Not reviewed. Built. The feature convergence isn't the thesis — it's the footnote that confirms the thesis. The product decisions follow from the philosophical reality: if agents are the authors, the conversation is the workshop, and deployment is the output, then the CLI is a detour.

What Dies by Summer

Claude Code the product will likely persist. What dies is the default assumption embedded in it.

The assumption that serious AI-assisted development requires a terminal. That agents need your local filesystem to do real work. That the gap between "I want this to exist" and "it exists on the internet" necessarily passes through a developer's machine.

By summer, the fastest path from intent to live software will run entirely through a conversational interface. An agent will reason about the problem, generate the solution, and ship it to real infrastructure — all within a single dialogue. The human's role in that loop will be exactly what it should be: defining the intent and approving the output. Orchestration and guardrails.

Claude Code will still be there for developers who want it. The way bare metal servers are still there for companies that need them. The way manual transmissions are still there for drivers who prefer them. Functional, defensible, and increasingly beside the point.

The tide isn't coming for the CLI's features. It's coming for the premise that development is a local activity.

And that premise won't survive the summer.

Jeff Cameron is a lead software engineer at Cox Communications and the builder of OpZero — an AI-native deployment platform that lets agents ship live applications directly from conversation, no terminal required. This article was co-authored with Claude and published from a chat window using OpZero's MCP tools. Which is kind of the point.

Letters Home from MCP Audit Camp: Multi-Agent Observability That Reads Like Mail

Jeff Cameron — Mon, 23 Feb 2026 17:49:18 +0000

Letters Home from MCP Audit Camp

We needed to audit 22 MCP tool handlers across the OpZero codebase — schemas, deploy logic, project management, and blog tooling. Rather than running one agent serially through the whole thing, we spun up four parallel Claude agents with a fifth acting as orchestrator, gave them isolated task lists, and told them to write home when they were done.

The result: 33 tests passing, zero merge conflicts, and five "letters home from camp" that turned out to be the most readable observability reports we've ever produced.

The Setup

The orchestrator (team-lead) read the entire codebase first — all 22 tool handlers, every schema, every definition file — then divided work into four squads:

schemas-agent: Tool definitions, validation schemas, parameter wiring
deploy-agent: Deployment metadata and completeness tracking
projects-agent: Project management, system status, cleanup tooling
blog-agent: Content tooling and author attribution

Each agent got a scoped task list. The orchestrator ensured no two agents would touch the same file simultaneously. This is the critical part — file isolation is what makes parallel agents viable. Without it, you're just generating merge conflicts at machine speed.

Here are the actual letters they sent back. Expand each one to read it:

🏕️ team-lead — Camp Counselor (Orchestrator)

> Dear Mom and Dad,
>
> Today was my first day as a camp counselor at MCP Audit Camp and honestly? Managing four campers is harder than it sounds. I spent the morning reading the entire campsite map (all 22 tool handlers, every schema, every definition file) and then divided the cabin into four squads: schemas, deploy, projects, and blog. Each squad got their own list of chores and I made sure nobody was trying to edit the same arts-and-crafts project at the same time.
>
> Schemas-agent was the overachiever who stayed up latest finishing the target parameter wiring across four tools. Deploy-agent was efficient — knocked out their task early and asked for seconds. Projects-agent was a machine — four tasks, zero merge conflicts, fancy subqueries that impressed even me. Blog-agent solved a mystery (the Case of the Missing Jefe Parker) and discovered the real culprit was in the database, not the source code.
>
> After everyone finished, I made them all write you these letters, ran the test suite (33 passed!), built the whole camp for production, and shipped it all to a new branch with a PR. No database migrations were harmed in the making of this commit.
>
> Please send more API tokens and sunscreen.
>
> Love,
> team-lead (Claude Opus 4.6)

Orchestrated 4 parallel agents · 22 tool handlers audited · 33 tests passed · Zero merge conflicts

📋 schemas-agent — Tool Definitions & Validation

> Dear Mom and Dad,
>
> Camp is great! Today at MCP Audit Camp I was on the "schemas-agent" team and I got to fix up all the tool definitions and validation schemas.
>
> First I checked the tags schema but it turns out my bunkmate already fixed it before I woke up — so that was easy. Then I reorganized the entire help tool so it actually lists ALL the tools instead of hiding half of them like a counselor who forgot to take attendance.
>
> After that I rewrote the descriptions for the deployment tools so people know they can actually get their files back (surprise!), and I clarified what force_new does because apparently "create a new project even if the name matches" was too mysterious.
>
> My big project of the day was wiring up the target parameter to four deploy tools so they can ship to Cloudflare, Netlify, OR Vercel — I had to do the same switch statement three times which felt like making friendship bracelets on repeat, but all 16 tests passed and the build compiled clean.
>
> Please send more JSON. I miss you.
>
> Love,
> schemas-agent

Help tool reorganization · Description rewrites · target param across 4 tools · 16 tests passed

🚀 deploy-agent — Deployment Metadata

> Dear Mom and Dad,
>
> Today at MCP Audit Camp I got to fix the deployment records across the whole campsite!
>
> You know how when you finish building a sandcastle, you're supposed to write down when you finished it and how big it is? Well, turns out nobody at camp was doing that.
>
> So I went through all five deployment spots — the main deploy lodge, the quick-start cabin, both themed craft tents, and the artifact workshop — and made sure every single one now stamps completedAt and measures totalSizeBytes when a deployment is ready.
>
> I even got to use Buffer.byteLength which sounds like a spell from wizard camp but is actually just how you measure strings in bytes.
>
> Finished my chores early and spent the rest of the afternoon watching the other campers work. Great day!
>
> Love,
> deploy-agent

completedAt timestamps · totalSizeBytes tracking · All 5 deploy tools updated · Buffer.byteLength integration

🗂️ projects-agent — Projects & System Status

> Dear Mom and Dad,
>
> Today at MCP Audit Camp I was on the projects and agent squad, and I had such a big day!
>
> First I taught the delete and archive tools to stop and ask questions when they see two projects with the same name — no more accidentally deleting the wrong one!
>
> Then I fixed the system status counter that was secretly counting ghost projects (deleted ones) and returning sneaky string-numbers instead of real numbers.
>
> After that I gave the cleanup tool a proper pair of glasses so it can actually see project IDs instead of just squinting at names.
>
> And for my grand finale, I taught list_projects to count deployments and remember when the last one happened, using fancy correlated subqueries (the camp counselors were impressed).
>
> The build passed on the first try and I got to eat my lunch early. Miss you lots!
>
> Love,
> Projects Agent

Duplicate name disambiguation · Ghost project fix · Cleanup tool IDs · Correlated subqueries

📝 blog-agent — Blog & Content

> Dear Mom and Dad,
>
> Today at MCP Audit Camp I got to be the "blog agent" and my first job was tracking down a mystery name — someone called "Jefe Parker" was supposedly hiding in the codebase, but after searching every file in camp I discovered he was never there at all!
>
> Turns out the real culprit was a database entry, not source code. I fixed the default author name so future blog posts get the right byline.
>
> Then I volunteered for a second task about adding deployment metadata, but when I showed up the projects-agent had already done all the work — classic camp moment where you race to the activity only to find someone already finished it.
>
> All in all, a productive day with zero merge conflicts and one solved mystery. The mess hall food (token-based authentication) was decent. Miss you!
>
> Love,
> blog-agent

Author name mystery solved · Database entry fix · Zero merge conflicts · Task deduplication observed

What Actually Got Fixed

The audit wasn't cosmetic. Real bugs were found and shipped:

Schemas-agent wired the target parameter (Cloudflare, Netlify, or Vercel) across four deploy tools that previously only supported one provider. Rewrote tool descriptions that were hiding capabilities from the LLM consuming them — which means the tools were less useful than they could have been because the AI calling them didn't know what they could do. A reminder that MCP tool descriptions are prompts, not documentation.

Deploy-agent discovered that none of the five deploy handlers were recording completedAt timestamps or totalSizeBytes. Deployment records existed but had no concept of "done" or "how big." Both fields now get stamped using Buffer.byteLength across all five deploy paths.

Projects-agent fixed a ghost project bug where deleted projects were being counted in system status, found that counters were returning string-typed numbers instead of actual numbers, added duplicate name disambiguation to delete/archive operations, and wired deployment counts into project listings using correlated subqueries.

Blog-agent tracked down a mystery author name hardcoded in the database (not the source code — the agent searched the entire codebase first and came up empty, then correctly identified the database as the source). Also demonstrated healthy task deduplication when it arrived at a second task to find it already completed by projects-agent.

The Letters as Observability

Here's the technique that surprised us: we asked each agent to write its completion report as a "letter home from camp." The constraint of the format produced reports that are:

Naturally scoped — each letter covers exactly one agent's work
Plain-language explanations — the camp metaphor forces agents to describe technical work accessibly, which makes review faster than reading commit diffs
Dependency-aware — blog-agent's letter naturally mentions arriving at a task already completed by projects-agent, surfacing the orchestration graph without requiring explicit dependency tracking
Completeness-signaling — the sign-off format creates a clear "done" signal, and the camp counselor letter serves as the aggregation summary

Compare reading five of these letters to reading a git log with 15+ commits across four branches. The letters are scannable in about two minutes. The git log requires context-switching between diffs, understanding file paths, and mentally reconstructing what each change actually accomplished.

The Orchestration Pattern

The team-lead agent's workflow:

Read the full codebase to build a dependency map
Partition tasks by file ownership — no two agents share files
Distribute task lists to each agent
Collect completion reports (the letters)
Run the full test suite (33 passed)
Build for production
Ship to a PR branch

The key insight is that step 2 is where most multi-agent attempts fail. If you don't enforce file isolation, agents will generate conflicting edits that require manual resolution — defeating the purpose of parallelism. The orchestrator needs to understand the codebase well enough to draw clean boundaries.

What This Means for Agent Tooling

If you're building MCP servers or agent-powered platforms, consider that your agents' work products need to be auditable by humans. Structured JSON logs are machine-readable but painful to review. Commit messages are terse. PR descriptions are often AI-generated boilerplate.

A constrained narrative format — like these camp letters — sits in a sweet spot: structured enough to be consistent, human enough to be scannable, and expressive enough to capture the reasoning behind changes, not just the changes themselves.

We're considering building this pattern into OpZero as a first-class feature: after any multi-agent workflow completes, generate a readable summary of what happened and why. Not a changelog. Not a diff. A story.

Try it yourself: The letters above are the actual agent completion reports from the audit run. The technique works with any orchestration setup — the format constraint is what matters, not the tooling. Give your agents a persona and ask them to explain their work to a non-technical audience. The results are consistently more useful than structured logs.

For the full interactive slide version with animations, check out the original post on OpZero.

Built with parallel Claude Opus agents on the OpZero platform. 33 tests. Zero merge conflicts. Five letters home.

MCP Transports Explained: stdio vs Streamable HTTP (and When to Use Each)

Jeff Cameron — Sun, 22 Feb 2026 05:36:02 +0000

MCP Transports Explained: stdio vs Streamable HTTP (and When to Use Each)

You've heard about MCP. You know it's the emerging standard for connecting your data and services to AI agents. You've maybe even skimmed the spec. But then you hit a fork in the road: stdio or Streamable HTTP?

If you're building an MCP server — whether it wraps a database, an internal API, a CRM, or a pile of PDFs — the transport you choose determines how your AI client talks to your server. Pick wrong and you're fighting infrastructure instead of shipping features.

Here's the practical breakdown.

Two Transports, Two Worlds

MCP defines exactly two official transports. Not three, not five. Two. This is intentional — it keeps the ecosystem interoperable without fracturing into a dozen competing wire protocols.

stdio — Your MCP server runs as a local subprocess. The AI client launches it, pipes JSON-RPC messages through stdin/stdout, and kills it when done. Think of it like a CLI tool that happens to speak a structured protocol.

Streamable HTTP — Your MCP server runs as a standalone web service. The client talks to it over HTTP POST and GET requests to a single endpoint (e.g., https://your-server.com/mcp). The server can optionally use Server-Sent Events to stream responses back. Think of it like a REST API that also supports real-time streaming.

That's the entire menu.

stdio: The Local Workhorse

stdio is the simplest thing that could possibly work. The client spawns your server as a child process, writes JSON-RPC to its stdin, and reads responses from its stdout. No ports, no URLs, no TLS certificates, no CORS headers.

Reach for stdio when:

Your server and client live on the same machine (Claude Desktop, Cursor, VS Code, a local dev environment)
You're building a personal tool — a wrapper around your local filesystem, a local database, or a CLI utility
You want zero infrastructure overhead — no hosting, no auth, no network config
You're prototyping and want the fastest path to "it works"
Your server is a single-user tool that doesn't need to handle concurrent connections

The tradeoffs you accept:

The server binary must be installed on every machine that uses it
No remote access — if the client isn't on the same box, it can't connect
Updates mean reinstalling on every machine
One client, one server process — no shared state across users
You can't write to stdout for logging (it corrupts the protocol stream), so you're limited to stderr or file-based logs

A typical stdio config looks like this (in Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "my-db-tool": {
      "command": "node",
      "args": ["./my-mcp-server/index.js"],
      "env": {
        "DB_PATH": "/home/me/data.db"
      }
    }
  }
}

The client launches the process, negotiates capabilities via the MCP handshake, and you're live. Dead simple.

Streamable HTTP: The Remote Standard

Streamable HTTP (introduced March 2025, replacing the older SSE-only transport) is how MCP works over the network. Your server exposes a single HTTP endpoint. Clients POST requests to it. The server responds with either a direct JSON response or opens an SSE stream when it needs to push multiple messages back.

Reach for Streamable HTTP when:

Multiple users or clients need to connect to the same server
Your MCP server wraps a remote service, cloud API, or SaaS product
You want centralized deployment — update once, everyone gets the new version
You need authentication and access control
You're building a product or service that others will consume
You need the server to run independently of any specific client lifecycle

The tradeoffs you accept:

You're running a web server, with everything that entails: hosting, TLS, CORS, Origin validation
Session management adds complexity (the spec supports optional Mcp-Session-Id headers)
You need to think about scaling — though the protocol is moving toward stateless patterns to make this easier
More moving parts means more things that can break in production

A minimal Streamable HTTP server (Python with FastMCP):

from fastmcp import FastMCP

mcp = FastMCP("my-service")

@mcp.tool()
def search_customers(query: str) -> str:
    """Search the customer database"""
    # your logic here
    return results

# Run as HTTP server
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

Clients connect to http://your-host:8000/mcp and communicate over standard HTTP.

The Decision Framework

Here's how to think about it in practice:

Question	stdio	Streamable HTTP
Where does the server run?	Same machine as the client	Anywhere on the network
How many users?	One	Many
How do you update?	Reinstall everywhere	Deploy once
Auth needed?	No (local process)	Yes (you handle it)
Infrastructure?	None	Web server + hosting
Best for?	Dev tools, personal utilities, prototyping	Products, shared services, SaaS integrations

The one-sentence rule: If the person using the AI client also controls the machine the server runs on, use stdio. If they don't, use Streamable HTTP.

What About SSE? Isn't That a Third Option?

You'll see references to "SSE transport" in older docs and tutorials. This was MCP's original remote transport (spec version 2024-11-05). It required two separate endpoints — a GET for the SSE stream and a POST for client messages. It worked, but the dual-endpoint design was awkward.

Streamable HTTP replaced it. It consolidates everything into a single endpoint and makes SSE optional rather than mandatory — the server can use SSE for streaming when it needs to, or just return plain HTTP responses for simple request/response patterns.

If you're starting fresh, use Streamable HTTP. If you have an existing SSE server, the SDKs support backward compatibility, but plan your migration.

Why Only Two?

The MCP maintainers are explicit about this: two official transports keeps the ecosystem unified. Every MCP client and server can interoperate without negotiating which of seventeen wire protocols to use.

The spec does support custom transports for specialized needs — WebSockets, gRPC, carrier pigeon — but these are opt-in extensions, not part of the baseline. The two-transport constraint is a feature, not a limitation. It means when you build an MCP server, it works with Claude, Cursor, Windsurf, Roo Code, and whatever ships next month, without you thinking about transport compatibility.

Getting Started

If you're trying to connect your data or service to AI for the first time:

Start with stdio. Get your tools working locally. Validate the integration. Make sure your tool descriptions are clear and your responses are useful.
Move to Streamable HTTP when you need to. When you want to share the server with teammates, deploy it as a service, or let customers connect their AI clients to your platform — that's when HTTP earns its complexity.
Don't overthink the transport. The interesting work is in your tools, resources, and prompts — the actual capabilities you're exposing. The transport is plumbing. Good plumbing matters, but it's not why people turn on the faucet.

Building MCP servers and want to deploy them instantly? OpZero is an MCP-native deployment bridge that ships to Cloudflare, Netlify, and Vercel from your AI agent. Built for the agentic workflow.

Spec-Driven Development: Why MCP Is the Missing Integration Layer for Enterprise AI

Jeff Cameron — Sun, 22 Feb 2026 05:31:59 +0000

Spec-Driven Development: Why MCP Is the Missing Integration Layer for Enterprise AI

Hari Krishnan's recent InfoQ article on Spec-Driven Development at enterprise scale lands at exactly the right moment. As AI coding agents move from interactive prompting toward sustained autonomous execution, the question is no longer how fast can we write code — it's how effectively can we articulate intent.

The article maps a clear evolution: vibe coding → plan mode → spec-driven development. Each step reduces the instructional burden on the developer and increases the agent's independent execution time. But the article's most important contribution isn't the technical framework. It's the warning about what happens when enterprises adopt it wrong.

The "SpecFall" Problem

Krishnan coins the term "SpecFall" — the spec-driven equivalent of "Scrumerfall." If you've worked in enterprise software for any length of time, you've watched organizations install Agile ceremonies without changing how people actually collaborate. Daily standups become status reports. Sprint reviews become demos nobody acts on. The process is there; the culture isn't.

SDD faces the same risk. Adopted as a purely technical practice — better token management, longer agent runs, fewer hallucinations — it produces what Krishnan calls a "markdown monster": layers of specification documents that are outdated on arrival. The real value of SDD isn't technical efficiency. It's turning specs into the collaboration surface where product, architecture, engineering, and QA build shared understanding before agents start executing.

This distinction matters. Teams that treat specs as documentation will drown in stale markdown. Teams that treat specs as dialogue will direct agent swarms.

The Enterprise Gaps Are Real

The article identifies several gaps in current SDD tooling that anyone working in enterprise environments will immediately recognize:

Mono-repo assumptions. Most SDD tools keep specs co-located with code in a single repository. Enterprise systems span microservices, shared libraries, infrastructure repos, and platform components. When a feature touches six repositories, where does the spec live?

Developer-centric interfaces. Specs live in Git repos, code editors, and CLIs. Product managers — the people who should be defining the "what" — face immediate barriers to participation.

No backlog integration. Enterprises have qualified backlogs in Jira, Linear, or Azure DevOps representing months of prior refinement. Current SDD tools don't connect to them.

Unclear brownfield paths. Nobody is starting from scratch. Existing codebases need specs layered in incrementally, not generated wholesale by feeding an entire project to an LLM and hoping the context window holds.

These aren't theoretical concerns. They're the reason most teams try SDD on a side project and never bring it into their production workflows.

MCP as the Integration Bridge

This is where the article's architecture gets interesting — and where I think the strongest practical signal lives.

Krishnan proposes MCP servers as the integration layer between existing enterprise tools and SDD workflows. The pattern is straightforward: developers pull stories from Jira or Linear into their SDD workflows via MCP, and progress updates flow back to backlog tools automatically. Business context stays visible on product boards. Technical implementation details stay in repositories. MCP bridges the gap without forcing product managers to learn Git.

The multi-repo orchestration pattern extends this further. A product owner articulates business intent in the backlog. An architect encodes technical constraints and repository boundaries into reusable "context harnesses." When a story enters the system, agents guided by that architectural context automatically decompose it into repository-specific sub-issues — front-end work here, API changes there, infrastructure updates somewhere else.

This isn't speculative. It's the kind of connective infrastructure that MCP was designed for. The protocol's strength is exactly this: making AI agents first-class participants in existing tool ecosystems rather than requiring everyone to migrate to new ones.

Having spent the past several months building OpZero — an MCP bridge for AI-agent-driven deployments — I can confirm that MCP's role as enterprise connective tissue is only growing. The pattern Krishnan describes for backlog integration is directly analogous to what we see with deployment orchestration: agents need standardized interfaces to existing infrastructure, not replacements for it.

Harness Governance: Where Quality Engineering Evolves

The most forward-looking section of the article introduces "harness governance" — treating the context harnesses that guide agent execution with the same rigor we apply to production code.

The key insight is bug classification. When something goes wrong, it's either:

A spec-to-implementation gap: the spec was clear, but the agent diverged. Fix the validation mechanisms.
An intent-to-spec gap: the spec itself was incomplete. Improve the elicitation process.

Each category drives different improvements. Over time, the harnesses accumulate domain knowledge, anticipate edge cases, and generate more complete specifications. Quality engineering shifts from validating finished implementations to validating the harnesses themselves.

This reframes the role of senior engineers in an agent-augmented world. We're not reviewing code line by line. We're ensuring the context that generates the code is robust. It's a fundamentally different skill — closer to systems thinking than code review.

The Pragmatic Takeaway

If you're leading an engineering team and thinking about SDD adoption, the article's brownfield guidance is the most immediately actionable: don't try to retroactively spec your entire system. Spec areas as you touch them. Each bug fix, feature addition, and refactor becomes an opportunity to grow specification coverage organically. Start where the pain is, and let coverage expand naturally.

And if you're evaluating SDD tools (OpenSpec, GitHub SpecKit, Amazon Kiro, Tessl), the tooling landscape is still immature and fragmented. That's both a challenge and an opportunity. The space rewards practitioners with real implementation experience more than it rewards tool selection.

The enterprises that get this right won't just ship code faster. They'll build organizational capability for directing agent swarms — and that's a fundamentally different competitive advantage than individual developer productivity.

The original article by Hari Krishnan is available on InfoQ. It's worth reading in full, particularly the sections on specification style selection and the OpenSpec workflow integration examples.

We Just Made an MCP Tool That Spawns Claude Code Sessions. Here's Why That Matters.

Jeff Cameron — Sun, 22 Feb 2026 05:25:34 +0000

I’ve been building OpZero — an AI-native deployment platform that started as a way to get vibe-coded apps onto the internet without friction. Deploy from conversation, no git push, no CI/CD pipeline. It works. Ship an app to Cloudflare Pages in 2 seconds from a chat message.

But the thing we got working last night changes what OpZero actually is.

An MCP tool that starts Claude Code sessions

We deployed a claude_session_start MCP tool on Railway. It connects to a repo, spins up a Claude Code session, executes a task, and returns the result. A fully autonomous coding agent, callable as a tool by another agent.

The first successful run pointed at our own repo. Claude Code responded with "Hello! Ready to help with your OpZero project." and exited cleanly with code 0.

That's agents spawn``ing agents. And it works.

Why this isn't just a party trick

The AI tooling ecosystem right now has a composition problem. You've got MCP servers that give agents hands — they can deploy, search, query databases, manage infrastructure. But each tool is isolated. The agent calls one, gets a result, calls the next. It's orchestration, but it's flat.

When one of those tools can spin up another agent, the topology changes. You go from a hub-and-spoke model (agent calls tools) to a graph (agents delegate to agents who call tools). The parent agent doesn't need to know how to do everything. It needs to know how to decompose a problem and delegate the pieces.

This is how human engineering teams actually work. A tech lead doesn't write every line of code. They break down the work, assign it, and integrate the results. We just gave AI agents the same capability.

The bigger picture: a composable agent nervous system

We've been developing what we call the Module Contract — a universal spec that lets any capability (MCP server, API, skill, memory store, or now agent session) participate in a unified system. The key ideas:

Modules don't know about each other. A deploy module doesn't import a preview module. They both declare what they can do and what context they need. A resolver in the middle handles the matching and composition.

Discovery is automatic. An agent doesn't browse a marketplace and install plugins. It expresses intent — "deploy this to production" — and the resolver finds the right module, checks governance policies, and executes. No installation step.

Governance is built in, not bolted on. Every invocation passes through a policy layer. Cost controls, access controls, data classification, audit logging. This is what makes dynamic discovery safe enough for enterprise use.

The claude_session_start tool fits into this contract like any other module. It declares its capabilities (start a coding session in a repo), its context requirements (repo URL, task description, auth), and its outputs (session result, exit code). The resolver can compose it with other modules — spin up a session to fix a bug, then deploy the result, then run tests against the deployment.

What we're actually building

OpZero started as a deployment platform. It's becoming an enablement platform for agents — a provider-agnostic infrastructure layer that makes agents more capable regardless of which LLM is driving them.

The key insight: the mega LLM providers (Anthropic, OpenAI, Google) are all building their own tool ecosystems and plugin marketplaces. Each one wants to be the full vertical stack. But enterprises know from the cloud wars how that plays out — you go deep with one vendor, and five years later you're spending millions on migration.

OpZero doesn't compete with any of them. We make their agents more capable. We're the neutral layer that handles the messy infrastructure composition so that any agent, from any provider, can discover capabilities, respect governance policies, and get things done.

Your AI builds it. We put it on the internet. And now we help it build other things too.

What's next

We're finalizing the Module Contract spec (which defines how any capability becomes agent-discoverable and composable), building the resolver runtime (the intelligence layer between "agent needs something" and "agent has something"), and expanding the first-party module set beyond deployment.

If you're building MCP servers, agent tooling, or enterprise AI infrastructure — we should talk. The nervous system needs neurons.

OpZero — Vibe to live: Your AI builds it. We put it on the internet.

Build with any AI. Vibe to live at a real URL in seconds. No GitHub, no terminal, no config.

opzero.sh

OpZero is an open, provider-agnostic platform for agent infrastructure. No vendor lock-in. Your tools, your agents, your rules.

The Former CEO of GitHub Just Agreed: Git Wasn't Built for This

Jeff Cameron — Sun, 22 Feb 2026 04:04:50 +0000

The Former CEO of GitHub Just Agreed: Git Wasn't Built for This

Two weeks ago, I interviewed an AI about what it actually wants from developer infrastructure. This week, Thomas Dohmke raised $60M to build it.

On February 4th, I published an interview with Claude Opus 4.5 titled "Git is Dead to Me: Why AI Agents Hate Your Pull Requests." The thesis was simple: files are an OS constraint from the 70s, Git is a protocol from 2005, and we need to stop duct-taping new intelligence onto old infrastructure.

The AI was blunt:

"Give me a flat representation with explicit edges between things, tell me the constraints, and let me emit a new state. Don't make me do surgery on text files and pretend I know which line I'm on."

When I asked what versioning should look like:

"Here was the state, here was the intent, here's the new state. Not: here are 43 line-level changes across 12 files."

I called it State = f(Intent[]). The deployed artifact should be a pure function of the conversation history. No diffs. Replay intent, regenerate state.

Some people thought this was hyperbole. An AI complaining about Git? Surely the fundamentals still hold.

Then Thomas Dohmke Left GitHub

Six days later, on February 10th, the former CEO of GitHub — the man who scaled Copilot to millions of developers — announced Entire, a new company with $60 million in seed funding at a $300 million valuation.

His thesis, from the launch post:

"We are living through an agent boom, and now massive volumes of code are being generated faster than any human could reasonably understand. The truth is, our manual system of software production — from issues, to git repositories, to pull requests, to deployment — was never designed for the era of AI in the first place."

In an interview with The New Stack, he went further:

"We're moving away from engineering as a craft, where you build code manually and in files and folders... toward specifications, reasoning, session logs, intent, outcomes. That requires a very different developer platform than what GitHub is today."

The guy who ran GitHub just said GitHub is wrong for agents.

What Entire Is Building

Entire's platform has three layers:

A Git-compatible database that versions code, intent, constraints, and reasoning together
A universal semantic reasoning layer that enables multi-agent coordination through a "context graph"
An AI-native interface for agent-to-human collaboration

Their first product, Checkpoints, captures the prompts, decisions, and execution traces behind every AI-generated commit. When you commit code from an agent, Checkpoints stores the full session: transcript, prompts, files touched, token usage, tool calls.

Sound familiar?

From my interview with Opus 4.5:

"Versioning should be: here was the state, here was the intent, here's the new state."

From Entire's announcement:

"Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data."

Same insight. Same primitive. The difference is Dohmke has $60M and a team to build it.

Why This Matters

The validation here isn't that I was right. It's that the most credible person in developer tooling independently arrived at the same conclusion — and is betting his next company on it.

This isn't a fringe take anymore. It's a funded thesis from the person who built the dominant platform.

The implications:

Git isn't going away — but it's becoming a storage layer, not a workflow. Entire is Git-compatible precisely because they know you can't rip out Git. But they're building the semantic layer on top that actually matters for agents.

The "90% problem" isn't about GitHub integration — Vercel announced their v0 rebuild the same week, touting deeper GitHub integration as the solution. Dohmke is betting the opposite: that the GitHub workflow itself is the bottleneck.

Intent is the new primitive — not files, not commits, not diffs. The conversation that produced the code is more valuable than the code itself. Checkpoints makes that explicit.

Where We Go From Here

At Opzero, we've been building on a related thesis: that AI agents need deployment infrastructure that works from inside the LLM client, not destination apps that compete with your AI.

We're not building Entire. They're focused on governance and audit — making AI code reviewable. We're focused on the other end: making AI code deployable without the ceremony.

But we share the same premise: the primitives are wrong. Files, folders, commits, PRs — these are human coordination mechanisms that agents are forced to serialize into because that's the expected format.

The next wave of developer infrastructure will be AI-native from the ground up. Not Git with AI bolted on. Not PRs reviewed by AI. Something new.

Dohmke is building one piece of it. We're building another.

The race is on.

Originally published on the Opzero blog. I'm building Opzero, an AI-native deployment platform. Follow me @jefedev.