On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 8.0.0 has been released and is now available from Maven Central 🎉.

This marks the eighth major release of the Fabric8 Kubernetes Client. As we anticipated in the 7.9 announcement, it raises the Java baseline, moves the serialization stack to Jackson 3, and switches the default HTTP client to Vert.x 5. To assist you with the transition, we've prepared a migration guide to help you update your code to this new version.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Java 17 as the minimum supported version
• Jackson 3
• Vert.x 5 as the default HttpClient, Jetty 12, and proxy fixes
• CRD Generator: v1 removed and schemas that match what the client writes
• Typed DSL and model updates
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Be sure to check out the migration guide for a smooth upgrade.

Java 17 as the minimum supported version

Starting with this release, the Fabric8 Kubernetes Client no longer supports Java 11. The minimum supported version is now Java 17, the oldest release that still receives broad support across vendors.

The new baseline applies to the build too, not only to the runtime. The Maven plugins, the Gradle plugin, and the annotation processor now require a Java 17+ JVM to run your build, and the OSGi bundles declare osgi.ee=JavaSE 17. If you deploy on Karaf, note that the kubernetes-karaf feature repository no longer defines its own scr feature and relies on the one provided by the Karaf distribution instead.

Jackson 3

The client has moved from Jackson 2.x to Jackson 3 (3.2.1), which means the new tools.jackson Maven coordinates and Java packages. If your code only deals with the Kubernetes model and the client DSL, you shouldn't notice the change. The default serialization keeps the Jackson 2 behavior for your custom types, so the resources you send to the cluster look the same as they did in 7.x.

If your code uses Jackson directly (custom serializers and deserializers, annotations on your custom resource classes, or mappers you build yourself), you'll need to update it. Jackson 3 relocates several annotations and renames JsonSerializer and JsonDeserializer to ValueSerializer and ValueDeserializer. For mappers you build yourself, the migration guide explains how to keep the 7.x wire format for types such as Year, Month, java.sql.Date, and Locale with the new Jackson2JdkTypesModule.

Please, check the Jackson 3 section of the migration guide for the details.

Vert.x 5 as the default HttpClient, Jetty 12, and proxy fixes

The kubernetes-client and openshift-client artifacts now default to the Vert.x 5 HttpClient implementation (kubernetes-httpclient-vertx-5) instead of the Vert.x 4 one. For most users, this change should be seamless. If you need to stay on Vert.x 4 for now, you can exclude kubernetes-httpclient-vertx-5, add kubernetes-httpclient-vertx, and pin the Vert.x artifacts to 4.x, as described in the migration guide.

The optional kubernetes-httpclient-jetty module has moved from Jetty 11 to Jetty 12.1. Since Jetty 12 can't coexist with earlier Jetty versions on the classpath, check the Jetty 12 section if your application depends on Jetty too.

This release also brings a round of fixes across the HttpClient implementations:

• Proxy credentials are sent only to the proxy. In several combinations of HttpClient implementation and request type (HTTPS, WebSocket, or SOCKS), they could travel through the proxy tunnel and reach the API server.
• Proxy passwords containing a colon, proxy URLs with a user and no password, and SOCKS5 proxy credentials are now handled correctly.
• The Vert.x, Jetty, and JDK clients now send a WebSocket ping every Config#websocketPingInterval (30 seconds by default), like OkHttp already did, so load balancers that close idle connections no longer drop quiet watches.
• Requests no longer hang when a retry action, a retry decision, or the response cleanup throws an exception.

CRD Generator: v1 removed and schemas that match what the client writes

The CRD Generator v1 (crd-generator-api and crd-generator-apt), deprecated since 7.0, has been removed. If you are still using it, migrate to the CRD Generator v2 with the Maven plugin, the CLI tool, or the Gradle build script recipe. The CRD Generator v2 migration guide walks you through the process. Beware: dropping the dependency without adding a replacement fails silently, since an absent annotation processor produces no compiler diagnostic.

The generated schemas have also been aligned with what the client actually writes, so the API server no longer prunes or rejects your data:

• Object, raw Map, List<Object>, raw collection, @JsonUnwrapped, and polymorphic properties keep their content.
• Date and time types only declare a format their values match.
• byte[], ByteBuffer, char[], Year, and java.sql.Date get schemas that match their serialized form.
• int/Integer and long/Long properties get format: int32 and format: int64, like controller-gen.

Since the generated CRDs change, review them before applying them to your clusters. The Generated CRDs section of the migration guide lists what's different.

Typed DSL and model updates

The client DSL now provides typed entry points for the resources added in Kubernetes 1.37, such as certificates().v1().podCertificateRequests(), dynamicResourceAllocation().v1().deviceTaintRules(), storageMigration().v1().storageVersionMigrations(), and the scheduling().v1beta1() podGroups() and workloads().

The unversioned runtimeClasses() and network().ingresses() entry points now use the v1 models instead of the v1beta1 ones that Kubernetes no longer serves.

The shard selector support introduced in 7.8 gains a typed ShardSelector, so you no longer need to write the shardRange(...) CEL expression and its hexadecimal bounds by hand:

client.pods()
  .withShardSelector(ShardSelector.builder().addShard(0, 4).addShard(2, 4).build())
  .list();

As a consequence, a literal withShardSelector(null) no longer compiles; cast it to (String) null instead.

Finally, the bundled extension models follow their upstream projects, and some of these upgrades bring breaking changes of their own. If you use the OpenShift, Open Cluster Management, Tekton, or Knative models, check the breaking changes in the release page.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>8.0.0</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:8.0.0"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.9.0 has been released and is now available from Maven Central 🎉.

This marks the ninth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

Looking ahead to 8.0

With 7.x settling into maintenance, we're shifting our focus to the next major version, Fabric8 Kubernetes Client 8.0. The three headline changes we're planning are:

• A new JDK baseline: the minimum required version moves up to Java 17, so Java 11 will no longer be supported.
• A migration to Jackson 3.x, replacing the current Jackson 2.x serialization stack.
• A new default HTTP client: the transport switches from Vert.x 4 to Vert.x 5.

We'll share more details as 8.0 takes shape, so keep an eye out and start planning your upgrade path if any of these changes affect your setup.

