Three Buttons No Human Had Ever Pressed

Monday, 11 August. I am sitting in front of my Mac, about to do what any normal user would do: download my own product from my own website and start it.

Double-click.

Nothing.

No window, no error, no message. Nothing.

For context: I had just shipped eighteen releases in eight days. Over a thousand tests, all green. A website that worked. A system I was proud of. And there I sat, clicking on my own software, and it ignored me.

At that moment I did not yet know that this one broken double-click would expose three defects stacked on top of each other like geological layers. That the deepest one had been in every single release for months. And that in the end I would be grateful for this moment. Because it burned the most important lesson of my career as a Quality Architect into my memory.But one thing at a time. To understand why this double-click ultimately made me happy, I have to rewind five and a half months.

But one thing at a time. To understand why this double-click ultimately made me happy, I have to rewind five and a half months.

What this is about, in four lines: One person builds a complete commerce system with AI. Six business domains, twenty roles, 915 deliberately built-in defects, live at pg.swisstd.ch. Along the way: two architecture reversals, a crisis of trust, and the realisation of why our profession is becoming more important right now, not less.

“Don’t you have a test system for us?”

The story starts harmlessly, in the planning of the Swiss Testing Day. Partners keep asking the same question: is there a test system we can demonstrate our tools on?

Good question. There wasn’t.

Sure, individual vendors have demo systems. But picture it: a neutral testing conference making partner A’s demo system the stage for partners B through Z. Awkward.

And then this one thought that has changed my life ever since:

Fine. Then we build our own.

Small catch: I am not a developer. Sixteen years of test management, quality engineering, consulting. Professionally, I examine what other people build. Two years ago the idea would have died right here, somewhere between the coffee cup and the reality check.

This time it did not die. Because now there was this new possibility: AI that writes code. Would it carry the load? Worth a try.

Spoiler: it carries. But differently than I thought.

The Rush

March was a rush. 726 commits in a single month, more than half of the entire project. Six services came into being one after the other: sales, logistics, finance, shipping, payment, procurement. Each with its own database. Plus twenty roles, a permission system, a defect framework.

I remember the feeling: you describe what you want, and it appears. An idea in the evening, a feature in the morning. Anyone who has experienced this once understands why everyone is talking about it.

What I did not understand back then: that very feeling is the trap.

Because when building costs nothing, you build. And build. And build. The Playground was planned for Swiss Testing Day 2026. Then one more feature came along. Then another. All sensible, all well justified. At some point the year was over and I was not done, because I had done exactly what I have been warning clients about for years: I never cleanly scoped the MVP.

Me, of all people. Feel free to smile at that, I do it myself by now. But remember the mechanism: AI makes building so cheap that the discipline of saying no becomes the most expensive asset in the project.

The Month I Owned Two Systems Without Knowing It

In May, the repository went quiet. 44 commits, almost nothing. From the outside it looked like a break.

In truth, May was the month of the most uncomfortable finding in the whole project.

Preparing the first release, I looked closer and found two complete architectures side by side. No joke. What we shipped was a monolith: ten shop routes, one database. What had long been developed and tested were microservices: gateway, six services, separate databases.

Both existed. Both looked functional. The frontend was already talking to the microservices, which were not even contained in the shipped package.

How does something like that happen? Simple: step by step, each one plausible on its own, none with a view of the whole. The AI had dutifully kept building, I had dutifully kept nodding, and nobody asked, neither it nor me: does what we build still match what we ship?

May ended with a cut: monolith out, a clear decision, two intended modes of operation. It was the first moment I sensed what July would then teach me with full force.

72 Hours, 27 Defects, One Full Shopping Basket

Late July. The system looks great. Over a thousand individual tests green. Services running, interface complete, two languages, wiki, everything there.

And then I ask the question that (confession time) I should have asked much earlier. The question I ask first in every client project:

Does a single business process actually run through from start to finish, the way a human operates it?

The system has six processes. Order to cash. Goods receipt to supplier invoice. Returns, dunning, end-of-day closing. So: all six, end to end, through the interface, with every role. Go.

The following 72 hours were, as I called it in my notes, a humbling with an announcement.

