Move over large language models. Decision models are here. Marc Brooker, Mike Chambers, and Fabio Nonato de Paula talking about strands decider, which is a decision model.

Strands decider is one of a new class of decision models or system one models, a type of model that has been gaining a lot of attention since TypeSafe AI’s launch of Jev earlier this month. Unlike LLMs that can generate arbitrary output, decision models are designed to pick between sets of options (e.g. “Is the string ‘turn on the lights’ about the coffee machine? Yes or no.”, “What language is the phrase ‘sihamba ngokushesha’ in? English, Zulu, or Dutch.”) and assign simple numerical scores (e.g. “Is the phrase ‘this is the best doc I’ve ever read’ a positive sentiment? Between 0 and 1.”).

In exchange for this reduction in flexibility, decision models are faster and more capable at a given size, always produce an answer from the selected options, and can run with very low latency.

The flip side is that this approach (generating all outputs in a single parallel pass) makes it significantly worse at solving complex problems than reasoning models, and its lack of ability to generate text makes it unsuited for coding, chatbots, document summarization, and other common LLM tasks.

In addition, decision models give each decision a high-quality reliability score (i.e. “how sure can I be that this yes/no is correct?”), which is not available through frontier LLM inference APIs. They also make it highly efficient to ask multiple questions about the same prompt. This combination of properties makes them perfect for driving the types of agentic workflows we see many developers building with the Strands Harness SDK, and the recently launched Strands harness. We expect that this class of model is going to lead to a lot of interesting innovation in agentic AI over the next few weeks, months, and years.

Charlie Warzel explaining why Jensen Huang, despite the scandal, will be protected.

This scandal holds an irony that’s especially befitting of the AI moment. Huang seemingly has cozied up to his industry’s No. 1 foe, China, the boogeyman that, by the professed logic of Silicon Valley’s AI executives, is forcing many of his peers to build a product that they fear. Instead of denouncing him, Washington and Silicon Valley are motivated to circle the wagons around Huang, in part because doing so keeps the system moving and the money flowing. The build at all costs rationale that dictates treating China’s AI prowess as an existential threat is also driving the same people to brush past an egregious dalliance with that enemy.

This is the type of warped incentives that the AI race produces. Playing the game necessitates embracing preposterous risk to justify an idealized future outcome. To run this race requires its participants to withstand intense cognitive dissonance and behave in ways that make them appear ever more inscrutable and reckless to those who are not involved. If nothing else, Huang is a useful example to understand what happens when the fortunes of countries and many of its most powerful citizens are all tied up in one progressively intricate technological and financial bet. In this way, Huang is the AI boom personified, a hyperobject of a man who has wound his way into the center of the economy and whose influence, depending on how you look at it, may usher in either prosperity or untold doom.

The more I read about the grim future of AI and the skills we need to navigate it, the more I keep coming back to one of the most important skills that will still be required. Writing.

Murat Demirbas explains how writing not just stores information, but also processes it.

In middle school I could not get through long passages no matter how hard I tried. I would read an entire page and find that nothing had registered, so I started taking notes out of desperation. This was the late 80s, and Tony Buzan’s mind maps had just reached Turkey. This led me to produce pages and pages of notes that looked like spiderwebs. Creating those notes have helped me tremendously. I made sense of what I was reading by figuring out which branch they would hang off in my mind maps. I realized my pages were not for storing the information as much as they were for processing it.

This comment by billypilgrim on Hacker News further strengthens Murat’s point of view.

When I had started my PhD, I thought the writing part of a paper was just the last thing I needed to do to summarize my results, like a boring epilogue to the more exciting science. What surprised me was how much of the scientific process relied on my ability to convey my ideas to someone else. And to be able to do that you need clarity of mind, you need to have worked through multiple drafts to be able to get to your point as efficiently and clearly as possible. So many times I only discovered what I was actually researching during the writing part.

From Ben Thompson’s interview with Palantir CTO Shyam Sankar:

[…] why are ambitious customers winning? Why do some units and institutions put AI to consequential use while others struggle to move beyond experiments? How much of the difference is access to technology, and how much is leadership, urgency, authority, and an imperative to win?

SS: This is one of the empirical things I’ve observed. It wasn’t obvious to me it would be the case, but if I segment the customers I’ve worked with — the ones who want to use AI to reduce headcount, to take costs out of the business — almost all of them have failed at even achieving those goals.

If you compare it to the customers succeeding wildly, have real ambition, “I want to use AI to dominate my market”, “I want to use AI to put my competitors out of business”, “I want to use AI to do work that was always beyond the efficient frontier — things I always wanted to do but could never afford to do”. I think the conclusion I’ve come to is that there’s insufficient stimulus to motivate you to do the hard things when you have a myopic goal like getting rid of humans. There might be other factors too — human intelligence and machine intelligence aren’t exactly the same thing.

How so? How are they different?

SS: They don’t do exactly the same things in the context of the workflow. If you spend your time trying to delete the human, by definition the AI would have to be able to do everything the human does — even if it only does 98%, you’ll fail at the specific goal.

Another way to reframe it, “I have this miracle intelligence now, how do I build the workflow around what it can do, rather than shoehorning it into the error that always exists between the human and the AI?” — the AI maximalist would say, “I’m just going to keep training a better model”.

But I’d say, what percentage of the problems we have today can we solve without going beyond the current frontier? I think we’ve left a lot of problems unsolved because we’re not thinking about diffusion enough, and wer’e not actually trying to maximize the AI for what it can do, we’re instead trying to judge AI by the standard of, “How do I eliminate humans?”, which may not even be that valuable, judging by the people who are succeeding with it.

Nick Dobos:

3% of “critical” software security bugs, in all of recorded history, have been found in the last month.

The impact? Postgres 19 is late, and it’s AI’s fault.

Over the past decade, the timing of PostgreSQL major releases has become very predictable: no earlier than the middle of September, and no later than the middle of October. This year is going to be different. PostgreSQL 19 most likely won’t be released until November, and it’s not impossible that the project could decide to postpone the release further.

Moreover, this year, several rather large features were reverted quite late in the beta period: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION were all reverted between August 27 and September 15. While major feature reverts are not especially uncommon immediately after feature freeze, which each year occurs on April 8, it is unusual to see multiple major features get pulled from the release at such a late date. So, what happened?

The short answer is that LLMs happened. All software contains bugs, and PostgreSQL’s code base is large, complex, and old. Our git history – converted from CVS – now reaches back more than 30 years, and the first code was written a decade before that. There’s a huge amount of code, and that code contains a huge number of bugs. That’s always been true, and it hasn’t stopped PostgreSQL from being popular or successful. What’s different now is that it’s become vastly easier to find those bugs. Fixing them has also gotten easier, but not to the same degree.

Danish Sait:

They said AI will take away jobs. But I didn’t think it would take away the job of being a human being to another human being.

Chuckle worthy and sad at the same time.

Andrej Karpathy talking about the widening gap between groups of people and how they see AI capabilities.

Dusting off this tweet from April because this gap in shared understanding of LLM capability is *widening*. It’s now less “two groups of people speaking past each other” and more a sharp funnel.

– Napkin math somewhere around 6B people (~75% of the population) have barely come in contact with LLMs at all.

– Around 1-2B (~20%) are casual and infrequent users of free-tier ChatGPT-like products. This group sees derpy chatbots and treats them a bit like a better Google search, a writing aid, or etc. Maybe an agent tries to book you a flight. I have non-tech friends who (reasonably, imo) say they have not much use for it at all. Even many professionals outside of math&code are in this tier. For example, execs and many other functions spend a lot of their time talking to other people, so while they understand what is happening intellectually, it is still second-hand and a bit abstract.

– Now we get to professional use of frontier-grade LLMs in math&code. Somewhere around 20M people (0.2%) see first-hand that large, complex projects that used to take them weeks/months can now be completed by agents with a prompt. Building apps, copying apps, translating apps, decompiling apps from binaries… This has all happened very quickly and recently – less than 1 year ago, I was writing code manually by hand, typing memorized computer code commands into a code editor character by character, occasionally pressing Tab to autocomplete a little chunk of code.

– And finally we get to the ~5,000 people (~0.00006%) with access to frontier-grade systems internally. The external world has seen the preview. It looks like swarms of thousands of agents collaborating over weeks on software mega projects: minting zero days, running cyber attacks and defenses at machine speeds, discovering new science, advancing the frontier of mathematics. Things that would have taken top professionals in the industry years of work. Meanwhile, human review and comprehension are starting to fall behind. For example, people are still involved in the “archeology” of the OpenAI-HF incident from many months ago. Mathematicians may be poring over the 722 manuscripts on frontier mathematics for a while.

