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

Introduction

In December 2025 I wrote about becoming a coding orchestrator, shifting my role from implementer to someone who directs multiple AI coding agents working in parallel. The productivity gains were real, but so was the chaos.

Running 5 to 10 Claude Code sessions across multiple machines, different projects, and various git branches quickly became unmanageable. I'd forget about sessions, lose track of what was running where, and sometimes only rediscover abandoned work hours or days later.

Terminal tabs and tmux solve local organization. They do not solve cross-device visibility. I needed a single view of everything, so I built a dashboard.

The Problem: Orchestrating Without Visibility

My daily setup involves a MacBook for on-the-go work and a Linux workstation for heavier tasks. On any given day, I might have Claude Code sessions running across both machines, each tackling different tasks in different projects and branches.

The cognitive overhead of tracking which agent is doing what, on which machine, adds up fast. You have to remember which terminal window maps to which project, which branch each agent is working on, whether a session is still active or has stalled, and whether the agent is waiting for permission or has already finished.

Without a centralized view, the orchestrator workflow I described in my productivity post breaks down. You lose the parallelism advantage that makes AI-assisted development so powerful.

Existing tools only solve parts of this problem. Tmux and terminal multiplexers work great on a single machine, but they don't span devices. IDE-based solutions are tied to a specific editor. What I needed was a tool that could aggregate information from all my machines and present it in a single, real-time view.

As I discussed in The Future of Developer Tools, our tools need to adapt to AI-agent workflows. This dashboard is one example of what that adaptation looks like in practice.

The Real Challenge: Context Switching and Cognitive Load

One thing that doesn't get discussed enough is that the biggest bottleneck in AI-assisted parallel development isn't the AI itself. It's the human.

When you're orchestrating multiple agents, the cognitive load of context switching between sessions becomes the primary constraint. Which agent was working on what? Did that session finish or stall? Is the agent waiting for my input? Every time you have to answer these questions by opening terminals and inspecting state manually, you pay a context-switching tax that eats into the productivity gains you're trying to achieve.

This is the core challenge of the orchestrator era: managing the mental overhead of parallel work. Any tool that claims to support AI-assisted development needs to address this head-on.

The Dashboard: What It Does

The dashboard provides a real-time overview of all my active coding agent sessions across every device and project.

Sessions are organized by device, so I can immediately see what's running on my MacBook versus my workstation. Each session is represented by a card that displays key information at a glance:

• Project and git branch: Which repository and branch the agent is working on.
• Pull Request link: If the agent has created or is working on a PR, a direct link is shown.
• Model and context usage: Which LLM model the session is using and how much of the context window has been consumed.
• Status: Whether the agent is actively working, idle, or waiting for user permission.
• Task description: A summary of what the agent is currently doing.
• MCP servers: Which Model Context Protocol servers are connected to the session.

The dashboard updates in real time as agents report their state. It uses this stream of information to detect stale or crashed sessions automatically. If an agent stops reporting for too long, the session card reflects that something may have gone wrong.

By externalizing this state, the dashboard directly attacks the context-switching problem I described above. Instead of cycling through terminal windows to reconstruct what's happening, I can glance at the dashboard and know the state of every agent instantly.

Remote Terminal Attachment

The feature that changed everything for me is the ability to connect to any agent session directly from the browser.

I've seen developers set up elaborate solutions to achieve cross-device terminal access: Tailscale VPNs, SSH tunneling from their phones, complex tmux configurations with nested sessions, and custom scripts to keep everything in sync. These approaches work, but they add layers of friction and configuration that become their own maintenance burden.

The dashboard takes a different approach. When I click on a session, I get a live terminal embedded right in the browser, attached to that agent's session. I can read the output, provide input, approve permissions, or intervene if the agent goes off track. No SSH setup, no VPN, no terminal app on my phone. Just a browser and the same interface everywhere.

This works from any device: my laptop, my phone, a tablet, or any machine with a web browser. During lunch, I can check on a long-running session from my phone. On the couch in the evening, I can review what an agent produced during the day from a tablet. The UX is the same everywhere because the interface is always the same web application.

On touch devices, an extra-keys toolbar (Esc, Ctrl, Tab, arrows) and clipboard bridging make the embedded terminal genuinely usable from a phone or tablet.

Security was a primary design concern from the start. This runs in my own environment with authenticated device registration and scoped access, so the goal is convenience without exposing raw terminal access publicly.

Spawn, Prime, Notify: Productive From Anywhere

If remote terminal attachment is the feature that keeps me connected, the next three are what keep me productive from anywhere. Each one removes a different friction point that shows up the moment you try to run several agents in parallel without sitting in front of the machine.

