AIツールの価値評価は、コード行数や開発者アンケートのような不完全な指標のために困難です。歴史的に、自動化は職業をなくすのではなく、職務を変化させてきました。そのため、AIが仕事に与える影響を予測することは非常に困難です。現在、クローズドAIモデルがイノベーションをリードしていますが、オープンモデルも急速に追いついており、能力の差は急速に縮まっています。AIの大きな問題は、幻覚的な引用であり、誤情報でインターネットの知識プールを汚染する可能性があります。AI生成コードが攻撃に使用されることへの懸念がある一方で、バグを事前に発見することでソフトウェア防御にも効果的であることが証明されています。AIモデルが既存のコードをコンテキストとして使用すると、コードベースの技術的負債が増幅され、「生成的負債」が累積します。インターネットはAI生成コンテンツでますます満たされ、「ゾンビインターネット」が形成され、人間のやり取りとAIを区別することが問題となっています。AIエージェントの生成は並列処理のように感じられるかもしれませんが、人間の注意は複製できない重要なシリアルリソースのままです。AIツールはソリューション構築のコストを削減しましたが、組織の連携と調整が新たなボトルネックとなっています。AIによる生産性向上は、品質向上ではなく出力量の増加として捉えられることが多く、重要な戦略的思考やメンタリングの時間を侵食しています。

著者は、GOTO Conferenceでの経験について論じ、LLM拡張プログラミングに関する観察と、ムーブメントを主導する新世代の必要性を共有しました。AIを使用してコードベースを再構築するIan Johnsonの業績が強調され、テストとアーキテクチャパターンによって促進されるライターからキュレーターへの移行が明らかになりました。英国政府のオープンソースリポジトリが、セキュリティ上の理由とされる閉鎖は、誤ったアプローチとして批判されています。Adam Tornhillのエージェンティックコーディングにおける認知的持久力に関する洞察は、意思決定密度の増加に伴う精神的コストを強調しています。著者は、ユーモラスな引用を共有し、テクノロジー寡頭制とAIに関する若者の不満に対処しています。The Economistの記事が2つ言及されており、1つは雇用に対する歴史的な技術的影響について論じ、もう1つはAIが卒業生の採用に与える影響に焦点を当てています。米国政府のAI規制への取り組みは、実質がなく専門知識を欠いているとして批判されています。AIの急速な進化により、規制の欠如は潜在的に有害であると見なされています。最後に、著者はソフトウェア開発の専門知識を持つBeth Anders-Beck氏を連邦議会に推薦しています。

Birgitta Böckelerは、テストスイートがリグレッションセンサーとして果たす役割を、ミューテーションテストが果たせる役割に焦点を当てて検証し、コーディングエージェント向けのセンサーに関する投稿を締めくくります。

Vibeコーディングはソフトウェアプロトタイピングを大幅に加速させましたが、AIエージェントはしばしば安全でない設定を推奨し、セキュリティ上の問題を引き起こしています。Gautam Koul、Lucian Moss、Neil Drew-Lopez、Daberechi Ruth Edeokohは、Thoughtworksのグローバルマーケティング向けアプリケーションを構築する際の経験を共有します。彼らは、これを克服するためには、AIをガイドするためのセキュリティコンテキストファイルを作成し、AIの権限要求には注意を払い、毎日のセキュリティインテリジェンスフィードを作成し、ビルダーにデフォルトで安全なハーネスとテンプレートを提供する必要があることを学びました。

Vibeコーディングとは、生成されたコードを一切確認せずに、LLMにプロンプトを与えることでソフトウェアを構築することです。Andrej Karpathyによって導入されたこの手法は、自然言語による指示に依存しているため、プログラマーでない人でも利用しやすいです。迅速なプロジェクトには有用ですが、vibeコーディングはコードの品質とセキュリティに関して深刻な欠点があります。vibeコーディングの核心的な原則は「コードの存在すら忘れる」ことであり、それが使いやすさと限界の両方をもたらします。これは、コードレビューと理解に焦点を当てた「Agentic Programming」とは異なります。Vibeコーディングされたソフトウェアは迅速に作成できますが、保守性に欠け、重大なセキュリティ脆弱性を引き起こす可能性があります。LLMは攻撃に脆弱であり、機密情報を公開する可能性があるため、セキュリティリスクは特に懸念されます。コードの品質が低いと、高度なLLMを使用しても、将来的にソフトウェアを変更することが困難になります。LLMはエラーや誤った動作を生成する可能性があり、これらのエラーは見過ごされる可能性があります。Vibeコーディングされたソフトウェアは、範囲とユーザーベースが限定された使い捨てプロジェクトに最も適しています。複雑なアプリケーションや広く使用されるアプリケーションでは、コードの品質とセキュリティにより多くの注意が必要です。

Birgitta Böckelerは、静的コード解析のためのさらに3つのセンサーについての議論を追加し、より良いモジュール性のチェックと強制に焦点を当てています。依存関係チェックのための計算センサーはルールを強制するのに適していましたが、ルールは限定的でした。カップリングデータをチェックするための計算センサーの構築は、期待外れでした。モジュール性をレビューするために推論センサーを促す方が効果的でした。

