nitlog

チームでいい感じにAIを活用して開発をしたい

従来と比べると、実装の速度が爆速になった。
そうなると、意思決定での足踏みがかなり目立つようになってきたように思う。

昔はアサインを割り振って並列で進めることが、そのまま効率化につながっていた。

ただ、今は速度が出るので、並列で進めようとすると逆に以下のようなことがボトルネックになる。

  • 他の人の設計や実装ができるのを待つ必要がある
  • 他の人の設計や実装とのすり合わせや認識合わせに割と時間がかかる

従来は考えを洗練させる時間、文章化する時間、整合性を確認する時間など諸々時間がかかっていたが、そのあたりはLLMで爆速でできるようになってきた。

なので、源泉となるアイデアや思想さえあれば、上記のような時間のかかる作業に対して人が時間を割く必要が無くなってきていて、そのせい(おかげ)で足踏み感がかなり目立つようになったと感じる。

こうなると、機能ごとの縦割りのアサインよりも、全体像のアーキテクチャやポリシー設計をガッツリ固めてから、それをもとに詳細を各々が担当して深堀りしていく感じのワークフローが良い気がしている。

個人的にはアーキテクチャやポリシー設計を決めるのは1人がやったほうが、思想を1本化しやすくブレないので良いと思っている。ただ極端な話、全員でやってもいい。

というのも、「この部分は別の人が考えるから、自分はやらないでおこう」と切り分けた結果、あとから別の人の設計が上がってきて、それを受けてのすり合わせや修正がお互いに必要になる。
それが積み重なると、間違ってはいないし整合性は取れているけど、なんだかイケてない仕様ができた……みたいになりがちで、そういうのを避けたい。

LLMのプロンプトは具体/抽象をコントロールするのが大事

  • コードRVして
  • ステージングしてる差分のRVして
  • コミット前にステージング分の最終チェックとしてRVして
  • 技術的負債にならないように、各種ベストプラクティスに沿っているかの観点を重視してRVして
  • DRY原則、YAGNI原則などを重視して、技術的負債をできる限り減らせるように広くコードRVして

まぁ当たり前ですが、粒度が変わると応答が大きくかわる。
どれが良いというわけでもなくて、期待する結果に合わせて意識的に変えるのが良い。

その上で「目的」を厚めに伝えると、思考力の高いモデルは想像以上に良い結果を返してくれることが多い。

例えば何かを作るときも、
「A機能を実装して。これに注意して、必ずこうすること。動きは~~~~。」
というよりも
「XXをするのがめちゃくちゃめんどくさい。今はコレをするために、あれをこうして、こうしなきゃいけない。30分も時間がかかってるので1分でできる感じにしたい。なのでいい感じに機能Aを実装して」

こんな感じで「機能Aの詳細」よりも「機能Aが欲しい理由」を手厚く伝えたほうが経験上100倍いい成果物ができる。
で、具体的なアーキテクチャや実装手順/思想は、プロンプトではなく、スキルなどでワークフローとして定義してあげておくのが一番楽。

具体的に書きすぎるとLLMの持つ知識量を最大限活かせない代わりに思い通りの結果を得やすい。
抽象的に書くと、正しく意図が伝わればLLMの知識量を最大限活かせて、入力に対して出力のコスパが高くなる傾向が強い。ただしその代わり、プロンプトや外部ツールでLLMがブレないようにするハーネス的な仕組みの重要性が増す。

そんなことを最近思ってる。

Tane(種)

nitlog.dev は以下のカテゴリで運用しています。

カテゴリ内容
Tech技術系の話
Movies映画の鑑賞記録
Tane(種)アイデアの種、TechやMoviesで記事にする前の断片

TechとMoviesは腰を据えてしっかり書きますが、このTane(種)では思ったことを気楽にどんどん書いていきます。

新しい一覧表示の形

通常、ブログ記事などのエントリ一覧は平面に並ぶ。
見やすいが、暇つぶしにネットサーフィン(死語)をするときは案外微妙だったりする。

  • 最近のやつのつもりで読んでたらめちゃ古いやんけ
  • 同じような内容のやつを読みたいけど、どのタグ/カテゴリを見ればいいだろうか?

みたいな。

そこで、XY の 2軸で記事の意味的な近さを、Z 軸で時系列を表現してみる。

というのがこのページ。

X / Y は、記事本文を OpenAI の text-embedding-3-small でベクトル化して、それを UMAP で 2 次元に圧縮したものをプロットしている。
意味的に近い記事は埋め込み空間上で近いベクトルを持つので、2 次元に潰しても話題ごとにクラスタが自然と浮かび上がる、という仕掛け。結果として、類似の記事が近くに並ぶ。

Z(奥行き)は時系列。古いものほど後ろに行く。

ちなみに、しばらくは記事を追加するたびに結構位置が動くと思いますが許してください。
記事が増えてきたら安定するはず。

あとスマホ対応は追々。

TANE
4
wheel / swipe · click