← Latest papers
💻 computer science

UCSC-NLP at SemEval-2026 Task 13: Multi-View Generalization and Diagnostic Analysis of Machine-Generated Code Detection

The UCSC-NLP team addresses SemEval-2026 Task 13 by achieving strong binary detection of machine-generated code through a multi-view fine-tuning framework of UniXcoder-base, while demonstrating that class-weighted training is essential to overcome catastrophic failure in multi-class attribution caused by severe data imbalance.

Original authors: Kargi Chauhan, Sadiba Nusrat Nur

Published 2026-05-01
📖 5 min read🧠 Deep dive

Original authors: Kargi Chauhan, Sadiba Nusrat Nur

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a teacher trying to grade a stack of homework. You have two main challenges:

  1. The "Who Did It?" Test: Can you tell if a student wrote the essay or if they used a robot to write it?
  2. The "Which Robot?" Test: If a robot did write it, can you tell exactly which robot model (e.g., Robot A, Robot B, Robot C) was used?

This paper describes a team from UC Santa Cruz who built a system to solve these problems for computer code. They entered a competition (SemEval-2026 Task 13) to see how good their system was at spotting AI-generated code.

Here is how they tackled the two challenges, explained simply:

Challenge 1: The "Who Did It?" Test (Binary Detection)

The Problem: The team trained their system on code written in Python, C++, and Java. But when they tested it, they gave it code in languages it had never seen before (like Go or PHP) and in different styles (like research papers or production software). Usually, AI detectors fail here because they memorize specific words or languages instead of learning the "vibe" of the code.

The Solution: The "Three-Lens" Camera
Instead of looking at the code just once, the team taught their system to look at every piece of code through three different lenses simultaneously:

  1. The Original Lens: Looking at the code exactly as it is.
  2. The "Blindfold" Lens (Delexicalization): Imagine taking a sentence and replacing all the names of people, places, and numbers with generic words like "Person," "Place," and "Number." This forces the system to ignore specific variable names (which change by language) and focus on the structure of the logic.
  3. The "Mixed" Lens: They randomly mixed in some plain English text into the code snippets. This taught the system to handle messy, real-world code that isn't perfectly formatted.

The Analogy: Think of it like a security guard checking a bag.

  • Old way: The guard memorizes that "Red Suitcase = Bad." If you bring a Blue Suitcase, they miss it.
  • New way: The guard looks at the suitcase from three angles: the outside, the inside (ignoring the brand logo), and a version where they've mixed in some random items. If the structure of the bag looks suspicious in all three views, they flag it.

The Result: This worked incredibly well. Even when the code was in a new language or style, their system correctly identified it as "Human" or "AI" about 84.5% of the time.


Challenge 2: The "Which Robot?" Test (Multi-Class Attribution)

The Problem: This was much harder. The team had to identify which of 10 different AI models wrote the code.

  • The Data Skew: Imagine a classroom of 500 students. 442 of them are humans. The other 58 are robots, but they are split among 10 different robot types. Some robot types only have 2 students in the class.
  • The Trap: If you train a teacher on this class, they will learn a very easy trick: "If I just guess 'Human' for everyone, I'll be right 88% of the time!"
  • The Failure: When the team tried this, the system got an 88% "accuracy" score, but it was a lie. It was ignoring the robots entirely. It failed to identify the minority robot classes almost 100% of the time. It was like a metal detector that beeps for everything, but only beeps for coins, ignoring all the gold.

The Solution: The "Weighted Score"
To fix this, they changed the rules of the game. They told the system: "If you guess 'Human' correctly, you get 1 point. But if you correctly guess a rare robot, you get 200 points."
This forced the system to stop being lazy and actually learn to spot the rare robots.

The Result:

  • Before: The system was a "Human-guesser" with a score of 0.08 (terrible at finding robots).
  • After: With the new rules, the system's ability to find the specific robots jumped by 301%. It didn't become perfect, but it finally started seeing the minority classes instead of ignoring them.

What Did They Learn? (The "Why")

The team looked inside the "brain" of their system (using a visualization called t-SNE) and found something interesting:

  • Task 1 (Human vs. AI): The "Human" code and "AI" code formed two distinct, separate islands. The system could easily tell them apart.
  • Task 2 (Which AI?): All the different AI models (OpenAI, Meta, IBM, etc.) were huddled together in one big, messy pile, overlapping with the human code.

Why?

  1. Shared Diet: All these robots were trained on the same internet data (GitHub, StackOverflow), so they all learned to write code that looks very similar.
  2. Same Architecture: They all use similar brain structures (transformers), so their "handwriting" is nearly identical.
  3. Math is Math: There are often only a few correct ways to solve a coding problem, so everyone (human or robot) ends up writing the same solution.

The Bottom Line

  • Can we tell if code is AI? Yes, very well, even if the language changes, provided we teach the system to look at the structure rather than just the words.
  • Can we tell which AI wrote it? It is extremely difficult. The different AIs are so similar, and the data is so unbalanced, that standard methods fail. You have to use special "weighting" tricks to force the system to care about the rare cases.

A Warning: The authors note that their system isn't perfect. Sometimes it mistakes a very concise human coder for an AI, or a verbose AI for a human. Because of this, they say this tool should never be used alone to make life-changing decisions (like firing someone or failing a student); a human must always double-check the results.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →