Agentic stress testing: the loop does not stop at plan and execute

📺 This article is based on the full video. Watch it here: https://mkc.sh/stress-test

Last week I published a two-hour video about the Killer SaaS method: how to replace any SaaS, even a complex one, with quality code. The point is not to vibe code a small app, but to produce clean, secure code.

Many of you watched it. And in that video I already said something important: most of you stop at the plan and execute phases. You plan, you execute, you move forward, and you think it is done.

It is not done. Agentic development covers more than that.

Even if you follow the method to the end and ship a SaaS to production, you are not finished. Your application working for you does not mean it will work for several users.

A request goes through five layers

The principle is the chain: its strength is the strength of its weakest link.

A request travels through several layers, and only one of them needs to be slow for the entire response time to suffer. It does not matter that the other four are fast. If the connection pool takes five seconds, your request takes five seconds.

The saturation points to know:

• the connection pool
• slow queries
• external APIs
• cold starts

Any of them can become the bottleneck.

The curve every developer should have in mind

Here is what usually happens. You test your app. You log in, you are alone on it, you look at the latency, and you conclude that everything is fine. It responds, it works.

It works with 10 users. With 20. With 30.

Then suddenly, maybe at 50, you get a heavy degradation and a spike of very slow responses.

That is exactly what a developer needs to detect before their users do.

k6, and the three numbers you must read

Load test scenarios are written in JavaScript. That is easy to have an AI produce, and it lets you launch several hundred virtual users in parallel.

To read the results, three concepts are enough.

VU, for virtual user. 200 VU means 200 people browsing simultaneously. k6 generates those user simulations.

p95. This is the metric that matters: 95 visitors out of 100 were served faster than this value. If your p95 is 1.5 seconds, 95 out of 100 visitors get acceptable response times. If your p95 is 4 seconds, 95 out of 100 visitors wait 3 to 4 seconds. That is not good.

The threshold. This is the limit you declare before firing. Without a threshold, you produce a chart, not a test.

The two skills

The workflow relies on two skills that I share in the kit: the one that writes and runs load tests, and the one that works through production errors.

The first has a useful behaviour: if you have never implemented a test scenario, it helps you implement one. If the scenario already exists, it tells you what was executed and asks whether you want to run the load test.

These skills have fixed rules, and those rules are what matter:

• always include a witness page with no database access;
• the agent never sets the thresholds on its own;
• the agent never closes an issue on its own.

In practice, the request looks like this:

Run a load test in production with 200 virtual users.

And the agent handles the rest.

What the test found

On my course platform, the run surfaced a database connection error: the maximum number of session connections had been reached.

The detail that matters: this error does not trigger at 200 users. It shows up from around twenty.

This is not the kind of problem you spot on the first try. But had I announced this SaaS to my community without running that test, many people would have hit that error. And their conclusion would have been simple: this SaaS does not work.

In production, concretely, the user lands on the site and gets a 500 error.

Cross-checking the test with production logs

This is the second part, and it is what makes the verdict trustworthy.

You run the load test, then you compare with what the error tracker actually recorded over the same period. Without that cross-check, all you measure is response times.

An example of what it saves you. In the errors, I saw a .php URL go by. I asked my agent whether it was related to the stress test. The answer: those are not my requests. Which makes sense, since the site uses next-intl and every URL goes through the locale, like /fr/.... So it was someone scanning the site, not my test.

Without the agent to settle it, I could have spent time hunting a bug that did not exist.

The verdict

After the fix, new run. Zero errors, this time actually verified.

That is the difference with the previous test. The first run had no tracker connected: I was looking at response times without really checking what was happening server side. The second run has both measurements, and only then does "zero errors" mean something.

What to take away

The agentic loop does not stop at plan and execute. After deployment, at least three areas remain: security auditing, production log analysis, and stress testing.

That last one is no longer a project of its own. With a well-written skill, it is one sentence to type, and an agent that builds the scenario, fires, processes the output and hands you a verdict.

As long as you do not let it choose its own thresholds.

---

Going further

📺 The full video: https://mkc.sh/stress-test

🎁 The 2 skills and 3 guides are free to download: https://mkc.sh/the-agentic-dev?lead=charge-sentry