AutoProberでHNが見たのは、AI agentが実物を動かす怖さだった
Original: Guy builds AI driven hardware hacker arm from duct tape, old cam and CNC machine View original →
AutoProberは、HNでscore 220台、40件超のcommentsを集めた。見た目はhackerらしい楽しいprojectだが、communityが最初に問うたのは「AI agentにphysical probeを動かさせてよいのか」だった。Demoの面白さと、machine-control systemとしての信頼性は別物だからだ。
GitHub READMEによると、AutoProberはhardware hacker向けのflying probe automation stackだ。Agentがprojectをingestし、hardwareを確認し、homingとcalibrationを行い、plate上のtargetを見つけ、microscope framesをXYZ位置とともに記録する。Pads、pins、chipsなどをmap上にannotateし、operatorがdashboardで承認したtargetsだけをprobeする流れになっている。
Hardware stackはGRBL-compatible 3018-style CNC controller、USB microscope、LAN/SCPI経由のSiglent oscilloscope、optical endstop、optional network-controlled outletで構成される。RepoにはPython control code、Flask dashboard、CAD files、docsが含まれる。重要なのは、READMEがこのprojectを普通のweb appではなくmachine-control systemとして扱っている点だ。
Safety modelも具体的だ。CNC probe pinはtrusted endstopではない。Independent safety endstopはoscilloscope Channel 4から読み、motion中は継続監視する。Channel 4 trigger、ambiguous voltage、CNC alarm、real X/Y/Z limit pinはすべてstop conditionになる。Recovery motionは自動では行わない。
HN commentsはこの境界に集中した。あるcommenterは、これは既存のflying probe testerと何が違うのか、AIがpinを見つけるのか、SPICE modelと照合するのかを問うた。別のcommentでは、実際のPCB撮影、fiducial math、本当にprobingしている証拠が足りないのではという疑いも出た。0.1mmの誤差でもboardを壊せるという指摘もあった。
だからAutoProberの面白さは「AI hardware arm」という見出しより深い。Softwareがmetalを動かす瞬間、promptの巧さよりinterlock、calibration、human approval、bounded motionが重要になる。HNは魅力的なrepoを見ながら、physical AI agentのtrustがどれほど高くつくかを見ていた。
Related Articles
coding agentのsecurity論点は「.envを読まないで」より広い。OpenAI CodexのissueとHNの議論はignore rule、sandbox、Unix permission、container境界を掘り下げている。
企業向けAI agentは実証実験から本番運用へ移りつつある。OpenAIはPresenceが英語電話サポートで問い合わせの75%を人手なしで解決し、10日で人間への引き継ぎを15ポイント下げたとしている。
企業向けAI agentの競争軸がデモから運用指標へ移り始めた。OpenAI Presenceは英語の電話サポートで問い合わせの75%を人手なしで解決し、Codexによる改善ループで10日間に人への引き継ぎを15ポイント下げたという。