Hacer vibe coding en un proyecto de fin de semana es una cosa. Hacerlo en un producto con clientes que pagan, una rotación de guardia y un código de cinco años es otra disciplina.
El feed de las redes sociales hace que el desarrollo de software moderno parezca resuelto. Un desarrollador abre un directorio vacío, escribe tres frases en Claude Code o Cursor, y observa cómo aparecen veinte archivos en rápida sucesión. En cuarenta minutos, una aplicación web funcional ya corre en el navegador, con autenticación, tablas de base de datos y un diseño pulido. La demostración parece magia porque en el desarrollo greenfield cada decisión arquitectónica está libre de ataduras. No hay usuarios activos que interrumpir, no hay migraciones de base de datos previas que preservar, no hay presupuestos de latencia que defender, ni colegas que tengan que mantener el resultado seis meses después.
Llevar ese flujo de trabajo a un repositorio de producción con cinco años de antigüedad produce una tarde muy diferente. Abres una terminal en un código con cientos de miles de líneas, le pides a un agente una actualización en un cálculo de facturación o en una tubería de notificaciones asíncronas, y esperas. El agente inspecciona varios directorios, escribe TypeScript limpio y legible que compila al primer intento, pasa dos pruebas unitarias triviales, y descartaría transacciones de base de datos bajo carga si alguien lo enviara a main.
La distancia entre esos dos resultados tiene poco que ver con la inteligencia bruta del modelo. Proviene del hecho de que un código maduro no es simplemente un conjunto de texto fuente. Es una acumulación de compromisos históricos, acuerdos organizacionales y restricciones operativas que rara vez figuran en los archivos del repositorio.
El sedimento de un repositorio vivo
En un proyecto que arranca de cero, cada patrón arquitectónico es fresco y unificado. En un sistema de cinco años construido por decenas de ingenieros a través de múltiples reorganizaciones, el código se parece a una roca sedimentaria. Encuentras el patrón de acceso a base de datos de 2021 conviviendo junto al constructor de consultas de 2023, justo al lado de la refactorización orientada a eventos de 2025 que se quedó sin presupuesto de equipo a mitad del tercer trimestre.
Cuando abres Claude Code en un código con años de historia y pides un cambio en un par de párrafos informales, el modelo carece del contexto organizacional para interpretar lo que ve. Un agente al que se le pide agregar un manejador de eventos lee a través de todas estas capas históricas sin saber qué patrón usa el equipo en la actualidad y cuál ha estado en desuso durante dieciocho meses. Detecta una función auxiliar antigua, nota que ya tiene documentación exhaustiva en sus comentarios, y construye la nueva funcionalidad sobre ella. Un ingeniero humano del equipo habría reconocido la trampa al instante por las conversaciones del sprint planning. El agente solo ve texto en el disco y trata a cada archivo como igualmente canónico.
La deriva de la documentación acelera esta confusión. La mayoría de los sistemas de producción contienen archivos README, registros de decisiones arquitectónicas y comentarios en el código escritos por ingenieros que dejaron la empresa hace años. El código siguió evolucionando bajo la presión de los incidentes en producción, mientras que el texto explicativo quedó intacto. Cuando un agente analiza el repositorio para orientarse, trata estas descripciones desactualizadas como verdades absolutas, generando implementaciones que se ajustan a diseños obsoletos de 2024 y que fallan silenciosamente contra las suposiciones modernas.
La densidad de tráfico introduce otro punto ciego. Para un agente que lee código fuente, una línea en un script administrativo de exportación poco transitado se ve idéntica a una línea en la ruta principal de pagos. Ambas son funciones que aceptan un argumento, ejecutan una consulta y devuelven una respuesta. En la realidad, un índice faltante o una consulta adicional dentro de un bucle en memoria en el script de exportación provoca una demora inadvertida de tres segundos una vez por semana. La misma construcción exacta en la ruta de pagos agota el grupo de conexiones en treinta segundos tras el lanzamiento de una campaña comercial. Un agente no tiene conciencia intuitiva del volumen de peticiones, los límites de concurrencia o la contención de bloqueos a menos que alguien inyecte telemetría de producción explícitamente en su prompt.
Las ediciones más peligrosas suelen apuntar al código más feo. Todo repositorio maduro tiene funciones que horrorizan a cualquiera con sensibilidad estética: una pausa arbitraria de diez milisegundos, un bucle de reintento manual alrededor de una llamada externa o una conversión de tipos forzada que elude al compilador. Casi cada una de esas manchas se agregó durante la respuesta a un incidente para sobrevivir a un fallo del proveedor de nube, un límite de tasa no documentado en un webhook de terceros o un corte de socket en un controlador de base de datos antiguo. Un agente instruido para limpiar el módulo solo ve deuda técnica. Elimina la demora, simplifica la lógica de reintento y reabre exactamente la misma falla operativa que el equipo diagnosticó dos años antes.
Gran parte de la arquitectura vive por completo fuera del historial de git. El tope del grupo de conexiones configurado en la consola de AWS, la política de desalojo de Redis elegida durante una migración de base de datos, las claves de partición en un clúster de Kafka y las banderas de funcionalidad gestionadas en un panel externo rara vez existen en el repositorio de la aplicación. Cuando un agente modifica el código, adopta suposiciones locales razonables sobre el entorno operativo que fracasan de inmediato al desplegarse en una infraestructura distribuida. Un cambio que supera cada comprobación local en Docker con dieciséis gigabytes de memoria en la estación de trabajo provocará un cierre forzado inmediato por falta de memoria (OOM kill) al desplegarse en un contenedor de producción con un límite estricto.
El arnés que hace segura la velocidad
El prototipado greenfield depende de la verificación visual. Haces clic en un botón en el navegador, ves que se abre una ventana modal, revisas que la consola de desarrollo no tenga errores en rojo y concluyes que la tarea está terminada. Ese bucle falla en un sistema que procesa dinero real y datos de usuarios reales. La inspección manual no puede verificar si una transacción de base de datos mantuvo aislamiento serializable bajo escrituras concurrentes, o si los datos de los clientes se mantuvieron estrictamente particionados entre inquilinos.
Cuando un repositorio carece de pruebas automatizadas rigurosas, delegar trabajo en un agente se convierte en un ejercicio de fe. En el vibe coding de proyectos nuevos, la falta de pruebas se percibe como velocidad; en un sistema de producción activo, la ausencia de una suite de pruebas convierte cada prompt en una ruleta rusa. Muchos equipos descubren que sus suites existentes miden la ejecución de líneas mientras dejan los contratos de comportamiento completamente desatendidos. Si la suite consiste en pruebas unitarias superficiales que simulan cada dependencia externa, un agente puede reescribir la implementación subyacente, actualizar los mocks para que coincidan con su nuevo código y presentar un build en verde que se rompe en producción.
Si un agente escribe tanto la implementación como las pruebas dentro de la misma sesión, crea pruebas que reflejan sus propias suposiciones incorrectas. La suite de verificación valida lo que el agente intentó hacer, no lo que el negocio requiere. Para confiar en un agente en un entorno de producción, el arnés de verificación debe existir de manera independiente al prompt del modelo.
Construir ese arnés requiere bases deterministas:
- Entornos locales herméticos que levanten instancias temporales de base de datos mediante herramientas como Testcontainers, permitiendo a los agentes ejecutar consultas reales sobre esquemas realistas.
- Sistemas de tipos estrictos con banderas de compilación que prohíban tipos implícitos y conversiones sin validar.
- Pruebas de contrato que validen integraciones contra límites de servicio reales utilizando protocolos de red reales.
- Suites de regresión de comportamiento que ejecuten casos extremos conocidos antes y después de cualquier modificación de código.
La puerta de revisión humana también cambia bajo el desarrollo con agentes. Revisar código escrito por otra persona es una evaluación colaborativa de una intención compartida. Entiendes cómo piensa tu colega y discutes los compromisos en contexto. Revisar cientos de líneas generadas por un agente exige un nivel de vigilancia completamente distinto.
El código producido por los modelos modernos es casi siempre ordenado, bien estructurado y acompañado de comentarios explicativos convincentes. Los fallos rara vez son errores sintácticos o variables no definidas. Son errores semánticos sutiles: reversiones de transacciones de base de datos olvidadas, errores por un paso en la paginación o estados nulos no controlados en cargas anidadas. Debido a que el diff se ve profesional y el build pasa, los revisores humanos experimentan fatiga cognitiva y tienden a aprobar cambios con menor escrutinio del que aplicarían al trabajo humano. Esa dinámica invierte las supuestas ventajas de velocidad de la automatización.
La prueba de la guardia y la propiedad colectiva
La prueba fundamental de cualquier práctica de ingeniería es la responsabilidad operativa. Si un despliegue activa una alerta a las tres de la mañana un domingo, el ingeniero de guardia no puede preguntarle al modelo de lenguaje por qué un algoritmo se implementó de una forma determinada. El ingeniero que aprobó y fusionó el pull request tiene que diagnosticar el problema bajo presión y decidir si aplica un parche urgente o revierte el cambio. Explicar en la autopsia del incidente que un agente escribió la lógica no conforma a los clientes cuyas operaciones fallaron.
Cuando las personas generan grandes volúmenes de código sin escribirlo carácter por carácter, la comprensión organizacional comienza a deteriorarse. Escribir software manualmente es un ejercicio de construcción de modelos mentales. Al redactar funciones, depurar fallas de pruebas y refactorizar interfaces, un ingeniero aprende dónde cede el sistema y dónde se quiebra. Si un desarrollador se limita a pedirle cosas a un agente y leer el resultado por encima, ese modelo mental nunca se forma. El equipo conserva el artefacto mientras pierde el conocimiento institucional de cómo se comporta.
La realidad social de una organización de ingeniería es lo que separa a los sistemas reales de las demostraciones en solitario. Un creador individual en redes sociales puede permitirse borrar una tabla, reiniciar el estado o sufrir una interrupción de medio día mientras experimenta con una nueva funcionalidad. En una organización con contratos corporativos, acuerdos de nivel de servicio y auditorías de datos, el código es una responsabilidad que debe mantenerse a lo largo de varios años y compartirse entre decenas de colegas.
Los equipos que usan agentes de manera productiva en productos maduros siguen un protocolo disciplinado. Acotan las tareas del agente a límites pequeños y aislados con entradas y salidas claras, evitando pedidos abiertos para refactorizar subsistemas enteros. Escriben las especificaciones y las aserciones de prueba antes de pedirle al modelo que toque la implementación. Y tratan al agente como a un colaborador novato muy rápido cuyo código debe ser comprendido, defendido y asumido por el autor humano antes de que llegue a producción.
El ritmo de generación de texto nunca fue el factor limitante en el desarrollo de software. El trabajo difícil sigue siendo el que siempre fue: comprender las necesidades de los usuarios, anticipar los modos de fallo, mantener la coherencia del sistema y asumir la responsabilidad personal por lo que corre en producción.