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?
+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 don't have an opinion on the matter, but it's pretty popular. According to [1], Phoenix "was used extensively over the past year" by 2.4% of responders.
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'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.
I see a good number of comments that seem skeptical or confused about what's going on here or what the value is.
One thing that some people may not realize is that right now there's a MASSIVE amount of effort duplication around developing something that could maybe end up looking like MCP. Everyone building an LLM agent (or pseudo-agent, or whatever) right now is writing a bunch of boilerplate for mapping between message formats, tool specification formats, prompt templating, etc.
Now, having said that, I do feel a little bit like there's a few mistakes being made by Anthropic here. The big one to me is that it seems like they've set the scope too big. For example, why are they shipping standalone clients and servers rather than client/server libraries for all the existing and wildly popular ways to fetch and serve HTTP? When I've seen similar mistakes made (e.g. by LangChain), I assume they're targeting brand new developers who don't realize that they just want to make some HTTP calls.
Another thing that I think adds to the confusion is that, while the boilerplate-ish stuff I mentioned above is annoying, what's REALLY annoying and actually hard is generating a series of contexts using variations of similar prompts in response to errors/anomalies/features detected in generated text. IMO this is how I define "prompt engineering" and it's the actual hard problem we have to solve. By naming the protocol the Model Context Protocol, I assumed they were solving prompt engineering problems (maybe by standardizing common prompting techniques like ReAct, CoT, etc).
I'm a full-stack developer with wide-ranging technical experience and strong general problem solving skills. Most recently I co-founded a startup, worked on it for a few years, and then took some time off to recharge, be with my family, and work on hobby projects. I'm most interested in, and in my opinion best suited for, the kind of fast-paced small-team environment you typically find in early-stage startups.
Hmm, maybe. I could run a server on my laptop and have the wifi/bt mic stream to it. But I really want this to work on the go, and having a running laptop, or Pi or whatever, at all times is kind of a non-starter.
Edit: On a more serious note, this book actually changed the way I think in a very concrete (and positive) way. The book spurred me to start consciously reflecting on "what about X, specifically, is surprising" and/or "what about X, specifically, is confusing". It's impossible to quantify, but the habit has definitely, definitely, boosted my ability to disentangle complex situations and make better decisions.