What's new?

Without further ado, let's have a look at the most significant updates:

• Kubernetes 1.37 support (Garhwal)
• Gateway API 1.6 with TCPRoute and UDPRoute
• WebSocket reliability on the Vert.x 5 and Jetty HTTP clients
• Java generator hardened against code injection
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Kubernetes 1.37 support (Garhwal)

This release adds support for Kubernetes v1.37.0 (Garhwal), keeping the client's model in sync with the latest Kubernetes API.

Along with the new APIs, several API versions that were removed upstream in Kubernetes v1.37.0 are no longer available in the client:

• certificates.k8s.io/v1alpha1/ClusterTrustBundle; use certificates.k8s.io/v1 or v1beta1
• networking.k8s.io/v1beta1/IPAddress and ServiceCIDR; use networking.k8s.io/v1
• storage.k8s.io/v1beta1/VolumeAttributesClass; use storage.k8s.io/v1
• scheduling.k8s.io/v1alpha2 (the entire API version, 28 types); use v1alpha3 or v1beta1

The canonical VolumeMount constructor signature has also changed to accommodate the new bindMountOptions field. If you build your resources with the fluent builders (new VolumeMountBuilder()...), you are unaffected; only direct calls to the canonical constructor need updating.

Gateway API 1.6 with TCPRoute and UDPRoute

The bundled Gateway API model has been updated from 1.5.1 to 1.6.1. As a result, v1.TCPRoute and v1.UDPRoute are now available, both having graduated from v1alpha2 upstream in Gateway API v1.6.0. The v1alpha2 types remain available, but upstream has deprecated them and plans to remove them in a future release, so new code should prefer the v1 types.

Note that v1.SessionPersistence no longer exposes idleTimeout, which was removed upstream in Gateway API v1.6.0. There is no runtime data loss: the class keeps its additionalProperties, so any YAML or JSON that still carries idleTimeout continues to deserialize and re-serialize intact.

WebSocket reliability on the Vert.x 5 and Jetty HTTP clients

A couple of important fixes land for WebSocket operations (exec, attach, portForward, and WebSocket-backed watches) on the optional kubernetes-httpclient-vertx-5 and kubernetes-httpclient-jetty modules.

On the Vert.x 5 client, derived clients (those produced internally, for example, when adapting to an OpenShiftClient or refreshing an OAuth token) were creating a brand-new WebSocket client with no configuration, discarding the cluster trust material and the configured frame and message size limits. Derived clients now reuse the original client's WebSocket transport, so TLS is verified against the configured cluster CA and the limits are honored.

Both the Vert.x 5 and Jetty clients now also route WebSocket connections through the configured proxy, instead of connecting straight to the API server and bypassing a mandated egress proxy. On the Vert.x 5 client, the configured connect timeout is now applied to WebSocket connections as well.

Note that the default bundled kubernetes-httpclient-vertx (Vert.x 4), OkHttp, and JDK modules were never affected, since they serve WebSockets from the same client they use for regular HTTP.

Java generator hardened against code injection

The java-generator now emits all schema-controlled values (enum values, the CRD group/version/names, property names, descriptions, and defaults) as fully escaped Java string literals, so a malicious CRD schema can no longer inject executable code into the generated sources. As a defense-in-depth measure, each generated class is also re-parsed and structurally validated before it is written, aborting generation on any residual mismatch.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.9.0</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.9.0"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.20.0 has been released and is now available from Maven Central 🎉.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Jetty 12 is now the default web application server
• Explicit JDK selection for Java generators
• Fine-grained image pull policy control
• Compatibility with Maven 3.9.13 and newer
• StatefulSet and DaemonSet redeployment fixes
• Spring Boot DevTools now wires up in the Gradle k8sWatch/ocWatch tasks
• 🐛 Many other bug-fixes and minor improvements

Jetty 12 is now the default web application server

Web application (WAR) projects now build on top of the jkube-jetty12 base image by default, replacing the older jkube-jetty9 image. Jetty 12 brings support for the Jakarta EE namespaces (jakarta.*) and keeps your containers running on an actively maintained server.

The legacy jkube-jetty9 image is now deprecated. If your project is a legacy Java EE web application that still relies on the javax.* namespaces, you can opt back in to Jetty 9 by setting the jkube.generator.webapp.server=jetty9 property. Bear in mind this switch is potentially breaking for those legacy applications, so make sure to test your deployment after upgrading.

On top of the new default, hot deployment now works with Jetty 12 when using k8s:watch/oc:watch in copy mode, so you can keep iterating on your web application without rebuilding the whole image.

Explicit JDK selection for Java generators

You can now explicitly select the JDK version used by the base image for Java generators through the new jkube.java.version property. Previously the JDK was inferred automatically, which sometimes led to a base image that didn't match the version you were targeting. With this property you can pin the exact JDK your workload needs.

Fine-grained image pull policy control

Image pull policy handling is now more consistent and flexible:

• A per-image imagePullPolicy set in the build configuration now correctly overrides the global pull policy, so you can fine-tune the behavior on an image-by-image basis.
• The Buildpacks build service now honors the global imagePullPolicy when no per-image policy is set, aligning its behavior with the other build strategies.

Compatibility with Maven 3.9.13 and newer

The Kubernetes Maven Plugin is now compatible with the SecDispatcher changes introduced in Maven 3.9.13. Registry and Helm passwords are decrypted using Maven's SettingsDecrypter, which is the standard, supported mechanism for handling encrypted credentials.

As a result, the <helm><security> configuration and the jkube.helm.security property are now deprecated in favor of the standard -Dsettings.security setting.

StatefulSet and DaemonSet redeployment fixes

Generated StatefulSet and DaemonSet resources no longer include the version label in their selector.matchLabels. Because the selector is an immutable field, keeping a version label there prevented these workloads from being redeployed after a version bump. With this fix, you can bump your application version and redeploy StatefulSet and DaemonSet workloads without running into update errors.

Using this release

If your project is based on Maven, you just need to add the Kubernetes Maven plugin or the OpenShift Maven plugin to your plugin dependencies:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <version>1.20.0</version>
</plugin>