I felt no joy that evening. I asked myself what exactly I had been building all this time.

The Test That Verified Phantoms

Because the real question would not let go of me: how can a system with a thousand green tests be this hollow?

The answer came in two stages, and the second one is the harder one.

Let that sink in for a moment. The safety net I trusted had holes. And precisely in the places where it would have been hard work to knit it tight.

I will say it openly: these findings seriously damaged my trust. Not just in the system. In the entire way of working.

Measuring Instead of Believing

How do you get out of a crisis of trust like that? Not with optimism. With evidence.

Three things restored the trust, and I pass them on to everyone building with AI:

Today I trust the system. With pragmatism: if ten percent is not perfect, so be it. It is a test system, not a production ERP. It is allowed to have defects. It even has 915 of them. On purpose.

And as a Quality Architect, I now phrase the lesson like this: whatever we define and let AI execute, we must verify it. Human in the loop is not a transition phase until the tools get better. It is structure. A system that phrases every answer convincingly needs a counterpart that measures instead of believes.

If you have ever wondered whether AI makes our profession obsolete: I spent five and a half months in the engine room, and my answer is the exact opposite. Faster building means more unverified assumptions per week, not fewer. Who is supposed to verify them, if not us?

The Resolution: Three Geological Layers

Back to 11 August, to the double-click that did nothing.

Three defects, stacked, each visible only after the one above it was fixed.

And why did nobody ever notice? Because every development machine runs a different setup. The shipped edition was used by exactly one group of people: the ones it was built for.

That is why this broken double-click made me happy in the end. In a single scene, it showed me what I can now explain to clients in one sentence:

Whatever you ship must be tested on the path it takes to reach the recipient. Not on the path you use yourself.

If you take just one sentence from this article: take that one.

What This Has to Do With You

Now comes the part I actually wrote this article for.

In this project I played every role myself: product owner, architect, developer, quality engineer, translator, operator, all the way to the forward deployed engineer who gets his own product running at the recipient’s end. At times it felt like five people were sitting at my desk, none of them agreeing. The product person wanted one more feature. The test manager wanted everything green first. The project lead knew: listen to those two, and you will never go live.

If “Forward Deployed Engineer” rings a bell: that very role sits at the centre of our Quantum Shift. An FDE owns the result inside the client’s environment. Not an advisor, not staffed capacity, but accountable for the outcome, even when much is unclear. It comes in three flavours: Domain, Delivery and AI Technology. (The names are still in motion. More on that later.)

The one that grabbed me is the Domain FDE, the outcome owner: accountable for the business result, not the build, translating business problems into work that agents can execute. This Playground was, without me calling it that at the start, my personal training camp for it. And many paths lead into this role, from very different backgrounds. If you are curious: talk to me, I will happily tell you what it feels like.

And when did all this happen? 47 percent of the 1,407 commits were made after 6 pm or before 6 am. 246 between midnight and six. 196 at weekends. Evenings, train rides, weekends. On the side, next to client projects.

Why am I telling you this? Not so you do it the same way. But so you know: it is possible. One person. A complete system. Idea to operations.

Elon Musk (think of him what you will) describes a principle I experienced daily: if you have a goal, you gather the information for exactly that goal. Not the foundational knowledge to the left and right of it. That is precisely what building with AI feels like. I did not need to know everything. I needed to know what I wanted, and to verify relentlessly whether I got it.

So, to everyone with an idea in the drawer thinking “I am not enough of a developer for that”:

Let go of the fear. Start. But verify like the pros.

Three things you can do right away:

The Bigger Picture: AXIS and ACE

To close, the view beyond my desk, because my five and a half months are, in miniature, what Xebia is building at scale.

What I experienced at my own desk, AI-powered building with human verification at the decisive points, now has a product world at Xebia. And for both offerings, I can supply the evidence from my own data:

Xebia Axis lays the foundation, the Agentic Data Foundation: consolidating, migrating and readying enterprise data for AI. My bedrock was a continuously maintained working memory: a database holding 557 entries for the Playground alone, among them 109 documented decisions and 72 lessons, plus 70 working rules that kept the AI honest. Rules like “never make unverified claims” or “only what is proven directly on the system counts as done”. Without that foundation, every working session would have started from zero. Exactly that foundation, at scale and for enterprise data, is what AXIS builds.

