Just use the AI to run sentiment analysis on the crate source!
(This is a joke.)
As usually, we should ask who will judge that a crate is crappy one or good for others? Ironically, it will be AI bot, because you have no bandwidth to evaluate millions of crates. I even do not have a bandwidth to review all code inside my organization, and I know it's mostly AI generated. Even mathematicians accepted the power of AI:
In March 2025, mathematician Daniel Litt made a bet. Despite the march of progress of artificial intelligence in many fields, he believed his subject was safe, wagering with a colleague that there was only a 25 per cent chance an AI could write a mathematical paper at the level of the best human mathematicians by 2030. Only a year later, he thinks he was wrong. āI now expect to lose this bet,ā he declared on his blog.
So we expect a similar confession from you in 2026.
PS AI got stuck to solve a simple problem to show search box in Ace editor prefilled with some text, so I believe that AI is still behind of humans.
Not really.
But you don't need to look on millions of crates. You only need to look on dozen, maybe two.
All others may simply be ignored.
This works with clothes or food, why should crates be any different?
So he haven't yet even lost the bet and you already declare victory? Hmm. Typical.
Chances are essentially zero.
Ah. So now we are moving the goalposts. Again.
Please note that I never said that AI wouldn't ever reach the point where it would be able to write sustainable code. Or would be able to fill the tax form. Maybe closer to the middle or the end of XXI it would. It's possible. Demis Hassabis estimates that it would be 5-10 years and and requires what he calls "two AlphaGo-scale breakthroughs which sounds possibleā¦ but I think he is too optimistic: he assumes that AI industry would continue to fail to deliver and yet people would continue to pour money into it ā if that wouldn't happen then 20 or maybe 50 years are more likely.
But 2026? I really like that quote (said about the use of AI for selecting targets like that infamous Iranian school): Using a system you shouldnāt trust with your taxes to blow people up. 2026 in a nutshell.
There's no way in hell AI would be producing good, supportable, code in 2026, the only thing that may happen is artificial (heh) declaration that AI is āreadyā and should be used everywhere.
That's possible, we had that story before, but it wouldn't end well.
Iām an old-time java enterprise developer but Iāve been learning Rust in my spare time. I find vibe coding to be not just useful in understanding Rust syntax, but darned fun. I treat each session as if Iām in a scrum standup, always skeptical and asking questions - why iterate over a vector when HashMap would be more efficient. Team coding used to be a thing. Vibe coding is just the next progression.
Common problems Iāve encountered are code duplication, verbosity, dead functionality and, of course, the usual bugs. These problems increase as the code grows larger, but the time saved is worth the price. Being able to produce a complex, workable app in a day or two that would require a development team weeks or months to mirror is the tradeoff.
But like any app, in any language, however built, the devil is in the details, that last 10-15% of coding that no amount of AI, alone, can complete. Thatās where Iād rather spend my time. Becoming a proficient Rust developer is not my aim. Building a quality app is.
Just another thought. While vibe coding may seem magical, itās just another turing machine. Whatever AI can do so can a piece of tape with symbols moving across a head that reads and writes according to a few instructions. Faster, yes, but more powerful? No. It doesnāt think and isnāt a replacement for well considered thought.
I think the term (as Karpathy originally used it) leans more toward not really reading or engaging with the generated code - the agent can more or less build the app from a description, and you steer at a higher level.
What youāre describing sounds closer to traditional engineering discipline, just with AI in the loop: questioning choices, thinking about data structures. I think that is increasingly becomming the norm in corporate environments - the shift has happened pretty quickly.
Karpathy had a recent follow-up idea: instead of sharing code, you maintain a detailed āidea fileā (intent, constraints, structure), and let the agent implement from that. Others can then take that same idea file and have their own AI rebuild the app.
Example:
Yeah, if AI actually works reliably then the code generated by the AI has negative value, in a sense -- better to not check it in, and just have the newer AI regenerate it as needed, since the newer AI will be better at it.
Not unlike how we don't check in the assembly code corresponding to our Rust projects.
Generally, it's what programming should be in my understanding. I called it as a declarative programming, when I specify what my code should do, and how, the machine decides. People call it as a vibe coding, but it's matter of a personal taste in names.
It is like telling a chef what to cook for your dinner instead of cooking it yourself. Some people better like the first option, some the second one. What I don't like is people inviting me to dinner and behaving as if they cooked when they did not (the chef did).
Which is about the style I adopted a few months back.
I have a little discussion with the LLM about my overall project goals. It's inputs, it's outputs, its user interface, etc.
Then move the discussion on to more detailed step by step approach to actually building it.
Then focus on more detail of the first step.
This all ends up in a design document, the "idea file", and we move in to generating code.
Then focus on the next step, add those ideas to the design doc and build it.
And so on.
Now, I'm not sharing the resulting design do, the "idea file" but it came in handy this week. I had build a real-time data visualisation using Slint. I decided I wanted that but in 3D for some extra effect. So the LLM got. the same "idea file" but with the requirement to use webgpu instead of slint. In no tie at all it was up and running and looking better than I dared imagine.
The worrying thing about all this is that the webgpu API is huge and complex and I have little idea how it works or about shaders and 3d graphics in general. So I have thousands of lines of code that it would take me weeks to begin to understand!
But if that ideas file is now my source code then why worry? As someone said, we don't worry about understanding all the assembler compilers generate.
The compiler is deterministic: given the same input you always get the same output. Have you tried to give the exact same instructions to an LLM twice and then diff the code? I did some experiments and sometimes as much as 80% of the code differs. And that, sincerely, bothers me.
...modulo optimizations which can change on every update. And yes, they must not change the meaning of the resulting machine code, - but for vibe-coders, LLM must not change the meaning of their prompt, either (whether this is possible even theoretically - I'm not sure, but that's the premise I've heard).
we don't worry about the assembler compiler generaes because compilers have the extremely strict contract of the as-if rule, which they have religiously upheld for as long as they have existed.
and if we ever had a compiler that did not respect the as-if rule, you can bet anyone using it would check the assmebly that was generated.
but llms, as random word generators, are completely unable of respeciting it. even if you had a perfect deterministic seeding for one. adding a word in one section of your input prompt would still completely modify how all unrelated parts would be generated.
so what you end up with is completely unreliable software, where bugs appear, disappear, and reappear every few versions.
In my opinion, LLMs shouldnāt be used for writing code, by professionals or for āvibeā coding, as some call that, period.
Iāve explained why often enough: LLMs donāt have the necessary components for problem solving, and theyāre very deceitful. We should put that new AI hype to rest and allow more funds to flow into more promising AI research instead. But my thoughts on LLMs have been expressed often enough.
Vibe coding is even worse. Iāve discussed with people who werenāt programmers and thought LLMs were great, which is worrying. They donāt have the methodology to develop and validate code, they donāt have the knowledge required to appreciate the issues in the code produced by a chatbot, and they donāt learn anything by doing it.
Anyway, I think itās too controversial a topic, so itās probably best to avoid it here.
What if something goes wrong? What if you find a bug that you never saw before? "Just ask the LLM to fix it," you might say. That simply makes the situation worse. I can't write this without sounding like @khimru, so here is what they said:
People become programmers for two reasons:
- The jobs/money.
- They enjoy programming and learning about it.
Generally a mix of both.
The first point is obsolete now, leaving us with programmers who code because they love it. This is the best kind of programmer. Now, sure, a plagiarising algorithm might be better than a new coder, but why would they outsource their passion? Why would anyone let a machine do what they love for them? It takes all the joy out of programming.
Yet another huge issue with AI is that it removes the maintainer. It removes the person who knows the code and how it works. When it all goes to pot, who does the user tell? You're not in charge. You didn't make the code. You don't even have a clue how it works!
Sounds like what we were trained to accept over last 10 or maybe even 20 years.
Looks like LLMs have been made viable not just by improving LLMs but also by degrading human codeā¦ in fact human code was degraded first.
ig it depends on what we are talking about, it's true that website and web apps have gotten clunky, but we still rely on a huge amount of fundational software, and that software is as relyable as ever.
even most mainstream javascript libraries are way more reliable than anything an llm could ever hope to produce.
You might think so - but there is still joy to be had.
I have noticed several famous programmers - who love programming - who have enthusiastically embraced it.
Eric S Raymond
Antirez
DHH
Furthermore, the AI wonāt learn. A human will, so thatās a good investment.
Well, to be honest, I could see how this is possible, if someone enjoys programming (=creating logic for the program), but not coding (=translating this logic into source code). In this case, LLMs could do exactly as advertised - "human does what one wants and leaves the boring parts to machine". It doesn't work exactly like this (because code review, necessary when working with LLMs, is also the "boring part"), but the idea might be actually meaningful.