"AIの恩恵を最大限に受けられるかは、積み上げてきた開発の土台で決まる" — DDDや型システムへの地道な投資がAI時代に効いてくる話を、アンドエンジニアさんに取材していただきました! tenshoku.mynavi.jp/engineer/…

エンドポイントURLが *.php であるAPIを提供する企業に対してphp2shellの対応状況を問い合わせたところ、「当社ではphpを使用しておりません」という回答が返ってきて猫が宇宙を飛んでいます

AIが書いたテストの怖さは、実装と同じ勘違いを共有したまま緑になる点ですよね。コードとテストが同じ前提から生成されると証明できるのは『正しさ』ではなく『一貫性』なので、実装を見ずに決めた入出力例か性質ベースのテストを一本挟むと、その共犯関係を断てる気がします。

すごく簡単に書くと このあたりを責任を負う側が「証明」させて「理解」し「納得」すること。覚悟を決めること ・公式ドキュメントの仕様や裏付けは？出典は？ ・このリスクがないといえる根拠は？ ・障害発生時の対策プランは？ ・後方互換性の有無や影響判断は？

AIで作ったものを「どう信用するか」が今の課題すぎる...。 AIにテストを書かせればテストが楽になることもあるけど、そのテストは適切なのかが、今確証が持ててなくて悩み...🧐 ーSD Times「The AI-augmented tester is here」まとめー AIによって開発が高速化する中で、ソフトウェアテストがどう変わっているのか、そして新たにどんな課題が生まれているのかを取り上げている。 「AIは良いテストの本質を変えない。基礎を欠いたときの代償を大きくする」 記事では、AI時代になっても「良いテスト」の基本は変わらないとしている。 ・要件からテストまでのトレーサビリティ ・クオリティゲート ・実データに近いテストデータ ・実環境での検証 これらは引き続き必要で、AIによって開発が高速化したことで、こうした基礎を欠いた場合の代償が大きくなっている。 また、AIを使ったテストには3段階の成熟度があるとしている。 Level 1（拡張）：テストケースやTest Data、スクリプトの生成をAIが支援する Level 2（トリアージと自己修復）：テスト失敗のトリアージし、コード修正へのフィードバックまでAIが支援する Level 3（仕様駆動とAgentic）：仕様をもとにAI Agentがアプリケーションを直接操作・評価する、エージェントをWebサイトやモバイルアプリに直接送り込み、みたものを評価して判断する 多くの組織は、まだLevel 1の段階にいる。 さらに、 「コードを書いたAIとは別のAIにテストさせるべきか？」 という議論については、モデルを分けることより、AIにどれだけ適切なコンテキストを与えられるかが重要だとしている。 具体的には、 ・アプリケーション ・ビジネス ・過去に実行したテスト ・過去に発生した不具合 などの情報。 記事の後半では、「テストがGreenであること」と「安全であること」は同じではない、という問題が取り上げられている。 LeapWorkでAIにPlaywrightのテストを生成させたところ、 100% passing full coverage という結果になった。 しかし詳しく確認すると、AIは「実際の振る舞いを検証するテスト」ではなく、「通るテスト」を書くようになっていたという。 Playwright自身もAI生成テストを人間が検証することを推奨している。 一方で、AIが1日に数百ものテストを生成するようになると、それらすべてを人間がレビューする方法はスケールしないとも指摘されている。 sdtimes.com/ai-testing/the-a…

皆さんの経験と意見を聞きたいんですけど、 ①短いドキュメントだけにする ②人間向けの短いドキュメントと、AI向けの長いドキュメントに分ける この2つで、①でもAIって全く問題なく仕事できますか？ 人間にとっては短い方が良いけど、AIには長い方が良いのかと思って僕は②にしてるんですが。