EN·ES·PT
El método · cómo funciona realmente cada proyecto

El Método Proof-First

La mayoría del trabajo con IA se lanza con una demo y un rezo — y un cliente encuentra lo único que falla. El mío se lanza detrás de una compuerta, con la evidencia adjunta. Este es el sistema operativo exacto que hace funcionar mis dos productos en vivo, aplicado a tu build: cuatro fases, un artefacto concreto producido en cada una, y el estándar aplicado antes de que algo avance.

Alcance fijo, por escrito Un artefacto en cada fase Hecho = verificado, no afirmado
El ciclo · cuatro fases, cada una con un entregable que te quedas
Fase 01 · ~1 semana

Auditoría — encontrar dónde falla antes de construir

Lo que recibes

Un plan priorizado, un mapa de riesgos de dónde puede fallar tu IA, una evaluación de referencia sobre tu función actual y una cotización firme y fija para el build — tuya, sigas o no.

El estándar aplicado

Cada afirmación se mide, nada se asume. Te vas con un número real y un plan real, no con un rango y un quizás.

Fase 02 · ~2 semanas

Sprint — lanzar una porción fina, con la compuerta desde el día uno

Lo que recibes

Una porción fina funcional de la función, el primer arnés de evaluación conectado a tus patrones de tráfico reales, y una compuerta de CI que ya bloquea que un cambio malo se integre.

El estándar aplicado

Se lanza detrás de una compuerta desde el primer commit. Ninguna función entra sin una prueba que pueda fallar — la evidencia va integrada, no pegada al final.

Fase 03 · ~4–8 semanas

Build — la función, y la evidencia de que funciona

Lo que recibes

La función completa, la batería de evaluación — fidelidad, inyección de prompts, regresión, seguridad — un libro de pruebas firmado y un runbook que tu equipo puede operar sin mí.

El estándar aplicado

"Hecho" significa verificado por un comando que puedes volver a correr, no afirmado en una reunión de estado. Sin falsos verdes — ni siquiera los míos.

Fase 04 · retainer opcional

Operación — mantenerlo probado en producción

Lo que recibes

Monitoreo, evaluaciones programadas, compuertas de calidad de CI mantenidas, y un informe de pruebas mensual en un lenguaje que tu PM puede leer.

El estándar aplicado

Una regresión se detecta antes de que tu cliente la vea — y el resultado se publica, no se afirma. Puedes entregarle el repo a cualquiera y seguirá funcionando.

Los estándares · los mismos que rigen mis propios productos

Cinco reglas que no rompo.

Sin falsos verdes — ni los míos

La compuerta se pone roja cuando debe, en público. Este mismo sitio publica sus propias corridas fallidas; tu proyecto recibe la misma honestidad.

Hecho significa verificado, no afirmado

Cada número está respaldado por un artefacto que puedes abrir — una corrida, un libro de pruebas, un código de salida de un test. Si no se puede mostrar, no está hecho.

Tu repo, tu infra, tus llaves

El trabajo corre en tus cuentas, no en las mías. No se retiene nada tras la entrega — sin dependencia de mí para que siga funcionando.

Precio según el problema, no un paquete

Alcance fijo, cotizado por escrito antes de empezar. Nunca horas abiertas, nunca un precio de menú inflado para el peor caso.

Liderado por el fundador, solo senior

La persona que lo define es la que lo construye y opera. Sin gerentes de cuenta, sin traspaso a juniors, sin teléfono descompuesto.

No es una diapositiva · la máquina detrás del método es real y pública

El mismo sistema hace funcionar mis productos y tu build.

Esto no es una metodología que escribí para una página de ventas. Es la herramienta que uso todos los días — y la mayor parte está abierta para que la inspecciones.

▸ sage-kernel — el SO de ingeniería proof-first ▸ llm-eval-gate — la plantilla de evaluación abierta ▸ el propio QA de este sitio, en público ▸ el cuerpo de trabajo que produjo ▸ el estándar de calidad y el SLA

Empieza con una semana de bajo riesgo.

La auditoría es la puerta de entrada: un plan y una cotización real que te quedas, construyas o no.

Empieza con la auditoría → Ver la prueba primero