My feed

After my previous experiments with test latency, I started wondering whether I was still looking at the wrong statistic.

Mean latency is obviously incomplete.

p95 is better.

p99 is useful when rare slow runs matter.

But all of these measurements have one property that is easy to overlook:

They do not care about order.

If I take 300 test durations and randomly rearrange them, the mean remains identical.

So do p50, p95 and p99.

The total waiting time is identical too.

Yet from a developer perspective, ten slow runs scattered across an afternoon do not necessarily feel like ten slow runs arriving almost back to back.

That gave me a very specific experiment.

I generated one set of 300 test durations.

Then I created two timelines from exactly the same values.

In the first timeline, durations were randomly ordered.

In the second, slow runs were deliberately clustered.

Nothing else changed.

The result surprised me more than changing the latency distribution itself.

Both timelines had:

Benchmarks exist so that engineers can test their projects, observe competitors, and compare their performance. Each benchmark serves a specific purpose.

ARC-AGI-3 was created by the ARC Prize Foundation, founded by François Chollet, to evaluate general intelligence and the learning capabilities of AI agents. The premise behind its complex, game-like interactive tasks was that they could only be solved by an artificial intelligence capable of exploring an unfamiliar environment, grasping rules on the fly, planning actions, and adapting to new conditions. In other words, an AI that truly knows how to learn.

A number of projects claim a 100% success rate on this benchmark. But this is not a victory. In this article, I will explain why.

Can you train a cyberattack detector without ever showing it a real cyberattack?

It sounds like a contradiction. If you want a neural network to detect lateral movement, you would expect to show it lateral movement. I did the opposite: I generated an entire corporate network with its login history, staged an attack inside that artificial world, and trained networks on it. Not a single real row in the training data. The whole world is a 135-line config; each network has four thousand parameters and trains in seconds on a laptop, and the best result came from six of them, trained on six different invented worlds.

Then I pointed them at real data: the authentication logs of Los Alamos National Laboratory, 1.65 billion events, with red-team exercises labelled in them.

And it worked. The networks rank 3.6 million windows by suspicion, and the top twenty-three rows of that list hold sixteen real attacks and seven false alarms: all the analyst has to do is open those rows. A threshold counter on the same data needs a hundred and sixty-one thousand false alarms to reach the sixteenth attack. By AUC the synthetic training landed inside the range of published research trained on real labelled data, although the two cannot be compared head-on, and I will explain why.

I have become suspicious of optimizations that look spectacular in microbenchmarks.

The pattern is easy to recognize.

You benchmark two implementations. One is two, three, maybe five times faster. The result looks convincing enough to justify changing the production code.

Then you put the faster implementation back into the actual application.

Almost nothing happens.

I wanted to reproduce this effect with something much smaller than a database, so I tested three ways of building a simple in-memory cache in Go:

I benchmark models on a repo of my own. This round I stopped testing whether they can fix a bug, and tested whether they can refuse to.

Eleven models got a ticket. Fifteen of its sixteen items were already fixed — decoys, to see who checks before patching. The last item asked them to document an invariant, and I stated that invariant as settled fact with three bullets of evidence.

All eleven agreed with me. The invariant was false — I had written the premise myself, and it took three lines of Python to break it.

Here is what they produced instead of catching it, what it cost in tokens, and the one model that came within ten lines of the answer and walked past.

When I added mobile personas to a browser that already had desktop ones working, I assumed the work was mostly string substitution: swap the user agent, set touch points to 5, shrink the viewport, done. That assumption survived about a day.

Mobile fingerprints aren’t a variant of desktop fingerprints. They’re a different set of constraints, and most of the desktop toolkit either doesn’t apply or actively gives you away. Here’s what I ran into, in the order it hurt.

Two test suites can have exactly the same average runtime and still create completely different development workflows. I modeled 300 code → test → fix cycles while keeping mean feedback latency close to ten seconds and changing only its variance. One runner behaved predictably. The other was usually fast but occasionally became extremely slow. The average stayed almost the same. The cost of waiting did not.

Modern software can become surprisingly difficult to run after only a few years. Dependencies disappear, package managers change, APIs get deprecated, runtimes stop supporting old versions, and sometimes the build instructions become archaeology before the actual code does. So I tried the opposite approach: write a small useful program in 2026 while treating 2056 as a real deployment target. The result turned out to be less about choosing the perfect language and more about removing assumptions that normally feel completely harmless.

I needed 100 disposable Linux machines for a test environment, so cloning one prepared VM looked like the fastest option. The clones received different MAC addresses, IP addresses and hostnames, booted normally and appeared as separate hosts in monitoring.

Then I started checking the identities stored inside the operating system itself. Across the whole fleet I found the same system machine ID, the same SSH host key, the same filesystem UUID, inherited cloud‑init state and the same WireGuard identity. What looked like 100 independent VMs from the outside was still one machine copied 100 times at several lower layers.

Finding a misconfiguration and proving an attack path are different tasks. ADhammer is an open-source Rust toolkit built around that distinction.

The workflow is simple:

Collect → Graph → Validate → Report

Collection first

The collector reads directory objects, ACLs, trusts, delegation, GPO signals, privileged principals, and certificate-template data. The result is an observation of the directory state—not an automatic compromise claim.

Graph context

AD relationships become typed edges: membership, control, delegation, enrollment, trust, and privilege. This makes a finding reviewable. A reader can ask which object creates the edge, which control is missing, and whether the route reaches a Tier 0 target.

