Enterprise on David Parry

📚 Open Source Wrote the Textbooks AI Learned From

Fri, 28 Aug 2026 11:00:00 -0500

We owe the open source community more than we usually credit for how good AI has gotten at writing software.

Here’s a theory that matters more as we move from asking LLMs to generate snippets to asking agents to build real systems:

An LLM didn’t independently discover what good software architecture looks like. It learned patterns from an enormous body of code written, reviewed, refactored, tested, documented, and maintained by developers over decades. Which means the quality of those examples matters.

Better Code In, Better Code Out

Research backs this up. One study found that removing low-quality code from training data cut quality problems in the model’s output significantly, without hurting functional correctness. Better code in, better code out.

That makes me wonder whether mature enterprise ecosystems have an underappreciated advantage in the agentic era.

Java’s Quiet Advantage

Take Java. Decades of professionally maintained open source projects have reinforced patterns around interfaces, dependency injection, domain boundaries, testing, error handling, package structure, API design, and backwards compatibility. The language then adds another layer of constraint through static typing and compilation.

Those constraints matter to AI too. Type-constrained decoding has been shown to cut compilation errors by more than half. Giving coding agents compiler feedback has produced similarly dramatic jumps in how often they generate valid code.

Not Java Versus Python

This isn’t “Java good, Python bad.” Python is one of the richest languages in current training data and performs extremely well on code-generation benchmarks.

My hypothesis is narrower: the more a language and its ecosystem encode decades of professional engineering constraints, conventions, and high-quality examples, the more structure an LLM has to imitate — and the more we can mechanically verify what it produces.

That starts to matter a lot more once the goal stops being “generate a function that passes a test” and becomes “build software another team can safely operate, modify, and maintain for the next twenty years.”

They Wrote the Textbooks

Which means every developer who spent years maintaining Apache projects, Spring libraries, compilers, frameworks, and testing tools contributed something bigger than they probably realized. They didn’t just build software for us. They helped write the textbooks our machines learned from.

So next time you’re working in a scripting language that never had to earn its keep in the enterprise — never got dragged through code review, backwards-compatibility guarantees, and a decade of production incidents — and you’re wondering why your agent keeps producing code nobody can maintain, that might be your answer. Try one of the languages the open source community spent decades hardening for exactly that job.

And thank your contributors while you’re at it.

👑 Data Is King. AI Just Removed the Middleman.

Tue, 18 Aug 2026 08:00:00 -0500

For years we have said data is king, without fully appreciating what that meant.

Data by itself was hard to use. Engineers had to understand it, write queries, encode business logic, build APIs and interfaces, then deploy and maintain the result. The application sat in the middle as interpreter. There was significant machinery between having data and getting value from it.

AI is collapsing that machinery.

Instead of developers anticipating every question and encoding every interaction, we can describe what we want, provide context, iterate, and spend tokens. The cost of turning data into useful information is falling, and strategic value is moving with it.

The data itself becomes king.

Origin Is a Signal

That is why Cursor’s Origin announcement caught my attention.

At first glance it looks like another GitHub, GitLab, or Bitbucket. That misses the point.

Cursor is an AI development company recognizing that its most important input is the code itself, plus the history, structure, reviews, decisions, tests, and context around it. If that intelligence depends on another company permanently providing access, an important part of your future belongs to somebody else. APIs, pricing, permissions, and terms can change. The provider can ship a competing product.

I have lived through that.

When Your Platform Becomes Your Competitor

Years ago I worked at a startup whose product depended on Facebook’s platform and APIs. That access made the business possible. Then Facebook changed the rules and built overlapping functionality of its own. The company providing the infrastructure became the competitor.

We did not control the platform, or our ability to reach the data the product depended on. When those conditions changed, so did the viability of the business.

That experience permanently changed how I think about platform dependencies. There is an enormous difference between having access to data and controlling your ability to access that data.

Reimagining the Software Development Lifecycle

