I think KronisLV's point, presented ironically, is that not even an AI superior to human reasoning, which can figure out things we cannot, can decide the undecidable.
Being undecidable is a hard limit, not something that requires better algorithms. Another phrasing of it could be: No finite program can decide it.
(And what even is an infinite program? Not something we can run on any current computer.)
If an AI is itself a finite-sized program, something we run on computers, it cannot possibly solve the halting problem.
And _any_ non-trivial property of programs is undecidable, so an AI "integrating with any .exe file" isn't really meaningful. It's just words.
> Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.)
The complexity of the program trying to decide is not really the issue. An "infinite program" could add an infinite number of extra rules to try to cut down on the time taken to determine if a decidable program halts, but the issue with the halting problem is that there is an infinite set of undecidable programs where the size of your detector will make no difference to your ability to decide them.
E.g. "while next_symbol() == some_arbitrary_symbol {}" is undecidable unless you add constraints on the length or contents of the input.
Even if you haven infinite-sized program you can't decide whether or not the unconstrained version of that halts, because deciding it is equivalent to being able to determine if an infinite tape contains a given symbol, and no matter how long you scan the tape the symbol can always be the next one on the tape after the last symbol you scan.
> And _any_ non-trivial property of programs is undecidable
I don't think I agree with this without adding the qualifier "in general". There are a whole lot of useful properties we can decide, but often the properties will have constraints. E.g. for a whole lot of programs where we can't decide whether or not they will halt, we can still decide whether or not they will halt assuming certain properties of their inputs. E.g. we can decide the property of my pseudo-code above that it will haltIF "some_arbitrary_symbol" is in the input. We can also decide the property that whether or not it will halt in general is undecidable, and that is itself useful to know, because for many programs knowing what makes them undecidable is useful in order to suggest e.g. adding timeouts, or ensuring there are ways to bail early from certain actions without restarting the machine or killing the program.
For a whole lot of problems we also do not really care whether or not a given property is decidable. We care whether they're decidable often enough within certain time constraints, and that's a very different ballgame.
It has meaning. By looking at a table in e.g. getopt() call and an output of --help I can often infer modes of a program that I probably need, to do my job when someone asks me to. Whether this getopt() gets called or if a program does what it claims in usage() is not my concern. I was commanded to guess the usage and I do it without burying into the halting problem. And so does that hypothetical AI.
Decidable or undecidable is about maths, not practice.
Being undecidable is a hard limit, not something that requires better algorithms. Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.)
If an AI is itself a finite-sized program, something we run on computers, it cannot possibly solve the halting problem.
And _any_ non-trivial property of programs is undecidable, so an AI "integrating with any .exe file" isn't really meaningful. It's just words.