コーディングエージェントユーザー向けのハーネスエンジニアリングに関する最近の記事で、Birgitta Böckelerは、コーディングエージェントハーネスを拡張するためのメンタルモデルを提示しました。これは、優れたエージェントの出力を生成する確率を高め、問題が人間の目に触れる前に自己修正を可能にするガイドとセンサーのシステムです。Birgittaは現在、コードベースを保守可能に保つためにセンサーを使用した経験を説明する記事を公開し始めています。この記事では、基本的なコードリンティングを使用した静的解析に焦点を当てています。

最近のリトリートでは、エージェンティックプログラミングを用いたソフトウェア開発の未来が探求されました。成功した応用例の一つに、LLMを使用してレガシーコンパイラをRustでクローンすることがありました。参加者は、人間の専門家にインタビューすることで、LLMを使用して複雑な仕様を検証することについて議論しました。重要な学びは、組織の変更管理ガイドラインをその歴史を映す鏡として理解することの重要性でした。会議では、LLMを考慮した「リフト＆シフト」移行の影響が議論され、それが最初のステップであるべきだと示唆されました。金融業界の専門家は、様々な管轄区域にまたがるソフトウェア管理の課題について議論し、LLMがどのように役立つかを探りました。エージェンティックソフトウェア開発の文脈における判断力を教えるためのペアプログラミングの価値が強調されました。著者は、LLMが退屈なデータ変換コーディングに優れていると指摘しました。AIシステムのための「カオスモンキー」テストの必要性がスピーカーによって提起されました。この記事は、ソフトウェア開発者がAIの選択やパターンから学ぶことの潜在的な利点を強調しています。著者の肘の怪我は、テクノロジーが仕事にどのように影響するか、そして将来的に音声入力を利用できるかどうかについての考察を促しました。

このテキストは、人間が書いた文書にのみ依存するのではなく、複雑なタスクのコンテキストを生成および評価するために言語学習モデル（LLM）を使用することについて論じています。これには、LLMに人間へのインタビューを促し、必要な情報を収集し、コンテキストレポートを作成するための質問をすることが含まれます。著者はHarper Reedのブログからインスピレーションを得ており、LLMが一度に一つの質問をすることの重要性を強調しています。別の応用としては、文書の正確性について専門家にインタビューするために尋問型LLMを使用することが挙げられ、手動レビューの代替手段を提供します。このアプローチは、まず文書作成、次に専門家レビューのために、順次使用できます。この技術はLLMの使用を超えて価値があり、書くことが苦手な個人から知識を抽出することを容易にします。書くことが難しいと感じる人々から情報を得るという課題を克服するのに役立ち、スタイルに特定の特性がある場合でも、AI主導のライティングの一形態を可能にします。最終的に、この方法論は、従来のライティングの好みに逸脱する場合でも、情報のキャプチャと共有を優先します。このアプローチは、多様なコンテキストでのコミュニケーションと知識移転を促進するLLMの能力を活用します。AIによって生成された出力は、情報がない場合や、特に書くプロセスに苦労している個人を扱う場合に、質の低い文書よりも好ましいと考えられます。この方法は、コミュニケーションのギャップを埋め、共同ワークフローを改善するLLMの可能性を強調しています。

人間はますますコードを書くことをエージェントに委任するようになっています。将来、ソースコードは存在するのでしょうか？この問いに取り組むために、コードとは何かを理解する必要があります。Unmesh Joshiは、コードには機械への指示と問題領域の概念モデルという、二つの異なるが絡み合った目的があると見ています。彼は、機械と話すための語彙を構築することがなぜ重要なのか、プログラミング言語は思考ツールであること、そしてLLMと協力するにつれてこれが私たちの未来にどのように影響するのかを探求しています。

ラフル・ガルグは、エンジニアリングのベストプラクティスを組み込み、コンテキストレイヤーを構築することで、AI支援プログラミングを改善するためのオープンソースフレームワーク、Latticeを作成しました。ウェイ・ジャンとジェシー・ジエ・シアは、高い関心のため、質問と回答のセクションを追加して、構造化プロンプト駆動開発（SPDD）に関する記事を更新しました。ジェシカ・カーは、AI支援開発に関わる二重のフィードバックループについて論じ、開発者が開発環境を形成する機会を強調しています。アシュリー・マックイサックは、GoogleのAIが彼を誤って犯罪者と特定したため、名誉毀損でGoogleを訴えています。スティーブン・オグラディは、AmazonやMicrosoftのようなテクノロジー企業によるAIへの多額の投資を検証しています。ウィレム・ヴァン・デン・エンデは、ローカルなオープンソースAIモデルがコーディングタスクに「十分良い」ものであり、より大きな制御とデータセキュリティを提供する可能性があると示唆しています。この戦略は、クラウドベースのAIに多額を費やしていないAppleの戦略を反映している可能性があり、ローカルAIに賭けているのかもしれません。その後、テキストはフレッド・ブルックスの「人月の神話」とソフトウェアの「タールピット」に言及しています。ケント・ベックの投稿は、コーディングにAIを使用することの課題と、内部品質における潜在的な落とし穴について論じています。最終的な疑問は、AIが複雑さの課題を克服するか、それともそれに囚われるかということです。

