Clineむずかしい
Clineを試してみた。使ったのはclaude 3.7 sonnet。とにかく速くて癖になる。
正直うまく使いこなせていない。 具体的には、11tyを動かしたときにCSSがうまく反映されない問題を解決しようとしたときに、Clineを使ったらかなり手こずった。原因を考えてみる。
11tyでのCSS問題とClineの対応
11tyでCSSが正しく適用されないという問題に対し、Clineに解決を丸投げしてみた。そもそも11tyの全体像もわからぬまま、clineの圧倒的なリライトにそのままApproveを押した続けたのが良くなかった。
気づけば、その場しのぎのような修正を繰り返してはなにも解決しないという状況になっていた。
具体的には、
- 11tyでビルドした後のファイルを直接修正する(その場しのぎ)
- 無効なリンクがあればベタ書きで追加する(それ更新されないじゃん) という感じだった。
使っている技術(ここでは11ty、ひいてはSSG)の概要をあまり理解せずにプロンプトをなげ、Approveを投げたのがよくなかった。
あとは、今回の実装の特別なところがclineに伝わりづらいんだろうなとも思った。
- 外部参照やコンテキストがない
- 技術的なドメインに閉じている
- モックデータを作りやすい
- すでに既存実装がありそう
がClineの得意なこと、とあった。逆に言うと、コンテキストがあったり、技術的なドメインに閉じていない場合は、苦手なんだと思う。あるいは、しっかりと人間が使いこなす必要があるのだろう。
ClineのE2Eテスト?
特に驚いたのは、Clineがページを読み込み、クリックしてテストしていたことだ。
今後の方針
この記事が参考になった。 Clineに全部賭ける前に 〜Clineの動作原理を深掘り〜
システムプロンプトの設計
Clineの実行フローの中で一番大事なのはアシスタントに送る最初のメッセージの作成です。
ここではユーザーのメッセージに加え、ユーザーの環境情報とシステムプロンプトを1つにまとめてアシスタントに送信します。
環境情報では、アシスタントがプロジェクトのコンテキストをより詳細に理解できるように以下の内容などを追加します
- ユーザーが使用しているOS情報
- 返答の際の言語設定
- ホームディレクトリなどの環境情報
- .clinerulesファイルに定義されたプロジェクト固有のルール
- .clineignoreに指定された無視すべきファイル情報
システムプロンプトはClineの中で最も重要と言っても良い部分で、AIがユーザーの要求に対してどのような形で返信すればいいかのをマニュアルとして定義しています。
実際、他の人はどう使っているのか気になり、以下の資料を読んでみた。
- mizchiさんのCline記事
- watanyさんのCline記事(100ドル使ったそう)
これらを読んで、やはりClineの適切な活用にはある程度の慣れが必要だと感じた。
もっと重要なのは、基礎となるような技術力ではあると思う。新しい技術の対応力も。
- ティム・オライリーの記事 にあったように、技術力があり、かつ、新しいパラダイムにも対応できるような人が、AIを魔法のように使いこなせるのだと思う。そうなりたい。
AIの「70%問題」
また、Clineに限らず、AIの開発支援には「70%問題」があるという記事を読んだ。
この問題は、AIが開発の初期段階を劇的に加速する一方で、最後の30%の仕上げにはエンジニアの知識と経験が不可欠である、というもの。熟練者ならAIを効果的に活用できるが、初心者は誤ったコードをそのまま受け入れてしまい、バグの修正に苦労することが多い。
まさに今回、Clineでのデバッグを試みたが、全体像を把握しないままデバッグしてしまい、結果として良くない修正をApproveしてしまった。
結局Hugoに切り替えた
最終的に、11tyのトラブルシューティングに時間をかけるより、Hugoでやった方がラクだったので、そちらに切り替えた。
まとめ
Clineを使ってみた感想としては
- AIに頼る前に問題を整理することが重要
- その場しのぎの解決ループに注意
- 細部の調整や判断は人間が行う必要がある
結局Hugoがラクだった。