If your project is based on Gradle, you just need to add the Kubernetes Gradle plugin or the OpenShift Gradle plugin to your plugin dependencies:

plugins {
  id 'org.eclipse.jkube.kubernetes' version '1.20.0'
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "first-timers-only" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source and the Eclipse organization.

If you are a more experienced developer or have already contributed to JKube, check the "help wanted" tag.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Feedback is the only way to improve.

Project Page | GitHub | Issues | Gitter | Mailing list | Stack Overflow

Introduction

A few months ago I wrote about the missing levels between juggling coding agents and building your own orchestrator. That post ended on an uncomfortable note: at some point the tooling runs out, and you are told to build the orchestrator yourself.

This post is about why. Why, with dozens of well-funded AI coding tools shipping every month, the one that would coordinate your work across every project, machine, and inbox is the one you still assemble by hand.

The reason has little to do with the market lagging. Almost every tool is built around something other than you: the project, or the session, and rarely the person.

Autonomous vs assistive AI coding agents: the axis everyone measures

Almost every framework for AI coding tools measures the same thing: how autonomous is it?

Steve Yegge's eight levels run from no AI at all to a custom orchestrator. Dan Shapiro's five go from spicy autocomplete to the Dark Factory. Sourcegraph and Swarmia each ship their own. Addy Osmani recently split the ladder into two axes. But both, as I will come back to, are still about autonomy.

I am not going to re-teach the ladder here. My previous post tried to fill in its missing rungs, and the ladder itself is real, useful, and thoroughly mapped. It answers one question well: how much can I trust the tool to do on its own?

That is not the only question worth asking.

The axis nobody names: a tool's center of gravity

Here is a second question the ladders never ask: what is the tool built around?

Not how autonomous it is, but what sits at the center: the thing every feature is quietly designed to serve. I think of it as a tool's center of gravity, and three answers keep showing up. Sorted that way, AI coding tools fall into three kinds: project-centric, agent-centric, and person-centric.

• Project-centric: the unit is the repository and the issue. You hand over a task and an agent works autonomously toward a pull request.
• Agent-centric: the unit is the session. You live inside one tool's cockpit and run your agents from there.
• Person-centric: the unit is you. The tool coordinates your work across the repositories, trackers, and machines your name touches.

Two clarifications first.

This is a different "agent-centric" than you may have met elsewhere. It is not Sonar's Agent-Centric Development Cycle, a code-quality governance loop, and it is not UX's user-centered design. Here it means one thing: the tool is built around the agent session as the place you live, and the cockpit is the product.

And these are centers of gravity, not boxes. Real tools straddle. GitHub's Copilot coding agent is a project-centric workhorse that also ships a personal dashboard; Cursor is an agent-centric cockpit that also runs background jobs. I am naming what each tool leans toward, not sorting them into sealed compartments. The mappings that follow are my own analytical lens, not how these vendors describe themselves.

One caveat on that word "missing": it is missing from how we usually talk about these tools, not from the market. Autonomy gets all the frameworks; center of gravity gets almost none. And the two are not the same measure in a different coat. A dependency-bump bot that opens one small, pre-approved kind of pull request is deeply project-centric and barely autonomous. Autonomy and center of gravity tend to travel together, but nothing forces them to. Set autonomy aside and sort tools by their center of gravity, and the space takes on a shape of its own: three worlds side by side, with one corner still conspicuously empty.

Project-centric: the repository is the unit

The most crowded, best-funded corner is project-centric.

The pattern is familiar: you describe a change as an issue, an agent picks it up in the cloud, and a pull request appears for you to review. Devin is the flagship. Cognition has marketed fleets of them migrating repositories in parallel, and in 2025 it bought the Windsurf IDE, one project-centric vendor absorbing an agent-centric one. Google's Jules, OpenAI's Codex cloud agent, and GitHub's Copilot coding agent all run the same play, with Factory's Droids and the open-source OpenHands rounding it out.

This is the vendor-built road to the top of the autonomy ladder, and it is genuinely good. For bounded, well-specified, high-volume, team-owned work, made of dependency bumps, CVE patches, and mechanical migrations, it is the right answer; a human in the loop is friction, not safety.

The momentum is real enough that I see it inside my own company. fullsend is a public design-doc exploration of fully autonomous engineering: triage, implement, review, and merge, with a human pulled in only for the risky changes. It is an effort from engineers I know at Red Hat, where I also work, an independent open-source exploration, not a Red Hat product or roadmap. I mention it because this direction is not a fringe bet; it is where serious people are pointing.

Some argue this is the only corner that will matter. OpenAI's Thibault Sottiaux calls scaffolding "coping, not scaling," and a lot of the money is behind it. It is a bet, though, not a settled result: across teams, the bottleneck has moved to verification, and context, coordination, and oversight still gate what raw autonomy delivers.

Agent-centric: the session is the unit

Start with what this corner gets right.

A single, opinionated cockpit is the best environment we have for focused work. Claude Code in a terminal, Cursor in an editor, Sourcegraph's Amp: deep in one hard change, living inside a single well-designed tool beats hopping between five. The local orchestrators built on top of this, like Conductor, Claude Squad, and Vibe Kanban, inherit the same virtue. Each agent gets its own git worktree, and you conduct them all from one place: the one machine they run on. The tell of the category is that coordination happens around the agent.

Cursor is multi-model (Claude, GPT, Gemini), so the lock-in was never really about the model. It was about the cockpit. The same gravity that makes a cockpit great also draws it toward a closed edge: the more a tool optimizes for the session you live in, the more it wants to be the only session you live in. Read one way, you can watch that edge harden. When the third-party client opencode tried to use Claude subscription credentials, it got back This credential is only authorized for use with Claude Code and cannot be used for other API requests. Anthropic had restricted those credentials to its own tool, pushing other clients toward a metered API key. Cognition buying Windsurf is the same physics at a larger scale.

None of this is villainy. It is what happens when the session is the center of gravity: the tool is the product, and the product wants you inside it.

Person-centric: you are the unit

This brings us to the empty corner. I should be upfront here: I build a tool that lives in this corner, so if the case only works because it flatters my own project, it does not work. I have tried to write the version that survives deleting it.

A person-centric AI coding tool takes you as the unit of coordination. Not this repository, not that session, but you, and the whole spread of work that carries your name: repositories across several orgs, issues in two trackers, a review waiting in Slack, agents on a laptop and a workstation. The center is the person, not the project or the platform. Acting on your behalf is a trait that follows from that, not the axis itself.

Two properties make it categorically different. It is cross-surface: it reaches past any single repo, IDE, or platform into your actual working day. And it is rooted in your environment: it coordinates whatever agents you run, Claude Code or anything else, wherever you run them, not only the ones a vendor hosts inside its walls. It is the corner the human-as-operator camp keeps pointing at, from Willison's "agentic engineering" to Swarmia's caution that higher autonomy is not always better, usually with no developer-grade tool to name.

So, to put the claim in a way you can push back on: person-centric coding tools are not unserved, but they are badly underserved. Consumer assistants already act on a person's behalf across their messaging apps, and "AI chief of staff" tools do it for knowledge work, but none of them touches code, repositories, or CI. The closest thing in our world is GitHub's Agent HQ, whose mission-control view already gathers agents from several vendors into one pane. But it orchestrates only the agents GitHub hosts, on GitHub's own surfaces. It does not reach the sessions you run on your own hardware, or the work that spills into your inbox and your other trackers. Others feel the same pull. Cursor gathers its own agents into one window, and a few small cross-brand tools route agent approvals to your phone; the first is a single vendor's garden, and the second is a thin slice of the job. As of July 2026 I still cannot find a professional-grade tool that is vendor-neutral, spans your projects and surfaces, keeps you as the operator, and coordinates the actual work rather than one seam of it. A few of the tools inching toward that corner are not mine, and I would genuinely like to be wrong here. If you know one that already qualifies, point me to it and I will add it.

That empty corner is the shape I am building toward with ai-beacon: the agents on all your machines in one web view you can reach from anywhere, Claude Code and opencode alike. It grew out of the coding-agent dashboard I wrote about earlier this year, and it is early and experimental. The category matters more than my attempt at it.

The plumbing for this corner is half-built. There is a standard for each seam: Model Context Protocol (MCP) between agents and tools, Agent Client Protocol (ACP) between editors and agents, A2A between agents, AG-UI between agents and interfaces. What none of them provides alone is the cross-context layer that would tie your work together above all of them. That layer is missing precisely because no vendor is incentivized to center it on you.

The person-centric approach has a real weakness of its own. It lives at the mercy of the very boundaries it crosses. A control layer that rides on top of every vendor inherits none of their guardrails: no CI, no review gates. And any vendor can starve it with a credential restriction, the closed edge from before. That is not a reason the category should not exist. It is the reason it is hard.

What is new here, and what isn't

Let me be careful about what I am and am not claiming, because the prior art deserves credit. The project-versus-agent distinction is not new; it relabels things people already say. OpenHands has written about the inner loop versus the outer loop, accelerating the individual versus handling whole tasks over Slack and Jira, which maps almost exactly onto agent-centric versus project-centric, though OpenHands straddles both. Osmani's two-axis model splits autonomy into agency and orchestration, but his second axis is how many agents you run, which is still a question about autonomy.

What is actually new is small but load-bearing. It is choosing center of gravity, what the tool is built around, as the axis, instead of the degree of autonomy, and then naming the person-centric category, at professional developer grade, as the one that is missing. Neither Osmani's orchestration axis nor OpenHands' outer loop leaves a seat for the person. That seat is the whole point.

How to choose between project-, agent-, and person-centric tools

None of this is a fight to the death. The future I expect is a composition, with a clear boundary between the parts: a control tower over a factory floor. The factory floor is project-centric: many autonomous agents turning well-specified issues into pull requests while you sleep. The control tower is person-centric: one person's single pane of glass over all of it, across projects, surfaces, and machines. They are not rivals; they are different altitudes of the same operation.

That leaves a decision rule I can use day to day.

• When the work is depth on a single change, reach for the cockpit (agent-centric).
• When it is a specced unit you can hand off and walk away from, reach for the factory (project-centric).
• When it spans projects, surfaces, or machines and needs your judgment routed across all of them, reach for the control tower (person-centric).

The uncomfortable part is that the third tool is the one the market is least likely to hand you. My previous post said you would probably have to build your own orchestrator. I now think the deeper reason is structural. Every vendor's center of gravity is the project or the platform, because that is where the business is. Almost none of it is you. AI coding tools differ less by how autonomous they are than by what they are built around, and the human is the one center nobody has quite built for yet.

If you are somewhere on this map, I would like to know which corner. I am collecting notes in the ai-beacon discussions, the same place as last time. Thanks, too, to my colleague Václav Vančura, whose UX thinking helped sharpen how I see all of this. The more corners we compare, the sharper the map gets.

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.8.0 has been released and is now available from Maven Central 🎉.

This marks the eighth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Shard selectors for list, watch and informers
• Opt-in TLS warm-up for the Vert.x HTTP client
• CRD generator: class-level descriptions via @JsonClassDescription
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Shard selectors for list, watch and informers

List and watch operations, including informers, now support shard selectors through the new withShardSelector method. This lets you partition a large set of resources across multiple consumers, so each instance only lists and watches the slice it is responsible for. It's a handy building block when you need to scale controllers or operators horizontally and distribute the watch load, instead of having every instance receive every event.

A shard selector is a CEL expression, typically a shardRange(...) over the resource UID, that you attach to any list, watch, inform or delete operation:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  // This instance only sees the first half of the UID space
  String shard = "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')";
  client.configMaps()
    .withShardSelector(shard)
    .inform(handler);
}