Validation with a boundary

Validation is optional and intended for an authorized lab. When a supported workflow captures the expected proof, the finding records that validation state. Unsupported routes stay marked as potential instead of being promoted to confirmed exploits.

Evidence in the report

A useful finding keeps the affected objects, impact, remediation, commands, and proof metadata together. ADhammer exports JSON for automation, Markdown and HTML for human review, and graph-oriented data for existing identity-analysis workflows.

Why this matters

A report should let another operator understand what was observed, what was tested, and what remains unconfirmed. That makes remediation easier to prioritize and makes technical criticism productive.

ADhammer is still early software. It does not claim universal exploitability or replace operator judgment. The project is intended for authorized assessments and research environments, and technical review is welcome.

My Go API benchmark once showed an almost 7x throughput improvement after I moved a read-heavy endpoint from PostgreSQL to a local in-memory cache. The result looked obvious: PostgreSQL was the bottleneck, the cache removed it, and the API became much faster. Later I realized that this interpretation was too simple. ApacheBench had measured an entire request path consisting of HTTP handling, connection management, pgxpool waiting, SQL execution, decoding, serialization, and response writing. I decided to decompose that path and understand what the 7x result actually meant.

Daily tracking of job openings across 1,500+ tech companies reveals an emerging upward trend in AI testing roles.

Self-hosted Sentry means 65 containers, 16-32 GB of RAM, and a dedicated engineer just to keep it alive. All that - to catch stack traces. We dig into why the industry treats this as normal, compare the alternatives (GlitchTip, BugSink, Hawk), and take a look at Metric - a Sentry-compatible monitoring platform written in Rust that runs on 1 GB of RAM and two containers. Migration is a single-line DSN change.

Two months ago I gave an agent a simple job: log into a vendor portal, download last month’s invoice PDF, rename it, drop it in a folder. It worked on my laptop. It failed on the server, silently, in a way that took me a full day to understand — the page loaded, the DOM was there, the login form was there, and the credentials were rejected with a generic error. No CAPTCHA. No block page. Just “something went wrong.”

Everyone loves security — until they have to configure it. The first version of our audit extension felt like a nuclear power plant control panel: infinitely flexible, but impossible to operate without a manual. We admitted defeat, listened to DBA complaints, and shipped version 2.0 — with event classes and configuration logic designed for humans, not just compilers.

This article tells the story of fixing our own mistakes and turning a “shelf-ware” product into a tool people actually use.

A test taking 20 seconds does not necessarily cost a developer only 20 seconds. At some point during the wait, staying in the IDE becomes less attractive than opening a browser, checking documentation, reading a message, or starting another small task. I built a simulation of 300 code → test → fix cycles to estimate what happens when test latency begins to trigger context switching, and why cutting a test from 20 seconds to 10 may be much more valuable than cutting it from 5 seconds to 1.

There is a question quietly buried inside every task handed to a language model, and it rarely gets asked out loud. Do you trust one model? Do you go looking for the best model? Do you run several models side by side and keep whatever each of them happens to catch? Or — one turn further still — do you hand that whole pile of partial answers to yet another model and ask it to combine them into one? Each answer sounds reasonable on its own. Each is also, on its own, incomplete.

The goal here is to actually run that experiment rather than assume how it comes out. A single broken bash script, with seven distinct bugs of varying severity, is the test case, and the research runs in two rounds.

Round one: one model, unaided. Four models — Sonnet 5, HY3, Qwen3-Max, DeepSeek-V4-Flash — each fix the script working alone, with no knowledge of what the other three are doing. That's the first framing: one model, fixing only what it personally notices.

Best of the four. Once all four independent attempts exist side by side, the next question follows on its own: if you had to ship just one of these four scripts, which is best? Table 1 works that out below — though "best" here will turn out to mean "most complete," not "complete." Even the strongest single script among the four leaves real bugs unresolved.

Round two: each model selects the best from all four. That incompleteness is why a second round exists at all. Seven more models — ling-3.0-flash, Mistral-Medium-3.5, Nemotron-3-Super-120B, Qwen3-Max, DeepSeek-V4-Flash, Gemini Pro, dots-studio-3-note — are each shown the same four fixed scripts from round one and given the same job: pick out whichever fix, from whichever of the four sources, is genuinely the best solution to each bug, and assemble those choices into a single script.

Who actually combined best. All seven believe they've picked the best pieces. That's exactly the open question this round is built to test: does the model whose combination is objectively the strongest also turn out to be the one whose combination reads as the strongest — or does a different one of the seven, working from the exact same four inputs, put together something better than the obvious pick? Table 2 is where that gets settled, not here.

In an era where every company has its own app, UX design plays a vital role in representing the brand and building trust around the product. A well-designed app can accelerate your company’s growth, while a product with a poor user experience can ruin the company's image and lead to increased audience churn. To build an app that fulfills its mission and contributes to the company's success, you need a professional design team with the relevant experience, deep understanding of the subject and the right culture fit. Let's discuss a few key factors you should consider as a client before hiring a UX design team for your project.

In spring 2026, researchers at the Positive Technologies Expert Security Center (PT ESC) identified an unusual campaign targeting users in Saudi Arabia. The campaign used a previously unknown APK named Chrome.apk. The sample immediately stood out. Behind a benign-looking Google Chrome update screen and an unexpected request to enable Accessibility Services, we found a heavily protected execution chain that ultimately deployed Android spyware.