Ingeniería de Software con IA Lista para Producción

Qué significa listo para producción

Listo para producción es una propiedad que puedes comprobar, no una sensación de confianza. Un cambio está listo para producción cuando el código se revisó contra un estándar explícito, el comportamiento que declara está cubierto por pruebas que se ejecutaron, sus superficies relevantes para la seguridad fueron examinadas, la documentación que lo describe sigue diciendo la verdad, y existe un registro que conecta todo eso con el contenido exacto que se publica.

Pocos equipos discutirían esa lista. La brecha está en la aplicación: cada punto vive en una herramienta distinta, ninguna se vincula con las demás, y la decisión de lanzamiento es un humano mirando puntos verdes. Un punto verde dice que un job terminó. No dice qué examinó ese job, si el estándar era el correcto para este cambio, ni si algo comprobó las partes que importan.

Qué cambia la generación con IA

Los asistentes de IA suben el volumen de salida y bajan el costo de producir código plausible. También mueven el cuello de botella: la capacidad de revisión se queda plana mientras el volumen que necesita revisión crece, y la plausibilidad hace que el código débil sea más difícil de detectar, no más fácil.

Un asistente optimiza para código que se ve bien y satisface el prompt. No tiene interés en tu cobertura de pruebas, en tu modelo de amenazas, ni en si el README sigue coincidiendo con el comportamiento. Esas preocupaciones pertenecen a la capa de ingeniería alrededor del asistente, y si esa capa es un humano ojeando un diff grande, el volumen gana.

El modo de fallo rara vez es dramático. Es un flujo de login sin límite de intentos, una migración que nadie clasificó como arriesgada, un doc que describe la API del mes pasado. Cada uno es atrapable por un chequeo que se ejecuta siempre. Ninguno es atrapable con fiabilidad por una atención que tiene que estirarse sobre todo.

Las seis prácticas

1. Estándares de revisión ejecutables

Un estándar de revisión que vive en una wiki es un consejo. Un estándar de revisión que se ejecuta es un control. Codifica los chequeos que te importan (arquitectura, superficies de seguridad, huecos de pruebas, estado de dependencias) como pasos de revisión ejecutables que corren contra el diff real, en el IDE mientras el cambio es barato de arreglar y otra vez en CI donde el resultado queda registrado.

Eso es el catálogo de skills: pasos de revisión como unidades ejecutables, versionadas e instaladas por proyecto en lugar de recordadas por persona. →

2. Clasificación de riesgo desde el diff

No todo cambio merece el mismo escrutinio, y pedir a los autores que declaren su propio riesgo no es fiable. Clasifica el diff mismo: toca auth, migra el esquema, cambia el contrato de la API, mueve dependencias. Deja que la clasificación decida qué evidencia exige el lanzamiento. →

3. Vinculación de evidencia

Registra qué examinó cada chequeo, qué encontró, y vincula el registro a un digest del contenido exacto revisado. El vínculo es el punto central: la evidencia que flota libre del contenido puede reutilizarse, caducar, o describir un cambio completamente distinto. La evidencia vinculada a un digest de contenido puede reproducirse y auditarse después, incluso por alguien que no confía en ti.

Dos incidentes nuestros que sostienen el argumento: una puerta de merge rechazó su propio repositorio porque un dominio requerido no tenía evidencia, y una sonda de digest atrapó un repositorio cuyos clones frescos aparecían modificados antes de que nadie los tocara. Ambos están escritos en las notas de ingeniería, con sus arreglos. →

4. Puertas que fallan cerradas

Una puerta que aprueba cuando falta evidencia es un formalismo. La decisión de lanzamiento debe computarse desde la evidencia mediante una función determinista de una política versionada: mismas entradas, reproducible. La evidencia faltante falla. La evidencia caducada falla. Ningún modelo, y ningún humano cansado al final de un sprint, puede convencerla de aprobar.

Las anulaciones siguen existiendo, porque el criterio sigue existiendo. El requisito es que una anulación se registre como todo lo demás: quién, por qué, con qué alcance, con qué caducidad.

5. Verificación post-despliegue

Los chequeos del momento del merge examinan lo que va a publicarse. No pueden decirte si el despliegue funcionó, si el flujo de login funciona en producción, ni si la API del proveedor que llama tu adaptador sigue comportándose como en marzo. La verificación post-despliegue ejecuta los recorridos que importan contra el sistema desplegado y registra los resultados como evidencia en la misma cadena. Un smoke semanal de solo lectura con credenciales reales atrapa deriva que tus mocks no verán. →

6. Aprendizaje institucional de los fallos

Cuando un chequeo atrapa algo real, la captura debe cambiar el sistema: una lección registrada con causa nombrada, una sonda nueva. La alternativa es el ingeniero senior que recuerda por qué, y ese conocimiento se va cuando él se va.

Para equipos y organizaciones

Todo lo anterior se compone a escala de equipo, porque la alternativa se fragmenta: cada pareja desarrollador-asistente deriva hacia su propia definición de terminado. Un solo estándar codificado, aplicado a cada cambio sin importar autor ni asistente, con decisiones registradas en un libro mayor de solo-anexado, es lo que hace gobernable el desarrollo asistido por IA, y no solo rápido.

La capa organizacional añade identidad y responsabilidad: roles de denegación por defecto, anulaciones registradas, mapeo de cumplimiento que empieza desde prueba de controles. La página de enterprise cubre lo que se entrega ahí. →

Por dónde empezar

Empieza más pequeño de lo que crees: un repositorio, revisión-como-ejecución más una puerta que falla cerrada sobre una clase de cambio arriesgada. El plan gratuito lo cubre y el camino guiado hace la configuración. Expande según lo que la evidencia te diga, no según el roadmap.

Y si quieres evaluar las afirmaciones antes de adoptar nada, la maquinaria es pública: cada decisión de lanzamiento que esta plataforma toma sobre sí misma está contrafirmada y es verificable contra una clave publicada, y los fallos están escritos junto a los aprobados.