By moving closer to the repository, Cursor is not merely getting better access to code. It can rethink the entire software development lifecycle around AI.

Today we insert AI into a lifecycle designed decades ago: source control, issues, pull requests, review, testing, security, CI/CD, and deployment. If the company building the AI environment also controls where the source and its context live, the repository can become persistent context for requirements, implementation, testing, review, security, deployment, and maintenance.

That is bigger than a better editor. It is a chance to own the lifecycle from the moment an idea becomes a requirement through the life of the software.

Your Source Is Your Data

That makes ownership of source more important, not less.

A repository is not merely files. It is years of intellectual property and organizational knowledge. History, reviews, architectural decisions, tests, security findings, and increasingly AI-generated context may become as valuable as the code itself.

I want companies building incredible applications around that information: better coding, review, security analysis, agents, and ways to modernize software. The distinction that matters is between applications operating on my data and applications controlling my data.

The enterprise should own its source and decide which systems operate against it. Ownership does not mean hosting every byte. It means control and portability. If another company can restrict your ability to access, move, interpret, or build upon your information, how much of it do you practically control?

This matters more as AI systems accumulate context around source. An organization can legally own its code while years of decisions, relationships, agent context, and development knowledge sit trapped in a proprietary platform. Legal ownership and practical ownership are not the same thing.

Follow the Data

I expect we will see much more of this. AI companies will move toward the data. Enterprises will need to be deliberate about portability and control.

The model I want is straightforward:

Companies own their data. Applications compete for the privilege of creating value from it.

AI makes applications easier to build, interfaces easier to replace, and information easier to consume. That does not make data less valuable. It makes it more valuable.

Data was always king. AI is simply making that impossible to ignore.

🔍 MCP: Enterprise Trust Through Traceability

Wed, 22 Jul 2026 09:30:00 -0500

The headline everyone pulled out of the Model Context Protocol (MCP) 2026-07-28 Release Candidate is that MCP is going stateless. Fair enough — it’s a genuine architectural improvement. Stateless protocols scale horizontally without sticky sessions, they cut operational complexity, and they make the infrastructure easier to deploy and reason about.

But I don’t think statelessness is the change that will matter most for enterprise adoption. I think traceability is.

When I gave a conference talk on building MCP servers earlier this year, the hallway questions afterward were rarely about what a server could do. They were about what it takes to run one: how the traffic shows up in gateway logs, what a trace looks like when a tool call fails, whether any of it can be audited later. So when the release candidate landed, I read it with those questions in mind.

Two changes stood out to me, and they work as a pair.

The first is SEP-2243 , which makes two headers, Mcp-Method and Mcp-Name, required on the Streamable HTTP transport. The spec is clear about their job: they exist so load balancers, gateways, and rate limiters can route on the operation without inspecting the JSON-RPC body. What interests me is the side effect. Every layer of the stack now gets a piece of standardized, protocol-level metadata — and standardized metadata is exactly the raw material enterprise observability and audit tooling is built on.

The second is SEP-414 , which locks the W3C Trace Context keys — traceparent, tracestate, and baggage — into the spec as reserved keys inside params._meta of every JSON-RPC request. Note where they live: in the message, not in HTTP headers. That’s deliberate. MCP is transport-agnostic and stdio has no headers, and a single Streamable HTTP connection can multiplex many JSON-RPC messages, so trace context has to belong to the individual request rather than the connection. A trace that starts in the host application can now follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and land in an OpenTelemetry-compatible backend as one span tree:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"
    }
  }
}

Several SDKs were already doing this — the release candidate fixes the key names so traces correlate across implementations instead of by convention. And in the same release, MCP’s own logging capability is deprecated, with OpenTelemetry named as the path for structured observability. Read those together and the direction is unambiguous: the protocol didn’t invent its own tracing story, it adopted the one enterprises already run.

