要件定義自体もAIにやらせたほうが捗りそう。当然100%とはいかないから適切にインタビューさせて要件を煮詰めてく感じだろうか。
結局は要件定義とデータ構造の設計が全て。AI時代こそ基本が大事って皮肉だな
“「この機能いれて」「ここは不要だった」試行錯誤がコンテキストに残るとコード劣化。的確に指示が大切。アプリの意味「だれがどんな目的で使う」つまり要件定義。「何を作るか」を把握すればデータ構造は明確に”
ﾁｮﾜｶの人 (超分かるの意)。 エンジニア視点では再現性が高い安定した手法であることを目指したい。
専用のサブエージェントにプロンプト生成をやらせてみようと思う。プロジェクトに不適切なアンチパターンをつぶしたりするくらいのことはできるはず。とりあえずやってみる。ぬか喜びにならないよう冷静に行く
初めから要件定義のための試作を作ってそれをもとに要件定義するのがいいのでは？
今まではコードを手で書いているあいだに気がついて補正していたものが、コーディングエージェントによってそういった部分がなく指示がそのままコードになり、誤魔化しが効かなくなっています。
“コーディングエージェントの時代には要件定義の技術がより大切になると思います。”
そのプロンプトの解釈能力もどんどん改善されていくから、あんまり拘る必要無いと思うよ それより「どう使うか」を考えるほうが大事 ずっとそう
要件定義書のフォーマットとして md が最強になった感はある。
少なくともAIエージェントを「使う」形式だと言語化が得意なエンジニアが優位だから、まだ戦えるかなって
SIerに一括請負で丸投げしてた時代に回帰してない？「要件定義が大事」って。変化するビジネスの中でそれが無理だから内製化に変わったという歴史があったはずだが…。同じ理由でAIエージェントでの開発は無理だと思っ
それはそうだけど何のためにウォーターフォール捨ててアジャイルしようとしてたのか忘れるの早くない？
一番最初に試行錯誤が行われないほど要件固めきるって、自分で考えて自分で使う自分用ホビーソフトウェアでも無理じゃね？このブログでAI試す時によくやってるSwingサンプルとかブロック崩しレベルが限界では
アジャイルにできるかで、知識や能力が試される
ブレなく生成するには仕様をいかに注入できるかかと
コーディングエージェントがブレなくコードを生成できるプロンプトが大切 - きしだのHatena
要件定義自体もAIにやらせたほうが捗りそう。当然100%とはいかないから適切にインタビューさせて要件を煮詰めてく感じだろうか。
結局は要件定義とデータ構造の設計が全て。AI時代こそ基本が大事って皮肉だな
“「この機能いれて」「ここは不要だった」試行錯誤がコンテキストに残るとコード劣化。的確に指示が大切。アプリの意味「だれがどんな目的で使う」つまり要件定義。「何を作るか」を把握すればデータ構造は明確に”
ﾁｮﾜｶの人 (超分かるの意)。 エンジニア視点では再現性が高い安定した手法であることを目指したい。
専用のサブエージェントにプロンプト生成をやらせてみようと思う。プロジェクトに不適切なアンチパターンをつぶしたりするくらいのことはできるはず。とりあえずやってみる。ぬか喜びにならないよう冷静に行く
初めから要件定義のための試作を作ってそれをもとに要件定義するのがいいのでは？
今まではコードを手で書いているあいだに気がついて補正していたものが、コーディングエージェントによってそういった部分がなく指示がそのままコードになり、誤魔化しが効かなくなっています。
“コーディングエージェントの時代には要件定義の技術がより大切になると思います。”
そのプロンプトの解釈能力もどんどん改善されていくから、あんまり拘る必要無いと思うよ それより「どう使うか」を考えるほうが大事 ずっとそう
要件定義書のフォーマットとして md が最強になった感はある。
少なくともAIエージェントを「使う」形式だと言語化が得意なエンジニアが優位だから、まだ戦えるかなって
SIerに一括請負で丸投げしてた時代に回帰してない？「要件定義が大事」って。変化するビジネスの中でそれが無理だから内製化に変わったという歴史があったはずだが…。同じ理由でAIエージェントでの開発は無理だと思っ
それはそうだけど何のためにウォーターフォール捨ててアジャイルしようとしてたのか忘れるの早くない？
一番最初に試行錯誤が行われないほど要件固めきるって、自分で考えて自分で使う自分用ホビーソフトウェアでも無理じゃね？このブログでAI試す時によくやってるSwingサンプルとかブロック崩しレベルが限界では
アジャイルにできるかで、知識や能力が試される
ブレなく生成するには仕様をいかに注入できるかかと