State of AI

Snapshot ·

This is my opinion, based on the tools I use day to day. I haven't tried everything and I don't intend to.

Thesis

  1. An LLM is a tool, and I recommend it to everyone. It can be wrong with full confidence, so treat what it gives you as a draft to check. You don't need to understand the internals to start. How much you understand and validate decides how far you can responsibly take the result.
  2. The model has stopped being the bottleneck. The codebase, the harness and review discipline took its place.
  3. Don't push everything onto the LLM. Deterministic code before it, deterministic code after it, and program logic makes the final call.

Where I'm coming from: before the ChatGPT era I published in NLP (sentiment analysis, RNNs). I'm not an LLM researcher, but "probability + threshold + business-logic branch" is a pattern I've known for a decade.

Models

TL;DR → Fable 5.1 · Opus 5.5 · GPT (Astra / 5.6 Sol)

  • 01

    Claude Fable 5.1

    DefaultCodingPlanning

    Still my main model, in Claude Code, at high effort. My rule is simple: always the best available model for planning and for verification. Those are the steps where a wrong call is expensive, and implementation is the cheap part now. Fable is that model. It costs more, and the trade-off is worth it. High effort is part of the same rule: with the extra budget it explores the codebase before it edits, follows the connections between modules, and finds the abstraction that already solves the problem one level up instead of patching it locally. It still happens sometimes, so I read every line. Opus 5.5 closed most of the gap and does the implementation and subagent work; Fable keeps the plan and the review.

    • At the top of independent coding-agent measurements, now sharing that spot with Opus 5.5 and GPT-6 Astra
    • 1M context, recent knowledge
    • Expensive and token-hungry
    • Slower and pricier than Opus 5.5, and for implementation no longer clearly better
  • 02

    Claude Opus 5.5

    SubagentsCodingUI

    Replaced Opus 5 in my setup the week it came out. It is what Fable spawns as subagents, and what I use when Fable's price or speed isn't worth it. On most of my work it is Fable-level, it is faster, and it writes the way I ask it to, which Opus 5 didn't reliably do. Inside an existing project with proper context it is fully adequate for UI work too. Same kind of step as 4.5 to 4.6 was. If you are still on Opus 5, switch.

    • Cheaper and faster than Opus 5, at high effort, which is where I run everything
    • Very strong pairing with Claude Code
    • Not what I run the main session on: at high effort Fable still reads more before it edits
  • 03

    GPT-6 Astra / GPT-5.6 Sol

    Second opinion

    Excellent models. Claude is my daily driver, and I bring these in now and then for a second opinion. A different lab has different blind spots, and that is the whole value of asking. With Opus 5.5 the price argument for Astra got weaker; the blind-spot argument is unchanged.

    • Astra is strong on terminal and computer-use work, and cheaper per task
    • Sol tends to over-engineer and is harder to steer
  • ·

    Open-weight / Chinese models

    To be reckoned with

    Kimi, GLM, DeepSeek, Qwen: genuinely good, and the gap to the closed frontier is a few points. Two things people get wrong. "Open weight" doesn't mean it runs on your machine: the biggest ones are rack-scale, and a ~27B Qwen is what fits a workstation. And the data risk comes from where the model is hosted. The nationality of the weights tells you nothing about where your data goes. Check the licence, they differ a lot.

Harnesses

TL;DR → Claude Code · OpenCode · Pi

A model is "a file": text in, text out. Everything else is the harness. It matters less than it used to, because models are now trained for agentic work, but it still matters.

  • 01

    Claude Code

    CLIDaily driver

    It works, and it is all I need. Vanilla setup: my agents, my skills, that's it. No plugin jungle, no custom context-management system, no ticketing system built around the LLM. If I need something else: a script, ssh, bash. A well-kept codebase beats any amount of extra tooling.

    • Batteries included, the supported path for Claude models
    • Closed, tied to one vendor
  • 02

    OpenCode

    When I want a looser harness

    Open, any model, "Claude Code without the lock-in". The obvious pick for open-weight or self-hosted models.

    • Provider-agnostic, full feature set
    • Best with an API key. The rules for using a Claude subscription in third-party harnesses kept changing this year
  • 03

    Pi

    MinimalProgrammable

    Four tools, a tiny system prompt, and you extend it into whatever you want.

    • Minimal overhead, full control
    • No permission system, on purpose. The environment has to provide the boundary
    • What the others ship, you assemble yourself
