2026年3月1日
Vibe coding時代の技術選定を考える
Vibe codingをするようになって、ものすごいスピードで成果物が上がってくるようになるとともに、これまでの自分の中での常識をアップデートする必要があると度々考えるようになったのでメモ。
2026/03/01時点で考えてることを吐き出すだけなので、すぐに意見は変わるかも。
主にバックエンド実装の話。
- 言語選定
- これまで
- ruby(とセットでrails)、typescriptなどを書くことが多かった
- これから
- (やや極端かもしれないが)Haskellなどがファーストチョイスになる可能性があるのではないか
- 純粋関数型的な特徴が自然と構造を固くする、実装の自由度を言語レベルで縛ることでLLMのアウトプットを一定にする
- 人間は構造部分(型情報として表現)される部分のレビューはするが、構造を保つ前提であれば具体の実装は真面目にレビューしない
- 動的言語が今後も生き残っていくのかは個人的に興味がある、あえて型安全でない言語を選ぶ必要性がどの程度あるのか疑問(既存コードの保守の話はのぞく)
- (やや極端かもしれないが)Haskellなどがファーストチョイスになる可能性があるのではないか
- これまで
- ディレクトリ設計
- これまで
- 時と場合によりけりだがMVC的なものとかクリーンアーキテクチャの簡易的なものとか
- これから
- クリーンアーキテクチャをある程度真面目にやる価値が上がる
- コアドメインと周辺領域はディレクトリレベルで明確に分離する
- 依存はcustom linterなどで違反ができないようにする
- 人間はコアを真面目にレビューする、周辺コードは真面目にレビューしない
- クリーンアーキテクチャをある程度真面目にやる価値が上がる
- これまで
- フレームワーク
- これまで
- rubyで言えばrails一択、typescriptもNestJSなどAltRails的なものがある程度強かった印象
- これから
- 重いフレームワークは使わない、フレームワーク自体の導入を慎重にする
- typescriptで言えばHonoとか
- フレームワークを入れずに自前実装や自前実装や薄いライブラリで十分な気もする
- 避けるべきものとして、新規性が高すぎるもの・日常のワークフローが重くなるもの・黒魔術的なコードになってるもの
- 将来的に置き換えやすいかを一つの指標としてもいいかもしれない
- 重いフレームワークは使わない、フレームワーク自体の導入を慎重にする
- これまで