コードを書くことは、本来理解、推論、そして選択のプロセスであるべきです。コピー - ペーストは「動く」と教えてくれますが、「なぜ」を教えてくれません。
GPT のようなコード生成ツールが登場してからの数年間、私たちに与えた影響は非常に大きく、私たちのあらゆる面、さらには周囲の人々にも影響を与えています。
あなたは気づきましたか ——
以前は GPT を使って何かを学ぶことができたのは、最初の頃だけでした。
私たちはほぼ問題解決と学びの姿勢で使っていました。
その思考を見て、わからないことがあれば質問していました。
今はどうですか？みんなそれに依存して、コピー＆ペーストしています。
さらに、いわゆる Coding Vibe や Coding Agent もあります。
見ず、変えず、テストせず、
動けば使えるということで、結果的に 3 ヶ月後には自分が何を書いたのか、プロジェクトの全体構造や各部分のパッケージの参照もわからなくなっています。
デバッグ中は頭の中に小さな疑問符が浮かんでいます：
「これは誰が書いたコード？」
「おお、GPT だ」
コード作業を全て GPT に任せることには非常に反対です#
コードを書くことが答えをコピーするプロセスになり、あなたはもう考えなくなります。
要件理解？コード設計？プロジェクトの保守性？これらは全て飛ばしてしまいました。
見た目は効率的に見えますが、実際にはあなたはプログラマーとしての最も基本的な判断力と成長の余地を失い続けています。
コードを書くことは、単に書くだけでなく、学ぶことでもあります。
バグは減らず、むしろ調整が難しくなる#
あなたが貼り付けたプロジェクトコードは、実際にはテストを通過していない可能性があります。
GPT はなぜあなたに境界条件を考慮させる必要があるのか、なぜあなたのプロジェクトの文脈を気にする必要があるのか。
彼らはただプロジェクトを完成させ、コードを正しく書けばいいのです。
見た目は「わあ、機能が実現した！」ですが、実際には中にたくさんの罠があり、たとえそれがトリガーされても、デバッグがさらに難しくなります。
なぜなら、それはあなたが書いたものではなく、あなたは全く理解していないからです。
エラーが発生した後、どこに問題があったのか全くわからず、ただ GPT に戻って質問するしかありません。
彼に自分が生成したコードを修正させるのです。
書けば書くほど、コードの質やスタイルがますます不明瞭になる#
今日、あなたは非同期を貼り付け、明日は古いコールバックを貼り付け、明後日は奇妙でより抽象的なものを作ります。
プロジェクトはパズルのように見え、メンテナはコードを情熱的にデバッグフリースタイルで行っています。
各コードは実行可能ですが、誰もメンテナンスをしたくありません。
プロジェクトを LLM に外注し、自分を騙す#
私は今でも理解できません、多くの人がそこにいて答えています。
「私たちの何か Coding AI ツールに新機能が追加されました！」
以前は「直接 GPT のコードを貼るのは害だ」と言われたとき、誰かが反論しました。
私たちは維新派です、Cursor、Trae、通義、Copilot Chat…… プロジェクト全自動化、デバッグ自動化です。
バグを一発で特定できると言っていますが、真実はツールがあなたのエラーログを持って、あなたの異常源を推測し続けることです。
見た目は良さそうで、役に立つかもしれないパッチを提供しますが、結果として A を修正すると B が壊れます。
自動リファクタリングは魔法ではありません#
いわゆるリファクタリングは、Find-&-Replace です。
彼らはこのプロジェクトの完全なテストプロセスがどうなっているのか、何が暗黙の合意であるのかを理解していません。古いコードに統合すると、しばしば多くのリスクを残します。
新しい人に優しいように見えますが、学習コストを完全に遮断しています。
低いハードルでの使用は、新人が数回クリックするだけで「バグを修正」しますが、その原因を理解することはできません。
次回同じ問題に直面したとき、彼らはただツールに頼って火を消すことになります。
時間の節約は表面的で、実際のコストは高い#
確かに、現状では時間を節約できる場合もありますが、今後はどうでしょうか。
あなたはそれの Diff を読み、プライベートな回帰を実行し、新しい穴を修正するために時間を費やさなければなりません。
最終的には、総時間がしばしば新しい人のデバッグよりも長くなります。
ツールに依存することは問題を解決することではありません#
今、多くの人が「Cursor を使えばいいじゃないか」と言っています。
これは概念のすり替えであり、問題を解決するのではなく、依存をコードを書くことからデバッグに拡張して、量が超倍増しています。
これらのツールは純粋に錯覚を生み出し、一部の新しい人々は「Cursor さえあれば、デバッグを理解する必要はなく、コードを理解する必要もなく、エンジニアになれる」と思い込ませます。
オンラインになり、事故が発生したとき、新人のあなたはどうしますか？まだ Cursor を使い続けますか？
短期的には進捗が非常に早いですが、長期的なメンテナンスは地獄のようです。
あの混乱したプロジェクト構造やインターフェースの参照（完全に同じインターフェースを繰り返し作成できることさえあります）
これらのコードは、あなたの会社のチームワークでも、オープンソースコミュニティでも、
引き継ぐ人はまるでチーシーのようです。
この一連のコードを見て、あなたはまずどれが人間が書いたもので、どれが AI の「調味料」なのかを理解しなければなりません。
それから一つ一つ戻したりリファクタリングしたりします。
要するに、もともと「CPDD（Copy-Paste Driven Development）」の傷口に、さらにそのいわゆる「自動デバッグの絆創膏」を塗り、コードの遺伝子をより早く、誰も触れられないように変異させています。
新人：単に「書けない」だけだったのが、今では「間違いを見つけられない」ことも一緒にパッケージ化されています。
ワンクリック生成 + ワンクリック修正 = 「自動巡航で崖に向かう」
新人は生成 - 貼り付け - 自動修正し、一回のラウンドで通過したと思い込んでいますが、デバッグ思考は全く形成されていません：ブレークポイントを設定し、スタックを見て、仮説を検証する……
プロジェクトが大きくなるにつれて、後半になるほど救いがなくなります。
最終的な選択：自分を信じ、主体性を持つ#
私は考える必要もありません。この長い愚痴を読み、繰り返される意見を見て、「理にかなっている」と口にしながらも、機能を書くときには、やはりためらうことなく GPT や LLM を開き、貼り付け、修正を続けます。
全く新しい「魔法のコード」を貼り付けます。
私は自分自身も使っていますが、盲目的に排外して新しい技術を享受しないのは純粋に愚かです。
しかし、理解して使うことと、無感覚で使うことは、最終的な結果が異なります。
あなたは質問することができ、参考にすることができ、さらにはテストを手伝わせたり、ドキュメントを補完させたりすることもできます。
しかし、プロジェクト内のコードは、最終的にはあなた自身の理解力に対して責任を持つべきであり、GPT の出力能力に対してではありません。
最後に：GPT はあなたではなく、あなた一人のためにサービスを提供するわけではありません。
良いコードを書くべき人は、あなた自身です。
ツールに考えさせないでください。そうしないと、問題を解決する能力を徐々に失ってしまいます。
自分を信じ、主体性を持ってください。
この記事は Mix Space によって xLog に同期更新されています。
元のリンクは https://ling.crashvibe.cn/posts/think/thinking-about-coding-and-the-impact-of-gpt