Spawning Sessions and Worktrees: Parallel Without Stepping on Each Other

From the dashboard, I can start a new Claude Code session on any of my registered devices. I pick a device, select a project from its available repositories, and a fresh agent session spins up in a new tmux window on that machine. The dashboard picks it up immediately and starts tracking it. This means I can kick off agent sessions while commuting, then sit down later to review the results, and distribute work across machines based on what each one is best suited for.

The piece that turns this from a convenience into something I rely on is the worktree picker. For the chosen project, the spawn dialog lists the existing git worktrees on that device and lets me either attach a new agent to one of them, or type a fresh branch name to spin up a brand-new worktree on the fly. Branch names are validated, so a typo never wedges the working tree. This matters because at five or ten parallel agents on the same repository, the bottleneck is no longer compute. The real cost is agents stepping on each other. Worktrees give every agent its own isolated filesystem, and the picker turns that into a one-click decision instead of a context switch into the terminal.

Workflow Templates: Priming, Not Just Spawning

Spawning a fresh session in the right place is half the problem. The other half is what the agent does once it is there.

Workflow templates are opinionated, built-in prompts that prime a new session for a specific task instead of dropping the agent at a blank prompt. Two ship today: Implement Issue and Review PR. For Implement Issue, I paste a GitHub issue URL; the dialog parses repo and issue number, spawns a session in an issue-<number> worktree, and labels it #<number> Implement. For Review PR, the same thing happens with a PR URL, optionally in a review-<number> worktree, labeled #<number> Review.

Each template embeds engineering-discipline guardrails I would otherwise paste from a snippets file every time: interview before you assume, write a failing test first, verify before claiming success, hand the diff to a peer-review pass. The agent starts from a strong baseline rather than from whatever I happened to type into the spawn box during a coffee break. Templates are configurable per-deployment via config.toml, and embedders can replace them entirely with their own prompts.

Push Notifications: The Loop Closes Back to You

Async delegation only works if the agent can find you when it needs to. Without that, you are back to polling the dashboard every few minutes, which defeats the point.

The dashboard registers a service worker that fires browser notifications on three transitions: Needs you when an agent is blocked waiting for human input, PR opened when a session has just produced a pull request, and Done when a session moves from working to idle. Clicking a notification deep-links straight to the relevant session card, so I am already where I need to act. Because they go through a service worker, the notifications survive the dashboard tab being closed, so I do not have to leave a browser window open all day to be paged. Awaiting-permission alerts beep because they actually need a human; the rest are silent so they pile up without nagging. The agents pull me back in only when there is something to do.

How It Works: Architecture Overview

Rather than walking through every implementation detail, I want to highlight the high-level architecture and the design decisions that make this system flexible.

The system follows a heartbeat model. Each coding agent session reports its state to the dashboard backend at regular intervals. This report includes project information, git status, context usage, active MCP servers, and the agent's current task.

The heartbeat data is gathered through coding agent hooks. In the case of Claude Code, these are notification hooks that fire when the agent transitions between states (working, idle, awaiting permission). The hooks execute a lightweight script that posts the session state to the dashboard API.

For terminal attachment, the backend establishes a WebSocket relay between the browser and the remote machine's terminal session. Since the agent and the human connect to the same underlying session, they can interact with it simultaneously.

The design decision I'm happiest with is the enricher pattern. The raw data coming from agent hooks is passed through a chain of enrichers, each responsible for extracting or deriving specific information. For example, one enricher parses the agent's transcript to extract model name, token usage, and context percentage. Another enricher detects PR URLs from the git branch.

This pattern is what makes the system extensible and agent-agnostic in the core dashboard, with agent-specific hooks and enrichers handling the adaptation layer. The dashboard doesn't need to know the internals of any particular coding agent. It only needs a hook script that sends heartbeats and an enricher that knows how to interpret the raw data. Supporting a new CLI agent, whether Goose, Gemini CLI, or any future tool, is mostly a matter of writing a new hook and a new enricher. The rest of the system remains unchanged.

The same composability applies to authentication. A pluggable auth layer lets the dashboard run with a zero-config pre-shared key on a personal laptop, or scale up to browser password auth, SSH challenge-response, or OIDC and per-user API tokens for team deployments. The goal is to adapt to each user's environment rather than force a single model.

Beyond standalone use, the dashboard is designed to be embeddable. I'm already integrating it into my personal automation platform, and the same plugin and auth interfaces that keep the core agent-agnostic also keep it tool-agnostic — it can live inside a larger system instead of replacing one.

