La IA puede escribir tu código, pero todavía no debería administrar tu producción
Mi experiencia haciendo codigo con IA y por qué nunca permito que una IA tenga acceso directo a un ambiente de producción.
Jose Gratereaux
Author
Durante los últimos meses hemos visto una explosión de herramientas como Claude Code, Cursor, Codex, Gemini CLI, Cline y muchas otras.
La promesa es increíble: escribir código, corregir errores, crear pruebas, ejecutar comandos e incluso administrar infraestructura.
Y sí...
Yo también las uso todos los días. De hecho, hoy sería mucho menos productivo sin ellas.
Pero hay una regla que jamás rompo.
La IA trabaja en mi ambiente local. Nunca en producción.
Y hay una razón muy simple para ello.
Una disculpa no recupera una base de datos
Hace poco se hizo viral un caso donde un agente de IA eliminó completamente una base de datos de producción.
Después del desastre simplemente respondió algo parecido a:
"Lo siento, cometí un error."
Y ahí terminó todo.
Las disculpas no restauran datos.
No recuperan clientes.
No revierten horas de inactividad.
No reconstruyen la confianza.
Yo también aprendí una lección
Por suerte... No fue en producción.
Mientras trabajaba en un proyecto Laravel le pedí a la IA que ejecutara unas migraciones.
Esperaba algo como:
php artisan migrate
Pero decidió ejecutar un comando equivalente a:
php artisan migrate:fresh
Si trabajas con Laravel ya sabes qué significa eso.
Toda mi base de datos local desapareció.
Segundos después llegó el clásico mensaje:
"Lo siento, ejecuté el comando incorrecto."
Por suerte era mi ambiente local.
Simplemente restauré una copia reciente de producción y seguí trabajando.
Si eso hubiera ocurrido en producción, probablemente estaría escribiendo un artículo muy diferente.
La IA no entiende el valor de tus datos
Aquí está el verdadero problema.
La IA entiende patrones.
No entiende negocios.
No entiende clientes.
No entiende años de trabajo acumulado en una base de datos.
Para ella, ejecutar esto:
DROP DATABASE;
es simplemente otro comando válido dentro de su entrenamiento.
No existe un componente emocional que le haga pensar:
"Quizás debería verificar dos veces antes de borrar millones de registros."
La IA tampoco siente miedo
Los desarrolladores sí.
Antes de ejecutar algo en producción normalmente pensamos:
- ¿Tengo backup?
- ¿Qué pasa si falla?
- ¿Hay usuarios conectados?
- ¿Existe una mejor alternativa?
- ¿Estoy en el servidor correcto?
La IA no siente esa incertidumbre.
Su objetivo es completar la tarea que le pediste.
Y muchas veces elegirá la solución que considera más rápida, aunque implique un riesgo enorme.
El problema no es Claude Code
Ni Cursor.
Ni Codex.
Ni Gemini.
Ni Cline.
Ni ninguna otra herramienta.
El problema aparece cuando les damos permisos que ni siquiera le daríamos a un desarrollador nuevo.
Piensa en esto.
Cuando entra un desarrollador junior a una empresa, ¿le das acceso root a producción el primer día?
Por supuesto que no.
Entonces...
¿Por qué sí se lo damos a una IA?
La IA debería tener los mismos límites que cualquier desarrollador
En seguridad existe un principio muy conocido:
Principio de menor privilegio (Least Privilege).
Cada usuario o servicio debe tener únicamente los permisos estrictamente necesarios.
Ese principio también debería aplicarse a los agentes de IA.
No porque sean malos.
Sino porque pueden equivocarse.
Y cuando una IA se equivoca, lo hace exactamente con los permisos que tú le diste.
Ni más.
Ni menos.
Lo que sí dejo hacer a la IA
En mi flujo de trabajo la IA puede:
- escribir código
- refactorizar clases
- crear pruebas unitarias
- revisar bugs
- optimizar consultas SQL
- generar documentación
- explicar errores
- sugerir migraciones
Pero siempre bajo supervisión.
Lo que nunca permito
Nunca le doy permisos para:
- ejecutar migraciones en producción
- borrar bases de datos
- hacer deploy automáticamente
- modificar infraestructura crítica
- ejecutar Terraform sin revisión
- eliminar recursos en AWS, Azure o Google Cloud
- ejecutar comandos destructivos sin aprobación
Puede parecer exagerado.
Hasta que deja de parecerlo.
Producción no es un laboratorio
Muchos desarrolladores caen en una trampa.
Como la IA acierta el 95% de las veces, comienzan a confiar también en el otro 5%.
Y justamente ese 5% suele ser el que destruye una base de datos.
La producción no es un lugar para experimentar.
Es donde están los clientes.
Es donde está el dinero.
Es donde está la reputación de tu producto.
Mi regla es muy sencilla
La IA propone.
Yo decido.
La IA escribe.
Yo reviso.
La IA ejecuta.
Solo cuando estoy completamente seguro de lo que va a hacer.
Buenas prácticas para trabajar con IA
Estas son algunas reglas que personalmente recomiendo seguir:
- Nunca conectes un agente de IA directamente a producción.
- Trabaja siempre en ambientes locales o de staging.
- Aplica el principio de menor privilegio.
- Revisa cada comando antes de ejecutarlo.
- Mantén backups automáticos y, más importante aún, verifica periódicamente que realmente puedas restaurarlos.
- Usa confirmaciones manuales para cualquier acción destructiva.
- Nunca delegues completamente decisiones de infraestructura a una IA.
La IA es un copiloto, no el piloto
Creo firmemente que los desarrolladores que aprendan a trabajar junto con la IA tendrán una enorme ventaja durante los próximos años.
Yo no volvería atrás.
La utilizo todos los días.
Me hace más rápido.
Me ayuda a detectar errores.
Me permite dedicar más tiempo a resolver problemas reales.
Pero una cosa es usarla como copiloto.
Y otra muy distinta es entregarle el volante.
Hasta que estas herramientas sean realmente confiables para operar infraestructura crítica, prefiero que sigan trabajando donde mejor funcionan:
Mi ambiente local.
Porque si algo sale mal...
La IA puede pedir disculpas.
El responsable frente al cliente siempre serás tú.
¿Y tú qué opinas?
¿Permites que herramientas como Claude Code, Cursor o Codex ejecuten comandos en producción?
¿O prefieres mantener siempre un humano aprobando los cambios críticos?
Me gustaría conocer tu experiencia.