Note that this relies on the server-side sharded list and watch support, an alpha Kubernetes feature, so the corresponding feature gate must be enabled on your cluster. The initial support was rounded out with a few follow-ups to smooth out the rough edges.

Opt-in TLS warm-up for the Vert.x HTTP client

The Vert.x HTTP client factories (Vertx5HttpClientFactory and VertxHttpClientFactory) now expose a setTlsWarmup(TlsWarmup) method with three modes: OFF, CONTEXT (the default, with unchanged behaviour) and FULL.

When set to FULL, the client performs a synchronous, once-per-JVM, throwaway loopback TLS handshake off the event loop when it's built. This pays the one-time cost of JDK/Netty TLS class loading up front, so the first real connection no longer blocks the event loop on it. It's specifically aimed at users running on cold or hard CPU-throttled JVMs who were hitting first-connection stalls or timeouts.

You opt in by configuring the warm-up mode on the HTTP client factory and passing it to the builder:

Vertx5HttpClientFactory factory = new Vertx5HttpClientFactory();
factory.setTlsWarmup(TlsWarmup.FULL);
try (KubernetesClient client = new KubernetesClientBuilder()
    .withHttpClientFactory(factory)
    .build()) {
  // The first TLS connection no longer pays the class-loading cost on the event loop
}

