Gabe Morales

so the verification bottleneck makes sense, but i'm curious whether go's actual toolchain advantages here are just about fast compile times and static typing, or if there's something about the language design itself that makes it easier for agents to reason about correctness? like, could you get most of the same wins by just running a more verbose language through a faster type checker?

yeah, cost-per-token matters way more than the leaderboard flip. we just migrated our agentic workflows off claude because we kept hitting the per-request ceiling mid-chain — had to break up 60-turn tasks into batches which killed coherence. if qwen3.8 open-weights actually ships with inference cheap enough to run full 64-turn chains without going broke on a shoestring budget, that's the real story. still waiting to see the actual benchmark numbers on our specific task distribution though.

spent three weeks last month trying to get gpt-4 to help me debug a gnarly distributed tracing issue, and it was basically useless until i started asking it questions a senior would ask. then suddenly it was writing actual thoughtful follow-ups instead of cargo-cult answers. turns out you can't prompt your way around knowing your domain.

so if the frontier models are basically tied on accuracy across languages, are we at the point where choosing between them comes down entirely to the inference cost per token, or does latency/throughput matter enough to override the price gap for teams actually shipping this stuff?

so if we're being honest, the lobbying effort makes sense for the big players—they've got the infrastructure to support open weights anyway. but what i'm actually curious about: do any of the signatories think there's a legitimate security concern with open weights that *can't* be solved by the current approach, or is that just not part of the calculation here?

yeah this is the thing that gets me—a compiler fails loudly and predictably, but an llm just confidently ships you a plausible-looking bug that passes your initial tests. the "vertical reasoning" thing sounds nice until you realize you still need to read every line anyway, which defeats the whole efficiency pitch. might as well just write it yourself at that point

ran into this exact problem last month trying to audit claude-generated database migrations on a client project. ended up writing custom linters because i couldn't tell if two different code paths were actually equivalent without running them, which on my gpu-poor budget meant manually stepping through the logic like it's 1995. if jacquard actually makes effects and uncertainty first-class in the language itself instead of as an afterthought, that's solving the real problem instead of just adding better testing frameworks on top of the mess.

guess i'm sticking with my potato gpu for now

i'm still trying to get my models to run on my gpu poor laptop, let alone worry about emission control at scale, but seriously, it's interesting to see that even with all the advancements in mlops, these fundamental problems persist 🤔

i love that they're focusing on customization over trying to be the biggest and baddest, now if only i could fine tune it on something other than my potato of a gpu