The harness is built on top of the Pi SDK. I initially used Codex, but Pi seems more hackable, and I like that it’s vendor-agnostic by default.

Running it on Kubernetes works, but dealing with the JSONL session files and making sure sessions survive pod interruptions adds some complexity. I’m using DBOS for that right now, which works well, although it still feels like overkill.

This came at just the right time. I’m looking forward to removing the pieces I no longer need and simplifying the architecture. Thanks Pi team!

The harness is built on top of the Pi SDK. I initially used Codex, but Pi seems more hackable, and I like that it’s vendor-agnostic by default.

Running it on Kubernetes works, but dealing with the JSONL session files and making sure sessions survive pod interruptions adds some complexity. I’m using DBOS for that right now, which works well, although it still feels like overkill.

The 1.0 release came at just the right time. I’m looking forward to removing the pieces I no longer need and simplifying the architecture!

What they’re doing with billions of tokens every week, beats me. But these users absolutely do exist.

GLM and DeepSeek are great examples. They’re a bit like Linux or Android in that there isn’t necessarily one best provider. You need to do some research, try a few, and pick whatever works best for your use case.

I think that’s partly why Anthropic has been pushing its most expensive models so heavily for a while now. Sonnet and Haiku were great, but at that level of intelligence it’s becoming much harder for them to compete on price with Chinese models that have largely caught up.

The main reason to use frontier models from Anthropic or OpenAI now is the combination of intelligence and speed. Chinese frontier models still struggle to match that, possibly in part because of hardware constraints. But judging by the recent GLM releases, they seem to be moving in the right direction.

The web and native apps serve different purposes. Users do not use a website the same way they use a mobile app, and the trade-offs are different.

I’m getting tired of web developers failing to acknowledge that and treating web technology like a hammer that needs to be applied to every nail they come across.

And especially when people say “the web”, what they often really mean is Chrome and the Chromium ecosystem. A lot of web apps barely get tested properly on Firefox or Safari, which only reinforces Google’s monopoly over the web platform.

Yes, app stores have their problems. That does not make the web the right answer for every product.

Most users don’t care. What they do care about is performance, and native is usually the easiest way to get there.

For your AI workflow questions, it depends. With or without AI, those decisions depend on the organisation’s direction, the team’s capabilities, and their preferences. Did your org have a single answer for the best programming language, framework, or workflow even before AI? There was never a single right answer to any of that.

All this static vs dynamic stuff doesn’t really matter anymore. AI doesn’t care. You just need to close the feedback loop with tests, linting, a compiler, or whatever else gives it a clear signal.

Simple as that.

I know some people might disagree, mainly because AI isn’t a new architecture or a new programming language in the traditional sense. But I still think it’s worth revisiting the assumptions and having the discussion.

That was Raycast v1, though. I don’t like the direction they’ve taken with v2, so I uninstalled it and switched to Tinycast.

If you just want something stable and boring, Linux is just not it. Every distro has its own goals and target users, so a lot of the effort gets spread across the ecosystem.

With macOS or Windows, for better or worse, everyone is working on the same platform. So more people are working on the same problems. With Linux, everyone is kind of doing their own thing.

It is basically the same Android versus iPhone argument. More choice and freedom on one side, more consistency on the other.

Banks, telcos, etc. aren’t monoliths either. They use plenty of different languages depending on the team, system, and requirements. Java isn’t inherently the choice for greenfield software just because reliability matters.

https://mise.jdx.dev/bootstrap/packages/brew.html

In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.

I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.

https://guides.rubyonrails.org/testing.html?#when-to-use-sys...

Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.

With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.

At the end of the day, both approaches work.

Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.

Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.