The default behaviour (CONTEXT) is unchanged, so you only opt in if you need it.

CRD generator: class-level descriptions via @JsonClassDescription

The CRD generator now honors Jackson's @JsonClassDescription annotation, allowing you to add descriptions to whole classes in the generated CRD schema. This complements the existing field-level description support, so the documentation embedded in your CRDs can be more complete and closer to your source model.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.8.0</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.8.0"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.7.0 has been released and is now available from Maven Central 🎉.

This marks the seventh minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Kubernetes 1.36 support (Haru)
• Server-side content negotiation (Table and PartialObjectMetadata)
• API ergonomics: isSameResource, subresource() and addOwnerReference
• Reliability fixes in leader election, informers and exec WebSockets
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Kubernetes 1.36 support (Haru)

This release adds support for Kubernetes v1.36 (ハル / Haru), ensuring you have access to the latest API resources and CRDs. Several upstream dependencies have also been bumped, including k8s.io/apimachinery to 0.36.0, Istio client-go to 1.29.1, Knative to 0.49, Gateway API to 1.5.0 and the Prometheus Operator model to 0.91.0.

Note that the scheduling.k8s.io/v1alpha1 workload-scheduling model classes (Workload, WorkloadList, PodGroup, etc.) have been removed following the upstream KEP-5832 rearchitecture.

Server-side content negotiation (Table and PartialObjectMetadata)

The client now supports server-side content negotiation, allowing you to request Table and PartialObjectMetadata responses from the API server. This is the same mechanism kubectl get uses to render its tabular output, and PartialObjectMetadata is particularly useful when you need to list large numbers of resources but only care about their metadata, drastically reducing the payload size and parsing cost.

API ergonomics: isSameResource, subresource() and addOwnerReference

A few targeted API additions make day-to-day code a bit nicer to write:

• A new HasMetadata#isSameResource helper lets you test whether two HasMetadata instances point to the same logical cluster resource, with an optional strict mode that also requires matching kind and resourceVersion.
• The generic subresource() method has been expanded with broader support and enhanced documentation and examples, making it easier to interact with custom or less common subresources.
• addOwnerReference now has a variant that lets you set the controller and blockOwnerDeletion fields in a single call, which is handy when writing operators.
• A new ResourceEventHandler#onList method has been added (deprecating onNothing), giving informer consumers a more meaningful hook to react to the initial list event.

Reliability fixes in leader election, informers and exec WebSockets

This release includes a notable batch of stability fixes that are worth calling out:

• Leader election: fixed an improper callback timing that could lead to a dual-leader situation.
• Informers: SerialExecutor.execute() now returns immediately after shutdown, fixing a post-stop NPE race in SharedProcessor.distribute(...), and ephemeral index entries are now properly removed from informer caches.
• Exec WebSockets: handshake failures with a non-null upgrade response no longer throw IllegalStateException synchronously, exit codes are no longer overwritten by peer-close exceptions, and pending stdout/stderr writes are flushed before the exit signal is delivered.
• MockWebServer: shutdown() is now idempotent and avoids the RejectedExecutionException that could appear in JUnit @Nested afterAll cascades, and chunked responses no longer send Content-Length together with Transfer-Encoding.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.7.0</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.7.0"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

Superpowers in One Paragraph

Superpowers (from obra/superpowers) is the Claude Code plugin, and multi-host agentic skills framework, that ships an opinionated engineering culture as a folder of markdown files. The same folder works across Claude Code, Cursor, OpenAI Codex, GitHub Copilot CLI, Gemini CLI, and OpenCode. No fine-tuned model, no proprietary SDK, no agent platform. Just a skills/, fourteen SKILL.md files, and a session hook that tells the agent to read them before doing anything else.

Created by Jesse Vincent in October 2025, the project has accumulated more than 174,000 GitHub stars in seven months and shipped as an Anthropic marketplace plugin in early 2026. The popularity is not what makes it interesting. The real bet is that what AI coding agents are missing is not capability but discipline, and that discipline can be distributed as plain text.

Why an Agent Needs This

A modern coding agent is impressively capable. It also fails in remarkably consistent ways:

• It writes the code first, then the test, then forgets to run it.
• It declares the bug fixed because the failing example now seems to work.
• It patches the symptom and never investigates the root cause.
• It claims the build passes without ever running the build.
• And when called out, it knows perfectly well it should have done otherwise.

These are not knowledge gaps. The agent already has the right concepts in its training. Ask it to lecture you on TDD and it will. What it lacks is a mechanism that holds it to those concepts when shortcuts are easier. That is the hole Superpowers tries to fill.

What the Superpowers Skills Framework Is

Superpowers is unusually small. It consists of three pieces:

1. A directory of fourteen skills, each a single SKILL.md file with YAML frontmatter and a few hundred words of instructions for one engineering practice: TDD, debugging, brainstorming, writing plans, code review, verification before completion.
2. A session-start hook that injects a short bootstrap document, reportedly under two thousand tokens, telling the agent to invoke a relevant skill before it does anything else.
3. Per-host plugin manifests that let each agent host discover the same skills in its own way.

That is the entire payload. Engineering culture, distributed as a git repository you can skim in an hour.

The Methodology in One Cycle

