I evaluate AI-generated coding work against what the task actually requires.
For AI teams that need a Software Engineer to assess whether a coding response or implementation actually satisfies the task.
I work from the task and evaluation criteria, inspect the response and relevant code, use tests or a real run when the conclusion depends on them, and return structured technical feedback at the criterion level.
First scope
One coding task or one implementation claim.
Best for
AI teams that need criterion-level engineering judgment on a coding response or implementation claim.
You receive
Criterion-level technical feedback grounded in code, tests, and runtime evidence.
From a coding task to criterion-level technical feedback.
The first scope stays bounded. I start with one task or implementation claim, check each criterion against the available code and evidence, and return a result another evaluation or correction can build on.
One bounded evaluation
Human-reviewed engineering evidence
01 · Input
Task and criteria
- Coding response or implementation claim
- Expected behavior and evaluation criteria
02 · Evaluation
Evidence I check
- AI response and relevant code
- Tests, runtime behavior, and edge cases
03 · Output
Criterion-level result
- Supported, partially supported, incorrect, or cannot verify
- Material findings and the next evaluation step
Across every criterion
Engineering judgment
Tools can capture code, commands, tests, and runtime output. I determine what that evidence supports for each criterion and explain material failures or missing evidence.
- The task, requirement, and evaluation criteria: what the response or implementation needs to satisfy.
- The AI-generated response and relevant code, including whether the implementation supports the claims made about it.
- Tests and runtime evidence: what they prove, what they miss, and whether they expose material edge cases.
- Each criterion separately, so a mixed result is not flattened into one pass or fail.
- A structured evaluation with each criterion marked supported, partially supported, incorrect, or cannot verify.
- Material technical findings, including incorrect logic, missing behavior, weak tests, and relevant edge cases.
- The evidence behind each conclusion and the next correction or evaluation step when something is missing.
- Each result applies to the criterion and material reviewed. It does not become a claim about the model as a whole, and a passing test or confident response does not decide the outcome by itself.
- You are building, training, benchmarking, or evaluating a coding model or agent and need contract or embedded software-engineering judgment on coding outputs or implementation claims.
- This is not a model-wide benchmark, security certification, or guarantee of correctness or production readiness.
- It is not a standalone audit package for an entire agent-built product. Product implementation and broken product flows belong under Product Engineering or Integrations & Stabilization.
Send one task or implementation claim, the criteria or expected behavior, and the response, code, tests, or runtime material available. We confirm whether the first scope is one bounded evaluation or the start of ongoing contract support.
PatchTrace
A Python CLI I built to record coding-agent sessions and compare declared file, test, and verification claims with Git changes and command output. It shows how I preserve evidence behind an evaluation; it does not decide whether code is correct.
What coding work needs evaluation?Send the task or implementation claim, the criteria, the material to review, and whether you need one bounded evaluation or ongoing contract support. I'll tell you what I can evaluate from the evidence available.