Cached at:
06/20/26, 02:34 PM
# What are you doing this weekend?
Source: [https://lobste.rs/s/wemk3j/what_are_you_doing_this_weekend](https://lobste.rs/s/wemk3j/what_are_you_doing_this_weekend)
**Stupid WebAssembly tricks\.**I am messing around with WebAssembly \(and WebAssembly GC\)\. This turns out to be a*weird*compilation target, partly because it's a Harvard architecture \(code lives in a separate memory space\), partly because it needs multiple stacks \(a managed stack for parameters and return values, plus a hand\-built stack for things that aren't managed\), and partly because the new GC support adds*another*opaque, managed heap\.
None of this actually makes it worse than "real" processors, but it certainly makes it different\.
I started out using some sketchy ancient Lisp tricks from MIT, including an s\-expression\-based macro assembler with Lisp macros\. This was fun for a while—I could add things like`%while`and`%inc`to WAT—but it was still tedious to write by hand\. In particular, constantly writing`\(global\.get NAME\)`,`\(local\.get NAME\)`,`\(i32\.const VALUE\)`was hard to patch around without massive reader\-macro abuse\.
So[I restarted in Rust](https://github.com/emk/toy-wasm-lisp), with the goal of building a real symbol table\. And, well, a low\-level infix language that lives even closer to the WASM than AssemblyScript\. Right now, I am trying to get the parameter references in`sum`to work:
```
func sum(a: i32, b: i32) -> i32 {
a + b
}
export func f() -> i32 {
1 + 2 * 3 + sum(2, 3)
}
```
Since this is a learning exercise, and also just for fun, I'm building this the hard way\. \(Life offers insufficient excuses for writing compilers\.\) The only "AI" tool that I'm using is inline autocomplete from Zed's Zeta2, which seems to limit itself to a few contextually\-obvious lines of code at a time\.
**Thoughts on AI\-assisted coding\.**So, yeah, I am not happy about the implications of Fable\. Here's my scale of AI tools, and how much they annoy me:
1. **Contextual autocomplete\.**\(Zed's Zeta2, old\-school Copilot inline completion\) This is my favorite spot, especially working in Rust\. Yes, given the doc string and the parameters, the body of this function is obvious\. No, I don't need to type it\. I remain rather fond of this type of model, and might fine\-tune my own at some point\.
2. **"Small\-ish" models\.**\(Local Qwen3\.6 27B all the way up to cloud\-hosted DeepSeek V4 Flash\) These are interesting, because they're smart enough to figure out bugs, or to implement a module with a clear "natural" implementation\. But Qwen3\.7 27B, for example, can't build anything especially large or complex\. And if the programmer loses track of what's going on, the model will quickly start failing\. I find this size*OK*for debugging, writing a new implementation of an existing interface, or for writing throwaway scripts\.
3. **Almost\-frontier models\.**\(Opus 4\.5\+, GLM 5\.2, etc\) These models are capable of building pretty substantial chunks of code, even if the human is losing track of the details \(or never understood them\)\. With persistent prompting, you can use these to build something, quality unknown\. I don't*like*this tier of model, because they write features faster than I can review them\. So they leave me with an ever\-growing backlog of code review, and I gradually lose detailed knowledge over the codebase—even if I*read*it all, and understand it at the time, I never build the kind of deeper, persistent memories that allow me to make real leaps of insight\.
4. **Frontier\-plus models\.**\(Fable\) I only got to play with Fable for a couple of days, but it honestly bothers me\. Given relatively simple prompts and appropriate tooling, it can go and build entire small\-to\-medium applications\. Except the code is honestly pretty sketchy: It lacks any kind of solid architecture, half the code is defensively hiding weird states produced by the other half, and so on\. But it*sort*of works, and it*looks*pretty good\.
My guess is that Fable is going to turn software into a "market for lemons", where buyers and users get repeatedly burned by impressive\-looking but fundamentally garbage software\. Unfortunately, markets for lemons famously drive out high\-quality producers, too, because customers struggle to differentiate, or refuse to pay a premium for quality\.
I mean, even if the market for software and programmers goes down in flames, I'll still code in my spare time for fun\. But I was hoping to put a couple of kids through college and then retire to something*slightly*better than dog food, you know? I know how to weather ordinary, dotcom\-sized crashes just fine, but I fear that tools like Fable are going to gut the industry\. And then they'll start on other industries\.
Overall, I am not a fan\. This is getting less fun with each generation, as more and more programmers are pressured to ship code they have no time to understand properly\.