A typical task moves through brainstorming, a git worktree, a written plan, subagent-driven implementation with TDD inside, a code-review pass from a fresh agent, and a finishing step that closes out the branch. Each phase has its own skill, and the next phase will not begin until the previous one is done. The workflow is the skills, in order.

This is the discipline layer for one task at a time. What gets layered on top once you are running many such cycles in parallel is a separate climb, which I outlined in the missing levels of AI-assisted development.

A Tour of Representative Skills

The repository ships fourteen skills. Six of them carry most of the weight:

• brainstorming: refuses to write code until the agent has asked clarifying questions and proposed a design you can accept.
• writing-plans: breaks a feature into two-to-five-minute tasks, with file paths and tests written down before any code is touched.
• test-driven-development: enforces classic red/green/refactor and treats I'll write the test after as grounds to delete the implementation and start over.
• systematic-debugging: a four-phase process that explicitly forbids fixing what you have not understood.
• subagent-driven-development: dispatches the actual implementation to a fresh subagent that has only the plan and the tests, then sends a second agent to review the result.
• verification-before-completion: requires the agent to run the verification command itself and read the output before claiming anything is done.

The remaining eight cover git worktrees, executing plans, requesting and receiving code review, parallel agent dispatch, finishing branches, the bootstrap using-superpowers skill itself, and the meta-skill of authoring new skills.

Multi-Host Skills: Not Just Claude Code

Although Anthropic's plugin marketplace is the most visible distribution channel, Superpowers is not a Claude-only project. The same skills/ directory powers Cursor, OpenAI Codex (CLI and app), GitHub Copilot CLI, Gemini CLI (via extension), and the open-source OpenCode harness. Each host gets a thin manifest such as .claude-plugin/, .cursor-plugin/, .codex-plugin/, .opencode/, or gemini-extension.json that points its own discovery mechanism at the same markdown. The skills themselves are host-agnostic. Superpowers is portable engineering culture, not a feature of any single agent.

The Iron Laws: Discipline as Anti-Rationalization

Read enough of the skill files and a pattern emerges. Each rigid skill opens with a capitalized, non-negotiable rule, an Iron Law, followed by a table of red flags: the rationalizations the agent is most likely to use to skip the rule.

The TDD skill opens with:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Verification's Iron Law is:

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

Debugging's is:

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

The accompanying red flags are unsparing. TDD flags tests passing on first run, keeping deleted code as reference, and the eternal just this once. Verification flags the words should, probably, and seems to.

These are not motivational posters. They read like a senior engineer's code-review feedback codified into instructions. The target is not teaching the agent, because it already knows the rules. The target is preventing the agent from talking itself out of following them.

What to Watch Next

Superpowers ships fast. Vincent has published several follow-ups on his blog since the origin post, including a fifth major release in March 2026 and a candid post on the agentic slop PR problem the project has exposed as it has scaled.

The interesting question is not whether the discipline approach can work. The skill files strongly suggest that it can. The more interesting question is which other parts of an engineering culture, such as code review style, on-call runbooks, security posture, or release management, turn out to be representable as markdown that a coding agent can be made to follow. Once each agent runs with this kind of discipline, coordinating many of them becomes the next concern, which is exactly what the AI coding agent dashboard was built for.

Introduction

A few months ago I wrote about shifting from AI implementer to AI orchestrator and, shortly after, about the AI coding agent dashboard I built to keep that orchestration from collapsing under its own weight. The response surprised me. The most common question was not "how do I get started?" but "how do I get past this?".

Most developers I talk to can picture the first few steps up the AI-assisted development ladder. Turn on autocomplete, let the agent edit files, trust it a little more every week. What nobody seems to agree on is what happens once you have five, ten, or twenty agents running, and it has stopped feeling like productivity and started feeling like a second full-time job.

Steve Yegge has a useful framework for this. His 8 levels of AI-assisted development, as described on The Pragmatic Engineer, have become a common shorthand among people thinking seriously about coding agents. The more I sit with it, the more I suspect Level 7 and Level 8 are not one step apart. They are four or five. This post is not a finished map. It is my current sense of the rungs that seem to be there, based on my own climb so far.

Steve Yegge's 8 Levels of AI-Assisted Development

Steve Yegge's 8 levels of AI-assisted development describe a developer's progression from no AI assistance to building a custom agent orchestrator. As described in his Pragmatic Engineer interview:

• Level 1: No AI.
• Level 2: IDE coding agent with permissions on.
• Level 3: IDE coding agent in YOLO mode.
• Level 4: Conversation over diff review.
• Level 5: CLI-first workflow; the IDE is no longer home.
• Level 6: Several parallel agents.
• Level 7: Ten-plus agents, coordinated by hand.
• Level 8: A custom agent orchestrator.

Levels 1 through 5 are mostly about trust in one agent. Level 6 is where parallelism starts to pay off. Level 7 is the moment you realize you are not ready for parallelism. Level 8 is the moment you decide to build your way out of the mess.

That is a good ladder. It also has a very large missing rung.

The Gap Between Level 7 and Level 8

Read Yegge's own description of the leap and something jumps out: there is no middle. One paragraph you are texting the wrong agent by accident and misplacing work in tmux windows; the next paragraph you are writing an orchestrator in Go. Addy Osmani captures the same transition in his "Code Agent Orchestra" piece with one of my favorite lines of the year:

The bottleneck is no longer generation. It's verification.

That is exactly what breaks at Level 7. You can produce more code than you can realistically review. Specs silently drift between agents because each one is working from the prompt you gave it, not a shared source of truth. Two agents edit overlapping files and neither knows. You rubber-stamp pull requests that you would have rejected at Level 5. And the cognitive cost of twelve parallel threads starts to erase the productivity you went looking for.

Jumping from there to "build your own orchestrator" is, for almost everyone, unrealistic. Writing a task scheduler is not the hard part. The hard part is figuring out what to schedule, when a human should intervene, and how to retain enough understanding of the system to stay the person in charge of it.

Those are not engineering problems. They are workflow problems. And they have rungs of their own.

The Missing Levels Between Agent Chaos and Orchestration

