AIコーディングツールはまだ研究開発段階にある

Stack Overflow の 2024 年の調査によると、開発者の 76% が AI ツールを使用しているか、使用を計画しており、AI ツールは今や仕事の一部となっています。AI ツールは日常的なタスクに役立ちますが、自信満々に意味不明な結果を生成すると迷惑になることがあります。YouTuber が ChatGPT プロンプトを使用して「10 億ドル規模のスタートアップ」を立ち上げ、AI エージェントが毎週世界を席巻する一方で、実際のチームはまだこれらのツールを効果的に使用する方法を模索しています。今日、AI アシスタンスを習得することは、コーディングやシステム設計と同じくらい基本的であり、迅速に適応する必要があります。

問題は、これらのツールが本質的にまだ研究開発段階にあることです。ツールは絶えず変化し、互いにコピーし合い、これまで解決できなかった問題を解決したことで称賛されるべきです。どのツールにも明確な使用ガイドがありません。Copilot は、より確立されているにもかかわらず、明確なチュートリアルとベスト プラクティスがありません。解決策は? 開発者が最も得意とすること、つまりフレームワークを自分たちで整理して作成することです。

ゲームチェンジャー

...また、「量子飛躍」、「パラダイムシフト」、「エージェントの登場」など、さまざまなものがあります。これらのツールは確かに私たちのワークフローを変えていますが、その変化はより実践的です。開発者は、コードを直接記述するのではなく、チームリーダーのように機能し、AI アシスタントを管理しています。コアスキルは、設計、計画、説明、レビューに移行しています。

これらのツールが導入する主な UX コンセプトは次のとおりです。

1. インライン提案- 最も自然な統合パターン。機能しているときはシームレスですが、コードが中断されると、生産性がすぐに低下します。
2. チャット- LLM がガイド付きプロンプトを通じてコードベースと対話する古典的なアプローチ
3. Composer (「 Copilot Edit 」、「 Cline Act 」) -多くの人が混乱する新しい概念です。これは自律エージェントへの移行です。Composer は複数のファイルで動作し、エラー、リンティングの問題などに基づいて変更を適用し、自動的に反復処理できます。
4. エージェント- 期待される次の進化 - IDE に直接統合された、完全に自律的でパーソナライズされた AI アシスタント。

「提案」に慣れるのは難しくありません。AI アシスタントは最初に「提案」から始まり、それが私たちの注目を集めました。チャットは簡単です。ファイルをコンテキストに挿入し、反復して適用し、結果を検証します。

コンポーザータイプのツールは習得が難しく、学習曲線といくつかのわかりにくいアプローチが必要です。現在、カーソル エディターは最も使いやすい「コンポーザー」ツールを提供していますが、コパイロットは最近エージェント ベースのワークフローを導入した「コパイロット編集」でそれに追随しています。

作曲家として熟達するには、次の 3 つの重要な概念を理解する必要があります。

1. 説明書
2. ルール
3. コンテクスト

これらをそれぞれ調べてみましょう。

説明書

開発者としてだけではなくチームリーダーとして、私たちは設計ドキュメントまたは明確な製品要件ドキュメントを作成することから、新しいプロジェクトや主要な機能を開始する必要があります。この方法により、強力なエンジニアリングと製品思考が開発され、実装時間が大幅に節約されます。最も良い点は、これらのドキュメントが次のものになることです。

1. AIで生成
2. そして作曲家への指示書として使われた

これらのドキュメントを作成するには、まず人間から要件を収集し、次に Chat の推論モデルを参照します。Copilot と Cursor の両方に、このタスクに適した推論モデルが組み込まれています。OpenAI のo1とo3-miniデフォルトで使用可能ですが、Cursor の Chat は DeepSeek-R1 をサポートしています (ただし、 Composer ではまだサポートされていません)。これらはすべて、この目的に最適なツールです。

設計ドキュメントをリポジトリの最上位レベル ( requirementsフォルダーを使用) に保存し、ルートにProjectOverview.mdを配置するのが良い方法です。Twitter Web アプリの要件の構造例を次に示します。

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

すべてが適切に設定されていれば、新しい機能の設計ドキュメントを追加するのは、次のプロンプトを書くのと同じくらい簡単です。

コードベースに指示を保存すると、バージョン管理、メンテナンスの容易さ、標準的な PR ワークフローなど、明らかな利点が得られます。ただし、プロダクト オーナー、マネージャー、UX デザイナーなどの非技術系チーム メンバーは、git を使用せずにアクセスする必要がある場合があります。次の 3 つの解決策があります。

1. すべてをNotionに保存し、説明ページを公開し、 @Docsショートカットを使用してドキュメントとして挿入する

2. Notionページを.mdファイルに変換してリポジトリに保存するパイプラインを作成する
3. チームにgitの使い方を教えましょう - チーム全体にとって最も有益なオプションです

エディターで指示にアクセスできるようになったら、コンポーザーに切り替えて実装を開始します。これで、ルールを整理することになります。

ルール

現在、カーソルのみが「ルール」、つまり特定のファイル/フォルダーに対する直接的な実装指示をサポートしています。この機能は、現在コードベースに直接添付できない「 プロンプト ファイル」のみを提供している VSCode Copilot を含む他のエディターにも広がる可能性があります。

Cursor のルールはより包括的です。CONTRIBUTING.md CONTRIBUTING.mdリンター ルールと組み合わせ、LLM 機能によって強化したものを想像してください。これらのルールは製品に依存せず、共有可能で、チームやライブラリ ユーザー間で知識、ベスト プラクティス、実装の詳細を効果的に転送します。

ルールはコマンド パレットから作成でき、プロジェクトの.cursor/rulesフォルダーに.mdc拡張子で保存されます。この形式を使用すると、コードベース内の特定のファイルを@mentioningなどの高度な機能が有効になります。これらのルールをリポジトリにコミットし、改善に協力することを強くお勧めします。ルールを使用するワークフローは次のとおりです。

1. キュレーションされたリストを参考にして、テクノロジー スタックに固有のカーソル ルールを調べます。たとえば、優れたテンプレートとして役立つ、Next.js と React のよく書かれたカーソル ルールを見つけることができます。
2. 開発中にルールを積極的に更新します。コードの作成中にルールとして形式化できるパターンに気付いた場合は、すぐにルール ファイルに文書化します。
3. 分野の最高のものから学びましょう。ライブラリ作成者が知識を共有し、採用を増やすための新しいアプローチは、AI アシスタント専用のルールを作成することです。これを行っている企業はいくつか知っていますが、 Convex はOpenAI と Anthropic モデルの両方のルールを作成し、それをドキュメントで共有することで際立っています。私は同社の製品を使用したことはありませんが、AI 統合を通じて開発者のエクスペリエンスを向上させることに重点を置いている点は魅力的です。Supabaseも優れた例です。

多くのライブラリでは AI ルールが緊急に必要です。フロントエンド開発者の観点からは、 TanStack Query 、 React Spring 、 Firebaseなど、さまざまなライブラリに AI ルールがあると便利です。これらのルールがあれば、時間を大幅に節約でき、開発者が新しいテクノロジーを学習する際によくある間違いを防ぐことができます。

コンテクスト

関連するコンテキストをすべて含めることを忘れないでください。提供するデータの品質が高ければ高いほど、より良い結果が得られます。カーソル エディターは、いくつかの種類のコンテキストを許可することで、この点で Copilot よりも優れています。

1. ドキュメント - 非常にうまく機能します。ドキュメントへのエントリ ポイントを提供するだけで、ダウンロード、解析、将来のニーズに備えて保存されます。
2. ウェブ検索 - 厳密にはコンテキスト検索ではなく、オンラインリソースへの迅速なアクセスを提供します
3. さまざまな開発ツール - 特定の Git コミット、Lint エラー、メモ帳、その他の成果物
4. MCPサーバーはリアルタイムのコンテキストを提供できます。セットアップは少し難しいですが、ライブ データ アクセスが必要な場合に役立ちます。

これらのツールを習得したら、次のステップは個人とチームのパフォーマンスを最適化することです。しかし、ここから先はどのような道筋があるのでしょうか?

クラインとルーコード。コントロール

シンプルさと制御、自動化されたソリューションと手動の意思決定の間で、常にトレードオフに直面することになります。深く掘り下げて取り組む気があり、バグ、パフォーマンスの課題、粗い部分に対処することを恐れない場合は、 Cline (または、哲学が少し異なるそのフォークRoo-Code ) を試してみることを検討してください。

どちらのツールも、内部で実際に何が起こっているかを可能な限り明確にするように設計されています。

1. これらはオープンソースで、サブスクリプションは不要です。代わりに、独自の LLM API キーまたはOpenRouterなどのサービスを使用し、使用した分だけ支払います。
2. Cline は、どのファイルを読み取り、変更するかを含め、すべての操作を明確に表示します。
3. Cline は、LLM 通信、コンテキスト ウィンドウのステータス、および各チャット セッションのコストに関する詳細な情報を提供します。
4. 直感的な計画/実行モードを備えています。これは、他のツールでも採用を検討すべき論理的なアプローチです。

キラー機能は、Cline が実際にアプリケーションを実行してデバッグできることです。試してみるとわかるように、これは現実的で機能します。

これらすべてに興味がある場合は、これらのエディターの優れた紹介を提供しているAddy Osmani の最近の記事をご覧ください。

結論

これらのツールを導入するのは簡単なことではありません。また、「5 分以内にプロジェクト全体をゼロから作成する」ことは期待できません。しかし、これは明確な前進の道です。

テクノロジはすでに存在していますが、開発者だけでなく、マネージャーやデザイナーなど、チーム全体をこれらの新しいツールを中心に組織化する堅牢な AI 統合ワークフローが欠けています。AI は威圧的に感じられることもあり、その影響を共有することは最初は気まずいかもしれません (慎重な構成により AI が機能の 80% を作成したことをチーム リーダーに伝えるようなものです)。ただし、ソフトウェア開発は、これらのツールがチームのワークフローに不可欠なものになったときにのみ進化します。最も成功する移行は、AI エクスペリエンスに関するオープンな議論、共同ツールの探索を促進し、学んだベスト プラクティスをより広範な開発コミュニティに積極的に貢献するチームで発生します。