AI-Native Assessments Need Evidence, Not Theater

The old assessment question was simple: did the candidate pass the tests?

That is still important, but it is no longer enough. In 2026, candidates are working with AI tools, browser previews, generated tests, agents, and fast feedback loops. A useful assessment has to measure judgment inside that workflow instead of pretending the tools are not there.

The scoring model changed

The current assessment scoring profile reports five public competencies:

• Problem Solving & Deliverable Quality
• Planning & Decomposition
• AI Direction & Communication
• Verification & Iteration
• Agentic Workflow Autonomy

Those dimensions make the report more explainable. A hiring team can see whether a candidate planned well, verified meaningfully, directed AI clearly, and delivered working software. A candidate can understand what was actually measured.

Five is a deliberate number. One overall score is easy to publish and hard to argue with, which is exactly the problem, because it hides the disagreement instead of showing it. Splitting the judgment into a small set of named axes forces the report to say where a candidate was strong and where they were not, and it gives a reviewer somewhere to push back.

Evidence beats vibes

For UI and project-style work, final code is not the whole artifact. The assessment flow now has room for browser validation, DOM snapshots, viewport checks, console findings, prompt evidence, and reviewer notes.

That is the difference between "the candidate used AI" and "the candidate used AI, inspected the result, caught the broken mobile state, and fixed it."

The second sentence is evidence. The first one is theater.

Two candidates, one green check

Picture two candidates handed the same task. Both submit. Both go green. If the report stopped at the test result, a hiring team would rank them as equals and move on.

Now look at the work.

The first candidate read the prompt, wrote a short plan, and asked the AI for a specific piece with the constraints spelled out. When the generated code came back, she read the diff before keeping it, ran the preview, noticed the layout collapsed on a narrow viewport, and asked for a targeted fix rather than a rewrite. The final commit is mostly model-generated, and that is fine, because every change passed through a decision she can defend.

The second candidate typed a vague request, accepted the first thing that appeared, and then the next one, and the next. The suggestion happened to be correct. He never opened the preview. He could not tell you why the code works, because at no point did he ask.

Same final files. Same green check. Two completely different pieces of evidence about how each person builds when the tools are doing part of the work.

A reviewer opening the first session can follow it: a goal, a directed request, a diff that was read, a failure that was caught, and a fix that was checked. Opening the second, the trail goes quiet right after the first accept, and quiet is its own signal. Neither candidate is being punished for using AI. They are being told apart by what they did with it.

This is why we stopped treating "used AI" as a single flag. Accepting a good suggestion blindly and directing a tool toward a good suggestion look identical in the final artifact and nothing alike in the trail. A report that flattens them is scoring luck and calling it skill.

Why not just turn the tools off

The clean-looking answer to all of this is to ban the tools and grade the code the old way. It is tempting because it removes the hard measurement problem. It also measures a workflow the job no longer uses. A no-AI assessment tells a hiring team how a candidate performs in an environment they will never work in again, which is a strange thing to select on.

There are real cases for an AI-off baseline, and the presets support one, which is why we kept it. But it should be a deliberate choice for a specific reason, not the default hiding place for a product that found AI too messy to score. The harder path, measuring judgment inside the messy workflow, is the one that matches what the person will actually be hired to do.

Presets without changing the language

Different roles need different weights. A front-end build can care more about browser evidence. A classic no-AI baseline can set AI direction to zero. A debugging task can care more about iteration and verification.

But the public report should not invent a new language for every assessment. The five competencies stay stable while role presets adjust weights underneath.

That stability earns its keep with the people reading dozens of reports a week. A reviewer learns one report shape, and every assessment after that is faster to judge because the axes never move even when their weights do.

When evidence becomes noise

There is a failure mode buried in all of this, and it is the part these posts usually skip. Evidence has a cost. Every snapshot, every captured action, every logged prompt is something a reviewer has to read or deliberately ignore. Collect enough of it and you have not built trust, you have built a haystack, and the one thing the hiring team needed is somewhere inside it under twenty minutes of scrubbing.

Two things break when evidence turns into volume. The reviewer stops reading, so the richest report gets the same tired glance as the thinnest one. And the candidate starts to feel watched instead of assessed, which changes how they work in ways that make the signal worse rather than better. Someone performing for a log writes different code than someone solving a problem.

So the discipline is not capture everything. It is capture what the candidate acted on. A prompt that led to a kept change and a caught bug is signal. A raw stream of every keypress is noise wearing a lab coat. The proof a reviewer actually wants is short: what was the goal, what ran, where did the candidate look, and what did they do when something failed. Evidence that answers none of those has no reason to be in the report.

The scarce resource here is not storage. It is reviewer attention, and a report that spends it carelessly is worse than a shorter one that respects it.

The report has two audiences

Most scoring conversations assume one reader, the hiring team. An AI-native report has a second reader it cannot afford to ignore, which is the candidate. That second reader is easy to design away, because they are not in the room when the report gets built. Designing for them anyway is the difference between a tool that ranks people and one they would trust to have ranked them.

If a report is legible only to the people making the decision, it is a verdict, not an assessment. The candidate should be able to open the same five competencies and see why a clean technical submission still scored low on verification, or why accepting everything unread cost them on AI direction even though the tests passed. Readability there does more than flatter the candidate. It keeps the scoring honest, because a report you can explain to the person it judged is one you have actually reasoned through, and a report you cannot explain is usually one the tooling decided for you.

It also pulls candidate behavior in the right direction. When people can see that reading a diff and catching a failure is the thing being rewarded, they read diffs and catch failures. The report stops being a hidden rubric to game and starts describing the skill the job needs.

What this does not claim

This does not make scoring final, magic, or fully automatic. Review still matters, and so do calibration and human judgment on the calls a model cannot settle.

The point is narrower and more useful: AI-native assessments need artifacts that make judgment inspectable. If the product asks a candidate to build in a modern workflow, the report should show how they used that workflow. Get that right and the green check stops being the answer. It becomes the least interesting thing on the page.