Testing Built for the Way Engineering Actually Works Now

A few years ago, when we started Testkube, the problem we were solving was straightforward: testing in cloud-native environments deserved better tooling than what existed. CI/CD pipelines were the same as the rest of software, but testing kept getting bolted onto them like an afterthought. We knew there could be a better solution.

Today, three things are shipping that I'm genuinely proud of. They're different from each other, but they're connected by that same belief that brought us here in the first place: that testing should keep up with how engineering actually works, not slow it down.

Let me walk you through them.

Three things, all today

First, we're launching Testkube AI, a new layer of Testkube that embeds AI directly into the fabric of our platform. The Early Access Program is open to anyone who wants in.

Second, Testkube is now available on the AWS Marketplace, making it easier for enterprise teams to procure through the channel they already use.

Third, the Test Execution Viewer is shipping for our open source community. It's a lightweight browser-based app  that gives every Testkube Open Source user a clear, shared view of what their tests are actually doing. No paywall, no login.

Three announcements. One day. They each matter for different reasons. While all of them are important, let me start with the one that I'm most excited about.

Testkube AI: not a feature, a layer

When we started building Testkube AI, we kept coming back to the same question. There's a lot of AI in the developer tooling space right now. Most of it sits outside the systems it claims to help. It looks at logs after the fact. It summarizes outcomes. It suggests things based on what it can see from the outside.

That's fine for some problems. It's not enough for testing.

Testing context lives below the surface. It's in the workflow definition, the runtime artifacts, the parallel worker logs, the partial state of an in-flight execution. AI built on top of that surface can describe what happened. AI built into the execution layer itself can actually participate in the work.

That distinction is what Testkube AI is.

We didn't bolt AI onto a dashboard. We rebuilt the platform so AI agents have the same fidelity of access that our execution engine has. Every workflow, every artifact, every log, in real time. They see what the engine sees. That's why the agents are useful, instead of just performative.

Here's what Testkube AI looks like at launch:

AI-powered test creation. Engineers describe what they want to test in plain language. Testkube generates the test, in the framework of their choice, and runs it against real infrastructure. Most teams today struggle with test coverage, not because writing tests is trivial, but because writing, maintaining, and running them at scale takes time most teams don't have. AI Authoring is how we close that gap. It's announced today; the EAP is where we're shaping what ships first.

Autonomous Agents. When a test fails, an AI agent responds automatically. It pulls the failure context, reruns the affected test to determine whether the failure is flaky or reproducible, generates a structured summary, uses context and tools from available MCP Servers, and posts a conclusion to your team's Slack or ticketing system. By the time an engineer sees the alert, the investigation is done. They get a verdict, not a log file.

[placeholder - Lucio to generate video]

Testkube MCP Server. We're exposing Testkube's execution context through a Model Context Protocol server, which means any AI tool that supports MCP can read live testing context natively. If your team is using Claude Code, Cursor, or any other MCP-aware tool, those tools can now see your test workflows, results, and artifacts directly. One integration, many tools.

If you want to be part of how this gets built, join the EAP. We're prioritizing teams who want to use it on real projects and  give us feedback. 

AWS Marketplace: meeting teams where they buy

A lot of the engineering teams we work with are standardized on AWS. Their procurement is set up for it. Their existing agreements are with AWS. Their committed spend is sitting there waiting to be applied. For those teams, the friction of bringing in a new vendor through traditional procurement is real, and it slows everything down.

Starting today, Testkube is available on the AWS Marketplace. Teams can apply existing committed spend toward Testkube, consolidate it under their AWS agreements, and skip new vendor onboarding entirely. Deployment continues to run through our standard install path into your own Kubernetes environment, exactly as before. Nothing changes about how Testkube actually runs. What changes is how easy it is to start.

If you've been waiting for this, today's the day. If your procurement team has been waiting for this, send them the link.

Test Execution Viewer: built for the people who built Testkube with us

I want to spend a minute on this one, because it's the announcement that means the most to me personally.

Testkube exists because of the open source community. From the very first release, Open Source users have been writing the tests that stress-tested our assumptions, finding the bugs we missed, and shaping what the platform became. A lot of what's in Testkube today started as a problem an OSS user surfaced.

For a long time, those same users have been running Testkube without a clean way to see what their tests are doing. To understand a test execution, they've had to piece together results, logs and artifacts using the Testkube CLI. It's worked, but it's been more work than it should be.

Our Test Execution Viewer changes that. It's a lightweight, on-demand browser-based app  that aggregates logs, results, and artifacts for any test execution into a single view. Run testkube view <execution-id> and a clean page opens in your browser. Logs. Artifacts. Everything in one place. No login required.

If you're a Testkube Open Source user, update your CLI and try it. If you've been on the fence about Testkube because of the visibility gap, this closes it.

Where we're going from here

A few years ago, the question was whether testing should be a first-class part of cloud-native infrastructure. We think we've answered that question. The next question is whether testing can keep up with engineering teams who are now shipping faster than ever, with more code generated by AI, in more environments, with less human bandwidth to validate it.

That's the question Testkube AI is built to answer. It's the start of a longer arc, not the end of one. AI-powered test creation will ship in stages. Autonomous Agents will get more capable. MCP integrations will grow as the ecosystem grows. We'll keep shipping.

If you want to see how all of this fits together in practice, we’re doing a live walkthrough on May 21 at 1pm ET. Real Kubernetes environment, real tests, real demonstration. I'll answer your questions live. Register here.

And if you've been part of the Testkube community at any point in the last few years, thanks. The reason any of this works is because of you.