Saltar al contenido
Aferiz

Documentar es fácil. Probar que el código hace lo que se pidió, no.

Aferiz lee el requisito en tu fuente de verdad, mira el código en el commit que indiques y responde, criterio a criterio, con evidencia en archivo:línea.

HablemosVer la demo

Sin registro — la demo muestra todo antes de cualquier conversación.

Elige un requisito

Atestado real, sin registro:

Agendar examen con confirmación de preparación

commit c7d2a109 criterios

Cumple
4
Parcial
1
No cumple
2
No concluyente
2
C1Endpoint POST /agendamentos/exames · Controllers/AgendamentoController.cs:69Cumple

Ruta declarada en el controlador y cubierta por una prueba de integración que agenda y vuelve a leer el horario creado.

EvidenciaControllers/AgendamentoController.cs:69commit c7d2a10

C2Instrucciones de preparación devueltas según el tipo de examen · Servicos/PreparoExameService.cs:24Cumple

Ayuno, medicación suspendida y el texto de orientación vienen del registro de preparación por tipo de examen, no de una constante en el código; un tipo sin regla falla explícito en vez de devolver una preparación vacía.

EvidenciaServicos/PreparoExameService.cs:24commit c7d2a10

C3Horarios guardados en el huso de la sede · Servicos/AgendamentoService.cs:63Parcial

Tres de los cuatro campos de fecha pasan por el conversor de la sede, que cae en America/Sao_Paulo cuando la sede no tiene zona registrada. DataSolicitacao guarda UTC crudo y aparece tres horas adelantado en la historia clínica.

EvidenciaServicos/AgendamentoService.cs:63commit c7d2a10

C4Confirmación de preparación obligatoria en la solicitud · Validadores/AgendarExameValidator.cs:14Cumple

La solicitud sin la aceptación del paciente se rechaza en el validador, antes de llegar al servicio, con un mensaje en el idioma del usuario.

EvidenciaValidadores/AgendarExameValidator.cs:14commit c7d2a10

C5El protocolo del agendamiento contiene la fecha del examen · Controllers/AgendamentoController.cs:85Cumple

Patrón AGD-yyyyMMdd-0000, armado en el controlador con la fecha del examen y el secuencial del día, no con la fecha en que se hizo el pedido.

EvidenciaControllers/AgendamentoController.cs:85commit c7d2a10

C6El horario ya ocupado del profesional se bloquea en la reserva · Servicos/DisponibilidadeProfissionalService.cs:45No cumple

La grilla de horarios libres sale solo de la agenda del profesional, y el único filtro aplicado es el intervalo de almuerzo. Un examen ya reservado no se descuenta, así que dos pacientes se quedan con las 8 h del mismo profesional; ese descuento se esperaba aquí, en el armador de las franjas.

EvidenciaServicos/DisponibilidadeProfissionalService.cs:45commit c7d2a10

C7Reserva limitada a los perfiles Recepción y Cuerpo Clínico · Controllers/AgendamentoController.cs:76No cumple

El endpoint exige autenticación y nada más: sin Roles, sin policy. Cualquier usuario autenticado —incluido el propio paciente conectado al portal— agenda un examen en cualquier historia clínica.

EvidenciaControllers/AgendamentoController.cs:76commit c7d2a10

C8Tope de 40 exámenes por turno en la sala de tomaNo concluyente

El servicio cuenta los agendamientos del turno, pero nada en el commit fija 40 como tope. El número puede estar en la parametrización de la sede, que no vive en este repositorio.

Sin evidencia en el código

C9El acceso al dato de salud queda en la traza de auditoríaNo concluyente

El agente respondió Cumple, citando Infra/Auditoria/AuditoriaService.cs:214. El archivo tiene 190 líneas en el commit c7d2a10: la línea citada no existe, y el veredicto bajó a no concluyente. En datos de salud, registrar quién leyó qué es una exigencia de la LGPD, así que el ítem vuelve a revisión humana.

Evidencia no confirmadaInfra/Auditoria/AuditoriaService.cs:214Cumple → No concluyente

Ejemplo ficticio de una clínica médica — API en C#, front en TypeScript — con los atestados precomputados.

Abrir la demo completa

Nadie compara los dos lados

El requisito nace en una tarjeta. Se vuelve código. El código pasa a code review. La revisión la hace quien leyó el diff, no el requisito. La entrega la acepta quien leyó el requisito, no el diff.