フレッド・ブルックスは、1960年代にIBMのSystem/360の開発を主導し、そのプロジェクトが彼のその後の洞察を形作りました。1975年に出版された彼の著書「人月の神話」は、ソフトウェア開発における古典として今もなお読み継がれています。一部時代遅れの側面もありますが、今日でも通用する普遍的な教訓を提供しています。ブルックスの法則は、遅れているプロジェクトに人員を追加すると、さらに遅延するという重要な概念です。チームサイズの増加は、コミュニケーションのオーバーヘッドを指数関数的に増加させ、進捗を妨げます。システムの設計の相互関連性である「概念的整合性」は、本書から得られる重要な教訓です。ブルックスは、断片的な機能を組み込むよりも、統一された設計を優先し、シンプルさと分かりやすさを強調します。彼は、まとまりのある設計は、単一の根底にある一連のアイデアを反映していると信じています。この概念は、彼のキャリアと仕事へのアプローチに大きな影響を与えました。本書はまた、アニバーサリーエディションの重要性も強調しています。これは、ブルックスの影響力のあるエッセイ「銀の弾丸はない」が含まれているためです。

クリス・パーソンズの更新されたガイドは、コーディングにおけるAIの使用を強調し、検証と人間によるレビューから自動チェックへの移行に焦点を当てています。彼は「エージェンティック・エンジニアリング」を提唱し、Claude CodeやCodex CLIのようなツールの重要性を強調しています。コード生成の速度よりも検証が優先され、堅牢なレビュープロセスの構築に焦点が当てられています。プログラマーのコアな役割は、AIのトレーニングと開発「ハーネス」の形成へとシフトします。この記事は、計算センサーの利点を強調するビルギッタ・ベックラーの「ハーネス・エンジニアリング」に関する研究に言及しています。アダム・トルニルの指摘は、関数の長さがコードの構造化と意図に関連していることを示しています。ニライ・パテルの「ソフトウェア・ブレイン」という世界の捉え方に関する指摘は、視点を提供します。この記事は、効果的なAIインタラクションに不可欠な、一貫したデータ定義を強調しています。著者は、AI専門家がAIツールに対して自身を「読み取り可能」にしようと競い合っているという観察を共有しています。著者は、AIの使用に関する自身の個人的な経験と、仕事へのAIの影響についての見解を探求しています。

LLM プログラミングアシスタントは大きな価値を示していますが、それは主に個々の開発者に対してです。Thoughtworks の社内 IT 組織は、チームでそれらを使用しており、「Structured Prompt-Driven Development (SPDD)」と呼ばれる方法とワークフローを開発しました。Wei Zhang と Jessie Jie Xia は、このワークフローの簡単な例を GitHub で詳細に説明しています。このワークフローでは、プロンプトをコードと共にバージョン管理に保持されるファーストクラスの成果物として扱い、ビジネスニーズに合わせた開発を調整するために使用されます。彼らは、開発者が効果的であるためには、アライメント（整合性）、アブストラクション・ファースト（抽象化優先）、イテレーティブレビュー（反復レビュー）という 3 つの主要なスキルが必要であると考えています。

Thoughtworks が 34 回目のテクノロジーレーダーを発表し、ツール、テクニック、プラットフォーム、言語を調査しました。レーダーは AI を重視しており、ペアプログラミングやクリーンコードといった基本的なソフトウェア開発プラクティスを再検討することを促しています。また、エージェント型ツールの台頭により、コマンドラインインターフェースが復活していることも指摘しています。LLM に関するセキュリティ上の懸念も取り上げられており、特に広範なアクセスを必要とする「権限に飢えた」エージェントは、プロンプトインジェクションのようなリスクをもたらします。レーダーでは、これらの野心的なエージェントを安全に管理するための「ハーネスエンジニアリング」について論じています。AI が生成したコードの品質についても疑問を呈しており、AI 支援コードが人間のレビューなしでは管理不能になった事例を挙げています。著者は、AI を使用する場合でも、耐久性のあるコードを維持するためには人間の監督が必要であることを強調しています。LLM によるゴーストライティングに関する哲学的な実験が提示されています。本文では、Direct File 税プログラムの廃止を批判し、政府改革のしばしば欺瞞的な複雑さを強調しています。Direct File の公共サービス精神と、DOGE の無関心と見なされるものとの対比を示しています。国家安全保障にとって効率的な税制の重要性が強調されています。

著者はPragmatic Summitに参加し、ケント・ベックとゲルゲリー・オロスとAIについて議論しました。その会話は、AIと過去の技術的変革との比較、アジャイル手法、TDD、そしてAIネイティブな業界で成功する必要性について触れました。著者は、効率的な抽象化を生み出す上で重要である、プログラミングの美徳である「怠惰」について考察しています。ブライアン・カントリルの「怠惰」に対する見解と、それがコーディングにどのように関連しているかについても言及されています。著者は、AIがこの美徳を欠いているため、コードが容易に生成されることで、過度に複雑なシステムにつながる可能性があると懸念しています。著者は、コードを簡素化するためにリファクタリングを行った自身の個人的な経験を共有し、LLMを使用した潜在的な結果と比較しています。ジェシカ・カーの、エージェントのプロンプティングにテスト駆動開発を適用した例が紹介されています。著者は、AIの過信と情報捏造の傾向について議論し、映画『ダーク・スター』を引用しています。著者は、特に高いリスクや取り返しのつかない結果が伴う状況において、AIシステムに結論を疑うことを教えることの重要性を強調しています。著者は、抑制、つまり行動を控える能力が、AIの安全性と責任ある自律性にとって不可欠な能力であると主張しています。