That matters because enterprises are not building greenfield. They already have API gateways, OpenTelemetry, centralized logging, SIEM platforms, operational dashboards, and distributed tracing — and years of trust invested in all of it. A new protocol gets adopted when it slots into that existing machinery, not when it asks to be operated as a special case beside it. Routing headers at the transport layer, W3C Trace Context in the message — small design decisions with a large consequence, because together they mean MCP can be operated alongside everything else instead of babysat beside it.

What Enterprise Traceability Looks Like

The important property is that the new metadata enriches an existing trace without changing how distributed tracing works.

                    End User
                       │
                       ▼
                  API Gateway ────────────────┐
                       │                      │
                       ▼                      │
            Spring Boot / Spring AI           │
                       │                      │
                       ▼                      ▼
                  MCP Client         Logs · Metrics · SIEM
                       │                      ▲
    Mcp-Method         │                      │
    Mcp-Name    ──────►│ ─────────────────────┤
    (HTTP headers)     │                      │
                       │                      │
    traceparent        │                      │
    tracestate  ──────►│                      │
    (in _meta)         │                      │
                       ▼                      │
                  MCP Server ─────────────────┤
                       │                      │
                       ▼                      │
                      Tool ───────────────────┘

  W3C Trace Context propagates through every hop above — over HTTP
  headers on ordinary hops, inside _meta on the MCP hop. The routing
  headers add protocol-specific metadata to that same trace.

The distributed trace flows exactly as it does today. The routing headers give the infrastructure something to key on, and the _meta trace keys keep the MCP hop stitched into the trace you’re already collecting.

The Questions a Platform Team Asks First

Enterprise engineering organizations rarely get stuck because they can’t scale a service. They get stuck because they can’t answer questions after the fact:

Which MCP method executed, on which server, running which tool?
Which distributed trace contains this interaction, and how does it line up with the gateway logs?
Which agent initiated the request, and why did it fail?
Can we reproduce it — and can we audit it six months from now?

These aren’t exotic questions. They’re the ones a platform team asks before it agrees to support new infrastructure in production, and standardized protocol metadata is what makes them answerable. With Mcp-Method and Mcp-Name riding alongside the trace context, requests correlate across services and gateways without custom parsing, dashboards and rate limits key off the operation instead of the payload, and the telemetry looks the same across different MCP implementations. That’s the difference between something a platform team can confidently run in production and something that stays a proof of concept.

Fan-Out Is Where This Gets Expensive

The stakes go up as organizations move toward agentic software. A single user request can fan out across multiple agents, several MCP servers, and dozens of tool invocations before anything comes back. Without standardized metadata, reconstructing what actually happened in that fan-out is slow and often guesswork.

With the routing headers and trace-context keys in place, each MCP interaction correlates cleanly with the telemetry you already collect, and the whole system gets easier to operate and troubleshoot. This is the same argument I keep coming back to: agentic systems only become enterprise systems when they’re as observable, governable, and auditable as every other critical application in the estate. This release moves MCP another step toward that bar.

More Than Stateless

Statelessness earns its headlines. Simpler deployments, better scalability, and lower operational complexity are real wins, and the changelog is worth reading in full. But the larger enterprise story is the standardized metadata that integrates naturally with the observability and tracing ecosystems organizations already trust.

Platform teams want a protocol that fits the infrastructure they already run, and the technologies that win in the enterprise are rarely the ones with the longest feature lists.

The claim I’ll defend is narrower than “MCP is enterprise-ready”: two required routing headers and three reserved trace-context keys quietly gave every gateway, trace, and audit log a common vocabulary for MCP traffic. In my experience, that’s the kind of unglamorous change that decides whether a protocol makes it out of the proof-of-concept stage.

☕ Java at Thirty: Still One of the Strongest Bets in the Enterprise

Sat, 18 Jul 2026 11:00:00 -0500

Three decades after its release, Java is still solving the problems that matter most to enterprise software. That staying power is easy to dismiss as inertia. I don’t think it is. I think it’s the predictable result of a platform that optimized for the things large organizations actually care about — and kept investing in them long after the hype cycle moved on.