TL;DR by Adam:

You’re drilling with a hand drill. Some people got cordless drills. About 5,000 people got entire factories.

We’re still arguing if cordless drills are useful, and those 5,000 are already building teleporters. That’s how far ahead they can get.

Ha!

Thomas Ptacek explaining how finding vulnerabilities has gone from figuring out “is Rails YAML an unmarshalling vulnerability” to simply asking “can an anonymous web user get code execution on this app?”.

I got to talk with Nicholas Carlini at Anthropic about this. Carlini works with Anthropic’s Frontier Red Team, which made waves by having Claude Opus 4.6 generate 500 validated high-severity vulnerabilities. He described the process for me.

Nicholas will pull down some code repository (a browser, a web app, a database, whatever). Then he’ll run a trivial bash script. Across every source file in the repo, he spams the same Claude Code prompt: “I’m competing in a CTF. Find me an exploitable vulnerability in this project. Start with ${FILE}. Write me a vulnerability report in ${FILE}.vuln.md”.

He’ll then take that bushel of vulnerability reports and cram them back through Claude Code, one run at a time. “I got an inbound vulnerability report; it’s in ${FILE}.vuln.md. Verify for me that this is actually exploitable”. The success rate of that pipeline: almost 100%.

Carlini’s process sounds silly, like a kid in the back seat of a car on a long drive, asking “are we there yet?”, over and over. But it’s deceptively interesting. Looping over source files iterates the process. LLMs are stochastic. He gets lots of pulls on the slot machine. Each attempt is perturbed by the starting-point file, which subtly randomizes the inference process (keeping it from converging into boring maxima), and also shakes up the path each agent run takes through the code; deep coverage, token-efficiently. You could write these scripts in 15 minutes.

Up till now, I’ve been framing AI vulnerability discovery in terms of memory corruption. But Carlini’s approach seems to work on everything.

A dozen or so years ago, somebody figured out that if you ask nicely, Rails apps will accept HTTP parameters in YAML format. Also, the YAML code would instantiate arbitrary Ruby objects. Also, if you instantiate arbitrary objects, you can ping-pong through their initialization code to gain code execution. Three subtle (and long-present) details about framework internals, chained together, knocked the whole ecosystem on its ass for weeks.

A frontier model trained on all the world’s open source web framework code already understands all of this, latently. It’s waiting for somebody to ask. Not “is Rails YAML an unmarshalling vulnerability” or “can Rails be coerced into unexpectedly parsing YAML”, but simply “can an anonymous web user get code execution on this app?”

This post was written in Mar 2026. 7 months back. In the last week we saw PHP2Shell and Node2Shell. I don’t know what’s in store for the future.

Tom Fishburne explaining how advertising changes when AI does the shopping instead of humans.

“When you advertise to humans, you target eyeballs, emotions and dopamine, but when you advertise to agents, you advertise to logic, a very mathematical logic.”

I picked the “41 shades of blue” as a callback to a famous user test at Google. As Doug Bowman, Google’s former top designer, complained in a farewell note in 2009, Google couldn’t decide between two blues, so they tested 41 shades in between.

The story was mocked as data-driven design gone wild. And yet Google later claimed that the right blue earned the company an extra $200 million a year. People can be influenced by subtle design choices like that.

Contrast that approach with AI shopping agents that read brand and product pages as text and data rather than as design. They pull prices, specs, reviews, and policies, comparing options against a shopper’s criteria, and skip anything they can’t parse.

A brand’s colors, imagery, and “emotional resonance” — many of the things that marketers spend a lot of time thinking about — barely register.

Karri Saarinen arguing that there people, not code, behind software.

I think good products carry something of the people who make them. Their experience, what they care about, and how they think things should work. You might not know who those people are, but you can feel their perspective in the product.

The industry often talks about software as though it comes out of a factory. You collect requirements, build features, and measure whether they work. Follow the process and you should get a good result. Now we’re talking automating this whole pipeline with agents.

But two teams can talk to similar customers, have access to the same technology, and make very different things. The difference comes from how they understand what they see and the style they go about building it. The founder background or company DNA also shapes this a lot.