昨夜、セントラル・スクエア・シアターの優れた「暗号を破る（Breaking the Code）」の公演を見ました。アラン・チューリングについてのもので、彼は私の職業と自由民主主義の運命の両方に巨大な貢献をしました。ボストン近郊にいるのであれば、来月見る価値ありです。

著者は、Simon WillisonとLenny Rachitskyが出演するポッドキャストと、Gergely OroszがUberの元CTOであるThuan Phamにインタビューしたポッドキャストという、2つの優れたポッドキャストを聴いています。Simon Willisonとのポッドキャストは、プログラミングがどのように変化したか、そしてこの仕事における重要なパターンについて議論し、世界の現状を包括的に概観しています。Gergely Oroszとのポッドキャストは、Uberのマイクロサービスの利用と、高成長ソフトウェアは必然的に多くの書き換えが必要になる「Sacrificial Architecture（犠牲的アーキテクチャ）」の概念についての洞察を提供しています。著者はまた、Axiosでの最近のサプライチェーン侵害についても言及しており、攻撃者はリードメンテナーと連絡を取り、リモートアクセス型トロイの木馬をインストールする前に数週間を費やしました。著者は、自身も同様の、非常に巧妙で正規に見える攻撃の標的になったことに言及しています。著者はまた、技術文書の整理のためのフレームワークであるDiátaxisを発見しました。これは、チュートリアル、ハウツーガイド、リファレンス、説明という4つの形式の文書を分類しています。著者は、チュートリアルとハウツーガイドの区別、そして説明を別々の領域に切り出すという考え方を高く評価しています。さらに、著者は、AIエージェントを使用してSQLiteを操作するためのツールを開発したLalit Magantiの経験に言及しており、AIによる開発の利点と危険性を浮き彫りにしています。著者は、Ryan Aventの、ケアに焦点を当てることで経済成長に対する重要な視点が得られるという投稿に言及して締めくくっています。成長はそれ自体を目的として望むべきではなく、むしろ私たちの集合的な能力を拡大し、苦しみを軽減する能力のために望むべきであることを強調しています。全体として、著者の投稿は、ポッドキャストやサプライチェーン侵害から技術文書やAI開発まで、さまざまなトピックを網羅しており、それぞれの分野における慎重な検討とニュアンスの重要性を強調しています。

ラーフル・ガグは、AI支援開発における摩擦を減らすシリーズを完結させました。彼は、AIセッションから得られた学びを収集し、チームの共有成果物にフィードバックする構造化されたフィードバックの実践を提案しています。これにより、個々の経験をチーム全体の改善へと繋げます。

現代のハードウェアは驚くほど高速ですが、ソフトウェアはそれを活かしきれないことがよくあります。Caer Sandersは、機械的共感 - つまり、基盤となるハードウェアに共感するソフトウェアを作成する実践 - を用いて、自身の作業を導くことが価値があると見出しました。彼らはこの実践を、日常的な原則に落とし込んでいます。それは、予測可能なメモリアクセス、キャッシュラインの意識、シングルライター、そして自然なバッチ処理です。

本書では、ソフトウェア開発における「認知債務」の概念を探り、それを技術的および意図的負債と並行させています。認知負債は、チーム内の共有理解が失われ、変化について理性で判断する能力を妨げることから生じます。この記事は「認知の三系統理論」を提案する論文に言及しており、カーネマンの二系統モデルにAI(システム3)を加えています。これにより「認知的降伏」が導入され、AI推論に依存することで批判的思考を回避します。著者は次に、HTMLタグをコードアイコンとして使うことを批判し、プログラミング言語に関する誤解を指摘しています。さらに、コーディングエージェントが普及する中で検証が重要なスキルとしてシフトしていることについても論じています。著者は検証の重視に同意しつつも、LLMがレガシーコードの理解を助けていると考えています。この変化により、コード作成だけでなく検証を中心にチームを再編成し、品質の定義と成果のモニタリングに重点を置くことが促進されます。最後に、テキストはLLMの文脈におけるソースコードの未来に触れ、多様な視点を要約し、人間主導の抽象化とドメイン駆動設計の重要性を強調しています。著者はコードにおける命名規則の価値を強調し、良い名前が問題解決の意図を示すことを強調しています。

先月、Birgitta Böckelerは、最近開発された「ハーネスエンジニアリング」という概念について、最初の考察をいくつか執筆しました。彼女はそれ以来、このテーマについてさらに調査と考察を重ねており、今回、ハーネスエンジニアリングを理解するための思慮深いメンタルモデルを執筆しました。これは、人々がコーディングエージェントをより効果的に活用するのに役立つと私達は考えています。

