0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新米エンジニアの私が最近AIを使ってて思うこと5選

0
Posted at

背景

最近私は転職活動のためのポートフォリオの充実化のために、codexとgithub-copilotを併用してvibe codingによるアプリ作成をしています。
新米エンジニアの私の立場でAIについて思ったことを5つこの記事では記載しようと思います。

1つ目:codexはターミナルで起動するディレクトリが超重要

当たり前のことではありますが、codexなどのコーディングエージェントcliはどのディレクトリで起動するかが重要になってくると感じています。

例えば...

モノレポ構成でリポジトリ管理している場合、

  • backend
  • frontend

みたいにディレクトリがあると思います。
そこで、backend開発時にリポジトリルートでcodexを起動させて全部やろうとすると、frontendディレクトリの情報が邪魔をしていらない型を定義したり、むりにfrontendを考慮しようとした実装をしようとしてしまいます。
そこでわたしは、

  • バックエンド開発時はbackendディレクトリ
  • フロントエンド開発時はfrontendディレクトリ
  • ソースコードレビュー時はリポジトリルートディレクトリ

でコーディングエージェントcliを起動させるべきだと思っています。(この縛り+特定のコンポーネントだけを修正したい場合そのコンポーネントがあるディレクトリみたいなのもいい。)

そこで...

vibe coding時代ではディレクトリ構造設計が今まで以上に重要になるのかなと思いました。

2つ目:UIの問題はスクリーンショットを渡せば意外とどうにかしてくれる。

これはcodexをしているときに、「描画が崩れているから直して」みたいな指示ではUIの描画崩れなどを直してくれない場合、スクリーンショットをリポジトリ内に配置してそのファイルをmentionしつつ「描画が崩れているから直して」と支持すると意外とうまく行ったりするというものです。

ただし...

現在、codexは.gitignoreで無視されたファイルは@を入力してもパス予測してくれないっぽいので一旦gitが認識できるところに置かないと行けないのがなあって感じです。

3つ目:機能全体を一気に作ってもらおうとしない。

僕は一時期、githubのissueで使用を詳細に記載してcopilotにassignして全部作ってもらうという方法でvibe codingしていました。ただ、その場合、どんだけ詳細に機能の仕様を記載していたとしても、大抵自分の思っていた方向性とは違うものが出来上がってきます。

そこで私は...

copilotで見えづらい状態でvibe codingするよりもcodexで見えやすい状態でvibe codingできるように機能最小単位まで粒度を下げで、1つの支持で1つのことしか言わないようにすることである程度気持ちの良いvibe codingをできるようになりました。

例えば...

PRでcopilotによるレビューを行い、多数の指摘が上がった状態かつvibe codingで指摘ごとにではなく機能ごとに修正していった場合を想像してください。
そのときに指摘に対してなにが対応できていて、残りはどんな指摘があるのか、そしてその指摘は妥当なのか、更には妥当な指摘に対してどのような解決策があるのかを提示してもらいたい場合、

実装上、解決しているであろう指摘はスレッドを解決にし、解決していないであろう指摘はその指摘の妥当性を判断し、その上で妥当な指摘であるものに関しては解決策を提案してください

と支持してしまうと、多分ですが、あまりうまく行かないのではないかなと思います。
そこで、

  • 実装上、解決している指摘に関してはその指摘スレッドに解決したcommitのhashをコメントしてください
  • 現在の実装を考慮して解決できていない指摘に関して、それが妥当な指摘なのかを判断してください
  • 妥当であると判断した指摘のそれぞれの解決策をざっくり教えてください

のような形で1支持1タスクにするとうまく行きやすいのではないかなと思います。

4つ目:フレームワークなどは実装能力よりもふんわり概念を理解しておくことが重要

このAI時代に実装そのものを自分でしようとすることは可読性の低いコードを生みかねないのではないかと思っています。正直、シンボルの命名や関数の粒度をどうするかなどに労力を費やすのはばかばかしいことになるのではないかと思っています。

そこで...

ある程度のコンピュータ・サイエンスの知識はあることを前提として今後はフレームワークがどのような思想・概念なのか を理解することが重要になってくると思います。
これによってフレームワークに対する学習コストはこれまでの比じゃないくらいに下がるのではないかと思います。

5つ目:AIは素直な後輩だと思うと可愛がりながらコーディングできてよい

わたしはAIを使っていて、こいつ可愛いな。と思うことが最近増えました。
そこには私のAIに対する価値観の変化があったのではないかと思います。

その変化は

「めちゃめちゃ何でもできる頼れるシニアエンジニアみたいな存在」

から

「めっちゃ賢くて知識豊富だけど、指示の仕方次第で作業成果が180度変わってしまう素直な新人社員みたいな存在」

というものです。
そう考えると、

  • AI成果を出せなかったときは細かく支持できなかった自分の責任
  • 支持に対して想像以上のものを提供してくれたときはめっちゃかわいいやつ

と思えると思います。

余談...

そうやって素直な後輩だと思って作業してると触ってほしくないファイルを触ったときなんかに自分のきつい先輩としての一面が見えることがあります。その時の指示は一時的にキツい言い回しになってしまいます。そのあと、それに自分で気づいて申し訳ない気持ちになってしまいます。笑

結論

現在のAIによるCoding Agentはまだまだ発展途上なのかと思います。
そんなAIとうまく付き合っていくには

可愛い後輩を過保護に育てるような気持ちで指示はできるだけ明示的な形にする

のがいいのかなと思いました。

全体的に言いたいことがぶれてしまいましたが、ご了承ください。
また、AIとの付き合い方について共感、補足、別意見等ありましたらコメントいただけると幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?