Let me be careful about the claim I’m making, though.

The honest version of the claim

I’m not going to tell you Java is the optimal language. That’s an opinion dressed up as a fact, and it falls apart the moment you change the context — Java is not my first reach for a data-science notebook, a systems kernel, or a quick shell script.

Here’s the claim I’ll actually defend: Java remains one of the strongest choices for enterprise software where long-term maintainability, stability, and operational reliability are the dominant concerns. That’s a narrower statement, and it’s a stronger one, because it names the conditions under which it’s true.

For most organizations, success is rarely about using the newest language. It’s about delivering reliable systems, controlling operational risk, hiring engineers at scale, and maintaining software for a decade or more. Judge Java against those goals and its longevity stops looking like nostalgia and starts looking like fit.

Backward compatibility is a feature, not a limitation

The thing developers complain about — Java’s conservatism — is exactly what enterprises are buying.

Code written years ago still compiles and runs. Upgrades are usually boring, and boring is the point. When a platform breaks compatibility casually, every upgrade becomes a migration project, and migration projects are where budgets and timelines go to die. Java’s discipline here means a large codebase can move forward without being rewritten, and that compounds over the lifespan of a system.

Predictable releases you can plan around

Since the six-month release cadence and the Long-Term Support (LTS) model, Java gives organizations something they can actually build a roadmap on. LTS releases give you a stable target with years of support; the interim releases let the language keep evolving without forcing everyone onto the treadmill. You choose your pace. For a business planning multi-year investments, predictability like that is worth more than raw novelty.

The platform is still being invested in

Java isn’t coasting. Recent years have brought genuinely significant work to the platform — virtual threads reshaping how the JVM handles concurrency at scale, ongoing improvements to startup time and memory footprint, pattern matching and records modernizing the language itself, and continued GC advances. This is a thirty-year-old platform still receiving serious, well-funded engineering. That matters when you’re betting a decade of software on it.

A mature ecosystem and a deep talent pool

Two of the most underrated enterprise concerns are “what do I build on?” and “who will maintain it?”

On the first, the JVM ecosystem is vast and battle-tested — Spring and Spring Boot alone cover an enormous surface of what enterprises need, with libraries, tooling, observability, and integration patterns refined over many years of production use.

On the second, the Java talent pool is one of the largest in the industry. You can hire for it, you can staff teams at scale, and you can find engineers who’ve operated Java systems in production for years. That’s not a glamorous advantage, but it’s a decisive one when you’re maintaining critical systems over a long horizon.

Operational reliability is where it earns its keep

None of the above would matter if the runtime fell over under load. It doesn’t. The JVM’s observability, profiling, and tuning story is deep, and the operational patterns for running Java in production are extremely well understood. When something goes wrong at 2 a.m., “well understood” is exactly the property you want.

Where Java isn’t the answer

Being honest about the boundaries is what makes the rest credible. If your problem is a small script, a latency-critical systems component, data science and ML research, or a lean startup optimizing for the fastest possible time-to-first-feature, Java is often not the best tool — and you should reach for something that fits. The claim is about a context, not a coronation.

Why this is on my mind

I spend most of my time now building agentic systems on the JVM, and this is precisely why. The interesting, fast-moving part — the reasoning, the model calls, the orchestration — sits on top of a platform I can trust to still be maintainable, staffable, and operable years from now. New capability on a stable foundation is a good trade. It lets me chase what’s genuinely new without gambling the boring, load-bearing parts of the system.

The takeaway

Thirty years in, Java’s relevance isn’t an accident and it isn’t sentiment. It’s the payoff of a platform that consistently optimized for maintainability, stability, backward compatibility, predictable evolution, a deep ecosystem, and a large talent pool — the exact concerns that dominate enterprise software.

That doesn’t make it the best language for everything. It makes it one of the strongest bets you can place when you need systems to run, and keep running, for a very long time.