Skip to content
Aferiz

Documenting is easy. Proving the code does what was asked isn't.

Aferiz reads the requirement from your source of truth, looks at the code in the commit you point to, and answers criterion by criterion, with evidence at file:line.

Talk to usSee the demo

No signup — the demo shows everything before any conversation.

Pick a requirement

A real attestation, no signup:

Book an exam with preparation confirmation

commit c7d2a109 criteria

Met
4
Partial
1
Not met
2
Inconclusive
2
C1POST /agendamentos/exames endpoint · Controllers/AgendamentoController.cs:69Met

Route declared in the controller and covered by an integration test that books and reads back the created slot.

EvidenceControllers/AgendamentoController.cs:69commit c7d2a10

C2Preparation instructions returned per exam type · Servicos/PreparoExameService.cs:24Met

Fasting, suspended medication and the guidance text come from the preparation registry, by exam type, not from a constant in the code; a type with no rule fails explicitly instead of returning an empty preparation.

EvidenceServicos/PreparoExameService.cs:24commit c7d2a10

C3Times stored in the site’s time zone · Servicos/AgendamentoService.cs:63Partial

Three of the four date fields go through the site converter, which falls back to America/Sao_Paulo when the site has no zone on file. DataSolicitacao stores raw UTC and shows up three hours ahead in the record.

EvidenceServicos/AgendamentoService.cs:63commit c7d2a10

C4Preparation confirmation required in the request · Validadores/AgendarExameValidator.cs:14Met

A request without the patient’s acknowledgement is refused in the validator, before it reaches the service, with a message in the user’s language.

EvidenceValidadores/AgendarExameValidator.cs:14commit c7d2a10

C5The booking protocol carries the exam date · Controllers/AgendamentoController.cs:85Met

Pattern AGD-yyyyMMdd-0000, assembled in the controller from the exam date and the day’s sequence number — not from the date the request was made.

EvidenceControllers/AgendamentoController.cs:85commit c7d2a10

C6A slot already taken on the professional’s schedule is blocked at booking · Servicos/DisponibilidadeProfissionalService.cs:45Not met

The free-slot grid comes from the professional’s shift alone, and the only filter applied is the lunch break. An exam already booked is never subtracted, so two patients end up holding the same professional’s 8 a.m.; that subtraction was expected right here, in the slot builder.

EvidenceServicos/DisponibilidadeProfissionalService.cs:45commit c7d2a10

C7Booking limited to the Front desk and Clinical staff roles · Controllers/AgendamentoController.cs:76Not met

The endpoint requires authentication and nothing else: no Roles, no policy. Any authenticated user — including the patient logged into the portal — books an exam against any record.

EvidenceControllers/AgendamentoController.cs:76commit c7d2a10

C8Cap of 40 exams per shift in the collection roomInconclusive

The service counts the shift’s bookings, but nothing in the commit sets 40 as the cap. The number may live in the site’s configuration, which is not in this repository.

No evidence in the code

C9Access to health data recorded in the audit trailInconclusive

The agent answered Met, citing Infra/Auditoria/AuditoriaService.cs:214. The file has 190 lines at commit c7d2a10 — the cited line does not exist, so the verdict dropped to inconclusive. With health data, recording who read what is an LGPD requirement, so the item goes back for human review.

Evidence not confirmedInfra/Auditoria/AuditoriaService.cs:214Met → Inconclusive

A fictional medical clinic — C# API, TypeScript front end — with the attestations pre-computed.

Open the full demo

Nobody compares the two sides

The requirement starts in a card. It becomes code. The code goes to code review. The review is done by someone who read the diff, not the requirement. The delivery is accepted by someone who read the requirement, not the diff.

Tests prove the code does what the code says. Lint and Sonar look at internal quality. Code review depends on the reviewer having read the spec. The question "does this meet what was asked?" belongs to no one.

Requirement · ClickUp

Book an exam with preparation confirmation

  • Show the preparation instructions before confirming
  • Refuse a slot already taken on the professional’s schedule
  • Record who accepted the preparation and when
Code · vitalis-api

                88
                public async Task<Result<Agendamento>> AgendarAsync(
              
                89
                    AgendarExameRequest req, CancellationToken ct)
              
                90
                {
              
                91
                    var exame = await _exames.ObterAsync(req.ExameId, ct);
              
                92
                    var slot  = await _agenda.ReservarAsync(req.Slot, ct);
              
                93
                
              
                94
                    return await _repo.SalvarAsync(
              
                95
                        new Agendamento(exame, slot, req.PacienteId), ct);
              
                96
                }
never made it across

From request to delivery

  1. You write what you need

    The way your team already writes it, in the tool you already use.

  2. It pushes back early

    It reads the system you already have and points out what does not add up — while changing is still cheap.

  3. You settle what was agreed

    Whatever you agreed on becomes the document everyone follows.

  4. At delivery, it compares

    Item by item: what was built against what was agreed.

  5. And shows you where

    It only claims something is done if it can point to the exact place. If it cannot, it does not claim.

Evidence, not opinion

An AI opinion with no evidence is both irrefutable and useless. Every Aferiz verdict points to file, line and commit. And when the cited evidence is not in the code, we downgrade our own verdict to inconclusive.

Generic assistant
"The implementation appears to cover the requirement correctly and follows best practices."
Aferiz

C7Not met

AgendamentoController.cs:76

booking endpoint with no role check

commit c7d2a10

Saying this out loud is counterintuitive. But it is the difference between a tool you double-check and a tool you use.

