Am I wrong to conclude that the statement by Google's VP of Security Engineering that "we simply must eliminate every software vulnerability on Earth" (before AI Agents find them) is not only stunningly ambitious, but doomed from the start?
As in, there is no programming language complex enough to describe any program, that is not inherently complex enough to describe bugs? Sounds legit, how would one prove it? :)
At least not automatically. From an algorithmic standpoint it seems likely to be undecidable. But let us not look too closely at what was really a throwaway remark.
It is true of course that there is no automatic procedure which takes in an arbitrary program and decides if it has a desired input/output behavior. (Whether an input program has a given “semantic property” is undecidable.)
But that doesn’t mean that it is impossible to have all our programs be formally verified. For that, if we have a formal specification for what each should do…
Well, I suppose it’s possible that some program we would want is possible to implement with the desired properties, but not possible to prove that it has those properties?
It is possible to enumerate (program, proof) pairs though.
It's my view of the Halting Problem that we've known for a surprisingly long time that eliminating all software bugs is mathematically impossible and should stop letting perfect get in the way of the good.
Especially with the more recent relative of the Halting Problem combined with the Church-Turing Theorem that found mathematical proof of a "0-day" sandbox escape in the Universal Turing Machine itself.
We have always lived in a house of glass. LLM agents automating trebuchets for rock throwing certainly seems like a bad idea to me and "let's simply eliminate all software vulnerabilities" an interesting bit of ostrich work (stick your head in the sand and hope it all gets better).
This has little to do with the halting problem, because we can choose to not deploy programs (or subroutines) that we want to be terminating but can’t prove that they are terminating. And that goes for any undecidable problem. There is no application where we want the program to have a certain property where we would be forced to deploy a program where we can’t prove the property due to computational theory reasons.
No, the real issue is that for the most we don’t want to put the necessary effort into proving the relevant properties, because it’s costly and time-consuming, and we think we can live with the risk. The issue is not some theoretical inability to do so.
We absolutely have pragmatic compromises and shortcuts for dealing with termination problems, but that doesn't mean we've solved the Halting Problem, it means we've adapted to coexistence with it. (And maybe we've coexisted with the Problem for long enough it feels like most of those adaptations are sufficient day to day, which makes it all the harder to appreciate the bugs that are always there we just mitigate enough to worry about them less.)
Potentially Infinite Loops are a great power. We've learned in most programming languages the "Uncle Ben lesson" that with such great power, comes great responsibility. In most programming languages we don't want to remove the ability to infinitely loop, because we might need that power, we work on ways to limit that responsibility (loop guards and timeouts and cancellations and teardowns). But it will likely always be possible to see some code spin in a loop we can't tell is accidentally infinite or just a loop with a lot more work than we expected. The infinite spin wait will always be a risk in our code.
I think it has a lot to do with the Halting Problem.
An infinite loop doesn’t mean that you can’t prove whatever property you want to prove about your program, if you’ve designed it for that. The limitations coming from undecidability don’t really affect our everyday applications. Unless your application is exactly to determine whether another arbitrary program will halt, that is. But that’s not what the vast majority of software whose bugs we might be concerned about is about.
“We can’t write bug-free software due to the halting problem anyway” is an incorrect argument.
You can't prove a program completed successfully if you can't prove a program even completes at all.
I don't know what properties you think people are trying to pragmatically prove about arbitrary programs but "did the program complete successfully" will always be an important, pragmatic property in software development. Especially in the pragmatic world where so much of our software is chaining smaller programs together to solve a task.
I'm saying we can't write perfectly bug-free software because of the Halting Problem and the inability to prove any given loop will not be infinite until running that loop. Perfect remains the enemy of the good and we certainly write a lot of "bug-free-enough" software without worrying about the Halting Problem day-to-day. But if you are saying the world needs to write perfectly bug free code starting tomorrow because LLMs will find all the vulnerabilities and sandbox escapes the Halting Problem is absolutely one of the reasons we can't ever provably hit that "perfect" target. We still need to find "good enough" or we give up on software development altogether and that's not what I'm advocating. Perfect is the enemy of the good. Mathematically perfect provably does not exist. Software will always have bugs, especially in the world with a threat model of active brute force machines.
I think you have slightly misunderstood the halting problem. There is no computer program H that, for every program P, determines whether P halts. This does not imply that for some particular program Q there is no proof that it halts. In fact in the setting where programs do not take input there is always such a proof (just a trace of the program running to completion). And there are many valid proofs of theorems like "For all x, Q(x) halts" for particular Q. Consider, for example, the case where Q has no control flow at all!
I think it's more that I lean into some of the corollaries that directly factor computation time into account. There is no computer program H that for every program P determines whether P halts faster than running P.
You cannot find/prevent every case of an infinite loop at design time/compile time if the only way to determine a complex enough control flow converges towards halting is to run the full program in a live environment.
You have a serious misunderstanding of the consequences of the undecidability of the Halting Problem. The Halting Problem says you can not prove the precise halting behavior in every problem. Precise and every are very important qualifiers.
If you sacrifice precise and widen it to: "Halt" and "Maybe run forever, but might just take longer than the age of the universe and is thus irrelevant for actual programs we might choose to run" then it is decidable for every problem.
Every means that there exist programs, in the infinity of all programs, that can not be proven. It does not mean that no program can be proven. Programs that are 10^8000000 instructions long that are intentionally obfuscated count in every. Human-designed programs that humans want to be correct and are reasonably sure are correct are extremely well-behaved in comparison and their provable termination can almost always be reasoned about.
Generally speaking, human-designed programs are almost always implicitly being constructed in the space of programs that will terminate (possibly relative to a event loop). At every step of the process you only extend using provably terminating constructions. Few humans will have a loop condition like: "Terminates if the Goldbach Conjecture is true" which is one of those sorts of things that makes it hard to prove termination. Just stay away from unproven conjectures in your loop conditions and you will probably be fine.
But again, the context is not about humans trying very hard to stick to problems in "terminating space" when writing software, but about LLMs with no such compunctions/boundaries finding inputs that break "terminating space assumptions". (Whether or not you also believe that LLMs are capable of staying within the lines of "terminating space" when generating code.)
Generally speaking, yes, humans want to design programs as best they can in the world of safely terminating applications. Humans aren't perfect at it today, given practical real world data such as CVE databases. Trying to hope humans become perfect to safeguard the world against LLMs like the Googler quote way above is the thing I find futile. Humans aren't going to magically get perfect. We need good enough solutions more than we need perfect solutions. The fear is that LLMs can greatly outpace humans in breaking "good enough" than humans can keep up in building "good enough".
You can prove a program is correct and terminates for all inputs and, absent a hardware or other assumption vulnerability that breaks the abstract machine assumptions, there would be no inputs that "break" anything. In fact, almost any human-designed program that is correct and terminates would not just be provable, but "easy" to prove algorithmically (in the theoretical sense, in a practical sense existing techniques are insufficient to prove complex programs).
Even ignoring isolation guarantees that could generically prevent unbounded escalation for arbitrary programs, you can just reject anything that is not "easy" to prove. Humans are really dumb, so anything that is not directly proven or easy to prove automatically is almost certainly not correct, so you can just err on the safe side and just reject them if you care about global correctness.
SolutionNotFound is a perfectly valid return case for my Algo. I start two threads, one searches for a solution, second one terminates the first after one second, if it is still running.
How in the world does the halting problem enters into the picture if my program is bug free or not?
The argument is that 'the program returns' is strictly easier to prove than 'the program returns the correct answer'. If the first is impossible, then the second is too.
I'm all in favour of sidestepping the argument by having our languages more resemble System F or some polymorphic lambda calculus.
Though still useful to remember that some of the earliest mathematical write ups of the Halting Problem were also by Alonso Church and directly in the lambda calculus. The Church-Turing Theorem is a lasting reminder that the two worlds imperative and functional describe the same algorithms (form the set of Turing Completeness).
My voice teacher had me blow air into water with a straw. Felt good and had some therapeutic effect on my vocal chords.
Apparently the technique had been developed by a Finnish speech and voice therapist. Here is some background: https://www.laxvox.com/history/
> "simply taking time to feel your body and put your attention into latched tissues can release them."
That has been my experience as well. I have developed my own little technique around this idea, where you invite tight areas of your body to soften and spontaneously make tiny stretching or unwinding movements - without forcing, bracing, or following a scripted routine. I call it Intuitive Release.
This is remarkable! I arrived at a very similar place in the last few days. I've been working with painful negative beliefs and memories.
This evolved from my meditation practice, I simply observe sensations in my body. (I tried meditating "normally" (focus on breath) but all this pain kept coming up!)
One of the techniques I arrived on through trial and error is simply asking the energy if it wants/needs to release itself. And then just allowing it to do so. Giving it permission as you say!
So far in every case I have tested, every bundle of pain in my body, the answer has been yes.
The hardest part is just being willing to let it do whatever it needs to do, which can be very odd and a little overwhelming sometimes. But you get used to it very quickly!
In more formal traditions the focus on breath (or similar) is to develop concentration/samatha/samadhi.
The focus on sensations is the insight/vipassana component, and often this is where the tension bubbles up to the surface. Keeping calm (equanimous) during this process can indeed be non-trivial!
It sounds like you have come to a practice very similar to a lot of the Burmese traditions of insight meditation, which is quite fascinating.
Sure, so my experience is... It feels like something solid is dissolving. That's the most common experience. It goes from the sharp heavy sensation into a diffuse watery pleasant sensation.
There could be many other effects as well. There can be sharp pain. There could be dull throbbing. It can feel like stuff is moving around (especially in the gut area, which seems to respond to such a process with actual physical movement).
Basically it's pretty weird if you're not used to it.
But in my experience, the fear of what we might experience is almost always greater than what we actually do experience. Which I think applies to life in general as well.
usually when a sharp sensation arises in an area, there is a habitual tendency to counteract - unconsciously tense surrounding muscles or antagonistic muscles or switch posture etc.
the idea is to observe with clarity the counteraction and let the sharp sensation arise and pass without the counteraction/resistance.
Sounds a lot like qigong, there is a whole… not sure what to call it, system? which involves pretty much exactly this increase of mind/body connection and relaxing/manipulating of fascia/muscles.
Do you have any specific pointers concerning that "relaxing/manipulating of fascia/muscles" part? I have only dabbled a bit in qigong and hadn't noticed this. Would love to learn more.
check out flowing zen qigong school, it’s online, not terribly expensive, the guy has a book that you can probably find on the high seas or def on amazon if you want to dip toes. he’s much more focused on no-woo than any others i tried.
his program is basically exactly this, body awareness and manipulations. i felt better when i was doing it, need to get back on the horse too probably.
I'm sharing Kelora, a hobby project that I have been developing over the last 6 months.
It's a scriptable log processor for the command line, with 150+ built-in functions for parsing, transforming, and analyzing log files and streams.
My original idea was to have an easy to deploy, potentially faster and more correct "rewrite in Rust" of my Python log processing tool klp.
It quickly turned into an AI coding experiment: how far I could get with vibe-coding, in a programming language that I barely know?
Kelora's code and extensive test suite have been generated entirely by AI agents (Claude CLI with Sonnet 4 to 4.5, Codex CLI with GPT5-codex).
I come up with feature ideas and discuss it with the AI agents. The AIs then write the spec, the implementation, tests, docs and CI.
I don't review the code, but I use the resulting program myself and review the docs.
The result is fully functional and quite useful, in my opinion.
I am fully aware that this vibe-coding process has its problems. Without human review we cannot be sure that Kelora does (only) what it's supposed to do.
And although Kelora passes 1000+ automatic tests and several checks (clippy, cargo audit, cargo deny, cargo fuzz), that probably shouldn't be sufficient to use it in production.
In this sense, it's an experiment, or a prototype. So maybe just run it against the example logs I've provided in the GitHub repo.
Or read the docs to get inspiration for your own log processing tool.
Because that's what I want to share: My ideas about a log processing tool with embedded scripting that can help turn messy logs into structured data.
Some interesting features like level maps, windows and spans, tracking and state, JWT parsing, pseudonymisation, etc.
And last but not least, my joy of working together with AI agent on a software project that would otherwise have been much too big for me.
I've never had so much fun in 30+ years of (hobby) programming.
Yes, the 3B variant, with vLLM 0.11.2. Parameters are given on the HF page. Had to override the temperature to 0.15 though (as suggested on HF) to avoid random looking syllables.
