desmondl

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

Update: It's pretty good.

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

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)

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.

This is awesome. I've watched frontend webdev swing back and forth over the last decade of my career: from server frameworks like ASP.NET MVC with hacky progressive enhancement, to huge SPAs that reimplement things the browser should already be doing, to lighter SPAs with the library fatigue from assembling and updating every dependency.

Now it feels like the ecosystem is swinging back to: standard web APIs, modern browser features instead of unnecessary javascript, and lightweight progressive enhancement instead a SPA or a heavy UI hydration.

Libraries like hono / htmx already do similar things, but what's exciting about Remix 3 is that it promises all this with batteries included, closer to what Angular was for the frontend or Django/Rails was for the backend, but using all the modern tech and patterns that was developed since then.

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.

I would have loved to try locally, but the installer asks me to create an account and I don't want to do that yet.

The main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it

Same thing happened to me. Except I created a new Facebook account using my work email. I had to use my personal Facebook account. Meta has become so awful.

I work on a small team. I talk to coding agents a lot. I also talk to my human team members a lot. So I have decent experience with interacting with both LLMs and humans.

My two ¢: I also get fatigue when reading too much AI generated words. There's something about the over-polished nature of AI text and the missing feeling that you are interacting with a real human that makes it tiring to engage with for long periods of time. I don't have any evidence to support this, but my gut feeling is that - in contrast to AI - there is some "roughness" with interacting with humans that makes it easier for me to mentally "latch on to" their words that doesn't come with AI.

This new product might be better, but Shimmer was publicly criticized exploitative when it launched. I saw those criticisms at the time, gave the product a fair chance anyway, and unfortunately found them to be accurate.

I used Shimmer in 2022. The app had poor UX and frequent bugs, and the core offering (weekly Google Meet sessions with a “coach”) felt like generic self-help and not personalized coaching. The promised between-session support mostly consisted of DM'd article links, even after I raised that concern directly.

The sessions themselves often felt unprofessional, with background noise, unstable connections, and poor audio quality. The coach WFM'd on their couch during call. Given the price (hundreds of dollars per month at the time), the gap between what was marketed and what was delivered was significant.

Hopefully the new product addresses these issues, but I’d encourage people evaluating it to look at Shimmer’s prior execution and customer feedback, not just the announcement.

Yeah true, I'm starting to remember the headaches with yaml when I was using kubernetes or cloudformation....

Yep, I think the compelling reason of humans writing code is key here. SQLite would make it less accessible for people to write external tooling to integrate with an obsidian vault. There are lots of existing and open that support diffing/parsing/syncing/manipulating json, while with sqlite you have to not only know sql but support another application’s database schema, which third party developers are less likely to do