それいゆ

AIコード支援の話で、まずLinuxカーネルのcoding-assistants.rstを読むといいんじゃないかと思う人が多いな。AI支援を禁止しないが、AIを責任主体とは扱わずにあくまで投稿者である人間がコードを理解し、ライセンスを確認し、DCOに基づいて責任を負う。そこそこのプロジェクトはこれがベースかなと。

その通りだと思う。 qiita.com/yurizono/items…

@mitsui_yoichiro 本当にそうですね。 変にビジュアルが良いとノイズも大きくなってしまいますね。

@soreiyu ですよね。そしてそこから沢山のことが想像できてしまいますよね。

ビジュアルが一番印象に残るんだから なんで宇宙服なのか を答えられないとやっぱデザインしてないなぁ。 となりますね

空想科学読本味を感じるw ちなみにメガジョッキ頼むためにやってます。ハイ

『遊☆戯☆王』の“あれ”に影響を受けたターン制戦略RPG『DDD: Dice, Dungeons & Drakes』体験版が配信中。ダイスロールで勝利の出目を掴み取れ news.denfaminicogamer.jp/news/260521g 「召喚ダイス」「アクションダイス」を駆使して相手リーダーへの到達を目指す。運命が味方するのは自分か、それともライバルか

ロードマップページ作っておくと自分のやる気も湧くので良い そしてようやくブラウザ拡張の開発を再開できそう…

「リーダーシップって何？」と正面から聞かれると、なかなか答えにくいものだが、あるコンサルがスパッと言い切っていた。「何をなすべきかを示して、自分ではなく他人にやってもらう能力」。極めて分かりやすい。技術者も何でも自分でやりたがっていては、リーダーシップは身につかないというわけ。

あ、でもDB側の負荷は分からないから一長一短か。

これわりとおもろいな。 負荷テストとかあらかじめデータ入れなくても出来る可能性を秘めてる

自分のやってることが肯定されてた zenn.dev/erukiti/articl…

使い込んでる人の思想は参考になるなあ。 色々プラクティスのパラダイムシフトがあるはず。テストも大きく変わると思う。 "テスティングトロフィーとか忘れてください。あれは人間がプログラミングをしていた時代の考え方です。AIコーディングでは結合テストがすべてです。" zenn.dev/erukiti/articl…

信頼こそがボトルネックである、という記事 blog.reqproof.com/p/engineerings… ・AIを使うとコードの作成や試作は劇的に速くなる ・しかしプロダクトを維持管理するのは別物であり、プルリクエストが増えても開発が加速するわけではない ・高レベルなエンジニアリングにおいてコストがかかるのは、タイピングではなく「変更を信頼できるかどうか」という点にある ・変更が意図に合っているか、既存の機能を壊さないか、テストや文書が正しいかを確信できることが開発のボトルネックとなっている ・AIは仕様、コード、テスト、文書をすべて生成できるため、それらが間違った意図で一致していてもCIをパスしてしまうリスクがある ・テストのカバレッジが高くても、想定外の入力など仕様に記述されていない挙動は検証できない ・セキュリティやエラー状態への対応は、もはや付加価値ではなく製品の必須要件となっている ・CI/CDやコードレビューのさらに上の層に、システムがあるべき姿を定義して検証を支える真実のソースが必要である ・外部の貢献者や他チームの人間は、コードは見えても過去の経緯や設計者の深い意図までは把握できない ・信頼が伴わない貢献は、表面的な修正にとどまりシステムを壊す危険をはらむ ・多くの仕様書は一時的な成果物として扱われ、時間が経つとコードとの関連を掘り起こす考古学のような作業が必要になる ・仕様、チケット、議論、コードが断片化しており、全体像の把握を個人の記憶に頼らざるを得ない ・開発が進むにつれて仕様は変わるが、文書が更新されずに実装と食い違う混沌とした状態に陥りやすい ・多くのバグはコードそのものではなく、書かれていない仕様の中に潜んでいる ・異常系や境界値など、記述すべき挙動のカテゴリを「義務」として定義する必要がある ・義務を果たす仕組みを作ることで、個人の記憶に頼らず機械的に検証を確認できるプロセスに変えられる ・AIは設計の良し悪しを判断するのではなく、検討が漏れている質問を人間に提示する道具として役立てるべきである ・航空や医療などの規制産業では、仕様はソフトウェアと共に生き続ける信頼の源泉として扱われている ・要件はIDで管理され、テストや実装とリンクして検証の証拠となる ・現代的な高速な開発手法を維持しながら、こうした信頼のレイヤーを追加することが求められている ・プルリクエストを単なるコードの塊から、意図や要件、証拠をまとめた「エビデンスパック」に進化させる必要がある ・変更の影響範囲や文書との整合性が可視化されれば、人間が判断すべき箇所が明確になる ・最初は手間がかかるように感じるが、この摩擦こそが多くの人が安全に動くための信頼を生む ・筆者はコードを増やすのではなく、意図を保存して信頼できる変更を増やすために「Proof」というツールを開発している ・仕様、要件、テスト、文書が互いに矛盾したときに検知できる仕組みを目指している ・AI時代に本当にスケールさせるべきなのは、コードの量ではなく信頼できる変更の量である

本番リリース作業やらされてる人が一番リスク背負ってるよね

これ知見ないときついよな・・・。自分もうまく作る自信ないもん。 zenn.dev/ivry/articles/…

The funniest part of all of this is Rust worked for years to establish a strong brand of “difficult to learn, slow to work with, but trust things built with it to be hardcore engineered and correct” And overnight Anthropic changed it to mean “probably vibe coded slop”.

そらそうよねぇ 昔のOSSの貢献が翻訳でも良いからISSUEを上げよう！ みたいのだったけど、今の時代それだけじゃダメだね。 theregister.com/security/2026/…

Anthropicが公開している「創業者向けプレイブック」で、「コード生成が容易なため、誰も欲しがらないものを爆速で作ってしまうリスク」を指摘していて、対策としてAIを「悪魔の代弁者」として使ってアイデアの前提や市場性を厳しくテストしろよ、と説いてる。 クソみたいなアイデアの開発で無駄にGPU食うなよ、ということか。

やっぱ人間にマルチタスクは無理なんやw note.com/simplearchitec…