Slop — this is the term we hear more and more often when talking about AI products. 何か低品質、コントロールしにくい、1つの目標を持つ不安定な量で絶え間なく作成された:注意を集め、時間を殺す、ヒープを生み出す。 その規模、その潜在的な爆発の結果とともに、まだ見られる。 産業におけるバブル これらすべては、AIの実際の有効性と危険性についての議論を再び促進します。ソフトウェア開発は例外ではありません。研究は、AIツールをマスターすることは簡単ではありません、そして適切なスキルがなければ、それらのツールを使用する効果さえあり得ません。 . 陰性 それにもかかわらず、AIはソフトウェア開発において非常に役に立つ可能性があります. All it takes is rigor, consistency, discipline. Or following a checklist. 1.ちょっとした動機づけ ソフトウェア開発は数十年にわたって根本的に変わっていない。我々は方法論を改良し、プログラミング言語、配信方法、観測性、QAなどを再発明しました。 その時代は 好きであろうと嫌いであろうと、コードは間もなく主に言語モデルによって生成されます。これは大きな転換です。私たちは多くの習慣を変えなければなりません――文字通り私たちの職業を変えなければなりません。 以上 
 
 
 AIが私にとって効果的に働くようにするたびに、私は本当に幸せを感じます。それは新しいツールをマスターすること、学習すること、そしてよくやった仕事の喜びです。 それは避けられない。かなり厳しいポイントですが、最も重要な1つです。あなたは現実を見る必要があり、それを静かに受け入れることができなければなりません。 それは仕事の要件になりつつあります. 良い例は、この雇用基準から : ザピエ あなたが正しい動機を持っているかどうかをチェックすることは簡単です - ソフトウェア開発のための新しいLLMバージョンとAI製品が出たときにあなたの感情を注意してください。 喜びと好奇心の代わりに、不安を感じるなら、それはあなたが新しいツールに十分に適応していないことを意味するかもしれません。 新しいツールを学ぶために自分自身を押すために、その不安が解消したときに感じるリラックスは、続けるためのもう一つの強力な理由になります。 生産性 2.孤立 この時点から、チェックリストのすべての項目は何らかの方法で接続されます。 ここでのアプローチは単純です - LLMが受信する指示がより簡潔で、具体的で詳細なほど、その出力の質が良くなります。 コンテキストエンジニア コンテキストの特定性は、適切なコードベースの組織を通じて達成されます - 制限された責任の範囲を持つ独立した孤立したモジュールに物事を分解します。 こうしたモジュールを組織する最も簡単な方法は、monorepos 内にあります。今日では、プロジェクト全体のための包括的な複数の言語のリポジトリを構築するのにあまり時間がかかりません。 ルールは単純で、アプリケーションはパッケージに依存し、パッケージは相互に依存することができるが、パッケージはアプリケーションに依存することはできない。 以下は、あなたが使用できる例の構造です. それはほとんどのケースに適しています: root/
├── applications/
│   ├── website/
│   ├── public-api/
│   ├── admin-dashboard/
│   └── ...
│
├── packages/
│   ├── js/
│   │   ├── ui/
│   │   ├── client/
│   │   ├── validation/
│   │   └── ...
│   │
│   ├── py/
│   │   ├── common-lib/
│   │   ├── models/
│   │   ├── auth/
│   │   └── ...
│   │
│   └── go/
│       ├── common/
│       ├── clients/
│       └── ...
└── Makefile
 Makefileは、テクノロジーアグネスティックなスクリプトオーケストレーションを可能にするすべてのための入り口として機能します。 Python と Go は、JS にとって、pnpm が最良の選択肢であることが証明されました - 今日、私は npm と 線の上にそれを選択します。 この種のモノレポは非常に便利で、柔軟で、拡張可能な構造であり、AIエージェントと本当にうまく機能します。パッケージの開発は、コードが厳密に隔離され、特定の機能を果たしているので簡単です。 アプリケーション内のコードで作業する場合、あなたは: 
 
 
 
 すべての外部パッケージを事前に識別する ステップごとに変更を行い、まずパッケージを変更し、次に実際のアプリケーション レイヤーを変更します。 フィードバックループ内の孤立のエラーを一歩ずつ修正します. This alone deserves its own point. 3.Feedback Loopの設定 AI によって生成されたコードの品質は、AI エージェントがテスト、ランターを実行し、これらのツールの出力を使用して作業プロセス中に結果を調整できるようになると劇的に向上します。 理想の世界では、AIにコード実行環境へのアクセスを与えることが最善の解決策になるでしょう - ウェブプロジェクト、すなわちブラウザのために。 . 未完成ソリューション したがって、基本的なランターやユニットテストさえ、品質管理と幻覚を減らすための優れたツールです。特にモノレポの静的コードチェックの設定はかなり安いので、すでに書かれているコードに基づいてユニットテストを生成することができます。 いくつかのAIツール(Cursorなどの)が自動的にランターを実行する一方で、LLMがチェックを実行するように明示的に指示することはまだ合理的です。 例えば、プロンプトはこのように見えるかもしれません: Update packages/js/api-client:

Add getUserProfile(userId) method:
- GET /users/{userId}/profile
- Include tests for success and 404 error

Run `make test-api-client` and fix any failures.
 4.メモリー銀行の作成 Memory-bank は、2種類のエンティティを保存および管理する方法を説明するフレームワークです。 そして . Rules Documentation 非常にシンプル - それはあなたの製品がさまざまな視点から説明されています:製品、アーキテクチャ、およびコンポーネントレベル. 良い技術文書を書くことについての多くの記事がオンラインです。私たちにとって重要なのは、文書がより細かいほど、コードに近づくほど、エージェントがそれにアクセスしやすいということです。 Documentation AI エージェントの標準入力ポイントは AGENTS.md ファイルです このファイルは、プロジェクトの全体的な構造と目的を概要し、他の文書ファイルへのリンクを提供する必要があります。 メモリー・バンクのファイル構造がどう見えるかは以下の通りです。 monorepo/
├── memory-bank/                          # Shared across entire repo
│   ├── AGENTS.md                         # Root entry point
│   ├── monorepo-conventions.md           # Overall structure & rules
│   ├── shared-tech-stack.md              # Common technologies used
│   ├── development-workflow.md           # Git, CI/CD, deployment
│   └── architecture-overview.md          # High-level system design
│
├── applications/
│   ├── website/
│   │   ├── memory-bank/
│   │   │   ├── AGENTS.md                 # References root + specific context
│   │   │   ├── product-overview.md       # What this app does
│   │   │   ├── user-journeys.md          # Key user flows
│   │   │   ├── tech-stack.md             # Specific technologies
│   │   │   ├── api-integration.md        # How it connects to APIs
│   │   │   └── tasks.md                  # Current work items
│   │   └── src/
 ルールは、自然言語で書かれたガイドラインをコードするものであり、本質的には、ルールの組み合わせである。 そして Cursor エディターの Rules へのアプローチは、グローブパターンを用いて特定のファイルにルールを付加することを可能にするため、特に強力に見えます。これは、あなたのレポジトリの異なる部分で作業するときに、関連するルールを文脈に自動的に「インポート」します。あなたは TypeScript、Supabase、または GitHub アクションのためのルールを一度定義し、プロジェクト間でそれらを再利用することができます。 Rules contribution.md .eslintrc ルールは常にグローバルで普遍的です. 最良の実践は、それらをリポジトリのルートに保存することです. That's what code editors expect. ルールは常にグローバルで普遍的です。 ドキュメントとルールの両方の「空白ページ」の問題は容易に回避できます. ドキュメントは、簡単なプロンプトでAIによって生成され、その後編集することができます. 特定のテクノロジーのルールは、オンラインで簡単に見つけることができます: で、 で、 . 1位 2位 3位 したがって、AIエージェントとのすべてのセッションは、メモリ・バンクを読むことから始まり、それを更新することによって終わります。 5.「Plan → Act」パイプラインを学ぶ プラン→アクトのアプローチは、AIアシスタントと働く方法の最大の変化であり、複雑で大規模なタスクに対処する唯一の信頼性の高い方法です。 たとえば、Cursor は、追加の指示を必要とせずにタスクの実行を自動的に計画します。 このアプローチは90/10の原則に基づいており、計画時間の90%を計画に費やし、実装に10%しか費やしません。計画は特定のアーティファクトを生成します。 あなたのタスクがより詳細で、徹底的で、一貫しているほど、あなたの結果はより良いでしょう。 典型的な Plan → Act ワークフローは、以下のようになります。 プラン 
 
 
 
 
 
 
 コンテキスト準備:メモリ銀行から必要な文書を収集 ビジネスコンテキストの説明. Essentially a user journey for the feature. 技術仕様の説明 - 実装する必要があるもの QAプロセス説明 - テストのために実行するスクリプト、追加するテスト Tasks.md ファイルの作成 Iterating through the tasks.md file, clarifications, fixes, refinements. タスク.md ファイル、明確化、修正、改良 アクション 
 
 
 
 
 
 
 新しいセッションを開く(チャット、タブ) 実施開始 ステップごとに、順番に 結果を視覚的にチェックし、各ステップでテストを行います。 フィードバックループの改良、テストカバーの追加 文書更新 Tasks.md ファイルの削除 2位 このパイプラインを利用するには: important tips 
 
 
 常にプランとアクションを異なるセッションに分けてください 便利で、さらに安定性を向上させ、トークンを節約します。 If the agent produces incorrect results, do not complicate things with additional instructions — go back to the Plan stage, refine your task.md, memory-bank, and rules. エージェントが間違った結果を生成する場合は、追加の指示で事情を複雑にしないでください。 プラン → Act パイプラインをマスターすることは、AIの熟練さだけではありません。これは重要な、あるいは重要な、エンジニアリングスキルです。基本的に、良いプランは準備済みの設計ドキュメントです - あなたは、チームのリーダーまたはチームとそれを議論し、PRで実装する前にそれに調和し、ドキュメントとあなたのテストレイヤーの基礎として使用することができます。 プラグイン・クラウド・エージェント 市場にはさまざまなツールがたくさんあり、特定のツールに焦点を当てるつもりはなかったが、少なくとも2つの主要なタイプを分解しよう:ローカルエージェント(Claude Code、Cursor、Codex CLI)やクラウドベースのエージェント(Codex Cloud、Jules、または新しくリリースされた ( ) Claude Code WEB 開発者として、あなたは通常、ローカルエージェントに基づくツールに到達します。AI駆動のコードエディターやCLIツールであれ、ほとんどの日常の作業タスクは、その方法で簡単に、より効率的に処理できます。 しかし、クラウドベースのツールには独自の甘いところがあります。彼らの主なことは、すべての相互作用はブラウザを通じて起こります - あなたは開発環境やローカルに展開されたプロジェクトを必要としません。 だからこそ、彼らはこれらの使用ケースに最適です: 
 
 
 
 すべてのコードベース分析、実装の時間推定、潜在的な困難の評価、またはワークプランの作成(task.md)は、大規模なタスクの作業を開始する前に大きな助けになります。 緊密な監督を必要としない大規模で繰り返しのリファクタリング 主なことは、まずテストを準備することです(チェック3を参照)。 ターゲットの非重要な変更は、開発チームを回避します。タスクトラッカーでタスクを作成する代わりに、あなたのPOまたはCodexアクセスを持つデザイナーは、クラウドエージェントのためのプロンプトを書くことができます。 完璧なタスクは、それ自体を解決するものであり、さらに良いことに、類似のタスクを解決するためのプロセスです。 7.シェア AIコーディングの最も困難な部分はチームワークかもしれません。 あなたはどのようにベストプラクティスを共有しますか? チームメイト間のワークフローを標準化し、すべての人が同じツールセットを使用する必要がありますか? AIアシスタントは、メモリ銀行をどのように管理するか、誰がそれを最新に保つ責任を負うべきか?PRでどのように働くか?AIのルールをどのように互いに共有するか。 AIプロバイダーはこのニーズに対応しようとしていますが、既製のソリューションはありません。ソフトウェアエンジニアリングではよくあるように、私たちは自分でソリューションを発明しなければなりません。 私の経験では、知識を広める最良の方法は、オープンな水平フォーラムを介してです。もしあなたが既に定期的な開発者会議を持っている場合は、実践を共有し、ニュースを議論し、経験を伝えるために、これらの会議でAIの採用を重要なトピックにします。

This story contains new, firsthand information uncovered by the writer.

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

「Stop the Slop. Start Coding Smarter with AI」

About Author

コメント

ラベル

この記事は

Related Stories

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps