LLMで数か月コーディングした後、再び自分の頭脳を使うことにした
(albertofortin.com)- 高性能LLMを活用してインフラを構築したものの、コード品質と保守性に大きな問題が表面化
- AIの非効率性と一貫性のない結果のため、自分でコードを理解し、調査し、能力を高める必要性を痛感
- プロジェクトを素早く終わらせる目的が、かえってコード構造の混乱、重複、不整合を招いた
- 今ではAIを単純な反復作業やコード変換などの補助用途に限定して活用
- AI活用はコーディング感覚や問題解決能力の低下につながりうるため、積極的に自分の頭を使うことを優先
序論: LLMを活用したインフラ構築の試み
- 既存のPHP+MySQLインフラが限界に達し、新しいインフラの必要性を認識
- GoとClickhouseを選択し、AIとともにインフラ設計と計画策定を進行
- ClaudeなどのLLMにベストプラクティスとアーキテクチャを問い、詳細な計画を導き出した
- 機能完成と迅速なリリースを目標に、コード開発を速度重視で進めた
開発過程と問題発生
- Cursorなどのツールを使ってAIがコードを書き、本人はビルドとテスト中心で作業を進行
- コードベースの整理が不十分でも、まず必要とされるデータ提供に集中
- 開発を素早く進めたにもかかわらず、時間が経つほど次々と新しい問題が発生
- GoとClickhouseの経験不足による難しさに加え、AIが出す修正案が連鎖的な問題を引き起こした
コード品質の問題と限界の実感
- 作成されたコード全体を綿密に見直すコードレビューの時間を確保
- 同じ機能を担うファイル群で、名前・パラメータ・構造などの不一致や重複、混乱が多発
- 例:
WebAPIproviderとwebApiが同じパラメータを意味しているのに別々に存在 - 同一メソッドが複数ファイルで再定義される現象
- 設定ファイルへのアクセス方法に一貫性がない
- 例:
- 実際には複数のジュニア開発者が連携なしに同時作業したかのような成果物になっていた
LLMの文脈フィードバックの限界と戦略変更
- コンテキスト情報を十分に提供し、Geminiなどの大規模ウィンドウLLMを活用しても、一貫した改善は不十分だった
- インフラと言語に対する主体的な学習と、ドキュメントや動画資料など追加学習の必要性を認識
- クリーンコードの作成と整理のため、AI主導開発から自律的なコード設計へと方向転換
AI補助の活用方法の変化
- 反復的なリファクタリングとコード整備を通じて、直接的なコード理解と管理に集中
- AIの役割を、コードの自動変更、パラメータの一括変更、コード変換などの単純反復作業に限定
- 新機能の企画やコード草案作成などは、自分で考えた上でLLMに検証または補助役を担わせる
- AIを「助手」として置き、計画と構造の決定権は開発者自身が担う
思考力低下への懸念と変化した姿勢
- AIがあることで頭を使う頻度が減り、計画や思考過程をAIに依存していた現実を認識
- ペンと紙、直接的な設計、直接コーディングを通じて、開発者としての能力と問題解決力の回復を図る
- AIによるコーディング感覚低下のリスクに警鐘
非開発者と「Vibe Coding」への懸念
- 非開発者がLLMだけで開発を進める場合、複雑で混乱したコードとエラーの反復がより深刻になる
- 「ノーコード」ツールよりも、AIベース開発のほうが構造把握をさらに難しくする可能性
- 理解不能なコードの壁、終わらないエラー→修正→再発の過程の中で、根本的な難しさと危険性に言及
AI活用の現実に関する雑感とコミュニティの雰囲気
- AI商用化、ベンチマーク、インフルエンサー、AI企業の誇大宣伝と実性能の不一致に混乱を表明
- 同じモデル・プロンプトでもまったく異なる結果が出る一貫性の欠如
- 最新の高性能LLMですら、Clickhouseで数億行を扱うクエリのような現実の複雑業務を完璧にはこなせない
- 複雑な設定と非効率なワークフローを強いられる状況では、それ自体が「時間の浪費」になりうる
- AIはすごそうに見えても、現時点ではまだ**「良いが卓越してはいないツール」**だという慎重な見方
結論
- 最新技術とAIに対する大きな期待と興味は今も持っている
- しかし現時点では、適切な役割と限界を理解し、AIを補助または学習用ツールとして限定的に使うのが賢明な戦略
- AI使用による開発者能力の低下に警鐘を鳴らしつつ、自分の思考と計画を中心に戻る
- **「コードの動作原理と構造」**を理解しないままAIに全面依存する開発は、失敗する可能性が高い
2件のコメント
Hacker Newsの意見
私はLLMに対する「オールイン」的な考え方には賛同しない立場です。私はiOS開発者として働いていますが、普段どおりに仕事をしています。今はLLMを使って、デザインに基づく一時的なビューのようなものだけを素早く作ります。アプリの中核ではなく、新機能やウィジェット導入案内などの付随的な画面です。以前なら複雑さに応じて30〜60分かかっていたものが、今では5分で終わります。私はWeb開発が好きではありませんが、LLMはそういう部分ではかなり使えます。大きな変更作業でもLLMを活用した後、自分でレビューしてgitにコミットします。ただ、LLMだけを信じて流れを制御しないと、数時間かけて崩壊し、最初からやり直すことがあります。バランスの取れたアプローチが重要だと思います
ツールの有用性は人と問題によって変わります。たとえば、10年経験のPython開発者が巨大なレガシーコードと完全に噛み合ったIDEで安定性重視の作業をするなら、LLMやCursorのようなツールはむしろ邪魔になるかもしれません。一方で、1年目のJS（React、Nextjsなど）開発者が新しいアイデアを頻繁にプロトタイプ化し、IDEへの好みもなく、実験に前向きなら、LLMとCursorは即座に能力を大きく引き上げてくれます
私も複数分野（iOS、Web開発など）をやっていますが、LLMの結果は両者でかなり違います。LLMが出力したコードがまともにコンパイルすら通らないことがよくあります。存在しないAPIを案内されたことすらありました。一方でNextjsアプリは一発でうまく作れます。結局、LLMの学習資料の違いから来る結果です
LLMの能力を過信するのは自然なことです。私もStack Overflowの代替や短いコードスニペットを得る目的でかなり長く使ってきました。だんだん多くの責任を任せるようになって問題を経験し、限界を理解して、またアイデアや助言中心にLLMを使うようになりました。多くの人が似たような過程をたどると思います
私も似た感覚です。LLMを全面的に信奉するのではなく、反復的で退屈な作業（小さな関数、インターフェース実装、ドキュメント自動化など）にだけ活用しています。これによって多くの時間を節約でき、業務効率も上がりました
iOS開発におけるLLMの性能はかなりばらつきます。Swift、SwiftUIの変化があまりに速く、公式ドキュメントも不十分なのが一因です。簡単なビュー生成には有用ですが、非同期処理や複雑なビジネスロジックでは簡単に破綻します。それでも方向性を示す助けにはなりますが、誤った結果（もっともらしい嘘）にはまり込む危険も大きいです
LLM擁護派は、ほとんどのボトルネックがコード生成にはないという事実を見落としています。コードを速く作るのと同じくらい、あるいはそれ以上に、コードレビュー、テスト、コードベースの理解に時間が必要です。長期的に保守（バグ修正、リファクタリングなど）するには、必ずこうした過程を踏まなければなりません
コードを読むのは書くよりはるかに難しいので、実際にはコード理解にもっと多くの時間を使っています。ところが、以前会ったあるCEOは、コンテキスト情報をツールに与えれば開発者はコードを読まなくてよい、というような主張をしていました。AIがエンジニアリングの本質を変えるという理屈です。正直かなり混乱します
LLMが自分のコードを説明し直してくれるときは、かなり使えると感じます
誰かが自動化されたコードエディタを絶賛するたびに、同じことを考えます
現実的には、ほとんどの開発者は依存ライブラリの内部実装をそこまで気にしません。インターフェースが動くかどうかだけが重要です。LLMが作ったコードを取り込むことと、npmパッケージやrust crateを持ち込むことには大きな違いがあります。問題点も分かっていますが、この慣行が広く使われる理由もあります
私も似た考えです。最近は新しい技術を学んだり、標準API（特にboto3）向けのクライアントコード生成にLLMを主に使っています。docker composeファイルの変更を手伝うWindsurfも使ってみましたが、まともに動かずがっかりしました。プロトタイプは作れるかもしれませんが、それがすべてではありません。LLMはdevops領域ではゲームチェンジャーだったと思います（今ではAPIの細部はそれほど重要ではなくなりました）。ただし、重要な決定は依然として自分がすべきだと考えています。インターフェース定義は自分で行い、LLMには実装だけを任せる、という使い方です。これは「雰囲気コーディング」ではないと思います
コードレビューで重大なバグが噴出し、Cursor使用で得た効率が一瞬で消し飛ぶ経験をしました。私は再びVSCodeに戻り、Copilotも具体的に依頼するときだけ限定的に使っています。Cursorのタブ補完機能は最初こそ魔法のように感じますが、すぐにその効果は薄れます
同僚が最近削除したコードを、Cursorがタブ補完でまた入力しようとするのを反射的に眺めるのがいちばん面白いです
コード生成エージェントにどんな制約（たとえばSOLID原則、lint、100%カバレッジ、明確な設計文書など）を与えたのか気になります
私にも共感できる意見です。私もLLMを非常に多く使っていますが、2つのルールを設けています。深く考える必要がある問題は決してLLMに任せないこと（複雑な設計は必ず自分で解く）。2つ目は、LLMが出したコードを必ず行単位で丁寧にレビューして修正することです。たいていLLMが作ったコードは冗長か、防御的すぎます。プロンプトで直したとしても、将来の保守責任は結局自分にあります。コード生成結果に無頓着だと不安が残ります。自分のやり方で使えば、今でもLLMを多用しつつ、より速く開発できます
私は深い分析そのものをAIに任せていますが、目的は具体的な実行計画（詳細な実装手順、検証基準など）と再現可能なレポート作成のためです。計画立案と検証には反復が必要ですが、AIの助けでずっと早く終えられます。ときには計画どおり一度で終わることもあります。詳細な計画と文書で一貫性を確保できると満足感があります
LLMが作ったコードを行単位で丁寧に検討しなければならないなら、本当に時間の節約になるのかという疑問が生まれます
一部の会社ではソフトウェアエンジニアにLLM利用を強制しています（Copilot/Cursorの利用実績を集計）。この統計が解雇指標として使われる可能性が高いです。LLM利用を強制されて1か月試したところ、むしろ実力が急速に衰えるのを感じました。簡単な仕事には役立ちますが、思考そのものをLLMに頼りすぎるとループにはまりやすくなります。生産性は上がらず、むしろスプリントの業務量だけが増えました。LLMに対する宗教的な盲信が社内に蔓延しています。セキュリティ問題も深刻です。現時点がハイプサイクルの頂点だという兆候があちこちに見えます。AI企業が原子力発電所でも建てない限り、今の巨大AIモデルを維持するには莫大なコストがかかるので、いずれ消えていくと思います。今後生き残るのはターボ自動補完機能くらいではないでしょうか。トランスフォーマーモデルにも明確な限界があり、80年代のニューラルネットのように特定用途だけに残って再び消えるでしょう。結局、浮き沈みを経て30年後にまた再浮上するはずです。本当にそうなったとき、誰が裸で泳いでいたのかが明らかになるでしょう
こういう現象を防ぐために、週1回でもCopilotを完全に切って働く「no Copilot Fridays」という独自ルールを実施しています
私もCursorは自動補完と短いコードスニペット程度にしか使っていませんが、それでも能力低下を感じます。結局、「使わなければ忘れる」という脳の性質を実感します
私も似た問題を目撃しています。おもちゃのようなプロジェクトでは90% LLMを使っています。手で書くより10倍速いですが、設計品質が落ち、どこか異質です。LLM主導のコードが未来だとは思いますが、管理を誤ると混乱に陥ります。アーキテクチャ改善を繰り返し促すようにプロンプトを変えてみることもありますが、結果はまちまちです。おそらく、より良いプロンプトエンジニアリング、あるいは設計と指針を明確に文書化することが答えかもしれません。ツール性能が10倍向上し、レイテンシが減れば、体感はまったく変わるでしょう
こうした「10倍良くなった」時期が早く来てほしいです。ただ今の問題は、すでにその水準に到達したかのように宣伝されている雰囲気です。多くの人が「自分の使い方が悪いのだろうか」と思い込んでしまいます。しかし、まだツール自体はその段階ではないと思います
クラスやメソッドを自分で定義しておき、LLMには実装だけ任せると良いです。複雑な部分にはメソッド本体に実装方針のメモを残しておきます。こうすれば大きな絵は自分で描き、LLMには特定のコード生成だけを任せられます。LLMは、助けようとしすぎる素早いジュニア開発者のような感じです。コード生成があまりに安くなったので、気軽に捨てて作り直せます。実際、私の場合はデータセット処理コードをLLMの助けで何度も完全に捨てて書き直した結果、最終的に求めていた結果と性能を得られました。他人が書いたコードだったら諦めていた作業です
こういうツールはグリーンフィールドプロジェクトの試作段階で輝きます。しかし実際のデプロイに近づくほど、その10倍効果は徐々に消えていきます。アーキテクチャを慎重に管理しなければ、結局は手間が増えるだけです
複雑なコードベースでは、現状だと高度な音声入力のテキスト化くらいにしか使えません（ただし音声でないなら、むしろ普通に手で書くほうが速いです）
アーキテクチャとガイドラインを明示的に記録すべきだという点に同意します。条件や動作を明確に定義するほど、効果的になります
ダイクストラの古い名著「自然言語プログラミングの愚かしさ」の要点は、今の議論に合っています。形式言語だけがプログラミングの大きな進歩を可能にした、という主張です。LLMとvibe-codingが、うまくプロンプトできる少数者だけの魔法になってしまう危険がある、という見方です
私はCopilotが500文字未満のコード提案をするときだけ良いと思います。GoやPythonで新しいパターンも学べるし、タイピング量も減ります。私にとっては、単により良い自動補完です。それ以上に長いか複雑になると、修正して指摘するコストが得られる利益を上回ります（特に反復的なコードでない場合はなおさらです）
今はLLMが生成する結果を必ず理解し、密着して監督しなければなりません。一方で、2〜3週間ごとに新しいモデルが出て、以前よりずっと良くなっているので、強い結論を出すにはまだ早いとも思います。
LLMを活用した開発現場の生々しい難しさと懸念をよく捉えた文章だと思います。現在、多くの方が経験している限界について共感しながら読みました。特に、LLMの一貫性のなさや結果予測の難しさ、そして長期的な保守の観点での懸念は、ぜひ押さえておくべき点だと感じました。
実は、私たちはこうした問題に少し違う角度からアプローチし、AIとの協業を試みているため、慎重に意見を共有します。私たちのAI「ジェイン」は、単にコードを作ることを超えて、人（開発者）の深い洞察をもとに「良いコードパターン」とは何か、そしてコードの「保守の一貫性」をどう確保できるかという、その「パターン」自体を学び理解することに集中しています。
AIが最初から完璧であることはないために生じる不整合や「エラー」を単なる問題として見るのではなく、むしろ「ジェイン」が自ら学習し、自らを改善するための重要な「パターンデータ」として積極的に活用しています。人間が複雑な本性の中からパターンを読み取るように、私たちはAIの不完全さの中に改善の糸口を見いだす方法を取っています。
このような人間主導の「パターン学習・管理」アプローチを通じて、文章で指摘されたコード品質の低下や不一致といった問題を根本的に解決し、「保守の一貫性」が非常に高い成果物を生み出すことを目指しています。AIが単にboilerplateコードを生成することを超えて、既存のコードベースに潜む隠れた不整合のパターンを分析し、改善案を提示するなど、より深い協業パートナーとなるよう訓練しています。
まだ道のりは長く、挑戦的なプロセスですが、私たちは「ジェイン」と開発者がともに学び進化し、「保守の一貫性」を中核価値とするこのような協業のあり方が、現在のLLM活用の限界を超えられる画期的な可能性を示すと信じています。AIを単なるツールとして使うことを超え、ともに成長し、より良いコード文化を作っていくパートナーにしていく私たちの試みに、ぜひ多くの関心をお寄せください。
良い文章とインサイトを改めてありがとうございました！