AIが数学を解き始めたからこそ、数学者たちは「そもそも数学とは何をする営みなのか」を守ろうとしている。 1000人を超える数学者が「Association for Human Mathematics」に参加し、AI企業との協働を避けたり、AI生成物を研究成果として扱わなかったりする動きを始めている。背景にあるのは、AIへの感情的な反発というより、数学研究が「正しい答えを最速で出す競争」に変わってしまうことへの警戒だ。AIが未解決問題を大量かつ高速に処理できるようになれば、研究者が時間をかけて問題を選び、試行錯誤し、概念を育てていくというプロセスの価値そのものが揺らぐ。 ここで焦点になっているのは、「証明できるか」よりも「理解できるか」だ。数学では、ある命題が正しいと示すだけでなく、なぜそれが成り立つのか、新しい見方や概念をどう得るかが重要とされてきた。AIが証明を量産するほど、むしろ人間側には、その意味を解釈し、重要性を判断し、次に何を問うべきかを決める役割が残る。つまり、AIの性能向上が数学者を不要にするというより、数学者の仕事の定義を変え始めている。 ただし、問題は研究文化だけにとどまらない。 newscientist.com/article/259…

推し活。

AIでコードを書くコストが劇的に下がった2026年。そこで再評価されているのが、27年前のExtreme Programming（XP）だ。古くなったどころか、AI時代になってむしろ核心部分の重要性が増している。 XPというと、ペアプログラミングやTDDを思い浮かべがちだ。しかしKent Beckが示したXPは、それら個別の手法よりずっと広い。Communication、Simplicity、Feedback、Courage、Respectという価値観を土台に、原則を介して具体的な開発プラクティスへ落とし込む体系である。著者Anton Zaidesは、特に「Humanity」「Mutual Benefit」「Quality」がAI時代に重要になったと見る。 たとえばLLMなら大量のコードも文章も短時間で生成できる。しかし、その結果として巨大なAI生成PRを他人にレビューさせたり、過剰な設計を作ったりすれば、局所的には生産性が上がってもチーム全体には負担を押し付ける。だからこそ「最も単純なものを作る」「素早くフィードバックを得る」「互いを尊重する」というXPの価値観が効いてくる。 興味深いのは、AIがXPを不要にしたのではなく、XPの中で重要な部分を入れ替えつつあることだ。 manager.dev/newsletter/extre…

AIでプログラマーが消えるのではない。「コードを書くこと」だけが、プログラミングの中心ではなくなる。 この記事は、その変化をFORTRAN登場以来の歴史になぞらえて描いています。 1950年代、コンパイラは「コーディングやデバッグをほぼ不要にする」と期待されました。実際、機械語を直接書く仕事は減りましたが、プログラマー自体は消えませんでした。むしろ扱えるシステムが大きくなり、仕事の抽象度が上がった。著者は、生成AIにも同じことが起きると見ています。 AIはすでにコード生成を高速化しています。ただし、それがそのまま開発全体の高速化を意味するわけではありません。AIが大量のコードを作れば、レビュー、仕様確認、テスト、品質保証の負荷が増える。つまり、ボトルネックが「書くこと」から「読むこと、判断すること、正しさを確かめること」へ移っていきます。 そこで変わってくるのが、プログラマーの役割です。将来は、一日中コードを書くよりも、AIが生成した変更を確認し、曖昧な要求を関係者と整理し、テストや仕様として定義する仕事の比重が高まるかもしれません。AIがコードを書けても、「期限切れのカードへの返金をどう扱うか」のような業務上の判断までは自動では決まりません。 この流れを突き詰めると、さらに大きな変化が見えてきます。 hrih.si/articles/the-compile…

例の脆弱性の件で思い出したんだけど、太陽光のコントローラーにWebインターフェースがあって、この拡張子が.phpだった。 中身はLinux Box。 こういうシステムはアップデートのことを考えずに作ってると思われる。

最先端ではない。けれど「電気がなくても、人の時間を取り戻せる」こと自体が大きなイノベーションになる。 元Dysonの航空宇宙エンジニア、Navjot Sawhneyが開発した「Divya」は、電気を使わない手回し式洗濯機だ。きっかけは南インドで出会った女性Divyaが、週に最大20時間も手洗いに費やしていたことだった。普通なら電気式洗濯機を導入すればよさそうだが、安定した電力も十分な水もない地域では、それ自体が現実的ではない。そこで発想を逆転し、「高性能な家電」ではなく、電気不要、少ない水、簡単に分解・修理でき、持ち運べる機械を作った。記事によれば最大7kgを洗え、手洗いに比べて作業時間を75%、水使用量を50%削減できるという。 重要なのは、これが単に「洗濯を楽にする道具」ではない点だ。家事時間が減れば、その分を仕事、教育、子育て、休息に振り向けられる。つまりこの機械が生み出しているのは、清潔な衣服だけでなく「自由に使える時間」でもある。すでに10万人以上に届けられ、2030年までに100万人への普及を目指しているという規模感を見ると、家電というより小さな社会インフラに近づきつつある。 そして面白いのは、ペダル式やモーター付きにすればもっと強力にできるのに、あえてそうしないことだ。 newatlas.com/good-thinking/d…

Redisが1ms未満の応答を実現する秘密は、単にRAMを使っているからではない。ロックも、コンテキストスイッチも、厳密な管理も、できるだけやらない。速さとは、計算能力より「仕事を減らす設計」から生まれる。 Redisのコマンド実行は基本的にシングルスレッドで、I/O多重化によって多数の接続を扱う。Redis 6以降はネットワークI/Oの一部を複数スレッドに任せる一方、データ操作そのものは逐次実行することで、ロック競合や複雑な同期処理を避けている。さらにデータをメモリ上に置き、Sorted SetやBitmap、HyperLogLogなど用途に特化したデータ構造を直接操作することで、余計な処理を減らしている。 この「余計な仕事をしない」という方針は、メモリ管理にも貫かれている。たとえばLRUでは、全キーを厳密に利用順で管理するのではなく、少数のキーをサンプリングし、その中から古いものを削除する近似方式を採用する。TTLの期限切れ削除も、アクセスされたときの削除とサンプリングによる定期削除を組み合わせる。完全な正確さより、その正確さを維持するためのコストを避けることを優先している。 javarevisited.substack.com/p…

仕事を失わないために「自分にしかできない仕事」を増やす。一見すると賢いキャリア戦略だが、その先に待っているのは安定ではなく、その会社から抜け出せなくなることかもしれない。 記事に登場する架空のエンジニア「Sam」は、古いコードの理由からデプロイの特殊な手順まで、誰も知らないことをすべて知っている。障害が起きればSam、難しい問題もSam。やがて会社にとって「欠かせない人」になる。しかし、その重要性ゆえに新しいプロジェクトへ移れず、昇進もしにくく、休暇中にも連絡が来るようになる。 しかもSamが蓄積した知識の多くは、他社でも通用する専門性ではなく、その会社でしか価値を持たない「組織固有の知識」だ。長く不可欠であり続けるほど、現在の会社での価値は上がる一方、外の世界で使える経験を積む機会を失っていく。結果として、「会社が自分を手放せない」と「自分が会社を離れられない」が同時に成立する。 そこで著者が勧めるのが、あえて「自分を代替可能にする」ことだ。頭の中だけにある判断を文書化し、複雑なセットアップを簡略化し、手作業のデプロイを自動化する。同じ指摘を何度もするならlintやテスト、型などに埋め込む。つまり知識を「人」から「仕組み」へ移していく。 maroun-baydoun.com/blog/make…