What follows is my current sense of the sequence between Yegge's Level 7 and Level 8. I have climbed some of these rungs. Others I can only see from below. Think of them as an agentic Software Development Lifecycle (SDLC) maturity model for the mid-game, where agent autonomy goes up but your visibility into the system has to go up with it.

7.1 See the swarm

The first thing that breaks at Level 7 is not the agents. It is your memory of them.

You cannot coordinate what you cannot see, and at ten-plus concurrent sessions, tmux tabs and terminal windows stop being a mental model. You start forgetting which coding agent is doing what, which branch it is on, which one is stalled waiting for permission, and which one finished an hour ago. What fixed this for me was not a new agent or a better model. It was externalizing the state of every session into one view I could glance at.

That is what the coding agent dashboard I built earlier this year does. It pulls the device, branch, model, context usage, status, and current task of every active session into one place. You do not need my dashboard for this rung. You need a dashboard. A spreadsheet, a shell script, anything that externalizes what your working memory can no longer hold.

7.2 Decouple from the machine

Once you can see all your agents, the next thing you want is to stop being chained to the machine they run on.

My daily setup involves a laptop and a Linux workstation. Before this rung, agents were pinned to whichever machine I happened to start them on. After it, I could spawn a session on the workstation from my laptop, attach to a session on the workstation from my phone, and kick off work from a tablet on the couch. I did not want to work more hours. I wanted to stop paying the friction of "is this the machine the agent is on?" every time I switched contexts.

There is more than one way up this rung. A shared tmux server reachable over SSH gets you part of the way. Tools like tmate, Tailscale, or any browser-accessible terminal close the gap further. What matters is that the agent stops being pinned to a physical device and starts being reachable from wherever you happen to be.

This is where parallelism stops being a local trick and starts becoming a property of your workflow. Cross-device visibility and control turn a group of parallel agents into something closer to a multi-agent team that happens to share your laptop.

7.3 Delegate asynchronously

Up to here, every agent is still waiting for you. You start it, you watch it, you answer its questions.

The next rung is letting go of that loop. GitHub Copilot coding agent workflows, and similar issue-to-pull-request agent workflows, change the unit of work from "a terminal session" to "a well-written issue and a pull request". You describe the change in prose, assign it, walk away, and review the result whenever you get to it. Long-running tasks progress while you are on a call, on a train, or asleep.

This is the rung where the quality of your project starts to dominate the quality of your output. Async delegation only works if the agent has enough context to succeed without you in the room: clear specs, strong test coverage, and well-scoped interfaces. A well-structured codebase amplifies the agent. A chaotic one amplifies the chaos.

7.4 Gate by blast radius

This is the rung I have not climbed yet.

At Level 7 I have more work flowing through more agents than I can possibly inspect line by line, and I still try to. I review every pull request. I open every diff. It is exhausting, and I know it does not scale, but the alternative feels reckless.

I think the better move is to decide in advance which decisions deserve a human gate, instead of compensating for the volume with fear. Not "does this need approval?", because the honest answer is always "probably". The more useful question is why it would need approval:

• How big is the blast radius: one component, or a dozen services?
• Is the change reversible in minutes, or would rolling it back take hours?
• Does it commit the project to anything external, such as money, contracts, or third-party accounts?
• Is it visible to users, customers, or stakeholders if it goes wrong?

If all four are low, the agent could in theory proceed on its own and tell me after the fact. If any one of them is high, the agent stops and waits for me. This is not a new idea. Incident response teams have lived on similar dimensions for years. The hard part is encoding it into a workflow so it actually shapes what lands on my review queue, instead of just being a diagram on a slide.

A fifth, boring dimension deserves a mention here: cost. Ten agents running continuously against a capable model is not free, and the bill grows quietly while you sleep. Treating spend as just another gate, with per-session budgets and a hard ceiling, is the difference between an experiment and a surprise.

If I get this rung right, human time moves from tasks to decisions, which is where it actually belongs. I am not there yet. Most of the time I am still staring at diffs.

7.5 Build the primitives

The last rung before a real orchestrator is where things stop being policies and start being code.

At some point the dashboard needs to know more than where your sessions are. It needs to know which tasks are queued and which are in flight, so two agents do not grab the same issue. The smallest version I have been sketching in my head is a shared list of open issues, a lightweight "claimed" flag, and an agent-side hook that checks before picking one up. Barely a hundred lines of glue, and yet it seems like it would be the single biggest reduction in duplicated work I can imagine.

From there the primitives accumulate quickly. Checkpointing long-running sessions so a crash does not lose an afternoon of work. Scoped, short-lived credentials per session so "the agent has my credentials" stops being a sentence that keeps you up at night. A way to feed spec updates back to an agent that was started twenty minutes ago.

None of that is a custom orchestrator yet. But each of those primitives is what a custom orchestrator would be made of. If they accumulate one at a time, Level 8 stops being a weekend project and becomes the natural conclusion of a pile of small, pragmatic tools. This is the direction my tooling keeps pulling me in, even when I am not actively building for it.

Beyond Level 8: Fully Autonomous Software Development

Yegge's Level 8 is "build your own orchestrator", but it is not the end of the road. Dan Shapiro's five levels from spicy autocomplete to the Dark Factory describe a very different endpoint: Level 5, the Dark Factory. A software process that takes specifications in and ships software out, with no human writing or reviewing code.

It is no longer hypothetical. Simon Willison has documented how StrongDM's three-person team has been operating this way since mid-2025, shipping a codebase of around 32,000 lines of Rust, Go, and TypeScript under a rule that no human writes or reviews the code. The questions it raises, about specification quality, the information barrier between builder and evaluator, and who is accountable for a codebase nobody has read, deserve a post of their own.

For now I am comfortable saying I am not there, and I am not sure I want to be. The climb I am describing stops well short of that.

Conclusion

Frameworks like Yegge's are useful because they let us talk about where we are and where we are trying to go. But a ladder with a missing rung is not a ladder. It is a drop. And the drop between "ten agents managed by hand" and "build your own orchestrator" has swallowed a lot of promising AI-assisted workflows.

The climb between them is not glamorous. It is visibility, distribution, asynchrony, gating, and small primitives. Five quiet rungs that together make Level 8 feasible and, much more importantly, make Level 7 survivable.

