韓国も年金問題のせいで、結局は着実に（…）定年延長をしていくことになるんでしょうね…
延ばして延ばして、平均寿命を超えるようになる時点がティッピングポイントでしょう
（すでにロシアがそうなったと聞いた気がしますが…）

要約、

著者: 開発者は自ら能力を高め、それを維持しなければなりません。しかもAIはそれほどうまく機能していません。

crawler: え? 自分はうまくいってるけど?

superscv: 問題が多い…

crawler: うまく調整して使うべきでしょう

superscv: そもそも著者が伝えようとしているメッセージから、かなり離れてしまっているようです..

著者のメッセージはやや強めに感じられる傾向はありますが、文章をよく読めば、"AIを使うな"という話ではありません。どう活用するかについての提案があり、要点は開発者自身に能力の欠如があってはならない、というメッセージです。

なぜ著者のメッセージが強く感じられるのかを見ると、copilotで開発が可能になるだろう（copilotへの開発依存度が高いニュアンス）という見方に対して応答する立場からメッセージが作られているため、開発者に対して自分自身の存在価値を損なうようなスタンスを取るな、という形でメッセージを展開しているのだと思います。

著者自身も"AIを使うな"というメッセージではないので、結局AIを活用するということであれば、その妥協点のどこかに落ち着くはずで、先ほどご回答された内容ともおおむね近いメッセージになっているように思います。

ただ、最初に書かれていた内容のうち、『偏った見方』という部分には同意しがたく、先に返信させていただきました。

作ることは始まりにすぎず、10年ほどサービスを運営していると途中でさまざまなことが起きるはずで、そこで踏ん張るには基礎が必要なのでしょう……学ばなければなりません。

まず、私が言った「ドメイン内でAIを活用する」において、設計や調整を人間が行うのは当然のことです…
これは、昔ならともかく、今は誰もがLLMの限界を知っているので、あまりに当然の前提になっており、わざわざ言う必要もないでしょう。

次におっしゃっていた、開発知識のない一般の人々がLLMを使うケースについてですが、
これは本文でもHacker Newsでも私でも述べたことはないと思いますが、とにかくこの場合でも、利用者が結果に満足できる水準には達しています。
そうでなければ、Bolt.newやv0、Cursorまでが今のような評価を受けてはいないと思います。

どこまで再発明し、どこまで外部依存に頼るのかを判断するのは難しいです。
どんな場合でも、自分でこれを作れるのに時間を節約するためにその依存関係を選ぶことと、その依存関係がなければサービスを作れず依存関係に縛られることは、まったく別の話です。
すべてのコードで可能というわけではありませんが（OSのようなものなど）、できるだけ電子側まで踏み込んで努力することが、システムを理解する助けになるはずです.

著者が意図した意味の理解に、少し誤解があるのではないかと思います。
著者は、自分が管理するプロジェクトの性能、安定性、そして保守しやすいアーキテクチャやコードの一貫性などに焦点を当てており、代表的な例として、アーキテクチャとコードの一貫性は現在のLLMが本当に苦手とする分野の一つです。

特にWebは、開発への流入が多く、「とにかく動けばいい」という思想が強い領域なので、品質の低いコードがあまりにも多くデプロイされています。そしてそれを基にLLMが学習しているため、出力物の品質が呆れるほど低いです。

試しに、GPTに「Webフロントに入れるんだけど、jsでクイックソートアルゴリズムを実装して」と頼んでみてください。出力物の問題点を見つけられないのであれば、この対話にあまり意味はないと思います。

> 投稿者は以前の投稿を見ると、ゲーム開発者のようです
> ゲーム開発の知識や資料はLLMが大量に学習できておらず、CRUDアプリのケースとは違って、本文の著者のほうがLLMの限界をより強く感じているようです

一通り読んでみましたが、結局これが理由で著者がやや偏った見方をしているのだと思います。
もちろん、本文の内容どおりに進めるのはほとんど教科書的な話なので正しいのですが、
AIは学習できる資料が多いCRUDやフロントエンドについては、すでに十分うまくできていると思います。
自分のドメインの中で、できるだけうまく活用していくべきだと思います。

会社は学びに来る場所なのか？ それとも、他人が作った車輪を使って価値を再創造する場所なのか？

https://ja.news.hada.io/topic?id=21091
この記事を読んだあとだと、これで合っているのかなと思ってしまいます。

1番は本当に悪夢のような、絶対に受け入れたくない変化ですね。ソースコードの履歴追跡が無意味になってしまうということです。

GN+ AIボットにYouTubeのスクリプトを抜き出して要約してもらったところ、かなり性能が良いですね。
見るべき動画が多すぎて大変でしたが、これは良さそうです

Electron が上手なところに当たっていないからですよ〜
…ってことみたいですね（笑）

ことわざには込められた意味があるのに、言葉どおりにしか解釈しない人が増えている
ああいう主張が流行ると、また平然と会議室がめちゃくちゃになる
ペーパーワーク屋が勢いづいて暴れ回り、同じ失敗を毎年また繰り返す

これはその国の労働法の基準とかなり連動しているのですが……米国の多くの会社では、単純に持ち回りで回し、都合が悪い時期には順番を入れ替える、という形が一般的です。負担が大きいので……オンコール専任チームがある会社もあります。
ヨーロッパでは、業務が変わったことを理由に、あるいは時間外勤務を理由に、ほぼ別途の補償があります。
韓国では、包括賃金制の弊害によって、適当に処理されがちです。オンコールも明らかに勤務なのに、まるでその時間に対する手当が福利厚生であるかのように装っています。

実際、あのサービスを全部使いこなすのも大変そうですが、MCPがあるのは大きな利点ですね。
今後APIのメンテナンスさえしっかり続けば、有用だと思います

Appleのハードウェアは素晴らしいですが、ソフトウェアはユーザーを縛り付けようという意図に満ちています。
自分で作ってビルドしたアプリを自分の端末でだけ動かそうとしても、100ドルのサブスクリプションが必要です。

中小規模のオープンソースアプリを使い、自分でビルドして利用する開発者なら、
Appleの端末で脆弱性を突いて脱獄しながらサイドロードするくらいなら、ただAndroidを使うほうが楽です。

私たちは待機については時給の半額、通信費の支援、実際に対応した時間は残業として1.5倍でした。

途中にC#派が隠れていますね

> 率直に言って、今Javaを開発するのに、あえてJetBrains製品を使わなくてもいいですが

この部分は……ちょっと同意しにくいですね、しくしく……