📚 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.

☕ 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.

Java on David Parry