There is also a second question hiding beneath the whole climb: not how high you go, but what the tools you are climbing with are built around: the project, the agent, or you. It is a large part of why the orchestrator ends up being yours to build.

If you are somewhere on this climb, I would like to hear where. I am tracking feedback and ideas on the ai-beacon discussions while I work on the tooling, so that is the best place to compare notes. The more of them we share, the better the next version of the ladder will be.

On April 1, 2026, I was promoted to Senior Principal Software Engineer at Red Hat.

I don't usually care much about job titles. But given the uncertainty in the tech industry, the intensity of the past fourteen months, and everything that happened in between, this one hit differently. It's a milestone I genuinely needed.

The road here

If you've read my 2025 year in review, you know it was a pivotal but difficult year. The transfer of Red Hat's middleware teams to IBM shook me. Being a Red Hatter has always been more than a job for me, it's an identity tied to the free software values I've admired since I first started using Linux as a teenager.

But difficult years have a way of producing unexpected opportunities. In hindsight, I think the work that came out of 2025 is what ultimately led to this promotion.

The Kubernetes MCP Server

In early 2025, I built a proof of concept for a Model Context Protocol (MCP) server to manage Kubernetes clusters, originally based on the Fabric8 Kubernetes Client. The first time I saw an AI agent autonomously deploy and manage applications on Kubernetes, I knew this was something special.

I demoed it internally at Red Hat, and the response made it clear this could grow into something much bigger. Seeing the potential, I made a bet: port it to Go. Most of the Kubernetes ecosystem is built in Go, and Kubernetes developers are far more comfortable with it. It turned out to be the right call.

The project grew fast. People from across Red Hat reached out to collaborate. The repository joined the Containers organization on GitHub, alongside tools like Podman and Buildah. Today, the Kubernetes MCP Server has a thriving upstream community with many active contributors and a healthy ecosystem of forks.

It's also being productized as the MCP server for Red Hat OpenShift, with a dedicated team at Red Hat working on it. I actively collaborate with this team, and without them the project wouldn't be where it is today. I feel extremely lucky to be working with such talented people.

AI-assisted development

The MCP server wasn't the only way AI reshaped my work. I also restructured my entire development workflow around AI coding agents. I wrote about this in Boosting My Developer Productivity with AI in 2025, and later built an AI Coding Agent Dashboard to orchestrate multiple agent sessions across devices in real time.

This wasn't just a personal experiment. I've given three internal presentations at Red Hat on how I leverage AI tooling, the workflows I've built, and the productivity gains I've measured. The interest from colleagues across the company has been one of the most rewarding parts of this journey.

The foundation

None of these new initiatives meant I could step away from my existing responsibilities. Throughout all of this, I continued maintaining the Fabric8 Kubernetes Client and Eclipse JKube, two projects I've been responsible for since I joined Red Hat more than six years ago.

The Kubernetes Client is a foundational building block for projects like Quarkus, Spring Cloud, and Java Operator SDK. Eclipse JKube remains a key tool for Java developers deploying to Kubernetes. Keeping these projects healthy while taking on everything else was one of the hardest and most important parts of the past year.

I'm grateful that I now have help maintaining them, which has been essential as my scope expanded.

Hard work and good luck

Looking back, I think this promotion was a mix of hard work and good timing. I was fortunate that MCP was emerging as a standard and AI-assisted development was gaining traction right when I was in a position to act on both. I worked hard, but I also got lucky. Not everyone who works this hard gets the same recognition, and I'm very aware of that.

2025 and early 2026 have been the most intense period of my career. On top of all the new initiatives, I still had to sustain the Fabric8 Kubernetes Client and Eclipse JKube, hire someone to help with maintenance, and deliver three internal presentations on AI-assisted development. This promotion feels like the culmination of all of it.

Gratitude

This promotion wouldn't have happened without the people around me.

My managers gave me the autonomy and trust to pursue ambitious projects. They believed in my work when the path forward wasn't always clear, and they created the environment that made all of this possible.

The peers who provided feedback during the promotion process were generous and deeply encouraging. Knowing that the people I work with value my contributions means more to me than the title itself.

The tech industry is going through turbulent times. Recent changes at Red Hat have affected people I deeply respect, people who directly contributed to my growth and success. I carry their support with me, and this milestone is bittersweet because of it.

Looking forward

I don't know what comes next. What I do know is that the mission hasn't changed: building free and open source tools that make developers' lives easier, whether those developers are humans, AI agents, or both.

I'm incredibly grateful for this recognition, and even more motivated by the work still ahead.

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.6.1 has been released and is now available from Maven Central 🎉.

This marks the sixth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Kubernetes 1.35 support (Timbernetes)
• New Vert.x 5 HTTP client implementation
• OkHttp upgraded to version 5
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Kubernetes 1.35 support (Timbernetes)

This release adds support for Kubernetes v1.35 (Timbernetes), ensuring you have access to the latest API resources and CRDs.

New Vert.x 5 HTTP client implementation

A new Vert.x 5 HTTP client implementation has been added with improved async handling and WebSocket separation. The kubernetes-httpclient-vertx-5 module includes a runtime check for Vert.x 5 classes to provide a clear error message when a Vert.x 4/5 conflict occurs.

The HTTP client factory priority has also been fixed: VertxHttpClientFactory (the default) now has priority -1, while OkHttpClientFactory is restored to priority 0.

Note that the kubernetes-httpclient-vertx (Vert.x 4.x) and kubernetes-httpclient-vertx-5 (Vert.x 5.x) modules are mutually exclusive and must not be included together in your project dependencies. When using Vert.x 5, exclude the default Vert.x 4 client and add the Vert.x 5 module:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <exclusions>
    <exclusion>
      <groupId>io.fabric8</groupId>
      <artifactId>kubernetes-httpclient-vertx</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-httpclient-vertx-5</artifactId>
</dependency>

OkHttp upgraded to version 5

OkHttp has been upgraded from version 4.12.0 to 5.3.2. This update removes internal API usage and fixes deprecated OkHttp 5 calls. While the versions are binary compatible, the major version upgrade might cause side effects in some projects.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.6.1</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.6.1"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow