CounterProof es una práctica de revisión adversarial independiente para bases de código modernas — el código escrito por máquinas, ante todo. Entregamos lo único que usted no puede producir en casa: una evaluación de seguridad independiente, firmada, graduada por nivel de evidencia, construida para el escrutinio de reguladores, compradores, aseguradoras y clientes corporativos.
Un código escrito por un modelo y revisado por el mismo modelo no ha sido revisado por nadie.
Nadie compra una revisión de código. Se compra lo que desbloquea.
Usted no está leyendo esto porque se haya despertado queriendo una evaluación de seguridad. Algo le está pidiendo evidencia.
Tres de estos cuatro nunca aceptan su palabra sobre su propio código — la independencia es la propiedad que compran, y es la única propiedad que ningún equipo puede suministrar sobre su propio trabajo. El cuarto, el regulador, aceptará a menudo su autoevaluación — y luego le exigirá cada registro que la sustenta. En ambos casos, la evidencia tiene que sostenerse. Eso es lo que producimos.
El entregable es la cuestión.
Un encargo produce una CounterProof Assessment bajo un identificador de encargo persistente (CPR-YYYY-NNN — lo que citan sus mantenedores, su comprador o sus commits de corrección). Cada hallazgo se confirma contra su código fuente — fichero y línea exactos, ruta de reproducción, clasificación de impacto — o se gradúa explícitamente como solo plausible. Nada de relleno, nada generado por escáner, nada sobre lo que no pueda actuar.
Cada hallazgo nombra el peldaño de evidencia que alcanzó realmente — traza en el código fuente, prueba de compilación, test o reproducción en ejecución — y nunca insinúa uno superior. Cada cita ruta:línea se resuelve mecánicamente contra la revisión exacta que revisamos antes de que el informe salga de nuestras manos. Puede comprobar nuestro trabajo. Es deliberado.
El mercado ha empezado a competir en cuántos hallazgos puede generar una herramienta — pero un hallazgo es un testigo, no un veredicto, y la etiqueta de gravedad que hace el titular es el único campo que nadie puede comprobar. Un hallazgo no es un veredicto →
La fluidez no es señal de calidad. Es el modo de fallo.
Cuando una persona escribe una línea de código, duda de ella. Sabe que estaba adivinando — y esa duda es un dispositivo de seguridad, porque es lo que la lleva a ir a probar la cosa.
Un modelo escribe la misma línea con fluidez, precisamente con la voz que usa para las líneas que son correctas. Para quien lee, la fluidez se lee como competencia. Un ingeniero junior le entrega algo visiblemente tosco y usted lo comprueba. Un modelo le entrega doscientas líneas pulidas con una razón segura para cada una, y usted no lo hace.
La trampa no es que los modelos se equivoquen más a menudo que las personas. Es que sus respuestas erróneas llegan con la misma voz que las correctas — indistinguibles desde fuera, porque son indistinguibles desde dentro.
Luego el mismo proceso escribe el test que certifica el código, y el comentario que lo explica. Los tres concuerdan, porque los tres salieron del mismo sitio. Esa concordancia se lee como tres confirmaciones independientes. Es una.
Así que la pregunta útil no es si un modelo puede escribir buen código — puede, con un método alrededor. Es qué está midiendo realmente su proceso de revisión cuando todo lo que inspecciona salió de la misma fuente: el código, el test, la explicación y, cada vez más, la herramienta que usted construyó para comprobarlos. Bien hecho, el resultado es bueno. Mal hecho, se lee exactamente igual.
Una revisión encuentra lo que su revisor puede encontrar.
Pase un modelo sobre una base de código y un informe breve le dice algo estrecho: ese modelo, en ese arnés, ese día, sacó a la superficie esto. Lo que no sacó no está en el informe, y por construcción no puede estarlo.
Cuánto importa eso depende de cuánto se solapen los puntos ciegos de distintos revisores — lo cual, para la revisión de código, nadie ha medido. La investigación sobre errores correlacionados entre proveedores encontró un solapamiento sustancial en bancos de pruebas de opción múltiple y en una tarea de cribado de currículos; que eso se traslade a encontrar vulnerabilidades no está establecido. Lo que sí muestra: proveedores distintos no son automáticamente independientes entre sí.
Varias cosas pueden acotar lo que una sola pasada omitió: una prueba formal, una suite de tests, un fuzzer, un especialista, defectos sembrados, o un revisor distinto del primero. Lo que no puede acotarlo: leer la misma pasada con más confianza.
No hemos demostrado que la revisión multi-revisor atrape más defectos reales — el experimento que diseñamos para comprobarlo se retiró antes de ejecutarse, y lo decimos públicamente. El punto más estrecho es el que defendemos: una pasada limpia de un revisor es un resultado delimitado, y leerla como certificado de limpieza es una inferencia que ese resultado no sostiene. El argumento completo (en inglés) →
Hemos dejado el argumento largo por escrito, incluido dónde están los límites de nuestro propio método y lo que no hemos demostrado: una introducción en lenguaje llano, y el artículo completo detrás de ella, publicado como preprint bajo doi:10.5281/zenodo.22030516 (CC BY 4.0), en inglés. No está revisado por pares, y lo dice.
Usted podría ejecutar los mismos modelos. No puede ser independiente.
Pasar varios modelos de IA sobre su propio código replica nuestras herramientas y pierde la propiedad que importa. Su equipo elige lo que ven los revisores, encuadra las preguntas y juzga las respuestas — y cada una de esas decisiones devuelve sus supuestos directamente a la revisión. No es un fallo de disciplina; es estructural. El autor de un sistema no puede ser su propio árbitro.
Incluso una revisión interna impecable sigue siendo su palabra sobre su propio código. Lo que ellos compran es un tercero dispuesto a firmar. No somos un organismo notificado y no certificamos conformidad; producimos la evidencia independiente que apoya su evaluación y que está estructurada para ser reexaminada por la de cualquier otro.
Al método le da igual quién — o qué — escribió su código. La independencia falta en el código escrito por humanos con la misma frecuencia. El código escrito por máquinas solo hace que la brecha sea imposible de ignorar.
Lo descubriría de todos modos. Mejor que lo oiga de nosotros.
CounterProof forma parte de un grupo que construye infraestructura de pagos y de custodia de activos digitales. Ahí se forjó este método — y significa que, si usted construye en esos mercados, nuestra filial puede ser adyacente a usted, o competir con usted.
Así que: antes de cualquier encargo, le decimos por escrito exactamente qué construye el grupo y dónde opera. Usted decide si eso es aceptable, y lo decide antes de habernos pagado nada. Si no es aceptable, es una respuesta legítima y preferimos oírla al principio.
Lo que nuestra afirmación de independencia cubre y no cubre, con precisión: no emitimos evaluación alguna sobre código escrito por CounterProof o por cualquier empresa de nuestro grupo. Ese límite es estructural. Es una afirmación sobre el código de quién revisamos, no la pretensión de no tener intereses comerciales en ninguna parte cerca de su sector — ninguna firma de revisión con verdadera experiencia de dominio puede afirmar honestamente lo segundo, y no vamos a fingirlo.
Tres personas, con nombre, en el expediente.
Una evaluación firmada significa que el nombre de alguien está en ella. Estas son las personas — y qué nombre lleva qué.
Somos una práctica familiar — padre, hijo e hija — y el banco de revisión lo forman dos personas. Ambos son hechos que un equipo de due diligence descubre por sí solo, así que preferimos decirlos aquí: un banco de dos revisores acepta menos encargos que una firma, declina todo lo que queda fuera de su dominio y no puede esconder una pasada floja detrás de una marca. Ese es el intercambio, y es la razón por la que el método está escrito y mecanizado en lugar de llevarse en la cabeza de alguien.
Lo que estamos leyendo, y lo que estamos comprobando.
Tres estudios independientes, tres métodos distintos — un estudio dirigido de vulnerabilidades, una comparación controlada humano-modelo y un año de observación de repositorios reales — convergen en el mismo hallazgo: el código generado por IA acarrea un coste de calidad medible que sobrevive a la ganancia de productividad con la que llegó.
La IA puede generar hoy miles de hallazgos de vulnerabilidad en una tarde. Un hallazgo es un testigo, no un veredicto — y el único campo que nadie puede comprobar es el que todos inflan. Así se lee la avalancha sin ahogarse en ella.
La IA ha hundido el coste de encontrar vulnerabilidades. En el ecosistema open source de Bitcoin esa colisión llegó este mes — y Bruselas ha puesto un reloj sobre lo que viene después.
Háblenos antes de que lo haga el plazo.
Las solicitudes de información van a Elenora Soons, gestora de cuentas: