Hacker News new | ask | show | jobs
by kccqzy 94 days ago
Because AI still hallucinates. Since you mentioned algorithms, today for fun I decided to ask Claude a pretty difficult algorithm problem. Claude confidently told me a greedy solution is enough, before I told Claude a counterexample that made Claude use dynamic programming instead.

If you haven't learned the fundamentals, you are not in a position to judge whether AI is correct or not. And this isn't limited to AI; you also can't judge whether a human colleague writing code manually has written the right code.

3 comments

That is correct. But for how long ? How long would it take for AI to learn all of this too ? AI sure does learn faster than humans and even though it will never degrade the relevance of fundamentals, don't you think that the bar for someone beginning to learn about the fundamentals, would just keep increase exponentially.
AI takes XYZ data to set N range, it never created anything new but took all and created a baseline, which is at many tasks very good.

It cannot really create anything new and never seen, which most people will never do either.

So if we push away even more onto AI, I am afraid MANY(not all) that would previously gone through the discovery path won't stumble onto their next innovation, since they simply prompted a good baseline for ABC task, because we are lazy.

Even if AI knows everything and is basically sentient, we still need to understand these things to work with it. How can we prompt it reliably without understanding the subject matter for which we are prompting?

If anything I consider fundamentals in STEM (such as Math/CS) to be even more valuable moving forward.

Did you give Claude a way to test/verify/benchmark said algorithm compared to other solutions?

If not, how can it not hallucinate when you didn't give it any constraints?

You can just tell it that it's doing it wrong (and why). Of course, you have to know that it did it wrong.
The point is that if you know the algorithm will produce X as the output if the input is Y, give that as a tool to Claude

And if you know that the previous algorithm completes in Z milliseconds, tell Claude that too and give it a tool (a command it can run) to benchmark its implementation.

This way you don't need to tell it what it did wrong, it'll check itself.

It was the other way around. Claude gave me an algorithm. I found it fishy. So I specifically constructed a counterexample in response to Claude’s algorithm.

Of course when I gave that to Claude, Claude changed the algorithm. But if I didn’t have enough experience and CS fundamentals to find it fishy in the first place, why would I construct a counterexample?

The prompt would be <select code>, "Use a std::unordered_map<>" to make this code run faster." Review the code. Done.
I'm curious, what was the algorithm problem?
It’s a variant of a knapsack problem. But neither Claude nor I initially realized it was a knapsack problem: it became clear only after the solution was found and proved.