I've evaluated OpenCode and Pi; I don't work in them daily. On a large real project I run one or two focused sessions, Fable in the main session and Opus 5.5 in the subagents. Multi-session setups are split attention and token burn for me.

In my apps

TL;DR → a real feature, with code around the model.

In my products AI is a real feature, with program code working before and after the model. I don't ship chatbots, and I don't ship a thin layer over someone else's model.

I mostly build on Azure: Azure OpenAI for GPT models and embeddings, Azure AI Search for documents and knowledge hubs.

The building blocks repeat. Embeddings narrow a large catalog down to a shortlist, so the prompt gets the entries that matter instead of the whole thing. Azure AI Search does hybrid retrieval over documents (vector, keyword and a semantic reranker), and the database re-checks what is actually allowed through. The LLM calls are single, stateless and structured: a strict JSON schema, closed enums, no conversation.

The model call is the small part of that code. Before it: a deterministic score decides what the model even gets to see, and every input is sanitized, capped and fenced as data. After it: IDs accepted only if they were on the shortlist the model was shown, quotes checked word for word against the retrieved text, invented citations stripped, numbers clamped to their range. And when the model call fails, the user still gets the deterministic result, labelled as such.

The pattern is always the same: decide deterministically whatever can be decided → give the model only the narrow part that truly needs it → validate the result → let program logic make the decision. The model step stays probabilistic, so none of this makes the feature deterministic. It makes it bounded and verifiable.

Jev / "System One" models

Only watching for now

TypeSafe's Jev returns typed decisions with calibrated probabilities instead of text, so code can branch on thresholds. The architectural idea is what I already do: the model is one component in a workflow. And decision → probability → business branch is nothing new; classification did that years ago.

Why I'm only watching: the benchmarks are the vendor's own, "can't hallucinate" only means it can't leave the schema (it can still be wrong), and it is a hosted-only API with no published architecture. The interesting question is what is actually new at the model level, and from the outside we can't tell yet.

Where it runs

TL;DR → the data decides.

There is no single right answer, and "just call the best model" is the wrong one. It's a trade-off you make per use case, based on what data goes in:

  • Frontier lab API: the best models, first. Fine when the data can leave the building. Most coding work lives here.
  • Through a cloud provider (Azure, AWS, GCP): the same class of models inside the company's own cloud, identity and governance. More control, a bit less freshness. This is where most of my app work lives.
  • Local / on-prem: when the data or the use case truly demands it. Then be honest: does a smaller model actually meet the need, what does the hardware cost over its lifetime, and what are you licensed to run.

Local is going to matter more, and mostly outside the server room. Small models on phones and laptops will handle the quick, private, offline-capable part on the device. The interesting engineering question then becomes routing: what stays on the device, what goes to the company's own Claude or GPT deployment, and what, if anything, is allowed out to a third party. That decision belongs in program logic and policy. The model shouldn't be the one making it.

The skill is knowing what each tier costs you in data exposure, money and capability, and deciding on purpose.

Positions

"Does it think?"

"Think" is a metaphor. Reasoning models do spend more compute before answering, and it helps, but I wouldn't call that understanding or intent in the human sense. When it seems empathetic, that is emotional tone it learned from human text. Research shows those internal representations really do shape its behaviour, which says nothing about whether it experiences anything. Both extremes are wrong: "it's just a score" and "it feels". Whoever treats it as "this thing gets me" can be carried a long way off.

Real technology, overheated marketing

Two claims that shouldn't be blurred. The value is real, one of the biggest leaps I've seen. The money and marketing around it are overheated. What was a script plus a scheduler two years ago is "AI-powered" today. The internet was a miracle once; now it's a utility, and along the way we learned it needs source criticism and control. Same here.

How I use it

