はい
動いてるうちは神だけど障害起きた瞬間全員で顔見合わせる地獄が見えるわ
ソフトウェアエンジニア＝SE＋PG だったとしたら、今後はソフトウェアエンジニア＝SE ってことになっていくんだろうな
マネージャーよりSIerで言うところのリーダーの感じ近い。コードと仕様、要件との整合性、妥当性に責任を持つ役割。プロダクトとして責任を持つなら理解しないなんて選択肢なんてありえんのよ。プロ意識が低すぎる
理解も手段、なるほど
それでは聴いてください、きかんしゃトーマスで「事故は起こるさ」https://youtu.be/WC2dLwfDa7g
理解するものが何かによる。意味を理解しろ。仕組みは後回しでいい
会社としてとか個人としてどうするかではなくて「何」を対象として操作するときはリスクが許容できるか？例えば外部とのデータ連携では理解しないリスクは許容できないとかだと思うのだが誰も対象(Object)の話をしない
正しい方向感覚だと思う。「コードと仕様、要件との整合性、妥当性」は要求を満たすシステムそのものではなく、技術のエンジニアリング制約ですね。矮小な読解はプロ意識を履き違えた錯誤で、星付けてるのはやばい
人間側で「判断」できるように、最終出力にたどり着いた「プロセスや推論内容」もセットで可視化させるぐらいか。プロセスや推論内容すらもハルシネーションや論理の飛躍があることを人間が理解している前提だが。
AIコードの実装理解をどこまで手放すかは、リスク許容度と仕組みで決める。振る舞いは理解し、型・テスト・監視・段階的リリースで担保。変更の意図をAIが参照できる形で残し、エンジニアは担保の仕組みを作る側へ。
AIに的確に修正させるには理解が必要だと思う。
内部実装を理解することを品質保証の前提から外し、要求する振る舞いを型・テストで検証。監視・段階的リリースによりリスクを制御。設計意図はAIが参照可能な形で保存することで、人の実装理解への依存を減らす
理解をどこまで手放すかは、リスク許容度と仕組みで決まる - カレーの恩返し
はい
動いてるうちは神だけど障害起きた瞬間全員で顔見合わせる地獄が見えるわ
ソフトウェアエンジニア＝SE＋PG だったとしたら、今後はソフトウェアエンジニア＝SE ってことになっていくんだろうな
マネージャーよりSIerで言うところのリーダーの感じ近い。コードと仕様、要件との整合性、妥当性に責任を持つ役割。プロダクトとして責任を持つなら理解しないなんて選択肢なんてありえんのよ。プロ意識が低すぎる
理解も手段、なるほど
それでは聴いてください、きかんしゃトーマスで「事故は起こるさ」https://youtu.be/WC2dLwfDa7g
理解するものが何かによる。意味を理解しろ。仕組みは後回しでいい
会社としてとか個人としてどうするかではなくて「何」を対象として操作するときはリスクが許容できるか？例えば外部とのデータ連携では理解しないリスクは許容できないとかだと思うのだが誰も対象(Object)の話をしない
正しい方向感覚だと思う。「コードと仕様、要件との整合性、妥当性」は要求を満たすシステムそのものではなく、技術のエンジニアリング制約ですね。矮小な読解はプロ意識を履き違えた錯誤で、星付けてるのはやばい
人間側で「判断」できるように、最終出力にたどり着いた「プロセスや推論内容」もセットで可視化させるぐらいか。プロセスや推論内容すらもハルシネーションや論理の飛躍があることを人間が理解している前提だが。
AIコードの実装理解をどこまで手放すかは、リスク許容度と仕組みで決める。振る舞いは理解し、型・テスト・監視・段階的リリースで担保。変更の意図をAIが参照できる形で残し、エンジニアは担保の仕組みを作る側へ。
AIに的確に修正させるには理解が必要だと思う。
内部実装を理解することを品質保証の前提から外し、要求する振る舞いを型・テストで検証。監視・段階的リリースによりリスクを制御。設計意図はAIが参照可能な形で保存することで、人の実装理解への依存を減らす