ここでは主に書かれた資料へのリンクを紹介しますが、最近聞いた2つの優れたポッドキャストをおすすめしたいと思います。
これらの断片を定期的に読んでいる方なら、私がSimon Willisonの大ファンであることをご存じでしょう。彼の（やはり非常に断片的）投稿は、私のRSSリーダーに定着しています。しかし、断片はどれほど価値があっても、状況のまとまった概要を提供してくれないという問題があります。そこで Lenny Rachitskyとの彼のポッドキャスト は、鋭い目で見た世界の現状を概観できる、歓迎すべき調査です。彼は「11月の転換点」以降、プログラミングがどのように変わったか、この作業における重要なパターン、そして獣の中に潜むセキュリティ爆弾への懸念について、良い絵を描いています。
もう一つの素晴らしい聴き物は、私が定期的に聞いているポッドキャストで、Gergely OroszがThuan Pham（元Uber CTO）をインタビューしたものです。Gergelyのポッドキャストの多くと同様、Thuan Phamの魅力的なキャリアの方向性に焦点を当て、成功したプロフェッショナルから学ぶ機会をリスナーに提供しています。また、Uberのマイクロサービスの使用（5000個あった）や、高成長ソフトウェアが必然的に何度も書き換えられる方法（私がSacrificial Architectureと名付けた現象）についての有益な洞察もあります。
❄ ❄ ❄ ❄ ❄
Axiosは最近のサプライチェーン侵害に関する事後分析を公開しました。これはかなりな話です。攻撃者はリードメンテナとの接触を数週間かけて築き上げ、ミーティングソフトウェアがメンテナのシステムに何かが古いことを示すビデオ通話に至りました。それがメンテナにアップデートをインストールさせ、実際にはリモートアクセス型トロイの木馬（RAT）でした。
彼らはこのプロセスを私に特化して次のように調整しました：
- 会社の創業者と会社の両方をクローンした創業者を装って連絡してきました。
- 本物のSlackワークスペースに招待してくれました。このワークスペースは会社のCIにブランド化され、もっともらしい名前が付けられていました。Slackは非常に考え抜かれていて、LinkedInの投稿を共有しているチャンネルがあり、そのLinkedInの投稿は実際の会社のアカウントに送信されたものと思われますが、非常に説得力がありました。また、会社のチームメンバーの偽プロフィールだけでなく、他のOSSメンテナのプロフィールもあったようです。
- 私とつながるためのミーティングを予定してくれました。ミーティングはMS Teamsで行われ、関係者のグループが参加しているように見えました。
- ミーティングで私のシステムに何か古いものがあると言われ、Teamsに関連するものだと推測して欠けているものをインストールしました。それがRATでした。
- すべてが非常にうまく調整されていて、本物らしく、プロフェッショナルな方法で行われました。
Simon Willisonは要約とさらなるリンクを提供しています。
❄ ❄ ❄ ❄ ❄
最近Diátaxisに出会いました。これは技術文書を整理するためのフレームワークです。簡単にしか見ていませんが、気に入る点がたくさんあります。特に、4つの形式の文書を分類している点が気に入りました：
- チュートリアル：製品の使い方を学ぶ
- ハウツーガイド：製品を使って特定の目標を達成するためのガイド
- リファレンス：製品が何をするかを説明する
- 説明：製品の根拠についてユーザーを教育するための背景と文脈
チュートリアルとハウツーガイドの違いは興味深いものです
チュートリアルは、学習中のユーザーのニーズを満たします。その義務は、成功した学習体験を提供することです。ハウツーガイドは、仕事中のユーザーのニーズを満たします。その義務は、ユーザーがタスクを達成するのを助けることです。
説明を別領域に分離するという点も気に入りました。アイデアは、他の形式には最小限の説明しか含めず、より深い内容については説明資料にリンクするというものです。そうすることで、目標に向けた流れを保ち、ユーザーが自分の方法でより深い説明を求めることができます。説明とリファレンスの間の学習／作業の区別は、チュートリアルとハウツーガイドの間の同じ区別を反映しています。
❄ ❄ ❄ ❄ ❄
8年間、Lalit MagantiはSQLiteで作業するためのツールセットを欲していました。しかし、それは困難で退屈な作業で、「SQLiteのソースコードの細部に入り込むことになり、理解するのが非常に難しいコードベース」でした。そこで彼は挑戦しませんでした。しかし、11月の転換点の後、彼はこの必要性に取り組むことを決めました。
この試みについての彼の記録は、AIエージェントを使った開発の利点と危険性を優れた形で説明しています。
1月を通して、私は反復を続け、半ば技術的なマネージャーとして行動し、設計と実装のほとんどすべてをClaudeに委ねました。機能的には合理的なところに到達しました：SQLiteソースからPythonスクリプトを使って抽出されたCのパーサー、その上に構築されたフォーマッタ、SQLite言語とPerfettoSQL拡張の両方への対応、そしてウェブプレイグラウンドでの公開です。
しかし、1月末にコードベースを詳しくレビューしたとき、欠点は明らかでした。コードベースは完全なスパゲッティでした。Pythonのソース抽出パイプラインの大部分を理解できず、関数は明確な形もなくランダムなファイルに散らばっており、いくつかのファイルは数千行にまで膨らんでいました。非常に脆弱で、目の前の問題は解決しましたが、私のより大きなビジョンに対応できることはなく、ましてやPerfettoツールへの統合は不可能でした。救いだったのは、アプローチが実行可能であることを証明し、500以上のテストを生成したことで、その多くは再利用できると感じました。
彼はすべてを捨て、2回目の試みではAIとより密接に協力し、設計についての多くの思考、すべてのコードのレビュー、そして各ステップでのリファクタリングを行いました。
書き直しでは、リファクタリングがワークフローの中心になりました。生成されたコードの大きなバッチの後、毎回一歩引いて「これは醜いか？」と自問しました。AIがきれいにできる場合もありました。他の場合では、大規模な抽象化があり、AIには見えませんが私には見えました。私は方向性を与え、実行させました。趣味があれば、間違ったアプローチのコストは劇的に下がります。なぜなら、迅速に再構築できるからです。
彼は動作するシステムに到達し、AIは長年TODOリストに残していたことに取り組むことを可能にする価値を証明しました。しかし、書き直しでもAIには落とし穴がありました。
異なるシナリオにおけるAIの相対的な価値についての彼の結論：
すでに深く理解していることに取り組んでいたとき、AIは優秀でした…。 説明できるがまだ知らないことに取り組んでいたとき、AIは良かったが、より注意が必要でした…。 何を望んでいるかさえわかっていないことに取り組んでいたとき、AIは役に立たないから有害なまでのどこかにいました…
この核心は、AIが客観的にチェック可能な答えがあるときに最もよく機能するということです。いくつかのテストに合格できる実装が欲しい場合、AIは良い仕事をしてくれます。しかし、パブリックAPIに関しては：
3月上旬に数日間、APIのリファクタリングだけを行い、経験豊富なエンジニアなら本能的に避けるようなことを手動で修正しました。AIはそれを完全に台無しにしました。「このAPIは使いやすいか」「このAPIはユーザーが抱える問題を解決するのに役立つか」についてのテストや客観的な指標はありません。それがまさにコーディングエージェントがそれに苦戦した理由です。
❄ ❄ ❄ ❄ ❄
James TalaricoとZohran Mamdaniが選挙アピールの重要な部分として宗教を位置づけ、その信仰が他者への配慮を中心としていることについて、Ryan Aventの最近の投稿が語っています。彼は、配慮に焦点を当てることで、経済成長についての重要な視点が得られると説明しています。
まず理解すべきことは、私たちは成長それ自体を望むべきではないということです。成長が良いのは、私たちの集団的な能力を拡大することです。私たちはより多くのことを知るようになり、より多くのことを行えるようになります。これにより、苦しみを和らげ、宇宙についてより多くのことを発見し、完全な人間として過ごす時間を増やすことができます。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.