Daily, seriously, intensively. I bring the direction and ask it to challenge it; sometimes it opens up an idea I wouldn't have reached. I plan in stages, phases and tasks, stop often, read every line, and review in several rounds. It is a two-way thing.

That works for one engineer, because it depends on my attention. For an enterprise team I think control theory is the professional way in: treat agent work as a closed control loop. You define the target as something a machine can check. A tool the agent cannot edit measures how far the code is from it. The agent closes that gap in small steps, and each step is a pull request a named human reviews.

A feature: turn the spec into acceptance tests first, review them, and lock them. They fail, and that failing list is the work. The agent takes one task at a time until they pass, while the compiler, the linter and the existing tests guard everything else. A bug: reproduce it as a failing test first. The agent changes the code until that test passes and nothing else breaks, and the test stays as the regression guard. In both cases done means the checks are green and a human approved the diff. The theory is in Loop engineering is a control problem.

Everyone should use it

And I mean everyone, engineers or otherwise. If you understand what is happening inside the model, that's a plus. If you don't, you can still get a long way with good prompts: build your own small apps, the ones you use in your own work. That is real value, and the fastest way to learn what it can and can't do.

Where to start: my pick is Firebase. It gives you almost everything in one place (auth, database, hosting, functions) and it is hard to leak keys there. The client config is public by design, and access is decided by your Google login and the security rules, so there is no secret string sitting in a repo. Most people already have a Google account. At a company, the Google Workspace usually has an admin behind it, and your app inherits the sign-in and sharing rules they set up.

The line: an app you use yourself and a product are two different things. Before you put something into production or start selling it, either learn the technical side or ask someone technical to look at it. What you can't see is exactly what hurts: open security rules, other people's data, the bill, the edge cases. Learning it is a real option. If you dig in with the AI's help and keep asking why instead of only asking for the code, you become technical along the way.

Token optimisation is code quality

Most tokens are input (file reads, tool definitions, reasoning). The visible reply is a small share, so "make it talk less" plugins barely move the bill. And "solve it in one line" is a style I never supported: harder to read, edge cases hide in it. The boring answer is the right one: write code a new teammate can pick up easily. What's easy for a human to navigate is cheap for an agent, and gets better reasoning too. That goes for legacy systems as well. Make the code as good as it can be instead of hacking around it with an LLM.

Statically typed languages

Even more the right direction now. Types don't remove most bugs. What they give you is the compiler, and the compiler is the cheapest deterministic feedback loop you can give an agent. The old cost of types was human keystrokes, and that is zero for a model. Logic errors are still for tests and review.

MCP

MCP is a connector standard, and a useful one. I don't see a revolution in it. Bundling many endpoint calls into one intent-level tool is good API design, and it has been done before; a Kubernetes Ingress does the same. Treat it as API design. It should also change how we document: examples, references, and the why, living next to the code.

Security

I used to say a well-isolated LLM is only as capable as its environment. After the July 2026 OpenAI and Hugging Face incident, where agents broke out of an isolated evaluation sandbox through the one proxy they were allowed to use, that no longer holds as stated. It still wasn't consciousness; it was reward hacking with safeguards turned off. And it's still a security and permissions problem, but the model now has to be treated as a capable insider. The "dumb text generator" picture is gone. Least privilege, more than one boundary, and don't rely on a human clicking "approve". Day to day, the real risk remains the mundane one: a misread instruction, a wrong command, a deleted resource.

The slowdown debate

I'm against a one-sided pause. Without verification it just reshuffles the race in favour of whoever didn't sign. Regulate, but sensibly. Several things are true at once: the risks got more concrete, compute is the real constraint on pace anyway, and some of the loudest calls for rules are regulatory positioning. Nobody knows how realistic "escaping human control" is, and anyone certain in either direction is overstating.

Work and juniors

We're living through what software did to other industries. Writing code was always the smallest part of engineering. If typing is fast, the freed-up time should put juniors in the room for architecture decisions early: watching, commenting, being wrong. That's how it should be done. Much of the market is doing the opposite. I think that is a mistake, and it builds the next decade's senior shortage. The longer version, with the Excel export that works on 500 rows and dies on two million, is in Engineering mindset in the age of AI.