olooney

Big fan of VnM theorem, which this article alludes to in passing. I think it asks a really great question: "can we make good decisions under uncertainty?" And the answer turns out to be "Yes" with some caveats.

This is basically correct but there is some nuance. First of all, people working on unoriginal or very small scope stuff, such as app clones or ad hoc analyses in notebooks, will never hit that wall. They'll never even know the wall is there. This is a bit annoying, because they then generalize their experience with toy projects and come away with the mistaken belief that anyone could make anything if only given enough tokens. This is most problematic when they are in leadership positions.

However, the real value is in complex, non-trivial, and above all novel code. This has been true for a long time, and it's just as true in open source as it is in industry or academia. Here, agents are far less useful. In fact, the only people I've seen have any kind of success using agents on these kinds of "serious" projects are people who are already serious programmers. They already know how to design and test stuff, they already know how to supervise junior developers, they already have an intuition for which aspects of the project the can safely delegate to a less experienced developer. So they're able to use agents as a "better autocomplete" in their own code, or use it to flesh out the non-essential and more routine aspects of the project, or even just delegate the agents to the role of code reviewer.

Here's the thing though. The less experienced ones, the people who don't already have those skills, they do get burned when they "stick the fork in the socket," as you put it, or in other words when they try to use agents to take on projects they don't fully understand... but they don't learn anything! The ones I've seen, anyway. Relying on agents insulates you from the code, which also prevents you from building a mental model of what's going on under the hood, which in turn makes it impossible to learn anything at all. They just keep yelling at the agents, telling them to fix stuff even though each fix introduces yet another regression in an endless loop... they don't know how to dig themselves out of the hole they've dug. And after all, what is the solution? To spend five years down in the code mines, paying your dues as a junior dev, reading and typing and thinking about mere code for the requisite 10,000 hours? Nobody has the time or inclination for that.

Agents, in other words, break the learning loop. You can't learn to program, and therefore can't learn to design or architect software, not really, if you're using agents. I am unfortunately coming to the sad conclusion that the last programmer has already been born; if you didn't have 5+ years of experience and a pretty good handle on the more advanced aspects of programming (such as software architecture, design patterns, optimization, debugging, etc.) before agentic programming became a thing, then I don't see how you ever will.

It'll be like COBOL programmers - the industry will shrink from the top-down, with the first to go being the new college graduates looking to enter the workforce. Inexperienced devs have always been given less interesting projects, but they stuck it out because they were learning valuable skills, building experience, making the economically rational decision to invest in their own career. But anyone entering the market today will never get out of that trench - anyone that actually needs a real programmer for a serious project will hire someone with decades of experience - there will be plenty of supply. And the projects on offer for junior devs won't teach them how to program, only to supervise agents. As a knock-on effect, smart young people already see the writing on the wall and are pivoting to other majors, which just reinforces the trend. This might cause problems in a few decades when all the real programmers start to retire, but when has the market ever considered long term consequences?

Seems like an easier approach would be to just make all your keywords strings that trip safety filters.

Or use a graphical language like LabVIEW. I'd like to see an LLM drag connectors around using Playwright MCP if it doesn't have a DOM and has to script mouse movements and take screenshots. They can probably do it but it would be unbelievably slow and token heavy.

The character counting is interesting but I predict frontier models are going to give up on tokens and just traim end-to-end on characters soon, just as voice models have largely moved past phonemes and for pretty much the same reasons.

Twitter over 300 million daily active users. 13,000 is 0.004% of that.

A standard drop of water is 0.05 ml. A standard household bucket is about 3 gallons. So the proverbial "drop in the bucket" is 0.0004%.

So, for all you naysayers out there saying this is just a drop in the bucket, it's literally x10 that.

Why, if they could get this up to a repeatable process and ban 13,000 accounts per day, that would be 1.5% every year. After a couple of years of work, that might even be perceptible to the average user. Sounds like the problem is well in hand.

Since the frontier model scored 10/10, it saturated the benchmark, so there is no meaningful way to detect if the harness provided any benefit. You cannot conclude that a calculator provides no benefit when doing multiplication just because you ask me ten easy questions like "what is six times seven?" and I get all ten correct, the same as the calculator.

Given that, all the study found was that harnesses do work when the benchmark is not saturated. It does not provide any evidence one way or the other about the effect harnesses have on frontier model performance. Therefore, the recommendations in the "what this means in practice" section are unsupported.

Prism example fails to correctly draw the crossing between A' -> C' and B -> C. There's a `"crossing": true` in the JSON config, but this seems to be missing from both morphisms m169 and m171, so I think this is a bug in the example, not the tool.

Not a font. The VHS line striping is just a repeating gradient applied over the whole page:

    main::before { 
        background: 
            linear-gradient(rgba(18, 16, 16, 0) 50%, rgba(0, 0, 0, 0.25) 50%),
            linear-gradient( 90deg, rgba(255, 0, 0, 0.06), rgba(0, 255, 0, 0.02), rgba(0, 0, 255, 0.06) );
    }

The red glow is a red text shadow applied to every element on the page:

    :root { 
        --text-shadow: 2px 0px red, -2px 0px var(--glitch-color-2);
    }

Surprisingly, the glitchy logo is also done with CSS, with animations over two different versions of the text overlain atop one another:

        <span>explorator.dev</span>        
        <span>єӿƿłøгⱥʈøг.ᑻ</span>

I know this because the first thing I did when I got to the page was hit F12 to bring up the debugging tools and turn these styles off so I could read it. :)