If you haven’t listened to Kelsey Hightower’s recent interview with JetBrains, stop what you’re doing and queue it up. This is one of those conversations that recalibrates how you think about the industry. Not many speakers deliver that particular buzz where you find yourself nodding along, pausing to scribble notes, and occasionally saying “yes, exactly” to your screen. This was as close as I’ve come to that feeling since discovering “The Heretic of Redmond”.

What makes Hightower’s perspective so valuable is his refusal to chase hype cycles. While the rest of the industry pivots breathlessly from one paradigm to the next, he keeps returning to first principles: determinism, contracts, and the uncomfortable truth that most of our problems are human ones wearing technical disguises.

I took extensive notes. Here’s what stood out:

DevOps: A Movement That Lost Its Way

Hightower’s critique of DevOps is sharp but fair. The movement’s fatal flaw wasn’t its ideas but its lack of prescription. It offered a philosophy without a curriculum, and organisations responded predictably. They relabelled system administrators as “DevOps engineers” without changing behaviours, creating what Hightower calls “20 years of one year experience.” Same job, same patterns, shinier title.

The original promise was that specialisation would become a starting point rather than a destination. Developers would learn to write better logs. Sysadmins would understand the JVM. Everyone would expand their capabilities in service of the whole system. Instead, most organisations cargo culted the terminology while preserving their silos.

This matters because we’re watching the same pattern repeat with AI. New labels, same organisational dysfunction, and a vague hope that technology will solve what is fundamentally a people problem.

Platform Engineering: Products, Not Pipelines

The shift from DevOps to platform engineering represents something genuinely different, at least when done properly. Hightower frames it as product thinking applied to internal tooling. Instead of teaching everyone Terraform and Kubernetes, you ask yourself: “What questions would I need answered if I had to do all deployments myself?”

That question produces an API. And that API, Hightower argues, is surprisingly simple: version, memory, CPU, disk, region. That’s the contract. Everything else, including Kubernetes, Terraform, and your cloud provider of choice, is implementation detail hidden behind the abstraction.

This is the distinction between building products and automating existing workflows. The former creates leverage. The latter just makes your current mess execute faster.

Cloud Repatriation and the Myth of Lift and Shift

Hightower’s comments on cloud repatriation will resonate with anyone who’s watched organisations burn through budgets without changing their operational models. His summary is brutal: “You can’t rub cloud on your mess.”

The 37signals departure from major cloud providers illustrates his point. Talented teams can make any platform work. When your operational model remains unchanged, the two to three times cloud premium becomes a pure tax on inertia. You’re paying for flexibility you never use.

What makes repatriation viable now, where it wasn’t five years ago, is open standards. Kubernetes and Prometheus finally provide cloud like APIs for on premises infrastructure. The abstraction layer exists. Whether you run it yourself or pay someone else to becomes a genuine business decision rather than a technical constraint.

Serverless: A Framework, Not a Philosophy

The serverless conversation has matured, and Hightower captures where we’ve landed. Serverless is a framework, comparable to Ruby on Rails. Buy in completely and you benefit from its opinions. Try to break out and you’re fighting the abstraction at every turn.

The container image won. Lambda, Heroku, virtual machines, Kubernetes: same image, different runtime contract. That standardisation is the real victory, not any particular execution model.

Where serverless went wrong was scope creep. Functions that started as elegant event handlers accumulated databases, dependencies, and business logic until they became function main with worse visibility than the monoliths they replaced. Same complexity, less observability. Not the trade off anyone signed up for.

Kubernetes: Boring by Design

Here’s a statement that will upset the Kubernetes ecosystem: for stateless web applications, Kubernetes has been boring for six or seven years. The excitement, and the war stories, come from attempting things it wasn’t designed for. Databases. Stateful workloads. Edge cases that push against the abstraction.

Hightower’s framing is perfect: “Planes are only exciting when they don’t do what we expect.” If you’re thinking about your infrastructure, something has gone wrong. The goal is invisibility.

What persists beyond any particular tool is the concept of workload APIs. Typed definitions for what you’re running, how it should behave, and what resources it needs. Whether Kubernetes survives thirty years matters less than whether that pattern endures. It will.

AI in Infrastructure: Principled Scepticism

This is where Hightower’s perspective becomes most valuable, because he’s not dismissing AI from ignorance. He’s interrogating it from decades of operational experience.

His challenge to the current hype cycle is worth quoting directly:

“My whole career, the whole point of our profession was to take this non-deterministic thing and make it predictable. When it’s not predictable, we call those security incidents or bugs.”

And later:

“Why predict when you can know?”

