blixt

I always found Erlang (and Elixir) to be an interesting use case for this kind of agentic harness. It can run distributed across machines and can hot swap any function. It's order of magnitudes faster to update, and often easier to introspect and keep compatible over time.

I built something for this and also found that the idea of a "guardian" core that can detect misbehavior (crashing etc) and roll back a messed up state really helped. But it's a lot of work to get a harness to behave well, and each model reacts differently to the harness limitations, so I found more success in building a meta-harness instead (just run existing harnesses inside a common UI and inject all capabilities).

I've programmed for 30 years so I'm probably mentally locked into thinking about the code underneath it all. But I never understood the details of the electrons moving around in the computer, and it took a long time to even consider what happened as my code trickled down the compiler/JIT, into the OS, down to the CPU.

I don't think it's productive to tell students today they must spend all their time understanding the code. Because it's clear now so many people will bypass that, even myself included. Some of the most fun I have with software these days is figuring out how to make it without looking at the code (for now on side projects only, see below).

I agree we're not quite all the way there yet to do this with large production systems. Yes, LLMs are highly fuzzy and non-deterministic things, but so are electrons! As computers improved we handled random bit flips that would occur due to a large number of unpredictable reasons. In either case, we have to reach a high enough confidence and redundancy bar that it doesn't hinder our productivity.

Raising confidence and redundancy in code output from LLM is still a nascent field. We're learning some things like "maybe unit tests don't work as well for LLMs as they did for humans", and "if the AI can self-evaluate in a loop against a factual number, it does a lot better".

But yeah, in this rapid wave of change I would consider "write the code yourself" more and more similar to "know how your CPU does branch prediction so your loops perform better", and the majority of our efforts will need to go into raising our confidence in this new fuzzy shape of software.

This reminds me of a great series on YouTube called "Can You Draw Every Flag in Powerpoint?"[1] and the guy does his darnedest to do it precisely, and in the process you learn just how specific (and sometimes non-specific) flags are!

[1] Part 1: https://www.youtube.com/watch?v=w5QSVhgrqVE

I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?

It would seem like GitHub is in a precarious situation.