Las pruebas demuestran que el código hace lo que el código dice. Lint y Sonar miran la calidad interna. La revisión depende de que el revisor haya leído la spec. La pregunta «¿esto cumple lo que se pidió?» no tiene dueño.

Requisito · ClickUp

Agendar examen con confirmación de preparación

  • Mostrar las instrucciones de preparación antes de confirmar
  • Rechazar un horario ya ocupado del profesional
  • Registrar quién aceptó la preparación y cuándo
Código · 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
                }
no cruzó

Del pedido a la entrega

  1. Escribes lo que necesitas

    Como tu equipo ya lo escribe, en la herramienta que ya usa.

  2. Cuestiona antes

    Lee el sistema que ya existe y señala lo que no cuadra con el pedido — mientras cambiar todavía es barato.

  3. Cierran lo acordado

    Lo que quedó acordado se vuelve el documento que todos siguen.

  4. En la entrega, compara

    Punto por punto: lo que se construyó contra lo que se acordó.

  5. Y muestra dónde

    Solo afirma que algo está listo si puede señalar el lugar exacto. Si no lo muestra, no lo afirma.

Evidencia, no opinión

Un dictamen de IA sin evidencia es irrefutable e inútil. Cada veredicto de Aferiz señala archivo, línea y commit. Y cuando la evidencia citada no está en el código, degradamos nuestro propio veredicto a no concluyente.

Asistente genérico
«La implementación parece cubrir el requisito correctamente y sigue buenas prácticas.»
Aferiz

C7No cumple

AgendamentoController.cs:76

endpoint de agendamiento sin verificación de perfil

commit c7d2a10

Decirlo en voz alta es contraintuitivo. Pero es la diferencia entre una herramienta que revisas y una que usas.

Qué cambia en el día de cada uno

Es el mismo mecanismo — requisito, código, evidencia. Lo que cambia en el día depende de qué lado de la mesa estés.

  • Quien escribe el requisito

    hoy

    La tarjeta se vuelve tarea sin cruzarse nunca con el código. La contradicción aparece en la sprint review, cuando cambiarla ya salió cara.

    con Aferiz

    Antes de volverse tarea, el requisito se confronta con el código que ya existe. Vuelve con salvedades que señalan archivo y línea y hacen una pregunta que se puede responder. Ajustarlo cuesta una frase.

    V2 · abierta · DisponibilidadeProfissionalService.cs:45

  • Quien desarrolla

    hoy

    La tarea llega con el texto de la tarjeta. Lo que de verdad se había acordado se descubre en el code review — o después.

    con Aferiz

    La tarea llega con criterios explícitos, ya contrastados con el sistema real. En el code review, el dictamen señala lo que no cumple y en qué línea.

    C7 · no cumple · AgendamentoController.cs:76

  • Quien prueba

    hoy

    Los casos salen del texto de la tarjeta. Se escriben pruebas por las dudas, y nadie sabe qué criterio quedó sin cubrir.

    con Aferiz

    Cada caso de prueba nace trazado al criterio que cubre. Un criterio sin caso aparece como brecha en pantalla — y un caso que no cubre ningún criterio, también.

    C6 · sin caso de prueba

  • Quien lidera el área

    hoy

    La diferencia entre lo que se pidió y lo que se entregó aparece al final: en la homologación, en la demo, en el cliente.

    con Aferiz

    Aparece en el code review, criterio por criterio. Y el porqué de cada regla queda registrado: cada salvedad aceptada o rebatida se vuelve historia del proyecto.

    V2 · aceptada con ajuste · en el registro

El argumento de negocio, en tres ejes

Tú eliges adónde va tu código

El mismo agente corre en cualquier motor. El dato sensible se queda en el modelo local, dentro de tu propia infraestructura. Soberanía es poder cambiar de motor — no un modelo cerrado con otro nombre.

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

Cambiar de runtime no cambia la definición del agente. La misma vara, otro motor.

Nada cambia de lugar

El requisito sigue en ClickUp, el código en GitLab, el aviso en Discord. Aferiz lee de un lado, revisa del otro y deja el dictamen en el code review — nada que migrar, ningún proceso que cambiar, ni una pestaña más que abrir.

de dónde viene el requisito

  • ClickUp
  • Jira
  • Linear
  • NextWiki

de dónde viene el código

  • GitLab
  • GitHub
  • Bitbucket
  • Azure DevOps

