1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • AIで書くことは記事・コード・文書作成において強い誘惑だが、自分で書いて考える能力が落ちているという不安を強める
  • AIが作った成果物は読み返すと「ただAIっぽい」という感じがして、自分の文体や意図をきちんと込められない
  • この1〜2年、コーディングでAIに大きく依存し、ほとんどプロンプトだけを書いてきたため、自分でコードを書く方法を忘れてしまったような喪失感が大きい
  • いま再び手でコーディングする方法を学ぼうとしており、コードを読んで書ける人はAI以後も引き続き必要だと考えている
  • Claudeに文章を貼り付けて確認したくなる衝動そのものが自己不信であり、AIはその不安につけ込む存在として立ち向かうべき対象になっている

AIの使用が文章力とコーディング能力を弱めるという不安

  • AIで書くことは記事、コード、文書作成において非常に魅力的だが、自分で書く力を弱めているという感覚を与える
  • 以前は文章作成やソフトウェア開発で突出してはいなくても一定の能力はあると思っていたが、AIの使用が増えるほど自分のスキルが悪化している感覚が強まっている
  • AIで書いた成果物は読み返すと「ただAIっぽい」という印象を与え、自分の文体や意図に合わず、本当に言いたいことをきちんと表せていない
  • この不安は自己不信とインポスター症候群を強め、実際に自分が成果物を作れるのかどうかまで疑わせる

