仕事用のコードはAIエージェントに任せて、できるだけループを長く回せるように全部任せてしまっていて
趣味の個人プロジェクトはAIアシスタントやAI自動補完も使わず、自分で開発しています (...)

VSCode の AI 機能をオフにして Claude Code を使っていますが、確かに快適です。

AI のために vim を捨てて vscode に乗り換えたのですが、
開発するときの喜びを失ってしまった感じがして、vim に戻りました。
AI はアシスタントとして使っていますが、確かに開発の喜びを取り戻せた気がします。

難しく書いてありますが、結局言いたいことは人間にも当てはまる内容ですよね。
愚かなAが書いた文章を愚かなAがもう一度見たからといって、より良い文章になるのかという問題ですよ。

もちろん少数のケースでは良くなる余地もあるし、全問題を当てずっぽうで解いて大学入学共通テストで満点を取る確率もありますが、ほとんどの場合は愚かなAのN回の平均レベルへ回帰するだけでしょう。

（Chapter 2には完全には同意できませんね。）

ただ、論文で言っているように what-ever Scaling Law は一時的な増加法則であって、永遠に続くものではないことをもう少し分かってほしいです。
OpenAI の論文をきちんと読んでいたら、こんなことを言うはずもないでしょうが。

実際、ああいう論文100本より、単に「できる」と主張する人がそうであることを証明すれば済む話でしょう。

「できる」という錬金術ばかりやっているから問題なんですよ。

個人的には、自分の専門分野ではAIがひどく頼りないということを痛感しています。おそらく他分野の専門家も同じだろうと想像しています。もちろん大きな助けにはなります。とはいえ、一日中こまごまとした文書を書かされることにはなりますが、以前の生産性とは決して比べものになりません。

アテンションは多数決で形成されます。
検証エージェントは評価関数さえ通過すれば十分です。
優れた産業用コードの大半は公開されていません。
オープンソースは見せるためのコードです。

この点を常に念頭に置いて使うべきです。

QwenチームのいないQwenチームが市場の不安を管理しようとして、ベンチマークにだけ合わせて性急に出したモデルだというのが、うちの研究所の実験結果です。ツールへの強迫観念が強すぎます。3.5に比べて退化だと見ています。

短いサイクルでのリリース以外に、アジャイルに何が残っているのか分からない。
バックログやスプリントも別の形でそれ以前からすでに存在していたし、顧客とのコミュニケーションも現実に合わない部分が多い。結局、アジャイルよりもDevOpsの改善のほうが、開発の向上にはるかに大きく寄与したと思う。

SWを書くうえで問題になるのは抽象性というより曖昧さです。自然言語は本質的に曖昧です。多義的でもあります。 だから自然言語でコーディングしようとする試みがうまくいかないのではないかと思います。

こうした状況で、自然言語がコードを置き換えるなど到底ありえません。

こうした内容は、過去の作業方式への執着に見える。どうせそうした部分はAIの方がよりうまくやるようになるだろう。今重要なのは、AIを使いながら、うまくいかない部分を改善した経験だ。とはいえ、これもまた一時的なものだと思う。

人それぞれだとは思いますが、コンピュータ関連の学習はおっしゃるような方法で進めることが多いのではないでしょうか。最近は動画で学ぶという選択肢もありますし、自分に合った学習方法でやるべきでしょう。

では、純粋関数型プログラミング言語はどのように学習されましたか？ 私はこれまでプログラミング言語（C、Go、Python など）を技術書＋サイドプロジェクトで学習してきたのですが、関数型プログラミング言語もこのような学習方針で進めて問題ないでしょうか？

AIは、電動ドリルやチェーンソー、掘削機を使っているような感覚です。携帯電話を使うようになってから、自分の電話番号すら覚えられない人も多いです。

……こうしたものを衰退と見ることもできますが、私は効率だと捉えています。開発者やさまざまな職種を経験してきた立場から見ると、AIツールは、開発者だけの世界を離れてより広い視点を持つ機会や助けにもなる道具だと思います。ある部分では衰えるかもしれませんが、その領域は別のもので埋められます。

私の経験や多くの人の結論では、関数型言語は純粋関数型言語で学ぶべきだ、というのが定石でした。
関数型言語が注目され始めた当時や、大きな関心を集めていた時期に語られていた話で、私も共感していました。私は Erlang が出た初期にそれで学びましたが、当時はかなり衝撃的で驚くような体験でした。

Clojureが登場してからかなり長い年月が経っていますが、ここにきてまたClojureの話題が出てくるのはなぜなのか、気になります。
Clojureが出た初期に、ある本をレビューしたことがあります。その後、それを使おうと試みた企業をいくつか見ましたが、企業で使うには簡単ではない、というのが結論でした。そしてこのまま埋もれていくのかと思っていましたが、また話題になる理由は何なのだろうと思います。

私はJavaを初期から長年使ってきましたが、JVMはいまでも、大企業ですでに開発された多くのソフトウェアがJavaであること、（アメリカの場合）インド系の人材の多くがJavaを扱うこと、高校から大学までJavaを教えていることなどの理由で、依然として広く使われています。ただ、私見では今の時代にはもはや合っていないと思います。Lispは好きですが、かなりマイナーな言語であり、しかも衰えつつあるJVM方式が、いまのAI時代に再び取り上げられるにあたって、どの点が利点として再評価されているのか、上の記事からは見いだせませんでした。

広告やマーケティングはインターネット以前からそういうものでしたが、今では人々が目にするものが変わり、規制もできなくなってきたため、詐欺に近い手法が氾濫しています。

関数型プログラミング言語をきちんと学んだことがないので、Clojureから始めてみようかと思っているのですが、どのように学習していけばよいでしょうか？ 開発者の皆さんのアドバイスをぜひお願いします。

Unslothの創業者Daniel Hanは本当に天才だと思います。オープンウェイトモデルが出るたびに、モデル構造からトークナイジングのバグ、量子化エラー、テンプレートのエラーまで分析して共有してくれるので、本当に感嘆します。

「コーディング能力のかなりの部分は手続き記憶」という言葉がとても響きますね
数学の問題を解くのも、手順を記憶して同じ結果を出せるように練習する行為ですし、
AIでコーディングするのも構いませんが、同等以上の成果物を繰り返し生み出せるように、脳に負荷をかける必要がある気がします。

「もしそのスーツがなければ何者でもないのなら、それを持つべきではない。」 - トニー・スターク

少なくともAIに指示するときは、短く二言三言投げるのではなく、できるだけ具体的に自分の考えや論理の展開を解きほぐして伝え、その後、作業を進める前にさらに確認すべきことがあれば必ず質問してから進めるようにするのが役に立つようです。