No Meat Proxy

AIの回答を人に送り付けないでください

✕ やめてください

Jim

機能の切り替えはどのように行われるのですか？ユーザーごとに設定できますか？

Kevin

ここで採用されている機能フラグシステムは、設定ベースの独自実装です。定義: FeatureToggles クラスという @ConfigurationProperties のデータクラスがあり、enableNewCheckoutFlow や useOptimizedSearchIndex などの真偽値フィールドを持っています。これは FeatureConfig クラス内で、 @EnableConfigurationProperties を使って登録されています。利用方法: FeatureToggles を注入し、そのプロパティを見て分岐します。例えば、 if (!featureToggles.enableNewCheckoutFlow) で `ForbiddenException` をスローする、といった使い方です。一部のフラグは早期リターンや例外による処理の中断を制御し、別のフラグでは実装そのものを切り替えています。設定: 設定は app.feature-toggles.* 配下の通常の YAML で記述され、プロファイルごとに上書きできます。また、標準的な @ConfigurationProperties を利用しているため、環境変数からも上書き可能です。そのため、現在の実装ではユーザーごとに機能の有効・無効を切り替えることはできません。

✓ こうしましょう

Jim

機能の切り替えはどのように行われるのですか？ユーザーごとに設定できますか？

Kevin

残念ながらできません。オンオフの切り替えはハードコードされています。

AIの回答をそのまま垂れ流すだけでは、質問した相手をさらに困らせることになります。AIが生成した回答は、往々にして冗長で複雑で、時折求められてもいない詳細情報が含まれがちです。相手はあなたの判断を信頼しているから、あなたに尋ねたのです。AIの出力を転送するだけでは、あなたはただの「生身の中継役」に過ぎません。

もしあなたが、人とAIの間でメッセージを仲介しているだけなら、あなたの価値はどのようなものでしょうか？

AIの回答をそのまま返信するだけなら、あなたは:

• 周りの人の手間を増やしています。
• 自分自身が代替可能であることを示しています。
• 実際には役に立ちません。
• カッコ悪そうに見えます。
• 人からの信頼を損なっていくでしょう。

人らしく答え、人らしく扱いましょう。生身の中継役にならないでください！

中身について理解・検証していないAI生成物を提出しないでください

✕ やめてください

function chargeCustomer(order) {

+ try {

+ processPayment(order);

+ } catch (err) {

+ logger.warn(err);

+ }

Jim

なぜこのエラーを伝播させずに握り潰しているのですか？

Kevin

さあ？Claudeがそうやって書いたから。

}

✓ こうしましょう

function chargeCustomer(order) {

+ try {

+ processPayment(order);

+ } catch (err) {

+ logger.warn(err);

+ }

Jim

なぜこのエラーを伝播させずに握り潰しているのですか？

Kevin

上流側ではあらゆるエラーに対してリトライしますが、これについてはバックフィル中に発生しうるものなので、ログを記録した上で破棄しています。コメントを追加しておきますね。時間がある時に、アップストリーム側の処理を書き直すチケットを作成しておきましょうか？

}

AIがほとんどの仕事を肩代わりしてくれるとはいえ、あなたには責任があり、そしてあなたの名前が記されます。あなたの名前がある限り、それはあなたの仕事です。あなたには行った仕事の内容を理解し、検証し、それを自らの責任として受け入れる必要があります。

盲目的にAI生成物を提出することで、あなたは:

• 自分の仕事を理解し検証する負担を、他人に押し付けています。
• 自分でやるのが面倒なことを他者に押し付け、敬意を欠く態度を示しています。
• あなたの仕事はダブルチェックが必要であることを示しています。
• カッコ悪そうに見えます。
• 自分自身が代替可能であることを示しています。

自分の名前が載っている仕事には責任を持ってください。人から頼られるような存在になってください。生身の中継役になってはいけません。