adónde va el aviso

  • Slack
  • Discord
  • Teams
  • E-mail

Preguntas frecuentes

¿Adónde va mi código?

Al runtime que elijas. La pantalla lo muestra antes de ejecutar. En self-hosted con modelo local, el código no sale de tu infraestructura.

¿Y si la IA se equivoca en el veredicto?

Se equivoca. Por eso todo veredicto positivo exige evidencia que verificamos contra el commit: el archivo y la línea tienen que existir. Si no existen, el veredicto baja a no concluyente automáticamente. Y tú marcas de acuerdo o en desacuerdo en cada uno, lo que alimenta la calibración.

¿Hacen commit en mi repositorio?

No. Nunca. Aferiz no escribe código de feature y no hace commit ni push, bajo ninguna circunstancia. Lee el código y comenta.

¿Funciona sin una tarjeta bien escrita?

Funciona peor. Sin requisito no hay qué atestar. Si la tarjeta es vaga los criterios salen vagos — por eso son editables antes del atestado, y un atestado sobre criterios no revisados queda marcado como tal.

¿Reemplaza el code review?

No — se suma a él. Aferiz comenta en el code review como una opinión más, y quien revisa sigue decidiendo. La diferencia es la pregunta: quien revisa mira cómo está escrito el código; el atestado mira si cumple lo que se pidió, criterio por criterio, con la línea del archivo a la vista. Las dos importan.

¿Reemplaza a Sonar?

No, y usa su resultado. Sonar responde «¿está bien escrito este código?» — complejidad, duplicación, vulnerabilidades, cobertura. Aferiz responde «¿este código hace lo que se pidió?». ¿Falta en la reserva la verificación de horario ya ocupado que la tarjeta exigía? Sonar pasa en verde, porque el código está limpio. ¿Un método con complejidad 30? Aferiz no lo ve, porque el requisito no hablaba de eso. En el pipeline, el análisis estático y las pruebas corren antes y alimentan el atestado.

¿Esto reemplaza al desarrollador?

No, y no debería. Aferiz no escribe código, no decide merges y no resuelve nada solo: muestra la diferencia entre lo que se pidió y lo que se entregó, con evidencia, para que una persona decida qué hacer. Quien escribe el código, negocia el plazo, entiende el contexto del cliente y sabe cuándo una regla tiene excepción sigue siendo el equipo. Lo que sale del escritorio del dev es la verificación manual y repetitiva — el criterio se queda.

¿Aprobar una propuesta aprueba el merge?

No. Aprobar publica el comentario de Aferiz en el code review — una llamada de API que crea una nota. El estado de aprobación del MR/PR no se toca, ni en GitLab, ni en GitHub, ni en Azure. La aprobación del merge sigue siendo de las personas. Si quieres que un veredicto negativo bloquee el merge, eso se hace con un check de CI a partir del webhook, con la regla en tu propio repositorio.

¿Funciona con mi lenguaje?

Funciona con cualquiera. Aferiz no es un analizador estático atado a una sintaxis: un agente abre el repositorio, lee los archivos, busca, consulta el historial y contrasta lo que encuentra con el requisito. Vale para Java, Python, Go, TypeScript, PHP, Kotlin, Rust — y vale también para lo que no es código: migraciones, archivos de configuración, pipelines. El límite honesto es el modelo del runtime que configures, que tiene que leer bien el lenguaje; los modelos de hoy leen bien los más usados. Lo que cambia el resultado más que el lenguaje es la claridad del patrón del proyecto: cuanto más explícito lo acordado, más afilado el veredicto.

¿GitLab self-hosted? ¿Monorepo?

Sí a GitLab self-hosted. Para monorepos, un atestado puede abarcar varios repositorios o carpetas — backend y frontend en el mismo veredicto.

Basta de “pero yo pedí otra cosa”

Escríbenos y te mostramos cómo Aferiz acelera la entrega, reduce el retrabajo y aumenta el margen de tu proyecto.

Lo acordado se vuelve criterio, y cada entrega muestra lo que cumplió — sin cambiar las herramientas que tu equipo ya usa.

Escribe directo a

contact@aferiz.com

Abrir en tu correo

Ayuda si nos cuentas cómo tu equipo acuerda hoy lo que se va a hacer — ClickUp, Jira, una wiki, una planilla o correo. Así la respuesta ya llega en tu contexto.