もう一度、自分の手でコーディングを学ぼうとする理由

  • この1〜2年のあいだコーディングではAIを全面的に使い、ほとんどプロンプトだけを書いていて、自分ではコードを1行も書いていなかったように感じる
  • その結果、コーディングのやり方をほとんど忘れてしまったようで、かつて人生の中心だったコーディングを失ったことが悲しく、憂うつに感じられる
  • いま再び手でコーディングする方法を自分で学び直している
  • AIがあってもソフトウェア開発の能力が完全になくなるわけではないと考えている
    • コードを読んで書ける人はこれからも必要
    • 必要な人数は減るかもしれないが、そういう人材そのものは依然として必要
  • AIが、この20〜30年続いてきたソフトウェア開発者の需要超過の流れを逆転させることもあり得ると期待している
    • Robert Martin(Uncle Bob)の講義で語られるように、コンピューターサイエンスが職業になる前は、物理学者、数学者、研究者のような専門家たちがプログラミングをしていた
    • ソフトウェア開発者への需要が急増する中で、専門性が薄れていったと見ている
  • AIなしで書いた文章なのに、内容がおかしかったり抜けている部分があったりしないか心配になり、Claudeに貼り付けて確認したくなる衝動が湧く
  • そうした衝動そのものが、AIが糧としている自己不信であり、立ち向かって戦うべき対象として残っている

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsのコメント
  • この主張にはあまり共感できない。AIでコードを書くたびに、AIがやったことを全部見直して、自分のコードとして補ったり直したりしなければならないという気持ち悪さとずっと戦うことになる
    数分でバイブコーディングして動くアプリを得るドーパミンはあるが、その気持ち悪さで相殺されるし、しばらく消えそうにもない
    ただ、これは経験があるからこそだと思うし、ジュニアやミッドレベルの開発者だったら自分も十分にハマっていたかもしれない。キャリア初期に知識のあるメンターたちからコードレビューで叩かれてできた傷跡がなければ、その感覚もなかったと思う

    • 私の経験では、Claudeはコードを吐き出すことしか知らないように見える。どんな問題を与えても、「コードを減らす」より「コードを増やす」に翻訳してしまう
      Claudeが作ったものはかなり丁寧にコードレビューしないといけない。そうしないとコードベースが増え続け、技術的負債100%に漸近していく
      Claudeの成果物は全部レビューしているが、90〜95%くらいは「おお、動きはするな。でもコードが多すぎる。ではもう削れなくなるまで3時間かけて一緒に減らそう」となる
    • 「数分でバイブコーディング」はやるべきではない。誰かが思いつきで言った冗談だったのに、業界は冗談として受け取らず、一部は実際の開発手法として成り立つと思っているが、そうではない
      エージェントとのより良い協業方法を見つけるべきだ。人間が見るべき重要な部分はレビューし、残りを「外注」すれば、自分でプログラミングしたときと同じように動くコードや設計により早く到達できる
      私もエージェントが書いたコードの90%くらいはレビューするが、何万字も自分でタイプしてファイル間を行ったり来たりするより、いくつかプロンプトを書いたり話したりするほうがずっと楽しい。単にタイピングに疲れただけかもしれない
    • 完全に同意する。ゲーム開発でAIを補助として使っている。新しいことや面白いことをやるなら自分でコードを書くべきで、そうでないと苦労することになる
      ただし、時間がかかって退屈な雑務は、明確なアーキテクチャを設計したあとでAIに実装を任せる。それでも後で見直して、とんでもないものを作っていないか確認しなければならない
      最近の良い例では、Godotで作っているゲームでCodexが、すでにArea2Dが提供している挙動を一から再実装しようとした
      AIに意味のある仕事をさせると、足元の地雷と奇妙な選択だらけになる。何百ドル分ものトークンを使えば違うのかもしれないが、月10ドルの立場では頭痛の種に見合わない
      しかも私のプロジェクトは趣味で、コーディングはいまだに楽しい。保存/読み込み、データファイルのパース、設定メニューのような退屈な部分だけAIに任せ、人間の判断が必要な部分からは遠ざけている
    • 今は経験が本当に価値を持つ。エージェントをとてもうまく導けるが、言う通りジュニアは心配だ
      自分ならエージェントをもっと深く掘り下げ、より速く学ぶために使っていただろうと思いたい。昔はStack Overflowや複数のIRCチャンネル、Redditなどをつなぎ合わせて解決策を作るのがかなり大変だった
      ただ、大学のとき宿題を写したこともあるし、答えをちゃんと検討していなかったので断言はできない。それでも学位だけが目的ではなく、興味でプログラミングしていたので違ったかもしれない
      いずれにせよ、LLM時代に入る前にすでに多くの経験と失敗を積んでおけたのは幸運だ
    • LLMが作るコードは、私の基準ではただ平均的だ。自分をクリーンコードの権威だとは言わないが、コードがうまく構造化されているかどうかは分かる
      自分で直接書いたコードのほうが、ClaudeやGPTより毎回良い
      以前、すでに書いてあったプロジェクトから仕様を抽出し、LLMにその仕様だけを見せて再実装させてコードを比較したことがあるが、LLM版はひどいものだった
  • 開発者としては、これはある種の雇用安定のようにも感じる
    LLMをしばらく使ってみてかなり良いし、使うのも気に入っている。アプリをいくつかバイブコーディングしてみたが、アイデアが即座に形になるドーパミンは大きい
    ただ、私の経験では盲信すると必ず痛い目を見る。バイブコーディングしたプロジェクトでも、頼んでもいない「機能」を勝手に追加し続ける
    個人プロジェクトなら最終結果が期待通りならあまり気にしないが、企業はそこまで柔軟ではないだろう。顧客も修正やアップデートのたびに機能が変わったり追加されたりするのは好まないはずだ
    現状を要約すると、多くの企業がこの方向に進んでおり、きちんとしたエンジニアリングなしではAIはコードをさらに増やし、アプリを意図せず変えてしまうことがある
    AIへの恐れと採用減少のせいで、市場に入ってくるジュニアエンジニアは減るだろう
    AI利用が臨界点に達すれば膨大な変更が生まれ、それを「プロンプトする」人たちが圧倒され始めるかもしれない
    頭の中に保持しなければならない機能はさらに増えるだろう。LLMを100%信頼できない以上、開発者は依然としてアプリケーションが正確に何をするのか把握していなければならない
    結局はバグが多発し、開発者は追加人員が必要だと不満を言い始める。そうなれば採用がまた始まる
    今いちばん厳しい立場は新規開発者で、いちばん良い立場はすでに市場にいる人たちのように思える

    • 10〜20年前のアウトソーシングブームと似ている点が多い。小さくて安い会社が、アメリカ人開発者1人より安いコストで他国の開発チーム全体を雇えるのを見て、高い期待と低いプロセスのまま飛びついた
      成功させるための準備はほとんどせず、最安の選択肢を盲目的に雇い、曖昧な要件を投げ、継続的な技術レビューや監督もほぼ行わなかった
      流れはあなたの言う通りだった。最初は想像しうる限り最悪に汚いコードでプロトタイプがすぐ立ち上がり、成功に見えたが、時間が経つにつれて技術的負債と悪い判断がどんどん大きな抵抗となって進行が遅くなり、最終的にはプロジェクトが止まるか死んだ
      今回は違うかもしれないが、私の初期の仕事のかなりの部分は、こうしたパターンのプロジェクトを片付けることだった。これからの開発者たちにも同じような機会があるといい
    • 結局バグが多発して、開発者たちが追加人員が必要だと不満を言い出す時点まで自分が持ちこたえられるといいのだが
    • 私もほぼ同じ結論だ。インターンたちに王道のやり方を教えようと本当に必死になっている
    • 分散したカスタムソリューションが爆発的に増え、保守が必要になり、その結果採用が増えるかもしれないという全体的な感覚には同意する。ただ、それを有力な見方として完全に受け入れるには、まだためらわせるものを多く見てきた
      まず効率向上がものすごい。どの価格帯のどのツールより大きい。うちの会社の主力製品はWebアプリで、ここ数年その主力製品のリライトを進めてきた
      ある午後、望むスタックで新しいプロジェクトを作り、数時間で私たちが取り組んできた製品のMVPをバイブコーディングできた
      完璧ではなかったが、機能を一つずつ小さなプロンプトで依頼し、それぞれ5〜10分でできた。かなりプロっぽく見え、どんな基準でも「十分に良かった」
      もう少し時間をかければ、小さな開発チームが数年かけて作ったものを一人でリリースし、保守できたかもしれない。残念ながら、これは効率向上ツールというより安価な「チーム丸ごとの代替」に近い
      さらに非技術系CEOたちのAI過熱もある。うちのCEOと経営陣はClaudeのエージェントツール群を完全に受け入れ、毎日モックアップやアプリやツールチェーンを立ち上げている
      中毒しているのが見て取れるし、利益を直接実感している。まだ起きてはいないが、CEOが開発チームの大半を解雇して、熟練開発者数人と一緒にアプリ全体をバイブコーディングしても驚かないと思う
      今は「AIは代替ではなく倍率器だ!」と言いながら、同じ文の中で「これで今後数年採用しなくて済むなら勝ちだ!」とも言っている
      なぜアプリ全体をバイブコーディングしてはいけないのか、という質問を真正面から受けたが、これといった答えがなかった。「アプリの保守方法が分からなくなる」みたいなもっともらしい考えはあるが、Claudeは開発者1人の手でもかなりのことができる
      「AIがアプリを意図せず変え、バグを入れうる」という話もあるが、適切な可観測性、テスト、追加プロンプトがあれば数分から数時間で直せる
      正直なところ、会社が開発チーム全体を維持し続けることには、もはや意味がないように思える。どれだけ多くのプロジェクトを始め、施策を進めても、バックログは急速に減り、個々の開発者の処理量は馬鹿げたほど増える
      非技術系CEOは、技術的負債、認知的負債、悪いソフトウェア設計慣行、コーディング学習、開発者を賢く保つこと、問題解決の楽しさ、優れたアルゴリズムやアーキテクチャの芸術性には興味がない
      彼らが欲しいのは、そこそこ動き、価値を提供し、お金を払うに値し、できるだけ安い投資で出せる製品だ。不幸なことにAIはほぼあらゆる面でその条件に合っている
      新しく作られるソフトウェアの膨大な量が需要を押し上げてくれることを願うが、AIがもたらす巨大な生産能力の増加を相殺するには足りないのではないかと心配している
  • 来月TypeScriptを学ぶために時間を空けてある。その過程でAIを完全に排除するつもりはない
    計画としては、本を最初から最後まで読んで、そのあとでコードを書く。この方法をどこかのポッドキャストでMitchell Hashimotoが言っていた気がする
    元記事のようにプロンプトコーディングに多くの時間を使ってきたので、楽しみでもあり怖くもある

  • コードを手で書かないからといって、頭が悪くなるなんてありえない。もしそんなことがあるなら、休暇に行くたびに人はもっと馬鹿になるはずだ
    チャットボットと会話したからといって、脳の神経接続が死ぬわけではない
    実際に起きているのは、高度に技術的な能力を少し休ませているだけだ。地球上の誰であっても、しばらく使わなければその技術の一部を「忘れる」
    だが情報が消えたのではなく、より関連性の高い情報に押し出されて優先順位が下がっただけだ。少し復習すれば戻ってくる
    AI以前でも、複数の言語のどれかで完全なプログラムを書く間隔が何か月も空くことがあった。関数定義をどう始めるかのような単純なことすら忘れていた
    だが本当に忘れたわけではなく、既存の関数を一つ少し見れば、関数定義で使える別の構文も全部思い出せた。慌てる必要はないし、脳は正常に動いている

  • 学校ではAIの危険性がよく語られるが、同じ危険はどんな学習環境にも当てはまる
    最近新しい職場を始めたが、AIのせいでオンボーディングがずっと難しくなっている。AIをあまり使わない同僚より、役割への適応がずっと遅い
    慣れていない言語でコーディングしているので、バイブコーディングの誘惑がより強い。それでもClaudeがばかげた答えや不必要に冗長な答えを返していると気づける程度の実力はある
    しかしClaudeにコードを書かせる時間が増えるほど、この職務が求める能力を自分が育てているという感覚は薄れる。PRを上げるときも、自分の作業に必要な自信がなくて気分がよくない
    正直もう一つあるのは、人に聞くべき質問をClaudeにSlackやドキュメントから探させていることだ
    AIが私の社会不安を養い、理解のためにも基本的な社会的相互作用のためにも必要な人との接触を避けるよう誘惑してくる
    これは責任逃れのように聞こえるかもしれないが、ある技術が特定のタイプの人にとって特に中毒性が高く、否定的な行動ループに閉じ込めうるという点は指摘しておくべきだ
    今AI依存を先送りできれば、後で能力を伸ばして、結果の検証が容易で反復的な作業をAIに委任できる程度にはなれると思う。難しいが必要だ

    • Claudeには、必要なことを教えてくれと頼む方向を勧める。この文字列を大文字にするには? この問題にはどうアプローチするのがよいか? この作業には標準的なやり方があるか? といったふうに聞けばいい
      そうすればその過程で学べる。検索エンジンのように使う必要はなく、その場で知る必要があることを聞けば、トークンの連鎖を揺らして、とくに言語初心者に役立つ何かを返してくれる
      こうすれば、まず実力をつけて後で委任を始めるという計画を実行できる
      私はずっとそうしてきたし、自分には良いバランスだ。評価できないコードをClaudeに書かせるのは狂気の沙汰に見えるが、この考えは少数派らしい
    • 今は徒弟制的な教育、つまりインターンシップには最悪の時期だ。みんながAIで速く良く出せることを期待する一方で、速い反復の中では技術を身につける時間がほとんどない
    • LLMはコードベースを要約して素早く把握するのにかなり有用だった
      実質的に、バイブコーディング以外で私が体験した数少ない本物のユースケースの一つだ
  • AIを思考の代替としてではなく、反復的で退屈なコード記述から逃れるために使っている。プロトタイプが実装された後なら、AIはコードを書くのに十分有能だ
    私は初期の概念実証用の粗いプロトタイプを自分で書く。コメントなしで、変数をハードコードするようなものだ。その後AIがそれを製品レベルへと磨き上げる
    そのおかげで、仕事倫理、実力、高いコード品質を維持する能力がばらばらな人間たちを管理する代わりに、エージェントチームを指揮できる
    AIはコードベースの既存パターンを維持したり、業界のベストプラクティスに合わせたりするのも、かなり得意なことが多い
    AIを使うと、もはやプログラミング言語でそれほど多くは書かなくなる。英語であれLLMと対話する言語であれ、それが主たる言語になるだろう

    • 「プロトタイプが実装された後なら、AIはコードを書くのに完璧に有能だ」って、完璧に? どう考えても完璧とは程遠い
      最近の私の一日の大半は、コード生成ロボットが作った不完全さを直すことに費やされている
      もちろん私はプロトタイプを磨いているのではなく、8年以上運用されている重要製品を保守し、進化させ、モダナイズしている最中ではあるが
    • 反復的で退屈なコードって、いったい何のことだ?
      どんなプロジェクトで、そんな退屈な反復コードが正直どれほどあるというんだ?
    • 大半の時間は、LLMが作業計画とプロトタイプの輪郭を作るのに使っている。そうしないと全体がひどい混沌になる
      緻密に作ったプロンプトが必要なので、土台となるフレームワークと言語をきちんと理解していなければならない。そうでないと全体がひどい混沌になる
      複数エージェントをどう扱えばいいのかも分からない。普通はかなり早く終わるからだ。実行の合間に何かすることもできない。「あと1分あれば終わる」がずっと続く
      終わったら出力を評価しなければならない。だから「作業中」に深い思考もできない。パターンがソーシャルメディアに似ている。継続的な注意と、ほぼ即時の報酬だ
      結局、注意持続時間はどんどん壊れていき、本当に壊れる
      問題は、こうした計画が数時間で消え、その後は出力を分析して反復しながら、馬鹿げた部分をふるい落とさなければならないことだ
      複数エージェントの出力を扱うのは、終わりのないコンテキストスイッチだ。長期的にうまくいくことを願う
      エージェントを好き放題に走らせて何でも作らせれば、出力はほぼ確実にひどい混沌になる。それで終わりだ
  • 現在のプロジェクトでは毎日Java、Ruby、JavaScriptでコーディングしている。以前なら簡単なGoogle検索で済んだ言語差の確認のために、多くのトークンを浪費している
    RubyとJavaScriptのnull-safe演算子の違いとか、RubyとJavaのcontinue/break文とかをしょっちゅう混同する
    Claudeには、私が最も複雑にやらせる仕事が、古いJavaのループをより現代的なストリームへリファクタリングする程度なので、かなりがっかりされそうだ。そういうコードは人間が即興で書くのはほぼ不可能なこともある

    • 「人間にはほぼ不可能」って、残念だな。そういうリファクタリングは範囲が狭く、正確性の検証もしやすく、小さなパズルみたいで、私がいちばん好きな作業だ
      自前のcollectorを作ったり、標準ライブラリのやや obscure な部分を使ったりすればボーナスポイントだ
    • Googleが壊れたのも助けにならない。以前なら単純なGoogle検索で済んだものが、今ではどうせAIが割り込んでくる劣化した組み込み体験になってしまった
  • 反対の事例もある。/plan モードでAIとアイデアをやり取りし、自分がAIの誤った前提を見抜き、必要なときにはAIが知識の空白を明確に説明してくれる過程は、知的にかなり刺激的で、自分をより良いエンジニアにしている気がする
    要点は、AIにソクラテス式で向き合い、AIの提案をすべて慎重に考え、自信満々の口調と完璧に構造化された論理に催眠をかけられないことだ

  • 私は正反対の経験をしている。たぶん自分の分野では、コード/ソフトウェアが製品ではなく道具だからだろう
    はるかに速く、そして多くを学んでいる。たとえば今、ラマンやNMRのような分光学ハードウェアを扱っていて、Claudeに機器やハードウェアレベルでインターフェースするコードを書かせた
    自分でデータシートを漁ってラッパーコードを大量に書く代わりに、Claudeがやってくれた
    Claudeといろいろな手法を議論し、実装し、テストする形で、ずっと速く進められる。以前ならこのループは5〜10倍は長くかかっていたはずだ
    結果を見るためだけの些細なコードを書くことに精神的な努力を使わなくて済むので、この機器や手法やデータについてずっと多くを学べている
    開発者として10年以上働いてきた。ようやく、コードを延々と製品として作ることばかり考えるのではなく、道具として活用できる世界に向かっている気がして嬉しい

    • コードが製品ではなく道具だというのは、単にあなたの話かもしれない。道具としてのコードは昔からずっと存在してきた
  • 手でコードを書く時間を持てる特権を享受できる人は多くない気がする
    実際、私たちが書くコードを見ると、少なくとも自分の場合、その大半は新しかったり格好良かったりするものではなく、いつもの「Xのためのバックエンド作成」、簡単なバグ修正、ミッド〜シニアプログラマーにとっては些細な作業だ
    より難しい作業はたいていコードの上位にあるアーキテクチャ判断であり、LLMが機能実装で脱線しないようにするシステムをどう作れるかも考えている
    言いたいのは、今は手でコードを書くのが許されるかもしれないが、これからは株主や上層部がLLMの助けで機能リリースやバグ修正をより速く行うことを望むだろうということだ
    その速度を出せなければ、成果が低いと見なされる。結局重要なのは、私たちが望むことではなく株主が望むこと
    もちろん疲れないなら余暇に手でコードを書くことはできる。悲観論者みたいに聞こえたくはないが、かなり近いうちに現実になると思う

    • そもそも速度の問題ではなかった。速い進歩は同じ原始的な要素をより速く書くことからではなく、より良いシステムを設計し、堅牢な抽象化を作ることから主にもたらされる
    • 誰にでも手でコードを書く時間はある。AIが実際の生産性向上を生み出していないからだ