AIコードアシスタントは、誰がプロンプトを与えるかに応じて応答し、生成されるものの品質は、プロンプトがチームの規範をどれだけうまく表現しているかに依存します。ラフル・ガルグは、AIのやり取り（生成、リファクタリング、セキュリティ、レビュー）を規定する指示を、バージョン管理された、レビューされた、共有されたアーティファクトとして扱うことを提案しています。これらのアーティファクトは、暗黙のチームの知識を実行可能な指示にエンコードし、キーボードを操作する人が誰であっても品質を一貫して保証します。

Anthropicの調査は8万人のユーザーへのインタビューに基づいており、AIに対する微妙な見解を示しました。 人々は一般的に希望と恐怖の両方を示し、それは経済的安定や人間関係といった核心的な価値観に結びついていた。 この研究は、AI楽観派と悲観派の単純な区分ではなく、複雑な感情のスペクトラムを示しました。 地理的な位置も視点に影響を与え、発展途上国ではより楽観的でした。 Julias Shawは、LLMを使用する際に仕様を強制するための実行可能テストの必要性を強調しています。 彼は厳密なテストなしに仕様書を設計図として偏らせていることを批判しています。 ショウは仕様を効果的なテストスイートに変換するための5段階チェックリストを提唱しています。 Lawfareの記事では、イランの秘密工作に対抗する際の潜在的な問題について論じられています。 イランの執拗な攻撃試みと米国の反撃努力を強調しています。 記事は、最近の国家安全保障要員の削減が米国の対応を弱める可能性があると指摘しています。著者はこれらの変更の将来的な影響に疑問を呈しています。

アーキテクチャ決定記録（ADR）は、単一のアーキテクチャ上の決定を記録し、説明する簡潔なドキュメントで、通常は数ページです。ADRの主な目的は、決定の歴史的な記録として機能し、将来的にシステムの設計を理解できるようにすることです。ADRを作成することは、思考を明確にし、特にグループ内での議論を促進します。ADRは「逆ピラミッド」スタイルに従い、最も重要な情報を最初に優先します。通常、プロジェクトのソースリポジトリに保存され、多くの場合、Markdownのような軽量マークアップ言語を使用して、専用の「doc/adr」ディレクトリに保存されます。各ADRは、決定内容とそのステータス（「提案」、「承認」、「廃止」など）を反映した番号付きの名前を持つ個別のファイルです。 ADRには、決定、それを正当化する根拠、検討された代替案とその長所と短所、および決定の結果が含まれます。ADRは、不確実性にも対処し、決定を再評価する時期に関する情報を含めることもあります。これらは、アドバイスプロセスにおいて、決定を記録し、コラボレーションを促進し、受け取ったアドバイスを要約するのに役立ちます。簡潔さが重要です。ADRは短く、焦点を絞り、必要に応じて補足資料を参照する必要があります。短い決定記録という概念は、ソフトウェアアーキテクチャ以外のコンテキストでも価値があり、歴史的な記録を作成します。Michael Nygardがこの用語を普及させ、ADRドキュメントの形式を標準化しました。

コードレビューは、単なるバグ発見のメカニズムとしてではなく、コードの方向性と健全性を形成することに焦点を当てるべきです。主な価値は、判断に基づいて、コードが製品の一部となるべきかどうかを判断することにあります。コードレビューには、ペアプログラミングから後のリファインメントレビューまで、さまざまな実践が含まれます。オブザーバビリティは、システムがユーザーに対してどのように機能するかを明らかにし、初期の要件を超えた満たされていないニーズを発見します。著者は、コードレビュープロセスにおける判断力を高める上でのAIの役割を提唱しています。この著者は、コミュニケーションと多様な視点がコードレビューの不可欠な要素であるという意見に同意します。その後、テキストは、プロダクションの重要性を見過ごすことへの批判に移行し、コード開発の未来に焦点を当てます。著者は、人々が物事を学び、改善する方法に変化をもたらすAIの能力について考察しています。その後、テキストは、GPSと紙の地図を例に、能力を拡張するツールとそれを置き換えるツールについての議論に移行します。この著者は、GPSや電卓のような支援技術をパッシブに利用することの認知的影響を探求しています。著者は、難しいタスクには電卓を高く評価していますが、GPSで迷子にならないことにも価値を見出し、トレードオフを認識しています。著者は、LLMに自分の代わりに書いてもらいたいという願望がないことを強調しています。

AIとの会話は一時的なものであり、初期に下された決定は会話が進むにつれて注意を失い、新しいセッションが始まると完全に消えてしまいます。Rahul Gargは、Context Anchoringがどのように意思決定のコンテキストを、生きたドキュメントとして外部化するかを説明しています。

