Hacker Newsnew | past | comments | ask | show | jobs | submit | killthebuddha's commentslogin

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?


There may be good options coupled with agents like Claudes Front End Design skill, I haven't used it.

I have been using Magic Patterns which is very good at generating initial prototypes, especially when driven by an agent familiar with it's facilities and constraints.

I assume the service is just a wrapper plus scaffolding but I like it. You have to push it though to get anything particularly creative but it's good at standard front end designs.

https://www.magicpatterns.com/

That's not necessarily what you're after because I only use it for piloting stuff, not for adhoc feature addition and fixes.


Agents aren't great at complex async state updates, mostly because it's hard to represent what's happening in their context. They're fine at creating complex components in isolation and implementing decoupled stuff like animations.


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


And France has Molière, and Portugal has Camões...how many authors should be listed?


If you are a 250 year old nation built on "stolen land" (by the europeans, mind you), I would assume not many. But the US has been home to many great writers. This is just stupid.


All land is "stolen". The people the US "stole" the land from had "stolen" it from someone else and so on and so forth.


+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.

[1] https://survey.stackoverflow.co/2025/technology


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 know I can code it up myself and then offer it as a model to Roo Code, but an "out of the box" api served model that can use tools like the Claude 3 family would be nice.


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?


In theory transformers are Turing-complete and LLMs can do anything computable. The more down-to-earth argument is that transformer LLMs aren't able to correct errors in a systematic way like Lecun is describing: it's task-specific "whack-a-mole," involving either tailored synthetic data or expensive RLHF.

In particular, if you train an LLM to do Task A and Task B with acceptable accuracy, that does not guarantee it can combine the tasks in a common-sense way. "For each step of A, do B on the intermediate results" is a whole new Task C that likely needs to be fine-tuned. (This one actually does have some theoretical evidence coming from computational complexity, and it was the first thing I noticed in 2023 when testing chain-of-thought prompting. It's not that the LLM can't do Task C, it just takes extra training.)


As soon as you need to start leaning heavily on error correction, that is an indication that your architecture and solution is not correct. The final solution will need to be elegant and very close to a perfect solution immediately.

You must always keep close to the only known example we have of an intelligence which is the human brain. As soon as you start to wander away from the way the human brain does it, you are on your own and you are not relying on known examples of intelligence. Certainly that might be possible, but since there's only one known example in this universe of intelligence, it seems ridiculous to do anything but stick close to that example, which is the human brain.


> of course we can _in theory_ do error correction

Oh yeah? This is begging the question.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: