Yeah, I clicked expecting a review of GLM 5.3 Flash, but the article was more a retrospective about what he learned during his September challenge: "Only use GLM 5.3 Flash for one month"
He said his experiment was a failure because:
1. He accidentally spent 450M tokens vibe coding with the wrong model, instead of GLM 5.3 Flash.
2. When he used GLM 5.3 Flash, it was sometimes slow. So he switched to other models (Deepseek / Qwen) instead. His guess to why it was slow: GLM 5.3 Flash was so good that the providers were congested.
3. He still needed to use other models besides GLM 5.3 Flash, for R&D and benchmarking.
His takeaways from doing the experiment were:
1. Measure local usage more.
2. Experiment with agent orchestration, with bounded goals.
3. Don't count other models that are used for R&D.
4. Play with Jev.
5. Include experiments with flagship models to compare with cheap open models.
His conclusion about GLM 5.3 Flash: Probably viable for day to day work, but he'll have more thoughts next month.
> When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it.
Unfortunately I learned that not everybody thinks this way. Some orgs do imperfectly fine without good engineering discipline, and that has been the case before AI... AI has only made it easier to give the appearance of good engineering, which is exactly the pre-AI goal of many orgs
I'll keep an eye on this, it seems cool - write once in typescript, compiler compiles typescript into native apps. Seems like it combines ideas from React Native (one language/application model across platforms), Svelte (compiles away high level abstractions to avoid a heavy runtime), and Flutter (own enough of the UI model to target very different platforms).
What I still don't understand (and can't find documentation for) is how Gea defines the portable abstraction boundary.
The targets are radically different: embedded devices, native UI kits, framebuffer-style rendering, and webviews. The docs don't make it clear which Typescript/JS/node/browser semantics are guaranteed. If I write something like `requestAnimationFrame` and `fetch` and `queueMicrotask`, does it work on every target? The lack of caveats in the documentation implies "Yes" but provides no assurance. Where is the compatibility matrix?
Does an application developer mostly stay inside a portable Gea model, or do they need to understand both Gea internals and the target platform to know what will work? If it's the latter, then it's hard to see the advantage of Gea vs just writing a native app.
My impression right now is: potentially VERY interesting, but needs clearer technical documentation about the portability/limitations and convincing real world proof before I can believe it and let myself be excited about it :)
Looking at the compiler repo, it looks like there is just one contributor. So I'm curious, what AI coding tools did you use? Which models? What's your workflow like? (I'm really interested in first hand experience on how models perform on truly difficult projects, not just at drawing pelicans)
Amazing questions, thank you for the careful read!
We should ship a compatibility matrix... at some point we were hoping to report test262 coverage for ECMAScript compliance, but we had to prioritize the release. Of course any of the typical web APIs work, including localStorage, and even so far as the Web Audio API (and we're working on WebRTC to make it cross platform. It's especially interesting to be able to build real-time communication apps, say, on an ESP32-S3, with just the web semantics).
In short, most app code stays inside the portable model. You need to know the target when you use host APIs that are constrained on small devices: blocking I/O, memory limits, file sizes, and of course you can combine it with native code for the target. I'm building a guitar effects processor, for example, where the UI is powered by Gea Stack but all the audio processing happens natively (https://github.com/dashersw/coyopedal).
On AI: yes, it's mostly me plus agents for the compiler. We have a team at Coyotiv that helps with everything else. I use Claude Code with Claude Opus as the main model and Sonnet subagents for parallel work, with a fair bit of Fable. I also combine this with whatever GPT model is available over Codex. During the past 6 months I've started working on the compiler, I've changed several model versions :)
What makes AI perform on a compiler:
Hard gates the agents can't argue with, like a diff gate that names every program whose output changed, plus conformance sweeps, a diary that captures past failures so they don't repeat, and treating a passing exit code as insufficient and the outputs get checked against Node.js behavior and unit tests.
The biggest differentiator for me is, even though I'm a pretty relaxed manager for humans, I'm a heavy micro-manager for AI. I read its thinking tokens and its code live and as soon as I spot something I don't like, I intervene and guide the model to the output I want to see.
It wasn't easy, Gea Stack in total I think burnt more than a million dollars in AI credits, and I've been working on it literally non-stop for 6 months.
I'll have to try 5.5 on my work's Cursor account. If they really solved the communication issues, I might consider moving my personal account from Codex back to Claude Code.
It still covers as much detail as Opus 5, and provides a healthy amount of caveats, but it's much better at just providing the answer up front and framing the caveats.
5.5 communicates like a real collaborator and not something that constantly demands my mental energy to decode what it's trying to say.
In the application I'm working on, we don't want "user's local midnight" to mean "next day". If a live sports game extends past midnight, we don't want the UI to group it under "Yesterday's games." So I asked Opus 5.5 "can we use the backend's API response as the definition of today instead of the browser's local time?"
Opus 5.5:
> Your assumption holds, and the commit history backs it up. Every time the frontend decided for itself what "today" meant, it broke and was later replaced with the backend's currentSeasonDay. There's one catch: trusting the backend only works if the client's copy of currentSeasonDay is current, and right now it often isn't.
Opus 5 would have buried the answer in some kind of unhinged lecture. Something like:
> The assumption is right about ownership and wrong about possession.
> currentSeasonDay is the authority; the commit history has already paid for that conclusion. Every local reconstruction of “today” became a second clock and was deleted. But naming one clock does not make every copy of its reading current.
> The remaining failure is on the other side of the seam: the frontend no longer invents the day, but it can preserve an old one indefinitely. The source is right. The observation is stale. Those are not contradictory states.
> Do not reopen the ownership decision to solve a freshness defect.
Basically the point is just poll the endpoint every 5 minutes or so
The animation in the article shows GPT-5.6 Sol Ultrafast solving a question at 3 secs vs Fable's 27 secs. The "11 hour vs 78 hours" animation implied that they were solved in sequence and not in parallel
Yeah, I also notice that a lot in vibe coded apps. Tbf it's what a mid level dev would write as copy if they were given no product requirements. Kinda hard to shift from engineer brain to product brain in the middle of implementation. During a hackathon I kept a PRODUCT.md file with the product "vision", and ask a strong frontier model to put on a "product manager hat" to review the copy before committing changes.
He said his experiment was a failure because:
1. He accidentally spent 450M tokens vibe coding with the wrong model, instead of GLM 5.3 Flash.
2. When he used GLM 5.3 Flash, it was sometimes slow. So he switched to other models (Deepseek / Qwen) instead. His guess to why it was slow: GLM 5.3 Flash was so good that the providers were congested.
3. He still needed to use other models besides GLM 5.3 Flash, for R&D and benchmarking.
His takeaways from doing the experiment were:
1. Measure local usage more.
2. Experiment with agent orchestration, with bounded goals.
3. Don't count other models that are used for R&D.
4. Play with Jev.
5. Include experiments with flagship models to compare with cheap open models.
His conclusion about GLM 5.3 Flash: Probably viable for day to day work, but he'll have more thoughts next month.