"Unmaintanable" by who? Vite is on its n-th major revision, yet as a user none of my pain points have been addressed and god-knows-what has been added. If that's "maintenance", I don't want it, because what I need out of Vite is trivially replaced. It's the same for most other dependencies. I need a particularly problem solved, but along with a dependency come the authors who, having solved the problem, continue to invent new problems, because they are emotionally invested in their work. I don't begrudge that, but there is a conflict of interest here.
Big AI labs aren't making money. They're buying revenue. Sure, the product is amazing, but it wouldn't be as amazing if offered at cost - which is exactly where "good enough" smaller and specialized models will survive.
Raising prices is not a tail risk, anything a local LLM setup can do for you can be done by any cloud provider, with the same capex as yours (or less), there is no moat here, so it is highy price competitive and will remain so. If you want to speculate on hardware shortages, that is a different business altogether and you need no janky garage setup to profit.
I have removed vite because dev build and reload is noticable slower than just esbuild and browser refresh. Vite does nothing for me that an LLM can not just trivially rebuild in a bespoke manner.
> For the coordinator or judge above them I would put myself
You will not be able to keep up with the sheer volume, or alternatively you're never gonna ingest as much information as the LLM, so you're gonna miss out. Input tokens are relatively cheap.
Think of yourself as the CTO, they can't possibly make a judgement call on every detail, but an LLM can, and if you're gonna let an LLM do that, might as well go with frontier, and if you're not gonna let an LLM do that, you're stuck with whatever the lower-tier LLMs provided you with.
That doesn't mean you shouldn't read or judge the code at all, but you're still gonna want to use the LLM as the lever.
I think the idea that code should last decades is now questionable, if not problematic. If we can now produce code at 10x the rate, that means we can have 10x more code (probably not desirable) or we can have 10x as many revisions. Whoever inherits the code can have it rewritten to their liking and understanding. Nothing helps better in understanding a system than to rebuild it, even if just by handholding an LLM.
You need to train independently and merge rarely. The problem is the merge step. Weights are too entangled, you are not going to get an improvement commensurate to the effort. Otherwise, everyone would do it. It is an open research problem.
> As I replied to a child comment - this is a nice idea that just isn't tenable in reality. AI hardware isn't just hilariously faster than consumer GPUs, it's also hilariously more power-efficient and has hilariously better connectivity. Every one of these dimensions kills the idea.
The first part is not really true though, the chips are not that much faster, the DRAM is not that much faster, and in aggregate it does not matter because there is just so much more consumer hardware out there (although perhaps that is changing as supply shifts toward datacenters).
The interconnect and data locality is the problem. If you could train it like e.g. you can render a scene with monte carlo ray tracing, any result from any node could be merged with any other and the combined result would have converged closer to the limit. I am sure research in that direction exists, it just has not proven effective within the scales it has been attempted.
In large projects there is always a risk, if not an inevitability, that a code base becomes unmaintanable by some definition. AI surfaces this faster, but also AI lowers the cost of testing and refactoring. AI gives a linear multiplier in producing solutions, but complexity gives a quadratic increase in problems. The art of producing software has always been in choosing what not to do.
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
It is more like imitating the imitators. There is not much of a legal case here, but poisoning the data is fair game both for those producing original data as well as for those producing its regurgitations.
Anthropic is the opposite of wealthy, the more you use their service, the more money they lose. Unless you think your precious MDs being used for training data is gonna make them rich eventually.
You sincerely think a country that massacres its own people is better than the relatively good conduct of the US during war (or the treatment of foreigners on its soil)?
Mercurial was better than Git on almost any metric, it eludes me why it lost out to Git, perhaps because it lacked the kernel hacker aura, but also because it did not have a popular repository website with cute mascot going for it. Either way, tech history is full of examples of better designs not winning minds, due to cost, market timing, etc. And now with LLMs being trained on whatever was popular three years ago, we may be stuck with it forever.
C is fundamentally a bad target for LLMs. Humans get C wrong all the time, so we can not hope the nascent LLM, which has been trained on 95% code that does automatic memory management, to excel here.
I always found myself writing verbose copypasta code first, then compress it down based on the emerging commonalities. I think doing it the other way around is likely to lead to a worse design. Can you not tell the LLM to do the same? Honest question.
I detest the way ChatGPT writes. You can tell immediately when someone had a rough draft or just an idea thrown into the ChatGPT filter. At least tell it to cut to these chase next time, nobody has time for fluff in this attention economy.
Games do not sync data, they literally say what should be drawn on the screen, from scratch, 60+ times per second. They are in control of the entire process. They do not need to deal with DOM manipulation overhead because there is no DOM.
If the html+css+js trifecta was any good for creating UI beyond simple forms, we would not have witnessed the cambrian explosion of ways to do it differently. Reactivity itself was an answer to the pain of using MVC and similar approaches in older GUI toolkits not made for the web. The pain did not stop entirely, of course, because GUI is a complicated and ill defined problem - but I don’t look back fondly to programming without it.
No such right exists, except in moral terms, but if you are going to invoke morals, the Iranian regime does not hold up well. So no, they do not.
Perhaps you will argue that the US or Israel or Pakistan or North Korea have conducted themselves in a way where they do not have that moral right either, but that is a different debate, and either way it is moot because they do have them.
The cost of "perfecting" an idea here is ruining the broader ecosystem. It is much much better for an API to be kinda crappy (but stable) for historical reasons than dealing with the constant churn and fragmentation caused by, for example, the fifth revision of that URL routing library that everyone uses because everyone uses it. It only gets worse by the orthogonal but comorbid attitude of radically minimizing the scope of dependencies.
VFX is just too damn expensive. It will get much worse with AI tools taking hold. Once these are 80% there but 10x cheaper, they will be (over)used everywhere, despite delivering clearly inferior results.
Remember when Germany lost the second world war, lost a third of its territory, had millions ethnically cleansed from said territory and then proceeded to not maintain a goal to wipe Poland off the map (again)?