Deja de competir con la IA en volumen de código: audita, diseña y controla
Cuando los agentes de IA redactan más pull requests, tu valor pasa de escribir código a diseñar sistemas, hacer cumplir el control de versiones y revisar la salida antes de que se convierta en deuda.

Vas a fusionar un PR escrito por un agente que afecta a datos de producción. Antes de aprobarlo, pregúntate si la producción puede pagar escrituras pequeñas de autocommit más lentas. DoltLite hace concreta esa pregunta: un agente puede entregarlo como un fork de SQLite con un almacén de bloques basado en Prolly Tree, pero sus escrituras pequeñas de autocommit son mucho más lentas.
El nuevo hábito peligroso no es usar agentes. El nuevo hábito peligroso es fusionar su salida sin la misma disciplina que aplicarías a tu propio código. Si tu trabajo ahora incluye revisar más trabajo asistido por IA, tu palanca no es el volumen de código. Es el juicio de sistema: saber qué permite el modelo de datos, qué se puede revertir, qué coste de rendimiento es aceptable y qué puede defender un humano en una revisión de diseño. Ese es el cambio de limpiador de código a ingeniero responsable.
El trabajo se está desplazando de la velocidad de tecleo al juicio de sistema
Durante años, el valor de la ingeniería de software fue fácil de medir: funciones entregadas, errores corregidos, código escrito. Esa métrica se está derrumbando. Cuando los agentes pueden producir grandes cantidades de código, la habilidad escasa no es producir más código. La habilidad escasa es decidir qué debe existir, cómo debe almacenarse, cómo debe fallar y cómo debe revisarse.
Por eso cambia el rol del ingeniero de nivel medio y del contribuidor individual senior. Puede que sigas escribiendo código, pero tu salida es cada vez más un conjunto de decisiones: límites del esquema, contratos de API, cobertura de pruebas, rutas de rollback y estándares de revisión. Si no puedes explicar esas decisiones, el código que fusionas se convierte en un pasivo.
Lo que DoltLite muestra sobre los controles de producción
Considera DoltLite como un caso de estudio compacto. Es un fork de SQLite con un formato de almacenamiento estable y control de versiones estilo Dolt/Git, pero sus escrituras pequeñas de autocommit son mucho más lentas. Es exactamente por eso que se necesita un control: un formato de almacenamiento estable, un control de versiones estilo Dolt/Git y escrituras pequeñas más lentas plantean preguntas sobre el modelo de datos, el rollback y el rendimiento que un revisor humano debe responder. Las comprobaciones restantes preguntan si un humano puede explicar la arquitectura y si el PR es lo suficientemente pequeño para revisarlo. Ese es el control que debes ejecutar antes de fusionar.
El control para PR de agentes: cinco comprobaciones antes de fusionar código de IA
Usa este control cada vez que un agente de IA, un asistente o un compañero de equipo envíe un pull request que afecte a producción, datos o infraestructura compartida. No fusiones hasta que las cinco respuestas sean sí.
- ¿Respeta el almacenamiento y el modelo de datos? Comprueba si el código asume índices incorrectos, nulabilidad incorrecta, propiedad incorrecta o un invariante no aplicado. Si el agente inventó una ruta de datos que evade tu modelo canónico, marca el diff como bloqueado.
- ¿Hay versionado o rollback? Pide la ruta de rollback antes de aprobar: qué pasa cuando este cambio es incorrecto, si puedes revertirlo limpiamente y si necesita una migración, un backfill, una purga de caché o una limpieza manual.
- ¿Se miden los compromisos de rendimiento? No aceptes confianza vaga. Pide un benchmark o una estimación razonada de la ruta crítica para cualquier cambio que afecte a escrituras, lecturas, uniones, caché o serialización.
- ¿Puede un humano explicar la arquitectura? Si no puedes explicar el cambio a otro ingeniero en unas pocas frases, el diseño probablemente es demasiado opaco. Pide al autor que resuma la intención, los límites, los modos de fallo y por qué la implementación coincide con el diseño.
- ¿El PR tiene un alcance lo suficientemente pequeño para revisarlo? Un diff grande generado por IA es un riesgo de revisión. Pide una división si mezcla refactorización, nuevo comportamiento, actualizaciones de dependencias y formato.
Este control convierte la revisión de código de un ritual pasivo en un control activo. También protege tu reputación. Cuando el código generado por IA falla, la persona que lo fusionó asume las consecuencias. Tu trabajo es asegurarte de que el fallo sea pequeño, reversible y explicable.
Haz esto esta semana
Elige un pull request generado por IA de tu equipo y pásalo por las cinco comprobaciones. Escribe las respuestas en la descripción del PR o en una nota interna breve. Si no puedes responder una comprobación, solicita cambios o divide el trabajo. Luego elige un área donde tu equipo no tenga un estándar claro: cambios en el modelo de datos, migraciones, rutas sensibles al rendimiento o refactorizaciones asistidas por IA. Escribe una regla breve para esa área. No intentes superar a los agentes en tecleo. Supéralos en controles esta semana dejando las cinco respuestas en la descripción del PR o en una nota interna breve.