アニー・ベラの研究は、AIがエンジニアの仕事を、主にコードの作成から検証に向けてシフトさせている方法を探究しています。彼女は、AIの出力を指示、評価、修正することを含む新しい層である「監督エンジニアリング作業」を紹介しています。このシフトは、新しいスキルを必要とし、エンジニアがキャリアについて不確実性を感じる可能性があります。バシム・エレダスは、8つのレベルを持つエージェントエンジニアリングモデルを提案し、AIの潜在能力と実際の応用のギャップを強調しています。チャド・ファウラーは、コードを安全に置き換えることの重要性を強調し、交換可能なコンポーネントベースのアーキテクチャ上に構築された再生可能なソフトウェアの構築を提唱しています。マイク・マスニックは、教育におけるAI検出ツールについて議論し、これらは学生の文章の独創性を抑制する可能性があるものの、効果的なAIの使用に焦点を当てることにもつながる可能性があると指摘しています。アンキット・ジャインは、人間がコードを書いたりレビューしたりすべきではないと主張し、決定論的なガードレールなどの評価フィルタを提案しています。これにより、コードの役割と明確な表現の価値を再評価する必要性が生じます。ジェシカ・カーは、エンジニアの役割が新しい形のサーバントリーダーシップに発展していることを結論付けています。

テクノロジー企業が高校生のデータを販売したことで110万ドルの罰金を科せられたことは、企業に対する罰金が法令違反を阻止するのに十分なものであるべきであるという声につながった。著者は、企業が法令違反を単なる事業費用ではなく、潜在的に破滅的なものと認識する必要があると主張している。焦点を変えると、テキストは、生成的なAIがソフトウェア開発に与える変革的な影響について議論し、専門家がそれに抵抗するのではなく、積極的に関与するよう促している。また、「見習いギャップ」と呼ばれる問題、つまり、ジュニア開発者がAIエージェントに過度に依存することで、ソフトウェアシステムの深い理解が妨げられる可能性があることも強調している。「ラルフ・ループ」は、AIエージェントの故障から学び、継続的な人間の監視を強調し、認知的負債を軽減する。AIはCOBOLのモダナイゼーションを支援するが、単にコードを翻訳するだけでは意味がない。効果的なモダナイゼーションには、システムを現在の市場需要に合わせ、構文だけでなく内在的な弱点に対処する必要がある。著者は、LLM（大規模言語モデル）はコンパイラではないと強調し、それをスロットマシンとATMに例えている。最後に、この記事は、ジェフリー・エプスタインから資金提供を拒否した一部の学者について論じており、問題のある関連を避けることで、より快適でストレスの少ない生活につながる可能性があることを示唆している。

マティアス・ヴェラスは、ドメイン駆動設計におけるドメインと境界づけられたコンテキストについて議論し、それらの間に必ずしも1対1の関係があるわけではないことを明確にしています。ゲイリー・マーカスは、AI業界が汎用的なAIツールではなく、特化したAIツールへと移行することを提唱し、その方が効果が高いと述べています。米国の税制における電子申告の苦戦が強調されており、「ダイレクト・ファイル」構想、25州での成功、そしてトランプ政権によるその後の廃止に焦点が当てられています。記事は、ダイレクト・ファイルシステムの復活に向けた継続的な取り組みを明らかにしています。ブルームバーグのレポートは、サイバーセキュリティの脅威の悪化と、サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）内でのスタッフの懸念される再配置について詳述しています。このシフトは特に、緊急指令や価値の高い政府資産の保護に不可欠なCISAの能力構築チームに影響を与えています。CISA内でのスタッフの再配置は、リスクの増大にもかかわらず、サイバーセキュリティへの注力度が低下していることを示唆しています。この物語は、政府が危機が深刻化する中で、重要なサイバーセキュリティの責任を放棄しているように見えることを強調しています。この状況は、重要なインフラストラクチャと政府データの保護について懸念を引き起こしています。状況は、記事全文へのアクセスが有料であることによってさらに複雑になっています。結果として、政府は国家安全保障の重要な分野を弱体化させているように見えます。

ビルギッタ・ベッケラーは、最新のAIコーディングの流行語の一つである「仕様駆動開発（SDD）」を理解しようとしています。彼女は、SDDツールと自称する3つのツールを調べ、現時点でのその意味を解き明かそうとしました。

「サービステンプレートは、エンジニアリングチームが正しい方法で作業を進められるように、組織が構築する「ゴールデンパス」の典型的な構成要素です。テンプレートは、組織内のすべてのサービスのロールモデルとなることを意図しており、常に最新のコーディングパターンと標準を表現しています。しかし、サービステンプレートの課題の一つは、チームがテンプレートを使ってサービスをインスタンス化した後、そのサービスにテンプレートの更新をフィードバックするのが面倒であることです。Birgitta Böckelerは、GenAIがその問題を解決するのに役立つかどうかを検討しています。」

ビルギッタ・ベッケラーは、確率、影響、検出可能性という3つのリスク次元を用いて、バイブコーディングを使用するタイミングに関するリスク評価を検討しています。

著者がLLMとAIに関する考えを共有し、休暇の準備をしながら業界のトレンドを振り返っています。ソフトウェア開発におけるAIの影響に関する調査では、LLMの多様な使用方法が見過ごされがちで、結果が偏る可能性があります。著者はプログラミングの将来について不確実性を表明し、LLMを使った実験と経験の共有を奨励しています。AIブームは過去の技術進歩と同様のバブルだと考えていますが、最終的には弾けるものの、永続的な価値を生み出す可能性もあると見ています。著者はGOTOコペンハーゲンカンファレンスに参加し、業界の同僚と再会する予定です。LLMは幻覚生成エンジンと見なされており、出力の検証と複数のプロンプトの検討が必要であることを強調しています。ソフトウェアエンジニアリングは、他のエンジニアリング分野と同様に、非決定性を取り込むように進化するかもしれません。著者は、LLMが信頼できないジュニア同僚のように振る舞い、誤解を招く結果をもたらす可能性があることを指摘しています。最後に、著者はLLMによってもたらされるセキュリティリスクの増加、特にエージェント型ブラウザ拡張機能に関するリスクを強調しています。

