コードを書くことは、本来理解、推論、そして取捨のプロセスであるべきです。コピー - ペーストは「動く」と教えてくれますが、「なぜそうなるのか」は教えてくれません。
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