「あなたが将来新人のメンターやテックリードになった場合、そのスタンスだとどうやって他の人のコードをレビューするつもりですか？

それとも、ずっとこのままジュニアクラスで給与は一切上がらなくてもいいし、辞めさせられても問題ないというスタイルですか？」

と、人事評価権を持ったマネジャーに言ってもらうのが一番かと思います。

その想定ができていないだけの人であれば、言われたらハッとしてやる気が出ることもあるかもしれません。

そのジュニアの立場になって考えてみると、C言語でプログラムを書いていたら、80年代からプログラム書いてるおじさんに、生成されたアセンブリも理解して、必要に応じてアセンブリ手書きしないとダメだよって言われるみたいな感覚なんでしょうね。

フィードバックへの反応から、そのジュニアのそもそもの姿勢や素養が微妙な気はしつつ、

3年、5年後のSWEの在り方が不透明な中、シニア陣や組織として現状のジュニアはこういうスキル・マインドを持つべきという組織としてのスタンスが持てず必要なオンボーディングができていない、みたいな構造的な問題もありそうだな、と思いました。

その状況で、ジュニアはなおさら解像度が低いので、成果出すために学習したり調べたりせずAIに書かせた方が早い→試行錯誤がスキップされ知識も身につかない→フィードバック受けても判断軸がなく「そうなんですね」と受け止めるだけ。

それを続けたら自分の市場価値がどうなるかも考える材料がない。みたいな。

個人的には結構深刻な問題だと感じますね。

知識のある人から「どうですか？」と聞かれると形式的に聞かれてるだけで私の意見は求めてないんだろうなと思うのでそういう返答になります。

あなたはジュニアエンジニアの将来を心配しているのですか？ジュニアのくだらない仕事に付き合うのが嫌なのですか？

前者なら粘り強くコミュニケーションを取ればいいですし、後者ならその人の仕事を生成AI爆速コーディングで奪えばいいのでは。

コードとも生成AIとも関係ない話なのですが、フィードバックへの反応の話として、こういう考え方もあるかもよ？という話をひとつ。

私自身の話ですが、顧客問い合わせへの回答案を書いて同僚にレビューを依頼したとき、本質的ではないマイナーな部分に対する指摘は言われるまま受け入れちゃいます。事実関係の認識に相違があるとかならしっかり議論が必要ですが、「ここに読点を入れるべきか」とか個人の好みの問題でしょ、みたいなことで議論するの無駄なので。

相手のジュニアさんにとっては、どっちの関数使おうが同じ結果を得られるんだからどっちでもいい、そんな瑣末なことで楯突いても時間の無駄だから言われた通りにするほうがコスパタイパがいい、という感覚なのかもしれませんよ。

使ったメソッドがダメなケースのテストケースを追加するように言えばお互いに納得するのかもしれません

生成AIが出る前から、ネットのコードをコピペして、なんで動くか説明できないジュニアって一定数はいたので、それと変わらんかなと。答えが早く手に入るようになった分だけタチが悪いですが笑

なので、AI関係なくマインドの問題なので、上の人に言って直してもらう方が良いと思います。