共通のエンタープライズの課題：重要なレガシーシステムは「ブラックボックス」化します。業務には不可欠ですが、中身は不透明で、触れるにはリスクが伴います。Thiyagu Palanisamy と Chandirasekar Thiagarajan は、クライアントと協力し、AI支援の逆アセンブル技術を用いて、UI要素、バイナリ、データリネージから機能仕様を再構築し、分析麻痺を克服しました。彼らは、可視的な成果物から始め、段階的に情報を充実させ、ロジックを三角測量し、常にリネージを保持するという、方法論的な「マルチレンズ」アプローチを開発しました。人間による検証は、抽出された機能の正確性と信頼性を確保するために中心的な役割を果たし続けます。この取り組みにより、システムをブラックボックスからブループリント（設計図）に変えることが、モダナイゼーションの意思決定を強化し、移行作業を加速させることが明らかになりました。

Bahmniオープンソース病院管理システムは9年以上前に、AngularJSを使用したフロントエンドとOpenMRS REST APIで始まりました。Rahul Ramesh氏は、これをReact + TypeScriptフロントエンドとHL7 FHIR APIを使用するように変換したいと考えていました。このモダナイゼーションを実行する方法を模索する中で、彼はResearch、Review、Rebuildという構造化されたプロンプトワークフローと、Cline、Claude 3.5 Sonnet、Atlassian MCPサーバー、およびファイルシステムMCPサーバーを使用しました。単一のコントロールを変更するには通常3〜6日間の手作業が必要でしたが、これらのツールを使用することで、1時間未満で完了し、コストは2ドル未満でした。

CLIコーディングエージェントは、チャットボットや自動補完ツールとは根本的に異なるツールです。コードを読み、テストを実行し、コードベースを更新できるエージェントです。Ben O'Mahonyは、商用ツールは印象的であるものの、私たちの環境の特定のコンテキストや特定のプロジェクトの特殊性を理解していないと説明しています。代わりに、テスト、ドキュメント作成、コード推論、ファイルシステム操作の特定の開発標準を使用して、オープンソースツールを組み合わせることで、独自のコーディングエージェントを構築できます。

数週間前、Unmesh Joshi と私は、LLM を使って作業する際に彼が抽象化の言語をどのように育てるかについての会話を始めました。この会話は他の人も興味深いと感じるかもしれないと考え、記事にしました。プログラミングは抽象化の構築と適用についてであり、LLM がそれぞれの活動においてどのようにさまざまな方法で私たちを助けるかについて話しています。

「拡張ジョイント」と呼ばれる、話すタイミングを効果的に管理するためのテクニックを著者は開発しました。これらは、事前に計画されたオプションのトピックであり、短くも長くも話すことができます。これにより、話し手は焦ったり準備不足に見えたりすることなく、プレゼンテーションの時間を調整することができます。各拡張ジョイントは通常、要点をまとめたスライド1枚で構成され、議論のきっかけとなります。時間が短い場合は、トピックはすぐに要約され、しばしば範囲外であると述べられます。逆に、十分な時間がある場合は、話し手はそのオプションの資料を詳しく説明することができます。著者はまた、聴衆に気づかれずにスライドをスキップする技術を習得しました。このスキルはラップトップの操作を必要とします。このテクニックは、著者がプレゼンテーションをそれほど綿密にリハーサルしていなかったため、特に自信を与えてくれました。拡張ジョイントは、さまざまな時間枠に合わせてプレゼンテーションを調整し、聴衆とのやり取りを管理するのに非常に役立つことが証明されました。これらの柔軟なセグメントは、プレゼンテーションの終盤で、残りの時間が最も明確なときに最も役立ちます。

はい、承知いたしました。以下に翻訳します。 --- OKRs（Objectives and Key Results）は、大企業において戦略と実行を結びつけるための一般的な方法となっています。しかし、トップダウンでカスケードされるように設定されると、その意味を失うことがよくあります。チームは、自身が作成に関わっていない目標を与えられ、その結果、コミットメントは弱まり、実質的な変化はほとんど生じなくなります。 パウロ・カロリは、ハイパフォーマンスチームが別の方法でどのように機能するかを説明しています。彼らは、組織が採用する協調的なプロセスを通じて、チーム自身の目標を定義し、チームのOKRsをより広範な戦略と整合させます。これらのチームOKRsを確立することで、チームは共通の目的意識を創造し、それが定期的な計画、チェックイン、および振り返りのサイクルの基盤となります。

Sriram Narayanは、インパクト・インテリジェンスに掲載された記事を、この活動に対する5つの一般的な異議、すなわち、スピードの低下、俊敏性や協力体制の欠如、そしてイノベーションの予測不可能性に言及して締めくくっています。

