To me it feels like part of the hype train, like crypto & VR.
I recently had the (dis)pleasure of fixing a bug in a codebase that was vibe coded.
It ends up being a collection of disorganized business problems converted into code, without any kind of structure.
Refinements are implemented as super-narrow patches, resulting in complex and unorganized code, whereas a human developer might take a step back to try and extract more common patterns.
And once you reach the limit of the context window you're essentially suck, as the LLM can no longer keep track of its patches.
English (or all spoken human language) is not precise enough to articulate what you want your code to do, and more importantly, a lot of time and experience precedes code that a senior developer writes.
If you want to have this senior developer 'vibe' code, then you'll need to have a way to be more precise in your prompts, and be able to articulate all learnings from your past mistakes and experience.
And that is incredibly heavy. Remember, this is opposite from answering 'why did you write it like this'. This is an endless list of items that say 'don't do this, but this, in this highly specific context'.
Counterpoint: AI has help me refactor things where I normally couldn’t. Things like extracting some common structure that’s present in a slightly different way in 30 places, where cursor detects it, or suggesting potential for a certain pattern.
The problem with vibe coding is more behavioral I think: the person more likely to jump in the bandwagon to avoid writing some code themselves is probably not the one thinking about long term architecture and craftsmanship. It’s a laziness enhancer.
> AI has help me refactor things where I normally couldn’t.
Reading "couldn't" as, you would technically not be able to do it because of the complexity or intricacy of the problem, how did you guarantee that the change offered by the AI made proper sense and didn't leave out critical patterns that were too complex for you to detect ?
Your comment makes it sound like you're now dependent on AI to refactor again if dire consequences are detected way down the line (in a few months for instance), and the problem space is already just not graspable by a mere human. Which sounds really bad if that's the case.
Before I started using advanced IDEs that could navigate project structures very quickly, it was normal to have a relatively poor visibility -- call it "fog of war/code". In a 500,000 line C++ project (I have seen a few in my career), as a junior dev, I might only understand a few thousand lines from a few files I have studied. And, I had very little idea of the overall architecture. I see LLMs here as a big opportunity. I assume that most huge software projects developed by non-tech companies look pretty similar -- organic, and poorly documented and tested.
I have a question: Many people have spoken about their experience of using LLMs to summarise long, complex PDFs. I am so ignorant on this matter. What is so different about reading a long PDF vs reading a large source base? Or can a modern LLM handle, say, 100 pages, but 10,000 pages is way too much? What happens to an LLM that tries to read 10,000 pages and summarise it? Is the summary rubbish?
Get the LLM to read and summarise N pages at a time, and store the outputs. Then, you concatenate those outputs into one "super summary" and use _that_ as context.
Theres some fidelity loss but it works for text, because there's quite often so much redundancy.
However, I'm not sure this technique could work on code.
You raise a good point. I had a former teammate who swore by Source Insight. To repeat myself, I wrote: <<Before I started using advanced IDEs that could navigate project structures very quickly>>. So, I was really talking about my life before I started using advanced IDEs. It was so hard to get a good grasp of a project and navigate quickly.
Sometimes a problem is a weird combination of hairy/obscure/tedious where I simply don’t have the activation energy to get started. Like, I could do it with a gun to my head.
But if someone else were to do it for me I would gratefully review the merge request.
Reviewing a merge request should require at least the same activation energy as writing the solution yourself, as in order to adequately evaluate a solution you first need to acquire a reference point in mind as to what the right solution should be in the first place.
For me personally, the activation energy is higher when reviewing: it’s fun to come up with the solution that ends up being used, not so fun to come up with a solution that just serves as a reference point for evaluation and then gets immediately thrown away. Plus, I know in advance that a lot of cycles will be wasted on trying to understand how someone else’s vision maps onto my solution, especially when that vision is muddy.
The submitter should also have thoroughly reviewed their own MR/PR. Even before LLMs, coders not having reviewed their own code would be completely discourteous and disrespectful to the reviewer. It's an embarrassing faux pas that makes the submitter and the team all look and feel bad when there are obvious problems that need to be called out and fixed.
Submitting LLM barf for review and not reviewing it should be grounds for termination. The only way I can envision LLM barf being sustainable, or plausible, is if you removed code review altogether.
Writing/reading code and reviewing code are distinct and separate activities. It's completely common to contribute code which is not production ready.
If you need an example, it's easy to add a debugging/logging statement like `console.log`, but if the coder committed and submitted the log statement, then they clearly didn't review the code at all, and there are probably much bigger code issues at stake. This is a problem even without LLMs.
Just call it “committing bad code”. LLM autocomplete aside, I don’t see how reviewing own code can happen without either a split personality, or putting enough time that you completely forgot what exactly you were doing and have fresh eyes and mind.
If person A committed code that looks bad to person B, it just means person A commits bad code by the standard of person B, not that person A “does not review own code”.
Maybe it’s a subjective difference, same as you could call someone “rude” or you could say the same person “didn’t think before saying”.
Person A as can commit atrocious code all day, that's fine, but they still need to proofread their MR/PR and fix the outstanding issues. The only way to see outstanding issues is by reviewing the MR/PR. Good writers proofread their documents.
My preferred workflow requires me to go through every changed chunk and stage them one by one. It’s very easy with vim-fugitive. To keep commits focused, it requires reading every chunk, which I guess is an implicit review of sorts.
I think, if it’s similar to how I feel about it, that it’s more about always being able to do it, but not wanting to expend the mental effort to correctly adjust all those 30 places. Your boss is not going to care, so while it’s a bit better going forward, justifying the time to do it manually doesn’t make sense even to yourself.
If you can do it using an LLM in a few hours however, suddenly making your life, and the lives of everyone that comes after you, easier becomes a pretty simple decision.
AI is a sharp tool, use it well and it cuts. Use it poorly and it'll cut you.
Helping you overcome the activation barrier to make that redactor is great if that truly is what it is. That is probably still worth billions in the aggregate given git is considered billion dollar software.
But slop piled on top of slop piled on top of slop is only going to compound all the bad things we already knew about bad software. I have always enjoyed the anecdote that in China, Tencent had over 6k mediocre engineers servicing QQ then hired fewer than 30 great ones to build the core of WeChat...
AI isn't exactly free and software maintenance doesn't scale linearly
> But slop piled on top of slop piled on top of slop is only going to compound all the bad things we already knew about bad software
While that is true, AI isn’t going to make the big difference here. Whether the slop is written by AI or 6000 mediocre engineers is of no matter to the end result. One might argue that if it were written by AI at least those engineers could do something useful with their lives.
There's a difference between not intellectually understanding something and not being able to refactor something because if you start pulling on a thread, you are not sure what will unravel!
And often there just isn't time allocated in a budget to begin an unlimited game of bug testing whack-a-mole!
To makeitdouble's point, how is this any different with an LLM provided solution? What confidence do you have that isn't also beginning an unlimited game of bug testing whack-a-mole?
My confidence in LLMs is not that high and I use Claude a lot. The limitations are very apparent very quickly. They're great for simple refactors and doing some busy work, but if you're refactoring something you're too afraid to do by hand then I fear you've simply deferred responsibility to the LLM - assuming it will understand the code better than you do, which seems foolhardy.
As the op, for the case I was thinking about, it’s “couldn’t” as in “I don’t have the time to go checking file by file and the variation is not straightforward enough that grepping will surface cases straightforwardly”.
I’m very much able to understand the result and test for consequences, I wouldn’t think of putting code I don’t understand in production.
> Your comment makes it sound like you're now dependent on AI to refactor again
Not necessarily. It may have refactored the codebase in a way that is more organized and easier to follow.
> how did you guarantee that the change offered by the AI made proper sense and didn't leave out critical patterns that were too complex for you to detect ?
How is it the wrong tool for the job? In this particular case it's excellent, it can help you find proper abstractions.. without them you wouldn't realize.
I kind of view this use case as enhanced code linters
Do you expect an incoming collapse of modern society?
That's the only case where LLM would be "not there anymore." Even if this current hype train dies completely, there will still businesses providing LLM interference, just far less new models. Thinking LLM would be "not there anymore" is even more delusional than thinking programmer as a job would cease to exist due to LLM.
> It only looks effective if you remove learning from the equation.
It's effective on things that would take months/years to learn, if someone could reasonably learn it on their own at all. I tried vibe coding a Java program as if I was pair programming with an AI, and I encountered some very "Java" issues that I would not have even had the opportunity to get experience in unless I was lucky enough to work on a Fortune 500 Java codebase.
AI doesn't work in a waterfall environment. You have to be able to rapidly iterate, sometimes in a matter of hours, without bias and/or emotional attachment.
> AI doesn't work in a waterfall environment. You have to be able to rapidly iterate, sometimes in a matter of hours, without bias and/or emotional attachment.
What do you mean? There is no difference between waterfall or agile in what you do during a few hours.
Not at all true. You just adopted the wrong model to partner with it. Think of yourself as an old school analyst vs a programmer.
Throw a big context window model like Gemini at it to document the architecture unless good documentation exists. Then use modify that document to drive development of new or modified code.
Many big waterfall projects already have a process for this - use the AI instead of marginally capable offshore developers.
Might not be the case for the senior devs on HN, but for most people in this industry, it's copy/pasting a jira ticket into a LLM, which generates some code that seems to work and a ton of useless comments, then pushing it on github without even looking at it once and then moving to the next ticket.
A form of coding by proxy, where the developer instructs (in English prose) an LLM software development agent (e.g. cursor IDE, aider) to write the code, with the defining attribute that the developer never reviews the code that was written.
I review my vibe code, even if it’s just skimming it for linter errors. But yeah, the meme is that people are apparently force pushing what ever gets spat out by an LLM without checking it.
Vibe coding is instructing AI to create/modify an application without yourself looking at or understanding the code. You just go by the "vibe" of how the running application behaves.
I have the same observation. I've been able to improve things I just didn't have the energy to do for a while. But if you're gonna be lazy, it will multiply the bad.
Trying to get some third party hardware working with raspi
The hardware provider provides 2 separate code bases with separate documentation but only supports the latest one.
I literally had to force feed the newer code base into ChatGPT, and then feed in working example code to get it going, else it constantly reference the wrong methods.
If I just kept going Code / output / repeat it would maybe have stumbled on the answer but it was way off.
This is one of several shortcomings I’ve encountered in all major LLMs. The llm has consumed multiple versions of SDKs from the same manufacturer and cannot tell them apart. Mixing up apis, methods, macros, etc. Worse is that for more esoteric code with fewer samples, or more wrong than right answers in the corpus means always getting broken code. I had this issue working on some NXP embedded code.
Human sites are also really bad about mixing content from old and new versions. SO to this day still does not have a version field you can use to filter results or more precisely target questions.
I see those as carefully applied bandaids. But maybe that’s how we need to use AI for now. I mean we’re burning a lot of tokens to undo mistakes in the weights. That can’t be the right solution because it doesn’t scale. IMO.
Yesterday I searched how to fix some windows issue, google AI told me to create a new registry key as a 32 bit value and write a certain string in there.
> Counterpoint: AI has help me refactor things where I normally couldn’t. Things like extracting some common structure that’s present in a slightly different way in 30 places, where cursor detects it, or suggesting potential for a certain pattern.
I have a feeling this post is going to get a lot of backlash, but I think this is a very good counterpoint. To be clear: I am not here to shill for LLMs nor vibe coding. This is a good example where an "all seeing" LLM can be helpful.
Whether or not you choose to accept the recommendation from the LLM isn't my main point. The LLM making you aware is the key value here.
Recently, I was listening to a podcast about realistic real world uses for an LLM. One of them was a law firm trying to review details of a case to determine a strategy. One of podcasters (sp?) recoiled in horror: "An LLM is writing your briefs?" They replied: "No, no. We use it generate ideas. Then, we select best." It was experts (lawyers, in this case) using an LLM as a tool.
If you couldnt do the task youself (a very loaded statement which I honestly dont't believe), how could you even validate what llm did was correct, didnt miss anything, didnt introduce a nasty corner case bug etc?
In any case a very rare and specific corner case you mention, a dev can go on a decade or two (or lifetime or two) without ever experiencing similar requirement. If it should be a convincing argument for almighty llm it certainly isnt.
I've found it can help one get the confidence to get started, but there are limits and there is a point where a lack of domain knowledge and a desired target (sane) architecture will bight you hard.
You can have AI almost generated anything, but even AI has limited to understanding requirements, if you cannot articulate what you want very precisely, it's difficult to get "AI" to help you with that.
Is cursor _that_ good on monorepo? My use with AI so far has been the chat interface. I provide a clear description of what i want and manually copy paste it. Using copilot, I couldn't buy their agentic mode nor adding files to the chat' session context.
Gemini' large context has been really good handling large context, but still doesn't help much in refactoring.
Cursor is good as retrieving the appropriate context and baking it into your request, which significantly improves responses and reduces friction. It sometimes pulls generic config or other stuff that I might miss to include in a first attempt
The same thing as always: either a strong tech voice convinces them to invest the required time or corners are cut and we all cry later. But I don’t see how that is made better or worse by AI.
Any actual evidence of it being better? Because publicly available evidence points to the contrary, where it repeatedly fails to complete the most basic of tasks.
> English (or all spoken human language) is not precise enough to articulate what you want your code to do
Exactly. And this is why I feel like we are going to go full circle on this. We've seen this cycle in our industry a couple times now:
"Formal languages are hard, wouldn't it be great if we could just talk in English and the computer would understand what we mean?" -> "Natural languages are ambiguous and not precise, wouldn't it be great if we could use a formal langue so that the computer can understand precisely what we mean?"
The eternal hope is that someday, somehow, we will be able to invent a natural language way of communicating something precise like a program, and it's just not going to happen.
Why do I think this? Because we can't even use natural language to communicate unambiguously between intelligent people. Our most earnest attempt at this, the law, is so fraught with ambiguity there's an entire profession dedicated to arguing in the gray area. So what hope do we have controlling machines precisely in this way? Are future developers destined to be equivalent to lawyers, who have to essentially debate the meaning of a program before it's compiled, just to resolve the ambiguities? If that's where this ends up, I will be very sad indeed.
> The eternal hope is that someday, somehow, we will be able to invent a natural language way of communicating something precise like a program, and it's just not going to happen
My take is more nuanced.
First, there is some evidence [1] that human language is neither necessary nor sufficient to enable what we experience as "thinking".
Second, our intuition, thinking etc are communicated via natural languages and imagery which form the basis for topics in the humanities.
Third, from communication via natural language - slowly emerges symbolism, and formalism which codifies intuitions in a manner which is operational, and useful.
As an example, socratic dialog was a precursor to euclidean geometry which operationally codifies our intuitions of space around us in a manner which becomes useful.
However, formalism is stale as there are always new worlds we experience which cannot be captured by any formalism. The genius of the human brain which is not yet captured in LLMs is to be able create symbolisms of these worlds almost on demand.
ie, if we were to order in terms of expressive power, it would be something like:
1) perception, cognition, thinking, imagination
2) human language
3) formal languages and computers codifying worlds experienced via 1) and 2)
Meanwhile, there is a provocative hypothesis [2] which argues that our "thinking" process lies outside computation as we know it.
> Are future developers destined to be equivalent to lawyers, who have to essentially debate the meaning of a program before it's compiled, just to resolve the ambiguities?
Future developers? You sound like you've never programmed in C++.
> The eternal hope is that someday, somehow, we will be able to invent a natural language way of communicating something precise like a program, and it's just not going to happen
what we operationally mean by "precise" involves formalism. ie, there is an inherent contradiction between precise, and natural languages.
>> The eternal hope is that someday, somehow, we will be able to invent a natural language way of communicating something precise like a program, and it's just not going to happen.
I think the closest might be the constructed language "Ithkuil". Learning it is....difficult, to put it mildly.
it doesn't have to be precise enough anymore though because a perfect AI can get all the details from the existing code and understand your intent from your prompt.
Every time someone points out the fundamental limitation of natural languages vs. formal languages, there's another zealot quick to reply with a logic defying concept of a plan.
"Forty-two!" yelled Loonquawl. "Is that all you've got to show for seven and a half million years' work?"
"I checked it very thoroughly," said the computer, "and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you've never actually known what the question is."
"But it was the Great Question! The Ultimate Question of Life, the Universe and Everything!" howled Loonquawl.
"Yes," said Deep Thought with the air of one who suffers fools gladly, "but what actually is it?"
A slow, stupefied silence crept over the men as they stared at the computer and then at each other.
"Well, you know, it's just everything... everything..." offered Phouchg weakly.
"Exactly!" said Deep Thought. "So once you do know what the question actually is, you'll know what the answer means."
I agree with this. People use natural language all the time for programs. Talking to a teammate when pair programming, clients asking for features in language to developers. Details are there in the existing code and through a running conversation. This is why I like a lot to code with ChatGPT over a copilot type of setup.
While I have a similar experience with, hurm, "legacy" codebase, I gotta say, LLM (in my experience) made the "legacification" of the codebase way, way faster.
One thing especially, is the loss of knowledge about the codebase. While there was always some stackoverflow-coding, when seeing a weird / complicated piece of code, I used to be able to ask the author why it was like that. Now, I sometimes get the answer "idk, its what chatgpt gave me".
"Code increases in complication to the first level where it is too complicated to understand. It then hovers around this level of complexity as developers fear to touch it, pecking away here and there to add needed features."
Most teams are understaffed and under pressure to deliver. Agile is all the rage so why spend time developing architecture when you can yolo it during the implementation phase?
You're not wrong that AI is hyped just like crypto and VR were. But it's also true that automation will increasingly impact your job, even for jobs that we have considered to be highly technical like software engineering.
I've noticed this over the last decade where tech people (of which I am one) have considered themselves above the problems of ordinary workers such as just affording to live. I really started to notice this in the lead up to the 2016 election where many privileged people did not recognize or just immediately dismissed the genuine anger and plight of working people.
This dovetails into the myth of meritocracy and the view that not having enough money or lacking basic necessities like food or shelter or a personal, moral failure and not a systemic problem.
Tech people in the 2010s were incredibly privileged. Earnings kept going up. There was seemingly infinite demand for our services. Life was in many ways great. The pandemic was the opportunity for employers to reign in runaway (from their perspective) labor costs.
Permanent layoff culture is nothing more than suppressesing wages. The facade of the warm, fuzzy Big Tech employer is long gone. They are defense contractors now. Google, Microsoft or Amazon are indistinguishable from Boeing, Lockheed Martin and Northrop Grumman.
So AI won't immediately replace you. It'll start by 4 engineers with AI being able to do the job that was previously done by 5. Laying off that one person saves that money directly but also suppresses the wages of the other 4 who won't be asking for raises. They're too afraid of losing their jobs. Then it'll be 3. Then 2.
A lot of people, particularly here on HN, are going to find out just how replaceable they are and how aligning with the interests of the very wealthiest was a huge mistake. You might get paid $500K+ a year but you are still a worker. Your interests align with nurses, teachers, baristas, fast food workers and truck drivers, not the Peter Thiels of the world.
I think engineers are more like doctors / lawyers, who are also both contracted labor, whose wages can be (and have been) suppressed as automations and tactics to suppress wages arrived.
But these groups also don't have strong unions and generally don't have the class consciousness you are talking about, especially as the pay increases.
You and I seem to be on the same page here but I want to take this opportunity to the role "middle class" plays in preventing class consciousness.
The "middle class" is propaganda we've been fed for decades by our governments, the media and the very wealthy. It's just another way to pit workers against one another, like how the flames of white supremacy were fanned after the slaves were freed so poor whites wouldn't socially align with freed slaves. It's why politics now tends to focus on socially divisive issues rather than economics, like abortion, LGBTQIA+ people, migrants, Islamophobia, etc.
Doctors are workers. Lawyers are workers. Professional athletes are workers.
There have always been segments of the working class, which have deluded themselves into believing that by co-operating with the capitalists, they could shield themselves from the adverse effects of what is happening to the rest of the working class.
And it's an understandable impulse, but at some point you'd think people would learn instead of being mesmerized by the promise of slightly better treatment by the higher classes in exchange for pushing down the rest of the working class.
Now it's our turn as software engineers to swallow that bitter pill.
>but at some point you'd think people would learn instead of being mesmerized by the promise of slightly better treatment
They have already learned, fortunately the entire 20th century was devoted to this. That is why any worker with even a little bit of brain and ability to learn perceives socialists as the main threat to his well-being.
Well given that you're the first in this subthread to even mention socialism, that lesson of the 20th century would probably ring true, yes. Although I must admit that talking about classes like that probably did help conjure that idea.
Of course, it's not like one needs to be a Marxist or even any other sort of a socialist to see the whole "employers are screwing their employees", since I do doubt that many employees working in Amazon's tech like AWS and whatnot would be in the ideology. In fact, that has become a fairly popular position even outside of traditionally leftist politics.
> fairly popular position even outside of traditionally leftist politics
Only leftist politics will actually be able to address the issues. Of course people will just mindlessly scream "sOcIaLiSm!" at anything and everyone, but it ultimately doesn't matter. We still have to be optimistic, once enough people have the vocabulary to think about their increasingly parlous circumstance, things will change in our direction inevitably.
well, in all honesty, a lot of code that actually works in production, and delivers... goods, services, etc. is an over patched mess of code snippets. that sad part is that cpus are so powerful that it works.
In 20 yeas in this market I saw a lot of this. A about 6 years back it was the blockchain crazy.
My boss wanted me to put blockchain in everything (so he could market this to our clients). I printed a small sign and left on my desk. Everytime someone asked me about blockchain, I would point the sign "We don't need blockchain!"
Every 5 years or so, there's some new thing that every uncreative product lead decides they absolutely must have, for no other reason than that it's the "in" thing. Web is hot. We need to put our product on the web. Mobile is hot. We need a mobile app. 3D is hot. We need to put 3D in our product. VR is hot. We need to put VR in our product. IoT is hot. We need to put IoT in our product. Blockchain is hot. We need to put blockchain in our product. AI is hot. We need to put AI in our product. It'll keep going on long after we're out of the business.
If you have to be so precise in your prompts to the point you're almost using a well specified, domain-specific language, you might as well program again because that's effectively the same thing.
One simile I've heard describing the situation where fancy autocomplete can no longer keep track of its patches is that you'll be sloshing back and forth between bugs. I thought it was quite poetic.
Makes me wonder if we’ll see more emphasis on loosely coupled architecture as a result of this. Software engineers maintain the structure, and AI codes it chaos at the leaf. Similar to how data engineers commoditized data via the warehouse
You can see that in this article referencing Jassy's 4,500 years of effort. Which is said "sounds crazy but it's true!"
It isn't true.
The tool he's bragging about most went about changing JDK8 to JDK17 in a build config file, and if you're lucky tweaking log4j versions. 4,500 years my ass. It was more regex and AI
Agreed. I can't think of another area where AI could amplify the effect of my existing level of knowledge as it does with coding. It's far exceeding my expectations.
Yes, it's new and impressive and changing things, but nevertheless it's still underdelivering because the over-promising is out of control. They are selling these things as Ph.D. level researchers that can ace the SAT, pass the MCAT, pass the Bar, yet it still has trouble counting the R's in "strawberry".
It's not solved, I had tried it across the latest versions of several different AIs before I posted, because I anticipated a reply like yours.
> Just because they struggle with that makes all the other things wrong?
No, it makes their grandiose claims very tenuous. But for me, yes I'm very underwhelmed by what AI is capable of. I think it's a useful tool, like a search box, but that's it at this point. That they are branding it as a Ph.D. researcher is just blowing smoke.
> I tried it too and I know this test for a while.
Not only did Claude respond correctly, I also wrote it in German.
You're missing the point though. If it worked for you when you tried it, that's great, but we know these tools are stochastic, so that's not enough to call it "solved". That I tried it and it didn't work tells me it's not. And that's actually worse than it not working at all, because it leads to the false confidence you are expressing.
The strawberry example highlights like all abstractions, AI is a leaky one. It's not the oracle they're selling it as, it's just another interface you have to know the internal details of to properly use it beyond the basics. Which means that ultimately the only people who are really going to be able to wield AI are those who understand what I mean when I say "leaky abstraction". And those people can already program anyway, so what are we even solving by going full natural language?
> I created single page html Javascript pages for small prototypes withhin 10 minutes with very little repromting.
You can achieve similar results with better language design and tooling. Really this is more of an indictment of Javascript as a language. Why couldn't you write the small prototype in 10 minutes in Javascript?
> I can literally generate an image of whatever I want with just text or voice.
Don't get me wrong, I enjoy doing this all the time. But AI images are kind of a different breed because art doesn't ever have to be "right". But still, just like generative text, AI images are impressive only to a point where details start to matter. Like hands. Or character consistency. Multiple characters in a scene. This is still a problem in latest models of AI not doing what you tell it to do.
> I can have a discussion with my smartphone with voice.
Yes, talking to your phone is a neat trick, but is it a discussion? Interacting with AI often feels more like an improv session, where it just makes things up and rolls with vibes. Every time (and yes I mean every) I ask it about topics I'm an expert about, it gets things wrong. Often subtly, but importantly still wrong. It feels like less of a discussion and more like I'm being slowly gaslight. This is not impressive, it's frustrating.
I think you get my point. Yes, AI can be impressive at first, but when you start using it more and more you start to see all the cracks. And it would be fine if those cracks were being patched, or even if they just acknowledged them and the limitations of LLMs. But they won't do that; instead what they are doing is pretending they don't exist, pretending these LLMs are actually good, and pushing AI into literally everything and anything. They've been promising exponential improvements for years now, and still the same problems from day 1 persist.
And we live now in such a fast pace that it feels like Ai should be perfect already and it's of course not.
I also see that an expert can leverage Ai a lot better because you still need to know enough to make good things without.
But Ai progresses very fast and still has achieved things were we have not had any answer than before.
What it can already do is still very aligned of what I assume/expect it from the current hype.
Llama made our ocr 20% better just by using it. I prompted plenty of code snippets and stuff which saved me time and was fun using it. Including python scripts for a small ml pipeline and I normally don't write python.
It's the first tech demo ever which people around me just 'got' after I showed it to them.
It's the first chatbot I have seen which doesn't flake out after my second question.
Chatgpt pushed billions into new computer. Blackwell is the first chip to hit the lower estimation for brain compute performance.
It changed the research field of computer linguistics.
I believe it's fundamental to keep a very close eye on it and trying things out regular otherwise it will over roll us suddenly.
I really enjoy using Claude.
Edit: and eli5 on research paper. That's so so good
You're reinforcing the disparity that I'm pointing out in my original reply. My expectations for AI are calibrated by the people selling it. You say "AI progress is very fast" but again, I'm not seeing it. I'm seeing the same things I saw years ago when ChatGPT first came on the scene. If you go back to the hype of those days, they were saying "Things will change so rapidly now that AI is here, we will start seeing exponential gains in what we can accomplish."
They would point to the increasing model sizes and the ability to solve various benchmarks as proof of that exponential rise, but things have really tapered off since then in terms of how rapidly things are changing. I was promised a Ph.D. level researcher. A 20% better result on your OCR is not that. That's not to say it's a good thing and an improvement, but it's not what they are selling.
> Blackwell is the first chip to hit the lower estimation for brain compute performance.
What does that even mean? That's just more hype and marketing.
Nope not marketing. I researched this topic myself. I'm not aware that Nvidia mentioned this.
But hey it seems I can't convince you of my enthusiasm regarding ai. It's fine I still will play around with it often and looking forward to it's progress.
Regarding your researcher: NotebookLM is great and you might need to invest a few hundred bucks to really try out more.
Your enthusiasm for AI is just more hype noise as far as I'm concerned. You say you've "done research" but then don't link it for anyone to look into, adding to the hype. Brain compute performance is not a well-understood topic so saying some product approaches it is pure marketing hype. It's akin to saying the brain is a neural net.
If I could afford it I'd quite happily employ a Ph.D. level researcher with inability to count the R's in strawberry. The real problem is in accurately characterising where these models fail in relatively subtle task-relevant ways. Hopefully people work that out before they are universally deployed. The overpromising is definitely a problem.
I recently had the (dis)pleasure of fixing a bug in a codebase that was vibe coded.
It ends up being a collection of disorganized business problems converted into code, without any kind of structure.
Refinements are implemented as super-narrow patches, resulting in complex and unorganized code, whereas a human developer might take a step back to try and extract more common patterns.
And once you reach the limit of the context window you're essentially suck, as the LLM can no longer keep track of its patches.
English (or all spoken human language) is not precise enough to articulate what you want your code to do, and more importantly, a lot of time and experience precedes code that a senior developer writes.
If you want to have this senior developer 'vibe' code, then you'll need to have a way to be more precise in your prompts, and be able to articulate all learnings from your past mistakes and experience.
And that is incredibly heavy. Remember, this is opposite from answering 'why did you write it like this'. This is an endless list of items that say 'don't do this, but this, in this highly specific context'.