Code Coherence Analysis: Catching AI-Pasted Submissions

「一貫性のある」コードの特徴

実際のエンジニアは習慣を持っています。関数全体でブール値を同じ方法で命名しています（isReady 対 is_ready 対 ready ですが、一貫して）。エラーハンドリングパターンを 1 つ好みます。同じ標準ライブラリツールを何度も使用します。TODO とコメントは同じ声を共有しています。

優秀なエンジニアでも「雑」ですが、「一貫して」雑です。その一貫性が、私たちが一貫性と呼ぶものです。

一貫性のないコードの特徴

LLM が貼り付けた提出物、特に複数のプロンプトから組み立てられたものは、予測可能な方法で一貫性に失敗します：

• 1 つの関数は try/except を使用し、次の関数はオプショナルチェーンを使用し、3 番目は静かにエラーを飲み込みます。
• 変数命名スタイルが反転します：userId、user_id、uid、すべて同じファイル内です。
• コメントが「明白なことを説明する」（LLM の特徴）と「完全に欠落している」（人間の特徴）の間で交互に現れます。
• 成句レベルが変動します：教科書的な汎用型のソリューションの隣に Stack Overflow からコピーペーストされたスニペットがあります。

これらのいずれか 1 つだけでは、疲れた候補者である可能性があります。4 つすべてが揃うと、別の話になります。

分析がどのように機能するか

ClarityHire の一貫性パスは、候補者の最終提出物を 1 つのプロンプトで LLM ジャッジ に確認させます：「これは 1 人の著者の作品のように見えますか、それとも組み立てられたものですか?」ジャッジはスコア、気付いた具体的な矛盾、および信頼度レベルを返します。

重要なことに、ジャッジは候補者のアイデンティティを見ることはありません。コードだけを見ます。

これが「AI 検出器」ツールより優れている理由

ほとんどの「これは AI か」検出器 は信頼性がありません。特にコードの場合（LLM と人間は同様の Python を書きます）。一貫性分析はその質問を完全に回避します：「AI がそれを書いたかどうかは気になりません。1 人の心によって統一されたソリューションとして書かれたかどうかが気になります。」そのフレーミングは、より答えやすく、採用マネージャーが実際に知りたいこととより一致しています。

一貫性フラグでやるべきこと

候補者に 20 分のライブフォローアップ でコードを 理解して説明するよう 促すメッセージとして扱います。正直な候補者はそれを簡単に説明できます。不正直な者はできません。どちらの場合でも、何かを学びました。