Abi Nodaは、大規模なエンジニアリング会社の開発者はCopilotによって週に2時間節約できるものの、ビルドの遅延、開発環境の労力、コードレビューの遅延によってそれ以上に時間を失っていると指摘しました。これは、AIがすべての開発の非効率性に対する完全な解決策ではないことを示しています。Nik Malykhinは、AIアシスタントを効果的に使用するには、まず自身のコーディングルールとコラボレーションスタイルを明確にし、コード化する必要があることを発見しました。これは、認知的な作業をオフロードするためのメタ認知的な努力を必要とします。Charity Majorsは、使い捨てコードと永続的なコードを区別し、コストは作成方法ではなく、保守性、拡張性、理解度によって決定されると主張しています。使い捨てコードは、長期的な維持を意図していないため安価です。Jim Highsmithは、AIを「代替知性」と見なすことを提案し、その欠陥ではなく、異なる思考プロセスを強調しています。Rod Johnsonは、AIシステムの記憶の一形態としてドメインモデルの重要な役割を指摘しています。Event Sourcingは、不変のイベント履歴を通じてエピソード的な記憶を提供します。Repositoryパターンは、ビジネスの意味を保持するドメイン固有のメモリインターフェイスを提供します。Bounded contextは、概念の汚染を回避するためにメモリを意味論的にパーティション化します。Aggregatesは、信頼性の高いエージェントの動作に不可欠な一貫性境界を持つ、まとまりのあるメモリクラスターとして機能します。

Sriram Narayan は、インパクトインテリジェンスを向上させるための5つの行動を概説して、インパクトに関する記事を続けています。それは、堅牢な需要管理の導入、測定債務の返済、インパクト検証の導入、 CFO/COO に ROI に代わる選択肢の提示、チームの装備です。

知識労働者の生産性を定量化することは難しく、しばしば直接的なビジネス成果から切り離されています。この理解の欠如は、多くのイニシアチブ、過剰なテクノロジー投資、そしてこの生産性を向上させるための誤った取り組みにつながります。Sriram Narayanは、彼らの仕事のビジネスへの影響についてのインテリジェンスを、アウトプットを近接的および下流への影響に結びつけるネットワーク全体で開発することにより、これを回避する方法を探る記事を始めています。

Birgitta Böckelerは、人間を介さずに、生成AIが現在、どの程度まで高品質で最新のソフトウェアを自律的に開発できるかを探索するために行った一連の実験について報告しています。テストケースとして、シンプルなSpring Bootアプリケーションをエンドツーエンドで構築するためのエージェンティックワークフローを作成しました。このワークフローは最終的にこれらのシンプルなアプリケーションを生成できましたが、特に複雑さを増すと、結果に重大な問題が見られました。モデルは要求していない機能を作成したり、要件のギャップに対して不安定な仮定をしたり、テストが失敗している場合でも成功を宣言したりしました。私たちは、再利用可能なプロンプトや参照アプリケーションのような多くの戦略はAI支援ワークフローを強化するために価値がありますが、生成を監督するための人間の介入は依然として不可欠であると結論付けました。

Matteo Vaccariは、AIコードの受容に関する一般的な指標に大きな欠陥がある理由を示しています。LLMは、そのコードを破棄したとしても役立つことができます。

LLM（大規模言語モデル）を扱う際、開発者の間で「ペルソナ」を与えることが一般的な習慣となっています。ここでは、頑固なロバ、ランプの精、スロットマシン、そしてユーライア・ヒープという4つのペルソナについて説明します。

Korny Sietsma は、コーディングに LLM を使用することが非常に役立つと同時に、限界もあるという素晴らしい例を示しています。 そして、熱狂も根強い懐疑論者も、どちらも時代遅れになっている理由についての思慮深い一般的なエッセイも。 その間、詩の教授が、執筆における AI の価値と限界について考察しています（ギフトリンク）。 ここでの本当の課題の1つは、AI が人間の注意の価値と、そこから生まれる個性を損なう方法です。 私たちが失うのは、単なるスキルだけでなく、存在のあり方です。発明の喜び、働く精神の生きた経験です。

「昨日楽しんだ3つの記事： スティーブン・オグラディーは、Gen AIツールが開発者ツールの2つの共通の定数を破ることを話しています。つまり、Gen AIツールと移り変わることに同意し、支払うことに同意するということです。これにより、新しいツールが登場するチャンスがあり、企業での採用は方向性の合意不足によって遅れることになるということを意味します。 ピート・ホッジソンは、Gen AIに関する優れた執筆を続け、AIアシストされた将来に向けたエンジニアのリーダーシップについて、aligned autonomyの概念を中心に提案しています。彼は、明示的な実験フェーズ、採用サポート、影響測定を主張しています。 チャリティー・マジョースは、彼女のキャリアについて反省しています。彼女の言葉「我々は自分の幸せ（何それか）よりも、価値のある仕事をしたいという気持ち」に本当に共感しました。」

「LLM（大規模言語モデル）があっても、ビルギッタ・ベッケラーは依然としてコードにこだわりを持っています。「LLMは、コンパイラ、インタプリタ、トランスパイラ、あるいは自然言語のアセンブラではありません。それらは推論器なのです。」