We have many agents per employee working in parallel pushing way more commits than was humanly possible before AI, triggering GitHub actions a lot more than the workflows were built for, causing Actions costs to escalate (they really aren't cheap if you compare to hosting it yourself), meanwhile working with YAML workflows is just a pain, and just writing code would be so much more fun and AI compatible[1].

At the same time, GitHub has about ~3 different PR review UIs? And they're all half-bad? Any decently sized PR triggers their "optimized for large PRs" UI which jumps around randomly in my experience. If you don't get that UI and keep the scrolling one (there's an old and a new one btw) then god forbid you click a line number because at some point your browser will randomly scroll back to that line and it won't unstick. Now Linear[2] (and others) is replacing the PR review experience for the agentic era.

I'd love to see a solid AI first Git + CI + reviews.

[1] Cloudflare CI https://blog.cloudflare.com/ci-workflows/

[2] Linear PR reviews https://linear.app/changelog/2025-01-23-pull-request-reviews

Fun data sheet! I was curious about most steps per part and it seems to be TROTTEN[1] at 1.07 steps per part (excluding some other products like a toilet brush with 1 part but the steps are actually for a separate add-on to attach it to the wall).

[1]: https://www.ikea.com/us/en/p/trotten-cabinet-with-doors-whit...

Yeah the UX doesn't seem great, though I do think in general the AskQuestion tool is very awkward when it gets used in a very long running process (I personally use Claude to run repetitive tests to slowly iterate on a problem and verify in true conditions that it was solved), so I wouldn't like it without the auto-continue either.

(I had originally replied on safety of letting LLMs skip questions but I don't think that was your point so I removed it.)

Then I apologize, it seemed to me you wrote that part, but I guess I was reading Claude output.

So much attribution to malintent here, but most likely they're trying to build a product with the features that they themselves would use, and from my own experience it's very frustrating to leave a Claude session running and come back to find it did nothing because it got stuck on a question.

Furthermore, believing that the only thing saving you from disaster is Claude deciding to ask you a question is not a great conclusion either. You need guardrails in the power you bestow upon Claude from outside, not from inside.

Meanwhile, this article was written by Claude and has sentences like "Which cuts less far than it looks.", which I doubt Claude stopped to ask about.

The biggest performance bomb you can have in your code is a loop that does something like

    for (...) {
        el.style.height = `${something}px`;
        whatever.value = el.style.offsetHeight;
    }

This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned about it though).

I think I can see how dynamic data types make sense (eg flat key/value store), but my question would be:

What is least surprising? That INTEGER implicity accepts 'hello world' without error, or that you can't insert such a value unless you use a keyword like NONSTRICT or a type like ANY?

I would wager the vast majority of SQLite users if asked would probably not expect it to work.

I tried running this for some market research for my startup and it did a pretty nice job. It didn't necessarily find any obscure data, and it seemed to rely on older data than what I could find myself. On top of this, it had the same sycophantic tendencies as most LLMs these days (explaining why your idea is great and riffing on that), which I find to be unnecessary use of resources.

All put together, paying ~$60 to get a hit-or-miss report seems a bit excessive, but obviously as the models they use under the hood get better it becomes more and more worth it, assuming they also improve their grounding/search capabilities.

I'm a big fan of Sakana though, and have followed David Ha / @hardmaru since the world models papers (with the racing car game and the Doom clone), which were incredible at the time.

JWTs are fine, seems a bit sensationalist title...

Some nice topics to talk about instead:

- When to use an encrypted value (and symmetric or asymmetric), vs. a random (but secret) value, vs. a signed value (readable but not tamperable)

- Where to put these values (memory, localStorage, cookies)

- How to make sure these values don't last forever, and whether you need to be able to revoke them (make them invalid before their natural expiration timestamp)

In short, it lets you switch between all your Claude accounts seamlessly and will automatically pick the one with the most usage left.

I've been using the c, cw, and cr shortcuts for a long time but today I wished to switch to another account and wanted to keep the simplicity so I built this.

It's been mostly coded by Fable 5, with strong guidance by me. I've vetted the code and made sure the code it executes is readable in one file and that domain is secured, script is checksummed, project is open source, etc. but as always use your judgment and double check what you download from the internet!

If this shows itself to be highly useful as a concept, then I would perhaps avoid reinventing the wheel on the file format side of things, and just standardize what we already have:

- Come up with a file extension (.hmml)

- Decide on an entrypoint filename and format (index.html)

- Use an existing standard for combining resources into one file (tar + zstd)

Now you have something that is usable only using pre-existing tools.

I always find the minimizing view of consciousness a bit uninspiring. Like we need to be unique.

I've yet to find a reason why it couldn't be the opposite, way more things are conscious than we've been led to believe. What if consciousness appears out of any system that is actively persisting through effects caused by itself? That might be a forest, or outside the realm of the living, a company. An ant colony, or a planet.

Complex chemical reactions, layered upon each other such that tiny blocks make up large entities. Individual bits combined such that they make up something new intelligible by us.

I think the strongest argument against AI being conscious is that it does not persist, it resets, but that does not seem unchangeable.

Yeah this can go many ways but there's a world where OpenAI doesn't sell direct model access for the same reasons Cloudflare doesn't sell direct hardware access.

I started getting into webdev using PHP almost 30 years ago. So I'm probably biased. But when you're developing on just one machine in one language and you can do most of the stuff you need to do within that one system, you can make progress very fast, and the system can support you coding fast (I'm not proud of it but I was live patching production code via SSH and refreshing a web page as fast as humanly possible to make sure it didn't break).

I believe there are several ways achieve that analogy today, even though the technology we have access to (and our own demands) has exponentially grown in complexity. I am happy to see more people thinking about it.

[Side track: I am personally not a fan of "break it up into many tiny systems" (microservices, etc) since it removes that agility of logic/state moving around the system. I just see an attempt to codify the analog of a very large human organization.]

Now that AI lets a single person (and in some cases, no person at all!) write several orders of magnitude more code than they would possibly have been able to, the requirements of our systems will change too, and our old ways of working is cracking at the seams. In a way we're perhaps building up a whole new foundation, sending our AIs to run 50-year-old terminal commands. Maybe that's all we needed all along, but I do find it strange that AI is forced to work within a highly fragmented system, where 95%, if not 99%, of all startups that write code with AI while hiding it from the user, are essentially following the recipe of: (1) launch VM (2) tell AI to install Next.js and good luck.

I too have a horse in this race and have come to similar conclusions as the article: there is a way to create primitives on top of bare metal that work really well for small and large applications alike, and let you express what you really wanted across compute/memory/network. And I believe that with AI we can go back to first principles and rethink how we do things, because this time the technology is not just for groups of humans. I find this really exciting!

Releases keep shifting from API forward to product forward, with API now lagging behind proprietary product surface and special partnerships.

I'd not be surprised if this is the year where some models simply stop being available as a plain API, while foundation model companies succeed at capturing more use cases in their own software.

Isn't it pretty common for the smaller models to release a little while after the bigger ones, for all the big model providers?

I made this offline pocket vibe coder using Gemma 4 (works offline once model is downloaded) on an iPhone. It can technically run the 4B model but it will default to 2B because of memory constraints.

https://github.com/blixt/pucky

It writes a single TypeScript file (I tried multiple files but embedded Gemma 4 is just not smart enough) and compiles the code with oxc.

You need to build it yourself in Xcode because this probably wouldn't survive the App Store review process. Once you run it, there are two starting points included (React Native and Three.js), the UX is a bit obscure but edge-swipe left/right to switch between views.

Since AI became capable of long-running sessions with tool calls, one VM per AI as a service became very lucrative. But I do think a large amount of these can indeed run in the browser, especially all the ones that essentially just want to live-update and execute code, or run shells on top of a mounted file system. You can actually do all of this in the user's browser very efficiently. There are two things you lose though: collaboration (you can do it, but it becomes a distributed problem if you don't have a central server) and working in the background (you need to pause all work while the user's tab is suspended or closed).

So if you can work within the constraints there are a lot of benefits you get as a platform: latency goes down a lot, performance may go up depending on user hardware (usually more powerful than the type of VM you'd use for this), bandwidth can go down significantly if you design this right, and your uptime and costs as a platform will improve if you don't need to make sure you can run thousands of VMs at once (or pay a premium for a platform that does it for you)[1]

All that said I'm not sure trying to put an entire OS or something like WebContainers in the user's browser is the way, I think you need to build a slightly custom runtime for this type of local agentic environment. But I'm convinced it's the best way to get the smoothest user experience and smoothest platform growth. We did this at Framer to be able to recompile any part of a website into React code at 60+ frames per second, which meant less tricks necessary to make the platform both feel snappy and be able to publish in a second.

[1] For big model providers like OpenAI and Anthropic there's an interesting edge they have in that they run a tremendous amount of GPU-heavy loads and have a lot of CPUs available for this purpose.

I’ve been building on an opinionated provider-agnostic library in Go[1] for a year now and it’s nice to see standardization around the format given how much variety there is between the providers. Hopefully it won’t just be the OpenAI logo on this though.

[1] https://github.com/flitsinc/go-llms

I've gotten to a point where my workflow YAML files are mostly `mise` tool calls (because it handles versioning of all tooling and has cache support) and webhooks, and still it is a pain. Also their concurrency and matrix strategies are just not working well, and sometimes you end up having to use a REST API endpoint to force cancel a job because their normal cancel functionality simply does not take.

There was a time I wanted our GH actions to be more capable, but now I just want them to do as little as possible. I've got a Cloudflare worker receiving the GitHub webhooks firehose, storing metadata about each push and each run so I don't have to pass variables between workflows (which somehow is a horrible experience), and any long-running task that should run in parallel (like evaluations) happens on a Hetzner machine instead.

I'm very open to hear of nice alternatives that integrate well with GitHub, but are more fun to configure.

If the immediate next token probabilities are flat, that would mean the LLM is not able to predict the next token with any certainty. This might happen if an LLM is thrown off by out of distribution data, though I haven't personally seen it happen with modern models, so it was mostly a sanity check. But examples from the past that would cause this have been simple things like not normalizing token boundaries in your input, trailing whitespace, etc. And sometimes using very rare tokens AKA "glitch tokens" (https://en.wikipedia.org/wiki/Glitch_token).

One thing I tend to do myself is use https://generator.jspm.io/ to produce an import map once for all base dependencies I need (there's also a CLI), then I can easily copy/paste this template and get a self-contained single-file app that still supports JSX, React, and everything else. Some people may think it's overkill, but for me it's much more productive than document.getElementById("...") everywhere.

I don't have a lot of public examples of this, but here's a larger project where I used this strategy for a relatively large app that has TypeScript annotations for easy VSCode use, Tailwind for design, and it even loads in huge libraries like the Monaco code editor etc, and it all just works quite well 100% statically:

HTML file: https://github.com/blixt/go-gittyup/blob/main/static/index.h...

Main entrypoint file: https://github.com/blixt/go-gittyup/blob/main/static/main.js

Yeah I’ve found that the only way to let AI build any larger amount of useful code and data for a user that does not review all of it requires a lot of “gutter rails”. Not just adding more prompting, because it is an after-the-fact solution. Not just verifying and erroring a turn, because it adds latency and allows the model to start spinning out of control. But also isolating tasks and autofixing output keep the model on track.

Models definitely need less and less of this for each version that comes out but it’s still what you need to do today if you want to be able to trust the output. And even in a future where models approach perfect, I think this approach will be the way to reduce latency and keep tabs on whether your prompts are producing the output you expected on a larger scale. You will also be building good evaluation data for testing alternative approaches, or even fine tuning.

Extrapolating and wildly guessing, we could end up with using all that mostly idle CPU/RAM (the non-VRAM) on the beefy GPUs doing inference on agentic loops where the AI runs small JS scripts in a sandbox (which Bun is the best at, with its faster startup times and lower RAM use, not to mention its extensive native bindings that Node.js/V8 do not have) essentially allowing multiple turns to happen before yielding to the API caller. It would also go well with Anthropic's advanced tool use that they recently announced. This would be a big competitive advantage in the age of agents.

It's a bit odd to come from the outside to judge the internal process of an organization with many very complex moving parts, only a fraction of which we have been given context for, especially so soon after the incident and the post-mortem explaining it.

I think the ultimate judgement must come from whether we will stay with Cloudflare now that we have seen how bad it can get. One could also say that this level of outage hasn't happened in many years, and they are now freshly frightened by it happening again so expect things to get tightened up (probably using different questions than this blog post proposes).

As for what this blog post could have been: maybe a page out of how these ideas were actively used by the author at e.g. Tradera or Loop54.

The quirks of field values not matching expectations reminds me of a rabbit hole when I was reverse engineering the Starbound engine[1] and eventually figured out the game was using a flawed implementation of SHA-256 hashing and had to create a replica of it [2]. Originally I used Python [3] which is a really nice language for reverse engineering data formats thanks to its flexibility.

[1] Starbounded was supposed to become an editor: https://github.com/blixt/starbounded

[2] https://github.com/blixt/starbound-sha256

[3] https://github.com/blixt/py-starbound