My feed

Researchers and developers are increasingly warning that LLM-based agents exhibit dangerous, unpredictable properties. These properties potentially threaten not just the stability of internet platforms, but humanity as a whole.

Some propose halting model development until policies and tools guaranteeing safe agent behavior are designed and implemented. I believe this might yield some effect, but overall, these efforts will fall short of the expected results.

In this article, I examine anthills, humans, and LLMs to demonstrate exactly when an agent ceases to be merely an agent. The properties developers are trying to guarantee at the individual agent level actually emerge at the level of the "agent plus environment" system, where the individual agent does not dictate the overall trajectory of the system.

For 30 days, the IDE stayed closed after 8 PM. I expected the experiment to affect sleep, but the more interesting result appeared somewhere else: in Git history. The month produced fewer bug-fix commits, shorter debugging sessions, and a surprisingly different defect pattern. So I wrote a couple of scripts, reconstructed where several bugs had actually come from, compared the results with the previous month, and ended up changing the way I think about late-night coding.

A practical task arose: in a confined space (a narrow hallway, stairwell, or vestibule), monitor activity, take a photo of the area, and notify the user by forwarding the photos to Telegram. It is known that a standard household motion sensor, which turns on the lighting, is installed in the monitored area.

What happens if a modern coding AI is allowed to solve new requirements but forbidden from using modern tools? I built a tiny contact database in ANSI C, gave the model a deliberately 1995-style environment, and then kept changing the requirements. No SQL database, no package manager, no JSON library, no framework, no containers and no external dependencies. Twenty changes later, the program was still valid C89, but somewhere along the way it had acquired schema versions, migrations, an audit log, safer file replacement, a storage interface, validation and query structures. The interesting part was not that the AI ignored the rules. Most of the time it followed them surprisingly well. The interesting part was how quickly it started rebuilding the ideas those rules were supposed to remove.

WebGPU gives the browser direct access to modern GPU capabilities — not just for rendering, but also for general-purpose computation through compute shaders.

But how far can we actually push it? What happens if, instead of running a small compute demo, we try to build a full simulation with tens of millions of active objects? That is what I wanted to find out.

I'm part of a systems support team, where alongside diagnostics and incident troubleshooting I also do development work. One of the systems we support ingests telemetry from a large fleet of IoT trackers installed on vehicles. Every few seconds each device reports its coordinates and status parameters. An internal processing service turns that raw stream into higher level business objects: events, incidents, trips, that the rest of the platform consumes.

The system has been in pure maintenance mode for years. No development budget, no vendor to call. It still has to be supported though, people use it every day.

Every so often one device develops a hardware fault and starts “spamming”: emitting an abnormal volume of points or malformed events in a short window. That degrades the processing pipeline not only for that device, but for everyone sharing it.

Finding the culprit used to mean a first line engineer manually pulling several raw tables for the relevant day (events, incidents, raw points), cross referencing them by timestamp and device ID, and eyeballing the result for anomalous patterns.

With the events table alone running 2 to 3 million rows a day, that was a 6 to 7 hour job, basically an entire shift, with no guarantee of actually finding the source.

I gave the same AI model 20 Python programming tasks twice: once with a short prompt and once with a detailed specification. I expected the detailed prompts to win easily. They did help with some edge cases, but they also produced more code, more abstractions, and several bugs that did not exist in the shorter versions.

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.