ソフトウェア開発におけるAIの現状
原題: The AI Situation in Software Development
日本語訳
# ソフトウェア開発におけるAIの現状
AIの現状
プロンプティング、コンテキストウィンドウ、圧縮、そしてAIとの協業に関する断片的な考察。
頭の中にあることをAIに実行させたい。自分自身がその方法や内容を分かっている場合もあれば、分からない場合もある。そこには3つの選択肢がある。1つ目は、細部に至るまで、あらゆる具体的な事項をすべて伝える方法だ。
2つ目は、抽象的な指示だけを出して、AIがそれを理解してくれることを期待する方法。
あるいは、中間的な方法をとることもできる。AIにとって難しいだろうと思われる重要な部分だけを説明する。これが最も一般的なやり方だと感じている。
例示を与えることもできる。これは作業をスピードアップさせるが、その例が求めるものに近いかどうかに左右される。
これらはすべて時間を要する。AIに指示を出す前に時間をかけるものもあれば、出した後に時間をかけるものもある。
ユーザー認証の実装のように、学習データの中に必ずと言っていいほど含まれているような一般的なパターンは、LLMにとって実装が容易だ。一方で、自分が思いついた新しい問題や、AIに伝えたばかりの新しい課題は、当然ながらAIにとって難しく、手取り足取りの指示が必要になる。
次に、コンテキストウィンドウの問題がある。3000語、4ページにわたる詳細で密度の高い仕様書を渡して、すべてに従ってくれることを期待することはできない。コードベースが大きくなればなるほど、すべてを詰め込むことは難しくなり、膨大なドキュメントを読み込ませても、それに見合う成果が得られるとは限らない。これは詳細な仕様書の作成に限った話ではない。パターンの要約や、大量のデータセットからの結論の導出（例えば、株価の履歴データのような膨大な数値データの分析など）をさせたい場合も同様だ。
つまり、コストは人間に跳ね返ってくる。プロジェクトの詳細なガイド、その目的や課題、そして何より、実現したいことの設計図（ブループリント）を書くために、依然として時間を費やす必要があるのだ。
また、AIモデルのドメイン特化型の専門性という問題もある。適切なモデルを選び抜く必要がある。
より大きな問題に取り組み、アプリケーションにAIを統合していくにつれ、「圧縮」の必要性が生じてくる。特定の課題を解決したり、結論を出したり、意思決定を行ったりするために、可能な限り（あるいはすべてを）有用な情報としてAIエージェントに詰め込む必要があるのだ。この分野でこれを効果的に行う企業が現れるか、あるいはモデル開発者が根本的な解決策を提示するかのどちらかだろう。
コードベースが肥大化するにつれ、テスト、ツール（専用のものか否かを問わず）、そしてアプローチの洗練といったフィードバックループが不可欠になる。また、コードベースにおける信号対雑音比（S/N比）を向上させる方法も必要だ。
説明が上手な人や、天性の教師のような人は、AIとの対話が容易で、より優れたアウトプットを出せるのではないかと感じている。
結論として、依然として時間は必要だ。実装にかかる時間は減った。しかし、費やす時間は「事前のシステム設計」「前提条件の変更」「開発環境の洗練」へとシフトしたのだ。だが、実装そのものが消えたわけではない。私は今、コードの代わりに「言葉」で実装を行っているのだと感じている。
原文（英語）を表示
ai
The AI Situation
Random thoughts about prompting, context windows, compression, and working with AI.
You want it to do something you have in mind, and you know how/what to do, or sometimes you don’t. Now there are 3 options: you tell it everything down to the details, every specific thing.
Or you just tell it to do something at a high level and expect the thing to understand.
Or you can go the middle way. I feel this is the go-to way, explaining the important parts that you think might be difficult for it.
You can feed it examples. It’s a faster way to do things, but it depends on the example being close to what you want.
All of these are time-consuming. Some you spend time before giving to AI, some after.
A common pattern is easy for LLMs to implement, considering they must have seen it before in their training set, for example implementing user auth. A new problem you’re imagining or telling it is of course hard for it and needs hand-holding.
Then there’s the context window problem. You can’t just give a 3000-word, 4-page detailed dense spec and expect it to follow everything, and the larger the codebase, the less it can pack everything in, nor are the vast documents you can feed it worthwhile. Not only for writing detailed specs ~ you also want it to summarize patterns, draw conclusions from a large dataset, be it something like analyzing vast amounts of numerical data, for example a historical dataset for a stock.
So the cost is on you: you still need to spend the time to write a detailed guide for your project, its goals and its issues, and more importantly the blueprint of the thing you want.
Then there’s domain-specific expertise of AI models. You need to pick and choose the right one.
As you work on bigger problems and as you integrate AI into your applications, a need for compression arises, packing as much useful information as possible, if not all, into your AI agent to solve a particular problem or to draw a conclusion, make a decision or whatever. I think there will be companies in this space that’ll do this effectively, or the model builders will just solve this once and for all.
There must be feedback loops in terms of tests, tooling (purpose-built or otherwise), and refining its approach as the codebase grows large. And ways for improving the signal-to-noise ratio in your codebase.
I feel that great explainers or natural teachers find it easy to engage with AI and produce better outputs.
Bottom line: you still need to spend time. The implementation time is gone. Now the time you spend has shifted to designing the system upfront, changing assumptions, and refining your dev setup. But implementation is not really gone. I feel I am still implementing in words instead of code.