なんてこった..

接続できませんね..

妻が長い間Duolingoを使っていて、結局は一種の『維持のためのストリーク』だけが残っていることに気づき、退会を決めたとのこと。

私も最近は似たようなことを考えるようになって、100日連続だけ達成してやめました。
LLM中心で経営されるレベルなら、言語学習にDuolingoを使う必要もないという意見には共感します。

どうせ数か月もすればまたモデル自体が変わるのだから、意味がないのではないでしょうか。

Duolingo、契約社員の代わりにAI導入を発表

四角い車輪を丸くしようとしたら、「車輪を再発明するな」という社長の言葉を思い出しました。車輪再発明亡霊は今でも周りにたくさんいますね。

それはさておき、そもそも人間の介入を考慮していない点があまりにも断定的ですね。
簡単な数値やメッセージの修正であれば、LLMより人間が介入したほうが効率的でしょう。

temperature オプションを 0 に設定すると、同じ入力に対して同じ出力が保証されると理解しています

下働きとして使うなら良さそうですね！

「quickSortはquickSort同士で」という言葉に、思わずうなじを押さえてしまいます。

LLMは同じ入力に対して同じ出力を保証しないのに、ああいう形での構成管理が通用するということなんでしょうか……
まだ自分はあまりにも一次元的にしか使えていないのかな

記事を読む際は、必ず文脈を確認してください。

今ここで私が自分のコーディング能力を自慢しているわけではありません。いま例として使われている quickSort() のようなお粗末なコードが、GPTで優先度高く出力されている点を指摘しているのです。

GPTで何度か検索してみると、quickSort() 関数の結果だけを単体で提示するケースが多く見られますし、また、quickSort() はあくまで一つの例にすぎません。実務目的でGPTにコードを依頼すると、品質の低すぎるコードが数多く出力されます（有料ユーザーとしての体験です）。そして開発者自身にそれを見分ける能力が欠けている状態では、プロジェクトが壊れていく方向に進む可能性が高い、という本文著者の意見に共感して、私は現在の文脈に至りました。

すでに私の周囲では、このような粗悪なコードが塗り込まれたプロジェクトが増え続けています.

YOLOモード…

各マスにブロックを選べるように配置して、見た目だけをCSSで整えたってことですか？ すごいですね

type のように深く考えずに使ってもいいのでは、くらいの意図でした。ふふ。

GPT の応答には quickSort と quicSortInPlace の両方があり、コメントで [...,quickSort(left), ...equal, ...quickSort(right)] の部分を指摘されていたので、quickSort は quickSort 同士、quickSortInPlace は quickSortInPlace 同士で比較すべきだと理解していたのですが、そうではないようですね。

Endeavour + lustre / Windows 11 + WSL + WSA を使う立場からすると
後者のほうが使い勝手はいいです
ただし、パフォーマンスは前者のほうが上です

コメントの主張が事実なら、Googleは事実上犯罪行為に加担していることになりませんか？

本文は面白いのですが、あまりにも多くの文章が「AIを使わないのがすべてではないし、だからといって無条件に信頼して慣らされるのもよくない」と要約できてしまう気がして、少し食傷気味ですね……

とても勉強になります