killthebuddha

1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.

Does anybody here have a frontend development workflow that works well with coding agents? In my experience coding agents ship buggy, broken, incomplete, or awkward frontend features at a way higher frequency than they do for backend features. The reason seems obviously to be the difference in verifiability between the two. Basic test suites dont seem to help much. I assume something like Garry Tan’s gstack is the right direction but I dont know if that particular tool is mature enough to adopt yet. I was surprised too see here on HN recently that gemini 3.5 flash may outperform Opus/gpt-5.5 on frontend tasks (maybe because of Gemini’s supposed edge w.r.t. multimodality? or maybe it understands Chrome more deeply?), can anyone here second that take?

this is not super productive, but not including “Germany has Goethe” in the opening line turned me off immediately

+1. This thread, the thread about documentation, and the thread about turning off Sprites, when taken together, thoroughly illustrate why I'm not currently a Fly user.

I really appreciate his iconoclasty right now, but every time I engage with his ideas I come away feeling short changed. I’m always like “there is no such thing as outside the training data”. What’s inside and what’s outside the training data is at least as ill-defined as “what is AGI”.

The answer to (2) is, IMO, "to make computing cheaper". It's interesting to me that this is not the obvious, default answer (it may not be the most actionable answer but IMO it should at least be noted as a way to frame discussions). I think we're at the tail end of computing's artisanal, pre-industrial era where researchers and programmers alike have this latent, tacit view of computing as a kind of arcana.

I feel like the Netflix tech blog has officially jumped the shark.

I've always felt like the argument is super flimsy because "of course we can _in theory_ do error correction". I've never seen even a semi-rigorous argument that error correction is _theoretically_ impossible. Do you have a link to somewhere where such an argument is made?

Your second paragraph is basically what I'm saying but with the extension that we only actually care about reasoning when we're in these kinds of asymmetric situations. But the asymmetry isn't about the other reasoner, it's about the problem. By definition we only have to reason through something if we can't predict (don't know) the answer.

I think it's important for us to all understand that if we build a machine to do valuable reasoning, we cannot know a priori what it will tell us or what it will do.

Perfect reasoning, with certain assumptions, is perfectly deterministic, but that does not at all imply that it's predictable. In fact we have extremely strong evidence to the contrary (e.g. we have the halting problem).

IMO verifying a solution is a great example of how reasoning is unpredictable. To say "I need to verify this solution" is to say "I do not know whether the solution is correct or not" or "I cannot predict whether the solution is correct or not without reasoning about it first".

One thing he said I think was a profound understatement, and that's that "more reasoning is more unpredictable". I think we should be thinking about reasoning as in some sense exactly the same thing as unpredictability. Or, more specifically, useful reasoning is by definition unpredictable. This framing is important when it comes to, e.g., alignment.

The issue isn’t with who’s hosting, it’s that their SDKs don’t clearly integrate with existing HTTP servers regardless of who’s hosting them. I mean integrate at the source level, of course they could integrate via HTTP call.