We write unit tests to ensure systems behave only as intended. We build monitoring to detect deviation from expected states. We create runbooks to eliminate human judgment from incident response. The entire discipline of site reliability engineering exists to remove non-determinism from production systems.

Now we’re introducing models that are definitionally non-deterministic into those same systems. The concepts being marketed as innovations, guardrails and alignment, are just new vocabulary for old requirements: deterministic, safe, repeatable, reliable. We’ve always wanted these things. We’re just being sold them again with different packaging.

That said, Hightower acknowledges genuine value in intent based interfaces. Large language models let people express what they want naturally: “deploy this application to this region with these resources.” That’s useful. But underneath the natural language, it’s still Terraform. Still the same kernel. Still the same logs. The abstraction layer has changed. The fundamentals haven’t.

His observation about prompt engineering is particularly sharp. When teams version control hundreds of markdown files containing prompts, when they write tests to validate prompt behaviour, when they establish review processes for prompt changes, they’ve created a programming language. Whether they admit it or not.

The MCP Silver Lining

This section caught my attention given the work I’ve been doing on agentic AI security.

Hightower offers a surprisingly positive take on the Model Context Protocol and adjacent AI tooling:

“The MCP hype has now inspired these traditional SaaS vendors to finally give us an API.”

The APIs and documentation we’ve demanded for years, ostensibly for human developers, are now appearing because machines need them. If AI accomplishes nothing else but leaves behind well documented APIs and proper contracts, that’s a genuine win. This work was always required. We just didn’t have the leverage to demand it.

From a security perspective, this cuts both ways. Yes, we’re getting better APIs. But we’re also getting APIs designed for machine consumption with authentication models, permission scopes, and trust boundaries that weren’t built with autonomous agents in mind. The OWASP Top 10 for Agentic Applications exists precisely because this new integration surface creates novel attack vectors. Tool poisoning, excessive agency, and insecure output handling don’t disappear just because the APIs are well documented.

Hightower’s optimism is warranted, but it needs tempering. The contracts are appearing. Whether they’re the right contracts for agentic systems is a different question entirely.

Senior Engineers, Junior Humans

Hightower’s most philosophical observation deserves its own section:

“I see a lot of people that are like senior engineers and junior humans.”

Technical excellence without interpersonal development creates brittle teams. Individual brilliance means nothing without teammates handling their responsibilities. You win together. You lose together.

His point about silos is counterintuitive but correct. Silos aren’t inherently bad. Airlines work because pilots fly planes and passengers don’t need to understand avionics. Clear contracts between specialists enable scale. The problem isn’t specialisation. It’s specialisation without contracts.

The advice on inspiration is practical: watch films, spend time with family, pursue interests outside work. Then return with fresh eyes. That inspiration flows into the project whether you intend it to or not. Human development requires the same intentionality as technical growth. Ask yourself the same questions you’d ask about any system: what is this, how does it work, why does it exist? Apply them to your own behaviours and relationships.

Tool Discipline

You can build a company worth billions with remarkably little: one Linux server, a Golang monolith, one JavaScript framework. GitHub did it. Snapchat went public on App Engine alone. Choice doesn’t mandate adoption. Just because tools exist doesn’t mean you need them all.

Hightower’s analogy to professional tradespeople is apt. A carpenter reviews their tools, checks for damage, verifies they know how to use each one properly. Most developers don’t audit their dependencies or explore their IDE’s capabilities. The toolbox accumulates without curation.

The Learning Framework

Hightower’s pattern for approaching any new technology is worth adopting:

1. What is it? Definition and capabilities.

2. How does it work? Hands on experimentation.

3. Why does it exist? History, decisions, trade offs.

That third question is where leverage lives. Understanding why Guido van Rossum made specific decisions about Python’s syntax helps you evaluate any new language. The “why” absorbs decades of others’ experience in months. It’s the closest thing to a shortcut that actually works.

What To Take From This

Hightower’s interview is a reminder that our industry’s problems are more cyclical than we’d like to admit. DevOps promised transformation and delivered relabelling. Cloud promised efficiency and enabled expensive stagnation. AI promises intelligence and delivers non-determinism in systems we spent decades making predictable.

None of this means the tools are worthless. It means the tools aren’t the point. Contracts are the point. Clear boundaries between specialists are the point. Human development alongside technical growth is the point.

The next time someone pitches you on a paradigm shift, ask Hightower’s questions: What is it? How does it work? Why does it exist? The answers will tell you whether you’re looking at genuine progress or familiar problems wearing new labels.

References

1. Kelsey Hightower Interview with JetBrains - https://youtu.be/HdUbTyvrfKo