noto

いつもは数十秒で終わるはずのテストを、AIが80分以上待ち続けていた話。指摘して初めて分かった原因と、通知だけに頼る危うさを紹介します。

自動テストは全部パスしていたのに、実際にゲームをプレイしていて『あれ、おかしいな』と気づいた不具合の話。原因調査から、元の設計意図を壊さない直し方までを実例で紹介します。

AIが『前と同じ方針でいい』と即答した提案を、そのまま受け入れずもう一度理由を聞き直したら、結論が変わった話。同じ日にもう1件あった前提の訂正も合わせて紹介します。

将来の機能のために仕込んでおいた仕組みが、一度も使われないまま審査の書類作成で初めて負債として発覚した話。安全に削除するまでの判断と確認の手順を実例から紹介します。

『対応不要』と結論づけた報告書の一言が引っかかり、審査提出済みのAppの画像に実際に問題が写り込んでいることを発見した話。AIとの並行作業で、報告の要約だけでなく中身まで読む大切さを実例から紹介します。

たった1日で4回、自分の一言でAIの見落としが発覚した実話。実装漏れや計算バグの発見・修正の過程と、『なぜ直したか』を記録するルールが生まれるまでの経緯をそのまま紹介します。

アプリを1本作るごとに、共通の部品が1つずつ増えていった。ただそのペースは一定ではなく、あるタイミングで急に加速した。実際のAI開発でFrameworkが育っていった4日間を、そのまま振り返ります。

選択肢を並べて決めるとき、比較の数より効いたのは不採用案の記録とAIの提案より自分の逆提案の方が良かったという場面だった。実際のAI開発で起きた4つの意思決定をそのまま紹介します。

Debug環境では問題なく動いていたのに、本番リリース直前で次々と設定漏れが発覚した。テストやLintでは検出できない、動くのに本番準備ができていない落とし穴を、実際に見つかった4つの実例から紹介します。

CIもテストも全部greenだったのに、実機だけクラッシュした。実際のAI開発で起きた不具合の発見・診断・修正の過程を、間違った仮説の否定や、直したつもりでまだ確認できていない話も含めてそのまま紹介します。