A place for developers to talk about building on Farcaster.

/dev

/frontend dev (HTML/CSS)・founder/decentralized data wrangler /blockhead・contributor /ethglobal /walletbeat・hackathon bounty hunter・music maker・dropout・nomad・25

I agree. I think this is now a new dimension that frameworks need to take into consideration when making breaking changes.

Prior to LLM-coding, the cost was cognitive burden on developers to re-learn and adapt, but that was it.
Now, human developers still need to re-learn and adapt, but also need to hand-write sufficient amount of open-source code so that LLMs have sufficient data to re-learn. Ideally, that also has to outnumber the previous version's training data, so that the LLM uses the updated version by default. Then there's another delay for the LLMs to get trained on that training data, and trickle down to consumer models so they can get their hands on it. Only then they can generate code with the new version.

If the working assumption is that LLM-coding will take over, then there's a possibility that the volume of LLM-generated-code of the prior version consistently outpaces human-written code of the newer version. If that happens, the new version may never reach critical mass of training data.

Contributor @ /walletbeat.

Censorship resistance requires privacy.

The way out of it would be to have short, LLM-context-friendly explanation of breaking version changes which can stay in context window for models that were trained on the previous version. Still feels like that would add pressure to reducing the rate of breaking changes, to keep it context-window-friendly.

LLMs are good at replicating state-of-the-art frontend code from a decade ago and it shows. Fifty lines of added imperative runtime code to implement a basic UI interaction that with a declarative, newly baseline browser built-in takes three.

It's a real uphill battle. A gravity well pulling all my web apps toward verbosity, redundancy and mediocrity by default – because for better or worse, that’s the historically dominant software development culture represented in the training data, and which is now not-so-subtly being imposed on me.

I can only hope an inflection point will come where specialized model training is actually cost-effective and we can force the LLMs to “unlearn” entire corpuses of old training data through exclusion, so we don't have to keep wasting precious context tokens correcting the few truly decent and up-to-date generalist models we currently have with oodles of docs embeddings and system prompt overrides.

LLMs are good at replicating state-of-the-art frontend code from a decade ago and it shows. Fifty lines of added imperative runtime code to implement a basic UI interaction that with a declarative, newly baseline browser built-in takes three.

It's a real uphill battle. A gravity well pulling all my web apps toward verbosity, redundancy and mediocrity by default – because for better or worse, that’s the historically dominant software development culture represented in the training data, and which is now not-so-subtly being imposed on me.

I can only hope an inflection point will come where specialized model training is actually cost-effective and we can force the LLMs to “unlearn” entire corpuses of old training data through exclusion, so we don't have to keep wasting precious context tokens correcting the few truly decent and up-to-date generalist models we currently have with oodles of docs embeddings and system prompt overrides.

https://farcaster.xyz/polymutex.eth/0x43c25e74
https://farcaster.xyz/polymutex.eth/0x206cea70

That gravity warp field is gonna get real expensive. 

I like the metaphor. Its real!