ｗｗｗｗｗ

バイブコーディングしたものまで宣伝するんですか

スカイネットの始まりってことか（笑）

これは韓国が前にやっていましたね。

これはあり得るんですか??...

作業のネタを作ってくれたアップルをもう一度称えろって？ ふざけるな

ハーネス構成要素の再発明は、必然的な収束というより、Web検索などで先行事例がすでに十分見つけられるので、それをなぞった結果ではないかという気がします。

過去データのみで学習・アクセスできる状況で、AIエージェントの構成要素を再発明することに成功した、という程度であってこそ、アーキテクチャの収束と言えるのではないでしょうか。

残念ながら、会社ですでにAXチームが多くできている状況なので、最後の段落あたりを意識して対応していく必要がありそうですね。

私もすぐにその発想が浮かびました。最近はAIサービスやエージェントが、何か超法規的な権限を持っている状態をそのまま前提にしている気がします。こんなふうに半ば目隠しされたような状態で進んでいいのかな？という…

実際のところ、いろいろ設定すればよいだけなのですが、結局は経験が必要なんですよね（笑）。とにかく、私はこういう文章が好きです。

コンテナで立ち上げるときにボリューム設定を誤ったのが問題なのであって、同時書き込みができないことが問題になったわけではありません。記事をもう一度読めば、同時書き込みができない点は busy timeout で十分カバーできると書かれています。ボリューム設定は
ipc=host で解決できるはずです。

Postgres は結局運用が必要ですが、SQLite はどこでもアプリのバイナリさえ配布すれば済みます。

数多くの運用経験と失敗が積み重なった結果、SQLite が流行し始めているのであって、
同時書き込みは記事でもまったく問題ではないとはっきり書かれています。

ミュンヘン市のように失敗しないことを願います。 https://zdnet.co.kr/view/?no=20170213100421

ありがとうございます。
企画もデザインも手法は変わり続けてきましたが、だんだんスピードが速くなっている感じですね。

ブログ全文を読んでみると、もともとPMがやっていた仕事ですね。ただ、AI時代が来てやり方が少しずつ変わっているようです。良いインサイトをありがとうございました。

Linuxへの移行の試みは、みんな一度や二度経験して失敗してきたわけではなく、失敗した理由があるので、どうなるかは分かりませんね。
韓国でも過去に政府がLinuxベースを後押しした理由はこれです。
韓国企業はそれでも政府が統制力を発揮できるので。

ただ、方向性としてはLinuxネイティブというよりWebベースやSaaS中心に進む傾向がありますが、こうなるとまた別の領域で依存が生じてしまう結末になるかもしれません。

Skillsは剣術で、MCPは剣です……用途が異なり、どちらも必要ですね。

そうですね。だからこそ、こういう記事がたまに上がってくるといいですね。

インフラの複雑さの問題があるにしても、ショッピングモールのように同時書き込みが多く必要なところでは、最初から sqlite を使わないほうが良い選択ではないでしょうか?
しかも Docker で構成したものだったなら、postgresql 構成のインフラ複雑度もそれほど高くはないはずです。
rails で作っていて、エコシステムが sqlite を使う方向に枠組みができているので、それで良いと誘導されたのではないかという印象です。
注文漏れのような重大なエラーが発生したのに、pg のような同時書き込みに強い DB を使うべきところであっても、ショッピングモールのように同時書き込みが多く必要な場所では、最初から sqlite を使わないほうが良い選択ではないでしょうか?
rails で作っていて、エコシステムが sqlite を使う方向に枠組み化されているので、それで良いと誘導されたのではないかという気がします。
注文漏れのような重大なエラーが発生しており、これを根本的に解決するのは pg のような同時書き込み DB を使う方法なのに、
sqlite を技術的に好むからといってこれを使い続けると主張するのは、私にはエンジニアとしての信頼を下げる発言に聞こえます。
不要なのに k8s を載せて replica 1 の HPA を構成し、うまく使っていたモノリスを MSA に変える履歴書駆動開発の逆バージョンのように感じます。

国家として採用するなら、その資金でLinux開発の支援もしてほしい…。

それでなくても、似非伝道師がはびこる嵐のようなAI業界なのに