ふたりの近況

  1. 2026年11月
  2. Tibo
  3. poteto
  4. poteto
  5. poteto
  6. poteto
  7. poteto
  8. Tibo
  9. Tibo
  10. Tibo
    Tibo ·
  11. Tibo
  12. Tibo
  13. Tibo
  14. poteto
  15. Tibo
  16. Tibo
  17. poteto
  18. Tibo
  19. Tibo
  20. Tibo
  21. poteto
    poteto ·
    形式手法にはかなり期待してるけど、期待値はちょっと抑えて自分で調べてみるのがいいと思う(免責:私は専門家じゃないです)。形式手法はコードにバグがないことを保証できるわけじゃなくて、ある前提のもとでコードが spec に合ってることを保証するだけ。で、spec は数学じゃなくて人が何を求めてるかから来る。人間のためにソフトウェアを作ってる限り、spec が正しいって証明できるものは何もなくて、判断できるのは自分だけ。 pstack に /statechart スキルを作ったのは、主にコードに暗黙的にある状態機械をもっとはっきり、読みやすくしてくれるから。そうするとレビューする範囲を小さくして、もっと高いレベルでレビューできる:ほんとに自分の意図とゴールに合ってる? ゲームの tibo.dog を作ってるときにこのスキルをめちゃくちゃ使ってて、下のはストーリーモードの statechart。これでバグをたくさん見つけられた。 その意味で、モデル検査(例えば TLA+ と TLC)はシステムの性質を e2e で理解・チェックするのにかなり便利だと思うし、新しい検証コードを大量に書かなくていい。spec は実際のコードじゃないから常にズレるリスクはあるけど、今のところ実際のバグを見つけられていい感じ。本物か確かめるために、経験的な検証(コードを実際に動かす)とも組み合わせることが多い。 定理証明(Lean、Dafny とか)や有界モデル検査(CBMC、Kani とか)みたいな他の形式検証にもそれぞれトレードオフがある。証明はあらゆる入力をカバーするけど、指定した性質についてだけで、コードも手間もずっと多くかかる。有界モデル検査は実際のコードに対して走らせられるからズレは避けられるけど、一定のステップ数までしかチェックしないから、バグがないことを証明するよりバグを見つけるほうが得意。 だから近〜中期的には、まだコードベースを層にする必要があると思う:制約とガードレール(型、lint ルール、API 設計、リファクタリング)、経験的な検証(テスト、evals、実際の利用)、そして本当に必要な部分には形式検証。どれも単体では全部は拾えないけど、重ねればずっと多く拾えて、自分がレビューする部分も減らせる。 でも極限では bitter lesson が勝って、毎回バグゼロの完璧なコードがそのまま出てくるのかもね。そのシナリオでも、エージェントが自分の意図をちゃんと理解したか確認するのに /statechart はやっぱりすごく役立ちそう。まだなら試してみて!
  22. Tibo
  23. Tibo
  24. Tibo
  25. Tibo
  26. Tibo
  27. poteto
  28. poteto
  29. Tibo
  30. poteto
  31. Tibo
    Tibo ·
  32. Tibo
  33. poteto
  34. Tibo
    Tibo ·
  35. poteto
  36. Tibo
  37. poteto
  38. poteto
  39. Tibo
  40. Tibo
  41. poteto
  42. 2026年10月
  43. poteto
    poteto ·
    さらにTips: • routines を使うとbotがもっと自発的に動いてくれる。スケジュール型なら「毎朝issue trackerに新しいバグがないかチェックして」みたいな感じ、サブスクリプション型なら何かが起きたときに反応させられる。たとえば「クライアントXからメールが来たら、自動で要約してフィードバックと提案をnotionのドキュメントに追加して」とか • routines は発火しすぎるとコストがかさむ。スケジュール型なら1時間おきが一番短いおすすめ間隔で、サブスクリプション型はまずイベントを絞り込んだほうがいい • botにコードを書かせてタスクを自動化しよう!botが自分でタスクをこなすよりトークンをずっと使わないから、コードのほうが断然効率的。ワークフローのどの部分をスクリプトやskillsにできるか、botに聞いてみて。で、スクリプトはプライベートのgithubリポジトリに保存させておこう • チームプランなら、slackでbotを共有しよう!同僚とワークフローを共有するのにすごくいいし、チームがすでにメンテしてる質の高いbotを使い回せる • マネージャーみたいに考えよう:どうすればbotに自分と同じか、それ以上のクオリティでタスクをやってもらえる?そういうふうにbotをセットアップできれば、もっと野心的なことに時間を使えるようになる
  44. poteto
    poteto ·
    質の高い bot の作り方とチームの回し方についての短い grok bot ガイドだよ。@bot にこの投稿を読ませて、自分のチームを改善してみて! • dr eggbot をチームに入れて! 私が bot を作るのに使ってる bot デザイナー • bot はたくさん要らない。いい bot が少しあるほうが、大人数より使いやすくて管理も楽 • タスクのやり方を教えるときに、bot 自身に skill を作らせる。そうすると長い会話でも安定してできるようになる。私有の github repo を作らせて skill を全部そこに保存しておくのもいいよ • connector を足して、vault を使って、仕事で使うツール全部にアクセスさせる。bot に自分のメールを用意させて、自分でアカウント登録させるのも分離できていい • 手でやってる仕事や、ワークフローの中で情報をコピペして bot に戻してる作業を思い浮かべて。それを代わりにやる方法を bot に聞いてみて! • インターンを雇ったとして、どうオンボーディングして正確に効率よく働いてもらう? まず自己紹介して自分の仕事を説明して、どう自動化できるか聞いてみて 一番好きなコツ:音声モードか文字起こしを使ってみて! たくさん情報を一気に吐き出すのにいい方法。最後に「自分の言葉で言い直して」と伝えれば、ちゃんと理解したか確認できるよ
  45. Tibo
  46. poteto
  47. poteto
    poteto ·
    新しくてもっと速いペースに合わせて、ソフトウェアの多くを作り直して書き直す必要がある。 コードはかつて一滴ずつやってきた。もうすぐ、いやもうそうかもしれないけど、コードは途切れない流れみたいに書かれるようになる。好き勝手にうねり曲がる激流みたいに。 これは新しい話じゃない。ビッグテックは巨大なエンジニアリングチームの規模でずっとこれに向き合ってきた。でも今、ai がすべてのエンジニアに、めちゃくちゃ柔軟で有能な労働力を持たせた。これはもうあなたの問題。適応する唯一の方法は、システムを進化させて、agent が——正しいやり方についてほとんどコンテキストを持たない agent でも、いやむしろそういう agent こそ——活躍できるようにすること。簡単なことが正しいことになるようにしよう。 コードベースは有機的な建築になりつつある。agent の貢献は、あなたが設計した制約やガードレールの周りに育っていく。良いソフトウェアエンジニアリングは今こそもっと大事!それに、この途切れないコードの流れは、ただ無力に眺めるしかないものじゃない。もっと野心的になって、カオスを制御するシステムやフレームワーク、言語を設計しよう。 コーディングを悼む時間はとっくに終わってる
  48. Tibo
  49. poteto
  50. Tibo
  51. poteto
  52. Tibo
  53. Tibo
  54. poteto
  55. poteto
  56. poteto
  57. poteto
  58. Tibo
  59. poteto
  60. poteto
  61. poteto
  62. Tibo
  63. poteto
  64. poteto
  65. poteto
  66. poteto
  67. Tibo
  68. Tibo
  69. poteto
  70. Tibo
  71. poteto
  72. Tibo
  73. Tibo
  74. Tibo
  75. poteto
  76. Tibo
  77. poteto
  78. Tibo
  79. poteto
  80. poteto
  81. poteto
  82. Tibo
  83. Tibo
  84. Tibo
  85. Tibo
  86. Tibo
  87. Tibo
  88. poteto
  89. Tibo
  90. poteto
  91. poteto
  92. poteto
  93. poteto
  94. poteto
  95. poteto
  96. poteto
  97. poteto
    poteto ·
    ずっと引っかかってるのは、slop を自分に降りかかってくる出来事みたいに捉えてる人がいて、自分は何もできない無力な傍観者みたいな顔をしてること ちょっと待って、あなたソフトウェアエンジニアでしょ、砂に考えさせる方法とか、コンピュータを思い通りに動かす方法を literally 学んだ人でしょ?!それが今は何もできないの?お願いだから このノイズを抜けるために知っておくべきことは 2 つだけ: 1. agent が自分の仕事を検証できる手段を用意すること(これについてはさっき投稿したから繰り返さない) 2. あなたのコードベースは記憶 2 つ目も別に新しくない、lint ルールとか、診断がちゃんとしたコンパイラとか強い型システムとか LSP とか、より良いコードを書くためのものはずっとあった。コードを書くのが agent になっても同じで、ただより多く、より強く必要になるだけ。 rules や skills のことは忘れていい、それは後から足せる。 そう、あなたのコードベースは agent にとって記憶!agent はすでにあるものを拡張するのが大好き。だからあなたが見てきた小さな不満も、agent から見たミスもダメなパターンも、全部制約に変えないと、agent はウイルスみたいに同じミスをコードの中で繰り返し続ける。それを観察して繰り返して、コンテキストが少ない agent でも一発で高品質な PR を出せるくらいまでコードベースを固める。 もっといいのは、agent のアンチパターンがカテゴリ的に起こり得ないようにリファクタ/書き直すこと。型システムを活かして、アーキテクチャの探索空間を狭めるライブラリやフレームワークを使って、あるいは私たちが grok bot でやったみたいに自分でフレームワークを作って、質の高いプリミティブと考え抜かれた API を設計する
  98. poteto
  99. poteto
  100. Tibo
  101. Tibo
  102. poteto
  103. poteto
    poteto ·
  104. poteto
  105. poteto
  106. poteto
    poteto ·
    コードベースには昔から雑なコードが入ってる。ミッションクリティカルな「ハード」なソフト(組み込みとか)以外は、コードが完璧である必要なんてほとんどないから、ずっとそれで ok だった。 swe は特殊なエンジニアリングだ。作ってるものは常に進化してて、ほとんど有機的——ユーザーの好みは変わるし、自分のメンタルモデルも進化するし、機能は出ては消える。 正直に言うと、長くコードを書いてきた自分も、多くの人も、最初は(2024 年くらい)agent がプロダクションコードを書くなんて懐疑的だった。「でも、あの美しいコードベースに入ってくる雑なコードはどうするの?」って。 でも、昔から人間の雑さはあったし、しかも大量にあった!正直に言えば、ほとんどの人は「自分が書いてないコード」を雑と呼ぶ。現実には 99% の人(自分も含めて)は Good Code がどんなものかすら知らないし、書けるはずもない。自分が提案したい Good Code は: • 正しい • バグがない • 実行が速くてコスト効率がいい 本当に Good Code を書くのは昔からめちゃくちゃ難しくて高い。長い間(@bendlang が変えてくれるかもだけど)、コードはこの 3 つを安く形式的に保証できるものじゃなかったから。ハードなソフトを書くのが難しいのはそういうことで、用途によってはチャンスが一度きり、最初から正しくないといけない。 でも、私たちが使うソフトの大部分は、ユーザーに価値を届けるのに Good Code である必要はない。実際、使ってるソフトのほとんどは形式的に検証できないんじゃないかな!スピードと進歩と引き換えにバグを受け入れて、テストと o11y に頼って、もっとインクリメンタルなやり方にしてきた。これはいいこと! agent は私たちを速くしてくれるし、受け入れる気があれば、もっといいコードを書くのを手伝ってくれる。Good Code にはならない(それはまだ高い)けど、平均してスケールすればずっとマシになるはず。 swe の新しい職人技は、これをどうやるかを見つけること。今はそれがあなたの仕事!agent ありとなしで生産性が全然変わらないなら、何か間違ってる。でも、受け入れて新しいスキルツリーを学ぶ機会にするのに遅すぎることはない。
  107. poteto
  108. poteto
  109. poteto
    poteto ·
  110. poteto
  111. poteto
  112. poteto
  113. poteto
  114. poteto
  115. poteto
  116. poteto
    poteto ·
    量は大事 いや、わかるよ。エージェントが出てくる前からエンジニアだった人なら、コードの行数やPRの数を生産性の指標にすることに懐疑的なのは当然だと思う。私も同意!というか、少なくとも前は同意してた。説明しやすくするために、最低50人はいる大きいチームのエンジニアの視点で話すね。 前は量なんて関係なかった。インパクトを重視してたから。PRが少なくてもインパクトは大きくできた。たとえば設定を1行変えるだけで会社が何百万ドルも節約できる、みたいな。 でもエージェント以前、量が話題になるのは外れ値のときだけだった。下の端だとパフォーマンスに苦しんでる人、上の端だと「コーディングマシン」タイプの人。コーディングマシンっていうのは、部屋にこもって出てきたら大量の問題を解決するPRの山を抱えてるような人。だから量は大事だったけど、それは分布の両端だけで、しかもインパクトとセットだった。 大手テック企業で働いたことがあるなら、言ってることわかると思う。エージェントの話でいうと、大企業の問題が今や中小企業の問題にもなってるってこと。 じゃあエージェントでこの計算はどう変わるの?要するに、今は誰でもコーディングマシンになれる。めちゃくちゃ優秀なフロンティアモデルがあって、私たちの誰よりもうまく、ずっと速くコードを書ける。そんな世界で、前と同じ数のPRしか出してないなら、なんでもっと生産的になれてないのか立ち止まって考えない?エイリアンみたいな知能が来てるのに、人間のコーディングマシンに出荷量で勝てないの? だから私はずっと信頼の話をしてるんだよね。エージェントの出力を信頼できるようにちゃんと手間をかけてないと、生産性をスケールさせるのはすごく難しい。 で、たしかにこのやり方はトークンをもっと使う。でも私は知能あたりのコストで考えてる。エージェント以前はこのコストがすごく高かった。年収6桁後半のソフトウェアエンジニアを何人も雇わないといけなかったから。トークンは今もまだ高いけど、知能のコストを考えると時間とともに安くなっていく可能性が高い。今はとんでもなく高く見えるものも、6ヶ月から1年後にはたぶん手の届く値段になってる。エージェントを使うエンジニア1人で、数十人、いや数百人分の仕事を、ほんの一部のコストでできる。 まだみんなピンときてない現実は、ソフトウェアエンジニアの仕事が本当に変わったってこと。私たちの仕事はもう単にソフトウェアを作ることじゃなくて(まあ正直、昔からコードだけの仕事じゃなかったけど、説明のためにちょっと付き合って)、ソフトウェアを書く機械を作ること。このソフトウェア工場、私はミシュランのキッチンって呼んでるんだけど、そういう考え方はまだ研究段階。そういうのを共有するのが好きなんだよね。自慢したいんじゃなくて、エージェントを大規模に使うときにしっかり厳密にやると何ができるかを見せたいから。
  117. poteto
  118. poteto
  119. poteto
  120. poteto
  121. Tibo
  122. Tibo
  123. poteto
  124. poteto
  125. Tibo
  126. Tibo
  127. poteto
  128. poteto
  129. Tibo
  130. Tibo
  131. Tibo
  132. poteto
  133. Tibo
  134. Tibo
  135. poteto
  136. Tibo
  137. Tibo
  138. Tibo
  139. Tibo
  140. poteto
  141. poteto
    poteto ·
    エージェントの振る舞いを形作る環境を直すんじゃなくて、エージェントをマイクロマネジメントしちゃう罠にはまりがちなんだよね。 pstack 0.15.9 で新しい /correct スキルが入ったよ:同じミスでエージェントを何度も直してるなら、パターンを見つけて、アーキテクチャ・型・チェックで直してくれる。 コードベースにどんどん流れ込む commit って、好き勝手な方向にぐんぐん育つ盆栽みたいだなって想像するのが好き。やるべきなのはカオスに屈することじゃなくて、ちゃんとした制約で意図的に手なずけること 0.15.9 では他にも改善あり: • /architect:エージェントフレンドリーなアーキテクチャの設計方法を追加 • @brendangregg のベンチマークチェックリストをもとにした新スキル /benchmark-checklist pstack でより良いコードベース設計を始めるために grok bot に渡せるプロンプトはこちら: /poteto-mode 新しい Project agent を作って、アーキテクチャがもっとエージェントフレンドリーになるように私の repo をリファクタ&再設計して。/correct と /architect の両方のスキルを使って過去の commit を見て、コード品質・パフォーマンス・バグのどれであれ、エージェントがはまりがちな一番よくある落とし穴を見つけて。関係あれば /recall スキルで過去の会話を探してコンテキストにしてもいい。レビュー用にハイレベルな計画を作って。未解決の疑問は私に投げずにプロトタイプを作って自分で答えて。実データに裏付けられた計画を持って戻ってきて。計画を承認したら、stack か full autopilot の playbook(どっちがいいか聞いて)で実行して
  142. poteto
  143. poteto
  144. poteto
  145. 2026年9月
  146. poteto
  147. Tibo
  148. 2026年8月
  149. Tibo
  150. poteto
  151. 2026年6月
  152. Tibo
  153. 2026年5月
  154. Tibo
  155. Tibo
タイムラインを全部見る →