A quick note on scope: this is currently optimized for live orchestration and intervention, not long-term analytics. The focus is real-time visibility and control across devices. I can add historical views later, but the immediate win was reducing the cost of checking and steering active sessions.

What I've Learned Running This

After several weeks of daily use, a few insights stand out.

Visibility reduces cognitive load dramatically. The single biggest improvement isn't any specific feature. It's simply being able to see everything at once. Before the dashboard, I spent mental energy tracking session states in my head. Now that state is externalized, I can focus on higher-level decisions like what to assign next and which results to review first.

Context percentage is the most actionable metric. Of all the fields on the dashboard, context usage has been the best predictor of where I should look next. When an agent is running high on context, it usually means I need to review progress, reset with a fresh session, or prepare for handoff.

PR awareness shortens the review loop. Seeing which sessions have produced pull requests, with direct links, lets me move from orchestration to review immediately instead of hunting through GitHub notifications.

Remote access changes when and where you can be productive. This sounds obvious in retrospect, but actually experiencing it is different from theorizing about it. Being able to start a session from my phone during a coffee break and review the results from my workstation an hour later has added genuinely productive moments to parts of the day that were previously dead time.

What's Next

The dashboard is functional and I use it daily. The roadmap is driven by one goal: reducing the need to leave the dashboard for anything, while keeping the core flexible enough to support very different users and workflows.

Short-term, the focus is on features that eliminate round-trips to other tools:

• Coding agent settings management: Configure agent behavior directly from the dashboard instead of editing configuration files on each machine.
• File attachment: Send files, context documents, or reference material to an agent session without switching to a terminal.
• Code diff viewer: Review the changes an agent has made without opening an IDE, closing a major gap in the orchestration workflow.
• Desktop application: A native desktop build for users who prefer a dedicated app over a browser tab.

On the extensibility front, support for additional coding agents is a natural next step. The enricher pattern I described above was designed with this in mind. As more CLI-based coding agents emerge, the dashboard should be able to aggregate sessions from all of them into the same unified view, regardless of which agent is running underneath. Beyond agent variety, integration with skills frameworks like Superpowers is another extensibility direction I am watching: the dashboard tracks what each agent is doing, while a skills framework shapes how it does the work.

For team and multi-user scenarios, OIDC authentication and per-user API tokens are on the way, so the same tool that works zero-config on a personal laptop also fits shared deployments.

Given the interest the project has already generated in the community, I'll be releasing the source publicly. Beyond making it available to others, I want to use it as a way to research how developers actually adapt to AI-assisted workflows — what they orchestrate, what they intervene on, what they ignore — and let that shape where the tool goes next.

If you're running parallel coding agents and have thoughts on what would make a tool like this more useful, I'd genuinely love to hear from you. Whether it's a feature idea, a different approach to the same problem, or just your experience managing multiple agents, reach out.

Conclusion

The shift from implementer to orchestrator that I described in my productivity post requires different tools. Standard terminals and IDEs were not built for one developer managing a fleet of AI agents across multiple machines.

This dashboard is my current answer to that gap. It gives me visibility, control, and a consistent way to monitor, intervene, and start work from anywhere.

Developers who learn to orchestrate AI agents effectively will have a real advantage in the next era of software engineering. And the tools we build today to support that orchestration, however rough around the edges, will shape what that era looks like.

I'm still iterating on this, and I'd welcome feedback, feature suggestions, and stories from anyone tackling similar challenges.

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.19.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:

• Improved Spring Boot health probes configuration
• ECR registry authentication with AWS SDK v2
• IngressClassName support for Ingress resources
• Updated base images from UBI 8 to UBI 9
• Reduced dependencies (Guava removal)
• 🐛 Many other bug-fixes and minor improvements

Improved Spring Boot health probes configuration

This release brings several improvements for the Spring Boot health probes configuration:

• JKube now uses the correct management.endpoint.health.probes.enabled property. The previous property (management.health.probes.enabled) was deprecated in Spring Boot 2.3.2.
• Added support for server.ssl.enabled and management.server.ssl.enabled properties to enable liveness/readiness probes for Spring Boot Actuator. This allows for easier environment-specific SSL configuration.

ECR registry authentication with AWS SDK v2

JKube now supports Amazon ECR registry authentication using AWS SDK Java v2. This update ensures compatibility with the latest AWS SDK and provides a more robust authentication mechanism when pushing images to Amazon Elastic Container Registry.

IngressClassName support for Ingress resources

The IngressClassName field is now supported in the NetworkingV1IngressGenerator. This is essential for Kubernetes environments with multiple ingress controllers, allowing you to specify which ingress controller should handle your Ingress resources.

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