Xebia Ace is AI-Powered Software Delivery, exactly the kind of accelerated development I described here, professionalized for client projects. What that means in cadence is written in my Git: 18 releases in eight days, and 1,747 checks ran before every single one. Speed and control are not opposites when the gates are in place. ACE builds those gates into client projects.

Why do I mention this? Because every lesson in this article feeds straight into it. The layer shortcuts, the hollow tests, the human in the loop: those are not Playground anecdotes, those are the quality questions our clients must answer on their way to the agentic enterprise. If you want to help build one of these offerings or simply understand what is behind them: you will find the product world in our internal knowledge space. Your first port of call: every region has a Quantum Shift Ambassador, approach them directly. And as a second instance, you can always talk to me. My inbox is open, and I share my experiences gladly. Entirely in the spirit of: “A Xebian is never alone – One Xebia.”

And Then the Playground Becomes a Room

One more thing, because it shows where this journey is heading: at the Swiss Testing Day, the Playground gets a physical counterpart. A room where partners show their products on the living system and visitors simply try things out. No sales pitch. Anyone who wants more is guided to the right booth for the deep dive.

The test system that started as a stopgap, because we did not have one, becomes a centrepiece of the conference.

Not bad for a project that almost ended, symbolically, with a double-click into the void.

The Debate I Want to Open as a QA Lead and QA Architect

Before I close, one more thing on the table, as my personal opinion. This is not about roles or titles, but about the professional core of our delivery: that we deliver quality.

Think back to the phantom test: written by an AI, green like all the others, and it confirmed data that never existed. Tests like that are AI products themselves and need someone to check them in turn. That is why, for me, the human in the loop is one of the most important roles of the AI era. And honestly: this role has always existed. It was called the tester.

Today’s three flavours all check, each within its own field: the Domain FDE measures against the business outcome whether the promised value arrives. The Delivery FDE, the builder, owns production quality and review at the client. The AI Technology FDE sets the technical guardrails and measures the systems. But all three share one trait: the one who checks is also the one who delivers. So what I am adding is not a correction but a complement from my own practice: a fourth flavour whose sole mandate is the independent view on quality. As a working title, because “QA” falls short of it: Human-in-the-Loop FDE, HitL FDE for short. Whether that name is the right one belongs in the debate as well.

The role starts at risk, long before the first line of code, because quality people are risk thinkers by trade. Quality awareness belongs in every role, but it takes someone who makes it their craft: who reviews, sharpens and cross-checks assignment and statement of work, and who on a fixed-price project runs the uncomfortable calculation of what a failure would cost us. This article is full of examples of what unchecked assumptions cost. The HitL FDE leads that look at risk through every phase, because quality assurance is not product quality alone: it spans the entire delivery, end to end, from the assignment through definition into delivery and operations. They set the guardrails, make quality visible instead of claimed, act as the counterweight to the other FDEs and, where needed, as the devil’s advocate. A brake they are not: they want the product live like everyone else and use every craft, AI included, to accelerate validation. What gets shortened is the time. Never the quality.

And should it stay with the three flavours, my view is just as clear: then the Domain FDE is the right path for quality people. They own a business domain or part of one, define it together with the client, hand it into development and validate it in delivery. Defining and validating: exactly the two places where quality is decided.

By the way: does this role already exist? The market for Forward Deployed Engineers is exploding, from 643 to over 5,300 postings within a single year, checking roles among them. But almost all of them check results. A role that leads quality end to end, I did not find. That is not a weakness of any model; it is open ground. And whoever describes open ground first gets to shape it.

Thought through to the end, this role belongs in both products I told you about: what does quality mean in AXIS, in ACE? From a product view, a methodology view, a project view. These are questions I want to argue about, in the best sense of the word, with any committee, at any table. My door is open.

Questions, objections, your own AI project stories? Reach out directly. By now I collect other people’s geological layers, too.