uents

将棋でさ、「もう人間が見てわけわかんねぇ手だけど強い」が生まれてる以上。コーディングも「もう人間が見てもわかんねぇコード」のほうが優れてるようになるやろ。遠くなく。

LLMに内在してるからほとんど要らねて言われちゃった笑 まあハーネス含めてエージェント側に取り込まれて行くんだろうな

AGENTS.md 作業ステップや規約を書くよりもエージェントの行動規範を書く方がいいような気がしてるけど気のせいかな そういった規範はLLMが学習する過程で内在するのかもしれないけど

AIに巨大なプログラムを書かせているとき、本質的なのは「AIが1秒あたり何行書けるか」ではない。実際に効いてくるのは、コード量が増えるにつれて、開発オーバーヘッドがどうスケールするかである。 AIが素で単位時間あたり一定量aのコードを書けるとしても、実開発ではコンパイル、テスト、デバッグ、調査、影響範囲の確認といったオーバーヘッドが必ず乗る。問題は、そのオーバーヘッドがその時点tでのコード全体量C(t)に対してどう増えるかだ。 単純化すると、以下の二つのケースがある。 1. オーバーヘッドが C にほぼ比例するケース 2. オーバーヘッドが log C 程度に抑えられるケース コンパイル時間は、フルビルドだと1.に近い。 原因の切り分けが二分探索的に進められる種類のデバッグでは、2.に近い。 1.と2.のケースにおいてC(t)が時間tに対してどのように増加するか計算してみたのが添付図だ。 結論としては、 1.は、C(t)は√tに比例するので、コードを10倍にしようと思うと100倍の時間が必要。 2.は、C(t)はtに対してかなり直線に近い増え方をする。 である。 言うまでもなく1.と2.とは雲泥の差である。ソフトウェア工学のかなりの部分は、1.の世界をいかに2.に近づけるかという試みだったとも言える。 コードを書くときの認知的・構造的オーバーヘッドも、放っておけば前者に寄りやすい。しかし、モジュール分割、関数分割、クラス分割、依存の局所化、テスト単位の分離をきちんと行えば、そのコストを後者に近づけられる。そうなるようにプログラミング言語やモジュール機構、テスト手法、設計原則は発展してきたわけであり、マイクロサービスやクリーンアーキテクチャも、その文脈で理解できる。 AI時代になると、この問題はむしろ先鋭化する。AIはコードそのものを書く速度が高いぶん、設計や検証のオーバーヘッドの悪さが、以前よりはっきり露呈するからだ。 設計が悪く、影響範囲が広く、テスト単位が粗く、どこが壊れたのかを絞れない構造になっていると、1.に近づく。すると、せっかくの生成速度がオーバーヘッドに食われる。 だから、今後AIで巨大なプログラムを開発するエンジニアに強く求められるのは、単にプロンプトがうまいことではない。 システムを分割し、影響範囲を閉じ込め、検証単位を細かく設計して、開発全体のスケーリング則そのものを改善する能力だと思う。

バイブコーダーが絶対に守るべきこと ・GitHubにAPIキーを載せない 以外になんかある？ #個人開発

本物のOSS開発者はgithubを使わない。(Linuxカーネルの連中とか…

#若手社員の8割近くが 古のプログラミングとは、紙に書き、紙でデバッグする作業だった事を知らない。 多分、若手社員の10割が知らない。