代码和信任:起搏器的振动器
Code and Trust: Vibrators to Pacemakers

原始链接: https://punkx.org/jackdoe/code-and-trust.html

作者努力应对AI编码的新兴现实,将一个简单的振动器程序与Pacemaker软件的复杂性和关键性性质进行了对比。在承认人工编码的局限性的同时,即使在管理医疗设备的严格监管框架下,作者也质疑如何建立AI生成的代码的信任,尤其是当它控制影响公共安全的系统时。 该类比被吸引到自动驾驶汽车,尽管代码质量有潜在提高,但AI编程的制动系统仍会引入不可接受的风险。作者认为,如SWE-Bench之类的当前基准不足以评估AI处理现实世界后果的能力。 根治性透明度被提出为关键元素。开放代码,规格和流程是必需的,而不是特权。最终,AI必须通过可证明的性能和解释性来赢得信任,尤其是在失败可能会产生广泛影响的安全性应用程序中。

该黑客新闻线程讨论了为起搏器(例如起搏器)编写代码的挑战,以及诸如振动器之类的不太关键设备。一个关键点是对潜在用户伤害的固有接受以及最大程度地降低风险的严格过程,强调细致的测试和审核。讨论涉及与时间相关的错误的复杂性以及甚至正式验证的代码的局限性。突出显示了通过开放代码和规格的透明度的重要性,尽管并未被视为完整的解决方案。一些贡献者分享了轶事,包括开发人员承认造成过早死亡的同时挽救了更多的生命。示例代码中有关斐波那契序列实现的辩论。对话还探讨了AI在审核代码中的潜力以及对冗余验证过程进行分层以确保关键应用程序安全的必要性。还提到了详尽的测试,冗余和快速迭代与潜在失败之间的权衡。
相关文章

原文
← jackdoe

CODE AND TRUST: vibrators to pacemakers

I want to discuss two programs, one the program that controls a vibrator, and one that controls a pacemaker.

First pseudocode for a program of a vibrator:

def fib(n):
  if n 

This program will vibrate with increase frequency using the Fibonacci numbers 2, 3, 5, 8, 13, 21, 34..


Pacemakers are implant devices that have electrodes connected to chambers of the heart and can force it to contract and pump blood. Its goal is to create stable heart rate, of course the heart might pump without it, so it also needs to monitor what is going on and when it should send an electric pulse. This is how much we trust other people's programs, we allow them to control our heart.

Can you imagine? Just think of the simplest part of a pacemaker: "send a 2ms pulse every 810ms", ignoring the inhibited mode where it senses cardiac activity and does nothing if present, but focus on just sending regular pulse to maintain 74 beats per minute. A naive and absurdly reduced pacemaker program:

def pulse(ms):
    start()
    sleep(ms)
    stop()

while True:
    pulse(2)
    sleep(810)

Notice how similar it looks to the vibrator program: loop, pulse, sleep. On the surface the vibrator program even looks more complicated because of the Fibonacci sequence.

Oh, I forgot to say, the pacemaker's computer and battery are inside the human body.

If the battery runs out they have to cut it out.

If you read some pacemaker code you will see in the comments they put not only how many cycles an instruction takes but also how much current it will use, its very impressive. The real pacemaker code is ridiculously complex, tens of thousands of lines, true fault tolerant code is very difficult. It has taken many many years of talent and politics to make those kinds of programs possible, standards like ISO 14971, or IEC 62304:2006, IEC 60601, ISO 13485, DO-178C and hundreds more. Thousands of people have spent their life thinking: How do you write programs when a bug can kill their user?
Lets make an argument, who will write a better program, djb (Daniel J. Bernstein: a brilliant programmer) or FDA audited and ISO certified contractor company. Or maybe ask, which pacemaker would you buy? Or car? At some point we go down the critical list you will chose djb for sure, but when your life depends on it? Most people will prefer the FDA audited program.

Now, imagine in 1 year we have new AI models, and we are absolutely convinced that they can actually program. They go beyond tokens and patterns. Now, which code would you choose if you can use the all-seeing AI that can look at the code, each hardware component and their interconnection, the manufacturing process, the QA process? I will choose the "better" program, completely agnostic to who wrote it.

The same AI can of course write the program itself, now what would you choose? AI, djb, FDA? It should be possible that holistic AI writes better code than human specialists that communicate through abstractions and interface. Imagine the AI is djb in software, hardware, electrophysiology, in biology, biochemistry and physics.

At this very moment Opus 4 can absolutely code a vibrator together with its user, but what is the path to coding a pacemaker?

What about programs that are not individual, but affect all of us? What about people driving AI programmed cars? And I don't mean in comma.ai or Tesla way, I mean saying something like "hey the new v-jepa is out, can you retrain and condition on it, and lets hit road when you are ready", and then getting in their car with their fresh model and not crashing with other people's newly programmed cars. It will lead to complete chaos. Not even self driving, imagine if just the ABS is programmed by AI and the car's user.
How do we get to a point to `trust` it? I am not sure, I just know its not solving SWE-Bench. There is of course a whole spectrum of programs between the vibrators and pacemakers, and SWE-bench will do very well for most, but when push comes to shove, programs leak outside of the computer, into the body, a world model is needed to make a pacemaker program, most of it lives outside of RAM.

To be honest, my threshold is quite low, I think in 1 year we will be able to take any piece of code and audit it with `claude`, and I will put my life on the line using it. So my requirement will be the system must be open and all code and specs must be available. But.. what will it take to put my daughter on a car with AI programmed breaks, even if its open and my oracle says its amazing? My instinct is, no fucking way, but I also know 1 bug per 5000 lines of code is the pinnacle of human achievment. The pressure to produce is immense, all organizations are racing, beurocracy has its limits, the 737 MAX issue is an example. We are not ready for the flood of AI code, before AI can actually code.

Radical transparency is the only answer. I am convinced that open code, specs and procesees must be requirement going forward.

Trust is taken it is not given.


PS: I rewrote this post like 3 times, when I started writing, it was about personal programs, and allowing people to program their own vibrators or whatever, but as I was writing it I discovered that I am truly horrified that my car's breaks will be programmed by a contractor using some local 7b model that specializes in writing MIRSA C:2023 ASIL-D compliant software.
PPS: I learned a lot about pacemakers though, and really enjoyed reading some real pacemaker code.
联系我们 contact @ memedata.com