I was working on a new project and I wanted to try out a new frontend framework (data-star.dev). What you quickly find out is that LLMs are really tuned to like react and their frontend performance drops pretty considerably if you aren't using it. Like even pasting the entire documentation in context, and giving specific examples close to what I wanted, SOTA models still hallucinated the correct attributes/APIs. And it isn't even that you have to use Framework X, it's that you need to use X as of the date of training.
I think this is one of the reasons we don't see huge productivity gains. Most F500 companies have pretty proprietary gnarly codebases which are going to be out-of-distribution. Context-engineering helps but you still don't get near the performance you get with in-distribution. It's probably not unsolvable but it's a pretty big problem ATM.
That is the "big issue" I have found as well. Not only are enterprise codebases often proprietary, ground up architectures, the actual hard part is business logic, locating required knowledge, and taking into account a decade of changing business requirements. All of that information is usually inside a bunch of different humans heads and by the time you get it all out and processed, code is often a small part of the task.
I use it with Angular and Svelte and it works pretty well. I used to use Lit, which at least the older models did pretty bad at, but it is less known so expected.
I found that LLMs sometimes get confused by Lit because they don’t understand the limitations of the shadow DOM. So they’ll do something like throw an event and try to catch it from a parent and treat it normally, not realising that the shadow DOM screws that all up, or they assume global / reset CSS will apply globally when you actually need to reapply it to every single component.
What I find interesting is all the platforms like Lovable etc. seem to be choosing Supabase, and LLMs are pretty terrible with that – constantly getting RLS wrong etc.
As someone who works at an F100 company with massive proprietary codebases that also requires our users to sign NDAs even see API docs and code examples, to say that the output of LLMs for work tasks is comically bad would be an understatement even with feeding it code and documentation as memory items for projects...
I ended up building out a "spec" for Opus 4.5 to consume. I just copy-pasted all of the documentation into a markdown file and added it to the context window. Did fine after that. I also had the LLM write any "gotchas" to the spec file. Works great.
To be fair, it looks like that fronted framework may have had its initial release after the training cutoffs for most of the foundation models. (I looked, because I have not had this experience using less-popular frameworks like Stimulus.)
> You can’t make anything truly radical with it. By definition, LLMs are trained on what has come before. In addition to being already-discovered territory, existing code is buggy and broken and sloppy and, as anyone who has ever written code knows, absolutely embarrassing to look at.
I don't understand this argument. I mean the same applies for books. All books teach you what has come before. Nobody says "You can't make anything truly radical with books". Radical things are built by people after reading those books. Why can't people build radical things after learning or after being assisted by LLMs?
People can absolutely build radical things after learning or being assisted by LLMs. But that's not the meta they're selling. What they are selling with vibe-coding is that you can let the AI build things and don't even need to learn how to code. If someone truly believes that, then I would say the chances of them building something actually useful or radical is close to 0.
With books, the sell is not that it will create your app and you don't even need to learn to code. The sell is that you will learn to code with this and then use it to build the app (often through a painstaking process).
> Jensen Huang says kids shouldn't learn to code — they should leave it up to AI
> Why can't people build radical things after learning or after being assisted by LLMs?
Because that's not how this is being marketed.
I agree with you completely - the best use case I've found for llms (and I say this as somebody that does generate a lot of code with it) is to use it as a research tool. An instantaneous and powerful solution that fills the gap from the long gone heydays of communities like mailing groups, or Stack overflow where you had the people - the experts and maintainers - that seemingly answered within a few hours on how something works.
But then that's not enough for all the money that's being fed into this monster. The AI leadership is hell-bent on trying to build a modern day tower of babel (in more ways than one), where there is no thinking or learning - one click and you have an app! Now you can fire your entire software team, and then ask chatgpt what to do next when this breaks the economy.
>> You can’t make anything truly radical with it. By definition, LLMs are trained on what has come before. In addition to being already-discovered territory, existing code is buggy and broken and sloppy and, as anyone who has ever written code knows, absolutely embarrassing to look at.
> I don't understand this argument. I mean the same applies for books. All books teach you what has come before. Nobody says "You can't make anything truly radical with books". Radical things are built by people after reading those books.
Books share concepts expressed by people understanding those concepts (or purporting to do so) in a manner which is relatable to the reader. This is achievable due to a largely shared common lived experience as both parties are humans.
In short, people reason, learn, remember, and can relate with each other.
> Why can't people build radical things after learning ...
They absolutely can and often do.
> ... or after being assisted by LLMs?
Therein lies the problem. LLMs are not assistants.
They are statistical token (text) document generators. That's it.
It might be true, but it is extremely reductive and used pejoratively.
> That’s not a book, that’s just a soup of letters! That’s not an art, that’s just paint on a sheet! That’s not an instrument, that’s just a bunch of crap glued together!
If you’re edgy cynic and treat anything this way, that’s fine. But if you’re singling out LLMs just because you don’t like them, then you’re a hypocrite.
This is a really dumb point from my point of view.
People vastly over rate the novelty of software work. The vast majority of the time, it's at least got conceptual similarity to things created before. A lot of the time, being "radically new" is a huge negative. It's a recipe for something nobody can understand or maintain. Almost all software is mild variations on existing things that are assembled to create something new in feature space, but its nearly 100% mind numbingly boring in the methodology of how it is built.
Well the article went in a totally different direction to what I expected.
I do feel imprisoned by my vibe coded apps. But it's because I've lost control of them. I don't understand the code that was written well enough to work on it myself any more. So now I'm at the mercy of the AI to maintain it. When there's a bug to fix I just type it into the LLM and pray and hope that it will be able to solve it, because if it can't, I'm screwed.
It's actually a big reason I'm sticking with tools like Aider for things I care about and not going fully agentic yet. Having an agent do reams of work and then submit hundreds of lines of code for me to examine is counter productive to my longer term aims. I'm happy with the 2-3x improvement I get from lesser tools that still leave me in control.
> it's because I've lost control of them. I don't understand the code that was written well enough to work on it myself any more. So now I'm at the mercy of the AI to maintain it.
That's eerie. So basically this is the same walled-garden formula but this time directly targeting your intelligence, rather than your data like it has always been.
I recently tried out Copilot with Sonnet to implement whole C++ headers into .cpp files and it did very well making the implementation consistent, readable, and easy to reason about. Not having much C++ experience, it made the whole process much easier - some memory/etc errors in my own code would have been intractible to fix without it. It was also fantastic at turning a postgresql implementation file of that header into an sqlite implementation that worked/passed tests on the first try.
Overall, it seems like defining the structure to some extent yourself and letting the agent fill in implementation and suggest architecture changes is a good way to go to get a lot of useful work out of it without letting the structure of the overall app run away from you.
Isn't this the same problem as working on any large project you have no experience with? It takes time to understand the code base, but you can learn it by studying the source code. And LLMs can help you understand the code base, e.g. ask it to generate (mermaid) diagrams.
> I don't understand the code that was written well enough to work on it myself any more.
That's worse than you think. Maybe not for you though.
They are trying hard to push vibe coding in my work and they had one demo that stood out.
They showed how VC had created an app to analyse multiple logs. It worked, but when they showed the code it was using csv module in python and had created all its own functions. The app was 100's of lines long. The same thing could have been achieved in a few lines of code using pandas.
The person creating the app had no experience of python, nor how do to the work. So they could never tell whats wrong.
.. And that is what is going to happen as junior people come into the workforce, as the next line being pushed is you don't need an expert to VC.
Now imagine that tool in the hands of someone who knows how to build it the right way, and can instruct the LLM to generate the code in the right way. You get what you would have created yourself, but just much faster.
I agree with the notion that LLMs may just end up repeating coding mistakes of the past because they are statistically likely mistakes.
I'm reminded of an old quote by Dijkstra about Fortran [1]: "In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included."
I've encountered that same problem in some older scientific codes (both C and Fortran). After a while, the bugs somewhat become features because people just don't know to question them anymore. To me, this is why it is important to understand the code thoroughly enough to question what is going on (regardless of who or what wrote it).
> How does our imagination shrink when we consider our options of what we create with code to be choosing between the outputs of the LLM rather than starting from the blank slate of our imagination?
This has been my biggest hesitancy with adopting these technologies. All of the things of which I’m most proud of building were built from a foundation of deep understanding of several domains, not from the solutions of a series of one offs problems, but from the process of solving them.
There are too much of both fear and optimism in what's is essentially a better compiler and google.
Eventually we will gravitate back to square one, and business people are not going to be writing COBOL or VISUAL BASIC or the long list of eventual languages (yes this now include natural ones, like English) that claim to be so easy that a manager would write it. And Googling/Prompting remain a skill that surprisingly few has truly mastered.
Of course all the venture capital believe that soon we'll be at AGI, but like the internet bubble of 2001 we can awkwardly stay at this stage for quite a long time.
I’ve had a similar thought about language, and the evolution or lack thereof with LLMs.
With the printing press+internet, one might argue that we’ve helped cement current languages, making it harder for language to evolve naturally.
(A counterpoint may be slang/memes/etc. which has likely increased the velocity of new words for any given language.)
In either case, one might see LLMs as further cementing language, as it’s the thing the machines understand (until their next training run).
Assuming we struggle to make LLMs that learn in realtime, one might suspect that these amazing new tools might further cement the status quo, meaning less new words than before.
With all that said, I think I’ve come to the conclusion that LLMs will likely speed up the evolution of language.
The hypothesis being, that future generations will develop communication that the robots can’t read, at least at first.
A never-ending game of cat and mouse; while the cat is on v6, the mouse is on v7. Ad infinitum.
I am not sure I am doing it the right way or if there's a right way, but what I do is generate small files one at a time, with a functional system of stateless input/output. That way I can focus first on architecture, then on stateless input/output Lego blocks, and just ask the AI to generate the Lego blocks. Like this, everything is easy to keep in mind and update and change after experiencing the tech and having emotions telling me what to change. It has been working great for me. It strikes a good balance between simple and robust, fast to build, plus easy to update. The other thing is that since I haven't spent too much energy on writing the code, it is very easy to detach emotionally from it when reality gives me new info that requires throwing out part of the system.
Just finished my first fully vibe coded app. A proxy for Claude code to transparently switch between providers on the fly. Zero lines written by me
It works, but I wouldn’t give it to someone else to use because I have little idea how to fix or troubleshoot it beyond shouting at an LLM.
It’s weird.
I don’t think the authors thesis about „radical“ apps is right though. You can definitely arrange simple vibe coded components in novel ways. Much of the business logic out there powering billion dollar companies isn’t exactly mind bending innovative code
> A lot is still very uncertain, but I come back to one key question that helps me frame the discussion of what’s next: What’s the most radical app that we could build? And which tools will enable me to build it? Even if all we can do is start having a more complicated conversation about what we’re doing when we’re vibe coding, we’ll be making progress towards a more empowered future.
I can't wait for the days where LLM written articles are indistinguishable from real writing, so people stop complaining about this. I am giving that another 6 months. In a lot of cases its not just lazy prompt -> article, but rather text synthesis through LLMs -> article. But people will still complain /rant (bias: I run a blog with only AI written content, but a loyal audience).
I'm not sure that "radical" apps aren't more often built because we don't know how, than because we don't have the time, funding, or risk budget to do it.
For those cases, I think LLM-assisted coding has the ability to drastically change the usual formula and help bring into being projects that people would previously only daydream about, hoping that the world aligns with their vision one day and they can magically spin up a team to work on it.
Coding agents are fast becoming at least a part of that team. If you're idea is in a domain where they've had a lot of high-quality training code, they can already do a pretty amazing job of getting a project off the ground. If you're a programmer with at least some domain knowledge and can guide the design and push the agent past tough spots, you can keep the project going when the LLMs get bogged down.
I think at the very least, we're going to see some incredibly impressive prototypes, if not complete implementations, of OSes, programming languages, hypermedia systems, protocols, etc. because one passionate programmer threw a lot of LLM time them.
Basically lots of people are going to be able to build their own TempleOS now. Some of those might end up being impactful.
“Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.”
― Frank Herbert, Dune
> A huge reason VCs and tech tycoons put billions into funding LLMs was so they could undermine coders and depress wages
is just pure speculation, totally unsupported, and almost certainly untrue, and makes very little sense given the way LLMs and ChatGPT in particular came about. Every time I read something from Anil Dash it seems like it's this absolutely braindead sort of "analysis".
In whatever way this is true, it has very little to do with sticking it to "coders" but is about magically solving/automating processes of any kind. Replacing programmers is small potatoes, and ultimately not a good candidate for jobs to replace. Programmers are ideal future AI operators!
What AI usage has underlined is that we are forever bound by our ability to communicate precisely what we want the AI to do for us. Even if LLMs are perfect, if we give it squishy instructions we get squishy results. If we give it a well-crafted objective and appropriate context and all the rest, it can respond just about perfectly. Then again, that is a lot of what programming has always been about in the first place - translate human goals into actionable code. Only the interface and abstraction level has changed.
I recently heard a C-suite executive at a unicorn startup describe a particular industry as made up of small-scale, prideful craftsmen who will be unable to compete with agentic AI.
I don't know how much "VCs and tech tycoons" want to undermine coders specifically, but they see a huge opportunity to make money by making things much more efficiently (and thus cheaper) than they can be made now. The way to they plan to do that is to reduce the cost of labor. Which means either automating away jobs or making jobs much less specialized so that you don't need a highly-paid craftsman.
Think about Henry Ford setting up an assembly line where a worker sits at the same location and performs the same action all day, every day. You don't need a highly-skilled, highly-paid person with leverage and power to do that job.
> Vibe coding might limit us to making simpler apps instead of the radical innovation we need to challenge Big Tech
is also pure speculation and doesn't make sense. In fact, enabling people to create small and simple apps could well indeed challenge and weaken dependence on big tech.
I think this is one of the reasons we don't see huge productivity gains. Most F500 companies have pretty proprietary gnarly codebases which are going to be out-of-distribution. Context-engineering helps but you still don't get near the performance you get with in-distribution. It's probably not unsolvable but it's a pretty big problem ATM.
reply