everyone on their team commits and pushes to a shared mainline (usually shared master in git) at least daily.
チーム全員が 1 日に 1 回以上メインライン ( 大体は main ブランチ ) に commit と push をしていること
each such commit causes an automated build and test.
それらの commit すべてが自動的にビルドされテストされること
when the build fails, it’s usually back to green within ten minutes.
ビルドが失敗しても、大体は 10 分以内に再度成功すること

pull request 上でレビューを必須とした開発プロセスでは、そもそも最初の条件が非常に難しい。レビューやその後の意思疎通には時間を必要とすることが主な理由だ。

このテーマでは最近の GitHub merge queue 提供や、 stacking workflow の浸透などが語られている。

なおレビュー時間を短縮するための方法論として、 Martin のサイトでは次のようなやり方も提唱されているので、参考にすると良い。

日本において、これは技術課題というより適応課題と捉えたほうが良いと判断した。

非アジャイル的な、承認を前提とした開発プロセスを是とする文化があると感じている。周りに倣っているだけなのか、コードへのオーナーシップが違った形で発露されているのか、開発における安全や安定の感覚が更新されていないためなのか、真因は現場によって異なるだろう。

このあたりの感覚については、 t_wada さんが日本語で継続的に発信してくださっているので一読すると良い。

「コードレビューしている」とは「プルリクエストを使っている」ことであるという記事があるように、まずコードレビューという言葉について、開発者へのリフレーミングが必要だ。

Techniques

Adopt

Retrieval-augmented generation (RAG)

LLM は文章の生成モデルであり知識を取り扱っているわけではない。そのために幻覚やユーザーへの返答が的を射ていない状況が発生する。ならば知識を扱えるようにしてやればいいじゃん、という発想全般を RAG という。

具体的な実現方法も様々あり、一般的なテクニックとなってきている。

チラ裏

個人的に RAG は単語群間の相関をモデルの外から差し込むことで、利用者に都合の良いモデルへと変形させているという理解をしている。 LLM を道具として洗練させているだけ、という解釈だ。

この方向の変化を押し進めると LLM が身体性を獲得できるかどうか ? という疑問がある。歩くには足を使うなどの、人間にとっての前提を知識として付与することで「共感」を学習できるのか ? といったあたりだ。そうすることで活用できる範囲が広がるだろう。

生物としての制約や一般化した感覚などを RAG で後付けできるので、それで十分という可能性もある。

いち生物としての感覚では、喜びや痛みなどがわからないと使えない場面はあるだろうし、それを獲得するには五感インターフェイスを与える必要がありそう、という肌感だがどうなるだろうか。

Hold

幅広い統合テスト: Broad integration tests

「幅広い統合テスト」は Martin Fowler によって定義されている。 E2E テストのようなおおがかりなテストのことを指していると理解すれば良い。

最近はテスティングトロフィーという概念も提唱されているので、これは流れに沿った blip だ。

必要以上の LLM 利用: Overenthusiastic LLM use

LLM の発展は目覚ましいものがあるが、「とりま使っとこ」という風潮にストップをかける blip だ。

既存の手法で十分に解ける課題であれば LLM を用いる必要はない。コストがそれなりにかかるからだ。また、汎用 AI ではないので適用が難しい分野もある。

半年前に発表された去年の Gartner hype cycle でも Generative AI が Peak of Inflated Expectations に挙げられている。みな同じことを感じているのだろう。

他選択肢を考慮せずに LLM を fine-tune する: Rush to fine-tune LLMs

実際はわからないが、 ChatGPT レベルのモデルを作ろうとすると金銭的なコストが非常に高くなるらしい。理論の研究や学習用のコンピューティングリソースもだが、データを揃えるためのに専門家が大量に必要とのことで、人件費も馬鹿にならないと言われている。

RAG や既存手法の利用を考えずに fine-tune するのはオススメできない。

SSR web アプリでの Web Components 利用: Web components for SSR web apps

Web Components を使った SSR では client で layout shift なく hydration することが難しいらしい。

この問題がなくても React が React Server Components という hybrid な方式を模索し始めているのもあり、確かに立ち位置は微妙だ。

ピックアップ

継続的コンプライアンス準拠: Continuous compliance - Trial

昨今のサプライチェーン攻撃を防ぐために SLSA や SBOM が普及してきている。

この blip ではそれを発展させ、ソフトウェアライセンスに違反していないか、法令や業界のセキュリティ基準などに準拠しているかなどがチェックできるといいよね、というものだ。

全自動でやっていくにはまだ難しいところがあるが、法務の専門家と協力しながらやっていくことは非常に意義があるだろう。

負債でなく健全性を見る: Tracking health over debt - Trial

技術的負債が存在していることが即悪いというわけではないが、メタファーを用いるとどうしても言葉に引っ張られてしまう。

それよりも今うまくいっているかどうか、という指標を可視化し、悪化したらテコ入れするという姿勢のほうが自然に感じられる。

何を健全性の指標として用いるかは、その組織の目的が達成されているかなど、いわゆる North Star Metrics などに準じたものが良さそうだ。

LLM を用いた自律エージェント群: LLM-powered autonomous agents - Assess

最近は multi-agent system を LLM で実現しようという流れがあるようだ。これで今何ができるのかについては AutoGen の例を見るとよいだろう。

ただ、LLM はあくまで自然言語を介したインターフェイスしか持たないため、なにか示唆を得ようとするのは労力やコストに見合わない可能性がある。ディベートのような陣営設定による議論をシミュレートして決定に影響する観点を洗い出す、くらいだろうか。文化など様々なバックボーン間の違いによる課題のあぶり出しなどができてくると有用だが、どこまでできるかを試してみてもいいだろう。

ChatOps や定型作業の裏で自律エージェントが動くようになると楽になるだろう。