重度のAIプログラミングの数年間の日々

近年のプロジェクトにおいて、AIプログラミングが非常に多く用いられ、これは過去3年間にわたる最もAIの活用度が高かったプロジェクトである。記録したメモは体系化されておらず、思いついたことをそのまま書き留めている状態だった。

背景

Linux環境、バックエンドサービス開発、UI開発などのフロントエンドコンテンツは含まれません。

モデル

国内のminimax、glm、kimiの三巨頭も上手試してきたが、kimiの効果が一番良い。claudeは大規模な要求に対して効果的に分解し、codexは生産環境に最適で、非常に慎重だ。

Claudeは最も汎用性の高い選手で、現在プログラミング競技会では誰も打ち負かすことができない。ただ高価である。
Minimaxはコストパフォーマンスが最高で、速度も十分速く安定している – エビの波潮の下で利益を得た者。
Codexは大抵良いのだが、いくつかのタスクでは指示に従う度合いが低く、常に私の性能を最適化しようとして、実際には私が必要としていないのに、ユニットテスト時は冗長な回答をして直観的に事例を理解できるようにしたい – 私はそれを望んでいる。
Kimiは指定された指示に従う度合いが非常に高く、国内で一番使いやすいモデル。
GLMは休前はまともだったが、休後には計算リソースが深刻に不足し、廃止となった。

認識

AI の脳容量は個人を遥かに超え、一部のモジュールの設計において、AI とのプランニング議論を行うことで、思考連鎖を効果的に拡張し、より合理的な設計ソリューションを見出すことができます。

高度な指導者、能力のあるアシスタント。

位置（ポジショニング）

わからないことがあれば彼に聞いてください。明確な開発タスクを提示して実行させることができ、あなたをサポートする優秀な部下がいるようなものです。

問題

帰国後の国内のモデルで、春節（旧正月）を期して戻ってきた後、大規模な計算リソース不足が発生し、出力が非常に遅くなりました。確かに価格性能比は優れていましたが、出力速度が遅いため、実際の業務においてインタラクションの効率に大きな影響を与えます。智譜（Zhipu AI）も春節中にトラブルを引き起こし、開発者を裏切る行為と、プラン料金を乱に変更しました。最終的に事態が拡大し、大晦日の五日に謝罪文を発表し、内部プロセスも混乱していました。私の払い戻し申請後、帰国後に過去のプラン全体をすべて払い戻してくれました。当初は、アップグレード分のみ払い戻しと、旧プランの権利を維持するという公告が出ていました。

周限額（Weekly Limit）については、最初の智譜には存在しませんでしたが、現在は購入時に設定されています。これはプラットフォームがユーザーの「羊毛抜擢」（薅羊毛 -薅 sheep）能力を見下評価していたためです。全額払い戻しにより、私も「羊毛抜擢」ができなくなってしまいました。glm-4.7は、kimi-2.5とほぼ同じレベルの性能を持ち、指示に従う度合いも十分です。

いずれのモデルも、現在では人工による審査が必要です。

ユニットテスト

プロジェクト設計初期において、各モジュールの設計は独立したユニットテストが可能な状態で行われる。開発後期に、大規模モデルが自ら生成したコードに対して、自身でユニットテストケースを作成し、ほとんどのシナリオがすべてパスしてしまうことがあった。これはテスト駆動開発（TDD）のアプローチではないため、ユニットテストの役割は、その後のビジネスイテレーションやリファクタリングフェーズにおいて、AIによる修正コードが元の機能を破壊していないかを検証するために活用される。

パフォーマンステスト

AI が一部のコア関数に対して最適化されていない場合、おそらくパフォーマンステストを行う手間を省いてしまうでしょう。しかし、AI があると、データを確認して合わせてテストレポートを作成するのも手軽になります。

ドキュメント

ドキュメントのメンテナンスは大変な作業ですが、AIは違います。彼は修正したコードと同時に、ドキュメントのメンテナンスを支援し、関連するドキュメントを最新のコードブランチに同期できます。

新能分析

Codex を使ってサービスの性能最適化を試みたところ、権限付与後に自動的に perf で性能分析を実行できるようになった。しかし、十分賢くはなく、頻繁なメモリ申請が効率低下の原因であると分析したが、それがループの回数が多すぎるために発生していることや、コード上の不合理性（ループ内部で大量のオブジェクトを生成・破棄する）を理解できなかった。

プロセス

AIプロジェクトの保守において、人的介入を行い、モジュールや関数に基づいて反復開発を行います。AIが継続的に新機能のメンテナンスを期待することはなく、毎回プロンプトを作成する際には、まるで小さな開発計画を記述しているかのように、どのモジュールに関わるのか、どこで修正するのが最適かを検討します。インターネット上で流布している多くのプロセスは、私のもとでは試されておらず、プロセス自体が比較的伝統的であり、実際に使用しても最も直感的です。