[i_v]

I think until we solve the knowledge supplementation problem (i.e., libraries providing extensive examples and LLMs being capable of ingesting, referencing, and incorporating it quickly) we’ll be headed for a tech monoculture—one framework or library for every solution. There’s been some talk about this already with some developers preferring to use older libraries or sticking within the confines of what their LLM of choice was trained on.

Actually, I had a hardware project where I found myself gravitating toward the microcontrollers and sensors ChatGPT was already familiar with. In this case, I cared more about my project working than about actually learning/mastering my understanding of the hardware. There’s still time for that but I’ve been able to get something working quickly rather than letting my notebook of ideas fill with even more pages of guilt and unfinished dreams…

[_bin_]

I don’t think this is it either. Svelte actually has specially-compiled documentation for LLM ingest which I’ve tried supplying. It’s moderately less prone to directly write react, but still writes react-isms pretty often. Eg instead of $effect I’ll get useEffect(), or it’ll start writing svelte 4 and old $ syntax versus runes.

With the Python backend tests I did, it just barfed out absolute garbage. Fastapi and sqlalchemy are so common there’s not a great excuse here. I’d tell it what routes I needed written for a given table/set of models pre-written and I even tested with a very basic users example just to see. No dice; they were always syntactically valid but the business logic was egregiously wrong.