What changes on each desk

Same mechanism — requirement, code, evidence. What it changes in your day depends on where you sit.

  • Whoever writes the requirement

    today

    The card becomes a task without ever meeting the code. The contradiction turns up at sprint review, when changing it already costs.

    with Aferiz

    Before it becomes a task, the requirement is checked against the code that already exists. It comes back with objections that name file and line and ask a question you can answer. Fixing it costs a sentence.

    V2 · open · DisponibilidadeProfissionalService.cs:45

  • Whoever writes the code

    today

    The task arrives with the text of the card. What was actually agreed surfaces at code review — or after it.

    with Aferiz

    The task arrives with explicit criteria, already checked against the real system. At code review, the opinion names what is not met, and the line where.

    C7 · not met · AgendamentoController.cs:76

  • Whoever tests it

    today

    Cases come out of the text of the card. Tests get written just in case, and nobody knows which criterion was left uncovered.

    with Aferiz

    Every test case is born traced to the criterion it covers. A criterion with no case shows up as a gap on screen — and so does a case that covers no criterion.

    C6 · no test case

  • Whoever runs the area

    today

    The gap between what was asked and what was delivered turns up at the end: in UAT, in the demo, at the customer.

    with Aferiz

    It turns up at code review, criterion by criterion. And the reason behind each rule stays on record: every objection accepted or pushed back becomes project history.

    V2 · accepted with a change · on record

The business case, in three parts

You choose where your code goes

The same agent runs on any engine. Sensitive code stays on the local model, inside your own infrastructure. Sovereignty means being able to switch engines — not a closed model under another name.

  • claude-code
  • codex
  • opencode
  • grok
  • local model

Switching runtime does not change the agent definition. Same yardstick, different engine.

Nothing has to move

The requirement stays in ClickUp, the code in GitLab, the ping in Discord. Aferiz reads one side, checks the other and leaves the verdict in the code review — nothing to migrate, no process to change, not one more tab for the team to keep open.

where the requirement comes from

  • ClickUp
  • Jira
  • Linear
  • NextWiki

where the code comes from

  • GitLab
  • GitHub
  • Bitbucket
  • Azure DevOps

where the ping goes

  • Slack
  • Discord
  • Teams
  • E-mail

Frequently asked questions

Where does my code go?

To the runtime you pick. The screen shows it before running. On self-hosted with a local model, the code never leaves your infrastructure.

What if the AI gets the verdict wrong?

It does get things wrong. That is why every positive verdict requires evidence we verify against the commit — the file and line must exist. If they do not, the verdict drops to inconclusive automatically. And you mark agree or disagree on each one, which feeds calibration.

Do you commit anything to my repository?

No. Never. Aferiz does not write feature code and does not commit or push, under any circumstance. It reads the code and comments.

Does it work without a well-written card?

It works worse. With no requirement there is nothing to attest. If the card is vague the criteria come out vague — which is why they are editable before the check, and a check over unreviewed criteria is labeled as such.

Does it replace code review?

No — it joins it. Aferiz comments on the code review as one more opinion, and the reviewer still decides. The difference is the question: a human reviewer looks at how the code is written; the attestation looks at whether it meets what was asked, criterion by criterion, with the file line in hand. Both matter.

Does it replace Sonar?

No, and it uses Sonar’s output. Sonar answers "is this code well written?" — complexity, duplication, vulnerabilities, coverage. Aferiz answers "does this code do what was asked?". The already-taken-slot check the card required is missing from the booking? Sonar goes green, because the code is clean. A method with cyclomatic complexity 30? Aferiz does not see it, because the requirement said nothing about that. In the pipeline, static analysis and tests run first and feed the attestation.

Does this replace the developer?

No, and it should not. Aferiz does not write code, does not decide merges and does not resolve anything on its own: it shows the gap between what was asked and what was delivered, with evidence, so a person can decide what to do. Whoever writes the code, negotiates the deadline, understands the client context and knows when a rule has an exception is still the team. What leaves the developer’s desk is the manual, repetitive cross-checking — the judgement stays.

Does approving a proposal approve the merge?

No. Approving publishes the Aferiz comment on the code review — an API call that creates a note. The MR/PR approval state is never touched, on GitLab, GitHub or Azure. Merge approval stays with people. If you want a negative verdict to block the merge, that is a CI check driven by the webhook, with the rule living in your own repository.

Does it work with my language?

It works with any of them. Aferiz is not a static analyzer tied to one syntax: an agent opens the repository, reads the files, searches, checks the history, and compares what it finds against the requirement. That holds for Java, Python, Go, TypeScript, PHP, Kotlin, Rust — and for what is not code either: migrations, configuration files, pipelines. The honest limit is the model of the runtime you configure, which has to read the language well; today’s models read the widely used ones well. What changes the result more than the language does is how clear the project’s standard is: the more explicit the agreement, the sharper the verdict.

Self-hosted GitLab? Monorepo?

Yes to self-hosted GitLab. For monorepos, one attestation can span several repositories or folders — backend and frontend in the same verdict.

No more “that is not what I asked for”

Write to us and we will show how Aferiz speeds up delivery, cuts rework and improves your project’s margin.

What was agreed becomes a criterion, and every delivery shows what it met — without changing the tools your team already uses.

Write straight to

contact@aferiz.com

Open in your email app

It helps if you tell us how your team agrees today on what will be built — ClickUp, Jira, a wiki, a spreadsheet or email. That way the answer already fits your context.