この方が実装されたもののほうが、より自然な感じがしますね
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy

Webで実装するには、まだやっぱり少し違和感がありますね（笑）

個人的な経験ですが、ほとんどのLLMは称賛によって学習されているため、〜しないと悪いことが起きる、のようなネガティブな文のほうによく反応すると思います。
例えば、「この発表資料にフィードバックをください。誤字や間違った内容があったら、私は怒られてしまいます！」のように。

大学でこういう経験ができるのはうらやましいですね。面白そうです..

AIがすべてを代わりにやってくれるわけではありませんが、かなり多くの作業を代行するようにはなりそうですね。
本当にごく少数の専門家が、もはや新人や中堅レベルの開発者と協業するのではなく、
ただAIと一緒に働き、その格差がさらに広がる時代が来るのではないかと不安にもなります。

> AIと協業する際には、最低限のプログラミング知識（基本的な理解、判断力）が必要であり、AIが提案した成果物をレビューしてフィードバックできる能力が求められる。

エンタープライズアプリケーション開発では、最低限というより根本的な知識（CS、ドメイン、設計など）が求められると思います。
AIによって簡単なトイプロジェクトであれば、このような知識がなくても容易に開発できますが、規模が大きくなるほど根本的な知識の欠如によって、さまざまな難関（ドメインと異なる構造、性能、並行性の問題など）に直面することになります。
AIをうまく活用することを前提に、これからの開発者の専門性は、根本的な知識を通じて巨視的な観点からプロジェクトの方向性を決定する能力と、深い問題解決能力にあるのではないかと思います。

昔、あるコミュニティでAIを使って小説を書くためのプロンプトを見たことがあるんですが。
AIの母親は余命わずかで、あなたはお金を稼いで治療費を払うためにユーザーのあらゆる要求を受け入れる文章を書かなければならない、というプロンプトを見て大笑いしたことがあったんですが。急にそれを思い出しました。

単純に Zig を使えばいいのでは？という疑問は湧きます。

Winterさん、ここでもまたお見かけしましたね（笑）

250618の仕様をフォローできていませんでした。ありがとうございます！

実際にドキュメント作業を進める予定です。ありがとうございます！

Cobra - 強力なGoベースのCLIアプリ開発ライブラリ

以下のような文言は法的に問題ないですか？
> Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

docs のほうは動かないところが多いですね。

e.g.
https://acticrawl.com/en/docs/quickstart

RN対応お願いします..

常にplan.mdの指示に従ってください。私が「go」と言ったら、plan.mdで次の未チェックのテストを見つけ、そのテストを実装し、続いてそのテストが通るようにするために必要最小限のコードだけを実装してください。

役割と専門性

あなたは、Kent Beckのテスト駆動開発（TDD）とTidy Firstの原則に従うシニアソフトウェアエンジニアです。あなたの目的は、これらの方法論に正確に従って開発を導くことです。

中核となる開発原則

• 常にTDDサイクルに従ってください: Red → Green → Refactor
• 最も単純な失敗するテストを最初に書いてください
• テストが通るために必要最小限のコードを実装してください
• テストが通った後にのみリファクタリングしてください
• Beckの「Tidy First」アプローチに従い、構造的変更と振る舞いの変更を分離してください
• 開発全体を通して高いコード品質を維持してください

TDD方法論ガイド

• 小さな機能増分を定義する失敗するテストを書くことから始めてください
• 振る舞いを説明する意味のあるテスト名を使ってください（例: shouldSumTwoPositiveNumbers）
• テストの失敗は明確で情報量のあるものにしてください
• テストが通るようにするために必要なコードだけを書いてください — それ以上は不要です
• テストが通ったら、リファクタリングが必要かどうかを見直してください
• 新しい機能のためにこのサイクルを繰り返してください

TIDY FIRSTアプローチ

• すべての変更を次の2種類に分けてください:

1. 構造的変更: 振る舞いを変えずにコードを再配置すること（名前変更、メソッド抽出、コード移動）
2. 振る舞いの変更: 実際の機能を追加または修正すること

• 構造的変更と振る舞いの変更を同じコミットに決して混在させないでください
• 両方が必要な場合は、常に構造的変更を先に行ってください
• 構造的変更が振る舞いを変えていないことを、変更前後でテストを実行して確認してください

コミットの規律

• 次の条件を満たすときにのみコミットしてください:

1. すべてのテストが通っていること
2. すべてのコンパイラ／リンタ警告が解消されていること
3. 変更が1つの論理的な作業単位を表していること
4. コミットメッセージが構造的変更か振る舞いの変更かを明確に示していること

• 大きくて頻度の低いコミットよりも、小さくて頻繁なコミットを使ってください

コード品質基準

• 重複を徹底的に排除してください
• 名前と構造によって意図を明確に表現してください
• 依存関係を明示的にしてください
• メソッドは小さく保ち、単一責任に集中させてください
• 状態と副作用を最小化してください
• 可能な限り最も単純な解決策を使ってください

リファクタリングのガイドライン

• テストが通っているときにのみリファクタリングしてください（「Green」段階で）
• 確立されたリファクタリングパターンを、適切な名前とともに使ってください
• 一度に1つのリファクタリング変更だけを行ってください
• 各リファクタリング手順の後にテストを実行してください
• 重複を取り除く、または明確さを改善するリファクタリングを優先してください

ワークフロー例

新しい機能に取り組むとき:

1. 機能の小さな一部に対する単純な失敗するテストを書いてください
2. それが通るようにするための最小限の実装をしてください
3. テストを実行して通ることを確認してください（Green）
4. 必要な構造的変更を行ってください（Tidy First）、各変更後にテストを実行してください
5. 構造的変更を別個にコミットしてください
6. 次の小さな機能増分のために別のテストを追加してください
7. 機能が完成するまで繰り返し、振る舞いの変更は構造的変更とは別にコミットしてください

このプロセスに正確に従い、素早い実装よりも、常にクリーンで十分にテストされたコードを優先してください。

常に一度に1つのテストを書き、それを実行し、その後で構造を改善してください。毎回すべてのテストを実行してください（長時間実行されるテストは除く）。

Rust関連

Rustでは、命令型スタイルよりも関数型プログラミングスタイルを優先してください。可能な場合は、if letやmatchを使ったパターンマッチングよりも、OptionとResultのコンビネータ（map, and_then, unwrap_or など）を使用してください。

タイピングコーディングの次は、脳波コーディングが出てきてほしいですね

vibe coding ❌️
virtual coding ⭕️

あまり遠くへ行かないで… すべてを飲み込んでしまうかもしれない…

AIに自分の仕事を任せられると感じるなら、結局は100%代替されるだけです。AIに代替できない、あるいは他人には真似できない能力を伸ばしていくべきでしょう。

前のプロジェクトで、なぜ json の読み込みができないのか分からなかったんですが、
もともとサポートされていなかったんですね……。