Llevo semanas con una incomodidad que no logro sacudirme. Uso Claude Code y GitHub Copilot todos los días, me han cambiado la forma de trabajar y no pienso volver atrás. Pero cada vez que abro YouTube y veo el discurso de moda sobre cómo trabajar con IA, siento que estoy haciendo algo mal. Que voy demasiado despacio. Que reviso demasiado.
Este post no es un tutorial. Es una reflexión honesta, y termina con una pregunta genuina para quien lo lea.
Mi trabajo: infraestructura donde el downtime se factura en dinero
Para que la incomodidad tenga sentido, necesito explicar el contexto en el que trabajo.
Manejo principalmente infraestructura cloud. Los sistemas que soporto van desde plataformas de ecommerce hasta plataformas de análisis de datos. Y tienen una característica en común:
Si eso se cae, la empresa puede perder miles o millones de dólares en un par de horas de downtime.
No es una exageración para darle dramatismo al post. Es el cálculo real: un carrito de compras que no procesa pagos durante dos horas en temporada alta, o un pipeline de datos que alimenta decisiones de negocio y se queda mudo, tienen un costo que alguien mide y que alguien reporta.
Ese contexto cambia por completo la matemática de la velocidad. En un proyecto personal, si me equivoco, pierdo una tarde. Aquí, si me equivoco, la factura la paga la empresa y la confianza la pago yo. Cuando el costo del error es asimétrico de esa forma, ir despacio no es lentitud: es el precio de la operación.
Mi setup no ha cambiado tanto: terminal, VSCode y pocos plugins
Mi entorno de trabajo es deliberadamente aburrido. Una terminal y VSCode. Nada más.
No tengo cincuenta extensiones instaladas. No tengo un dashboard que me diga el clima ni un tema que renderice partículas cuando escribo. Cada plugin que instalo tiene que justificar su existencia, porque cada plugin es superficie que puede fallar, que puede quedar sin mantenimiento, que puede meterse en el camino cuando estoy resolviendo un incidente a las dos de la mañana.
Y aquí va mi primera opinión impopular: la terminal me obliga a saber lo que estoy haciendo. Cuando escribo un comando, sé exactamente qué va a pasar. No hay un botón que hace tres cosas de las cuales entiendo una. Esa transparencia, que parece incomodidad, es la que me permite dormir tranquilo.
Cómo uso la IA en mi día a día
Nada de lo anterior significa que sea un escéptico de la IA. La uso en prácticamente todo el ciclo de desarrollo, y le reconozco un impacto real en mi productividad. Lo que tengo son reglas sobre cómo la uso.
Leo línea por línea lo que genera la IA
Es una manía, y aquí quiero ser honesto: sí quiero curarla. Pero con mucha precaución y en ese orden, no al revés. Hoy todo el código que sale de un modelo lo leo completo antes de que llegue a un pull request. No lo escaneo buscando si “se ve bien”: lo leo.
Y no lo hago por desconfianza al modelo en abstracto. Lo hago porque el código generado tiene un patrón de fallo particular: es plausible. Compila, pasa el linter, se lee razonable, y está equivocado en un detalle que solo se nota cuando conoces el sistema. Un timeout que no corresponde al SLA real. Un retry sin backoff sobre un endpoint que rate-limitea. Un recurso que se crea sin el tag que usa el equipo de finanzas para asignar costos. Nada de eso lo detecta un test.
Digo que quiero curarla porque leer el 100% no escala, y lo sé. Si en un año sigo revisando exactamente igual que hoy, eso no será rigor: será que no aprendí nada en un año. Lo que no quiero es dejar de revisar por presión de tendencia, sin haber construido antes algo que sostenga esa confianza.
Lo que estoy tratando de hacer es soltar por capas, empezando por donde el error es barato: código de tests, scripts internos, herramientas de desarrollo, cambios que un pipeline puede verificar mejor que mis ojos. Ahí ya reviso bastante más rápido que hace un año, y no me ha costado nada. Lo que sigue bajo lectura completa es lo que toca infraestructura, datos de clientes, permisos o dinero.
No quiero dejar de revisar porque me lo diga la tendencia. Quiero dejar de revisar cuando tenga algo mejor que mis ojos en su lugar.
Le pido a la IA que me explique su propio código
Cuando leo algo que no entiendo, no lo dejo pasar con un “seguro está bien”. Le pregunto al mismo modelo que lo escribió que me lo explique.
Esto me parece la parte más subestimada de trabajar con IA. No la uso solo para producir, la uso para entender, y eso incluye entender lo que ella misma produjo. Si después de la explicación sigue sin cerrarme, no va. Mi criterio para aprobar código no es que funcione en la demo, es que yo pueda sostenerlo cuando se rompa un domingo.
Si no puedo explicar por qué ese código funciona, no estoy en posición de responder cuando falle.
La IA también me ayuda a revisar los PR de mis compañeros
Aquí es donde la IA me da más valor del que esperaba. Cuando reviso un pull request de un compañero, sobre todo si toca una parte del sistema que no escribí yo, uso la IA para acelerar la comprensión: qué hace este cambio, qué se rompe si esto falla, qué casos borde no están cubiertos.
La diferencia con el patrón que me preocupa es sutil pero enorme: la IA no aprueba el PR, yo apruebo el PR. Ella me ayuda a llegar más rápido al punto donde tengo suficiente contexto para tomar la decisión. La decisión sigue siendo mía, y la responsabilidad también.
AGENTS.md: darle contexto a la IA es parte del trabajo
Otra cosa que hago con IA es generar y mantener los archivos AGENTS.md de los repositorios: convenciones del proyecto, comandos reales, estructura, decisiones que ya se tomaron y no hay que volver a discutir.
Esto me parece la inversión con mejor retorno de todas. Un modelo sin contexto adivina; un modelo con contexto propone cosas que encajan con el proyecto. La mayoría de las quejas de “la IA me generó basura” que veo son en realidad quejas de haberle pedido algo sin darle nada con lo que trabajar.
Y hay un efecto secundario que no esperaba: escribir el contexto para la IA me obliga a hacer explícito lo que el equipo tenía en la cabeza. El documento sirve igual de bien para el compañero que entra nuevo.
La tendencia que veo: IA sin revisión
Vamos a la parte que me incomoda.
Consumo bastante contenido técnico, sobre todo en YouTube, para no perderme lo que se está moviendo. Y el discurso dominante en los últimos meses tiene una dirección clara: cada vez menos revisión. Demos donde alguien describe una funcionalidad, el agente escribe cuarenta archivos, y la persona hace commit sin abrir ninguno. Métricas de productividad medidas en líneas generadas por hora. La palabra “revisar” presentada como un residuo del pasado, algo que hacíamos cuando escribíamos el código a mano.
Entiendo por qué ese contenido funciona. Un video de alguien leyendo un diff con atención durante veinte minutos no lo ve nadie. El formato premia la velocidad visible, no el criterio invisible.
Pero lo que me inquieta no es el contenido. Es que el discurso se está convirtiendo en práctica.
Darle a la IA las llaves de producción
He visto, y no solo en internet, cómo se le concede a un agente permiso para ejecutar cambios directamente en producción, con muy poca evidencia de que quien aprueba entienda qué está haciendo el agente paso a paso. La aprobación se vuelve un trámite: el agente propone, se acepta, se ejecuta.
Quiero ser justo, porque es fácil ser injusto aquí. Puede que entiendan perfectamente lo que están aprobando y yo esté viendo la superficie de un proceso que sí tiene fundamento. Es una posibilidad real y me obliga a no asumir lo peor. Pero incluso concediendo eso, el patrón me sigue pareciendo frágil por una razón que no tiene que ver con las personas: funciona hasta que no funciona.
Un agente con permisos de escritura en producción y sin una persona que entienda el cambio no es peligroso el 99% de las veces. Es peligroso el 1%. Y en infraestructura, ese 1% no se distribuye de forma amable: llega en el peor momento, sobre el sistema más crítico, con el máximo de tráfico encima.
Hay una asimetría de la que se habla poco. La IA es excelente proponiendo el cambio y bastante peor evaluando el radio de impacto de ese cambio. Sabe cómo escribir la migración; no sabe que esa tabla la lee un job de facturación que corre el día 1 de cada mes y que nadie documentó. Ese conocimiento no está en el repositorio: está en la cabeza de la gente que operó el sistema.
Por eso hay una categoría de comandos que en mi caso nunca corren sin que alguien los haya leído completos y entendido el alcance:
# Cambios de infraestructura: siempre plan primero, y el plan se lee
terraform apply
# Borrado de recursos con estado
kubectl delete
aws rds delete-db-instance
# Migraciones destructivas o irreversibles
DROP COLUMN / DROP TABLE / TRUNCATE
# Cualquier cosa sobre IAM, security groups o redes
# (el radio de impacto casi nunca es el que parece)No es una lista de comandos prohibidos. Es una lista de comandos donde exijo comprensión antes de ejecución, la escriba una persona o la proponga un modelo.
Por qué la cautela con la IA en producción no es lentitud
El argumento que más escucho contra mi forma de trabajar es que la revisión es un cuello de botella. Que si la IA genera en dos minutos lo que yo reviso en veinte, el problema soy yo.
Ese argumento tiene un error de contabilidad: mide el tiempo de escribir y omite el tiempo de reparar.
Los veinte minutos de revisión son visibles y se sienten caros. Las cuatro horas de un incidente en producción, con medio equipo dentro de una llamada, el postmortem, la deuda de confianza con el cliente y el trabajo planificado que se cae de la semana, no aparecen en la métrica de velocidad de nadie. Pero se pagan igual, y se pagan con intereses.
En sistemas donde el fallo es barato, iterar rápido y arreglar después es la estrategia correcta. Yo no trabajo en esos sistemas. La estrategia depende del costo del error, y ese costo no es una opinión: es un número que se puede calcular.
Tener 1000 plugins no te hace mejor profesional
Esto conecta con mi setup aburrido, y creo que es el mismo tema de fondo.
Existe una confusión bastante extendida entre tener herramientas y tener criterio. Se ve en las listas de “50 extensiones que todo desarrollador necesita” y se ve ahora en la carrera por acumular agentes, MCP servers y automatizaciones.
Las herramientas amplifican lo que ya sabes. Si tienes criterio, una buena herramienta te hace mucho más efectivo. Si no lo tienes, te hace equivocarte más rápido y a mayor escala. La herramienta no aporta el juicio; multiplica el que ya traes.
Lo que me ha servido en un incidente real nunca ha sido una extensión. Ha sido entender cómo funciona el sistema, saber leer un log, tener claro qué se desplegó y en qué orden, y haber estado antes en una situación parecida.
¿Me estoy quedando atrás con la IA?
Aquí está el miedo, sin adornos.
Me pregunto si esto es un ciclo que ya viví. Cuando aparecieron los frameworks, hubo gente que insistió en escribir todo a mano por rigor, y el rigor no los salvó: el mundo se movió y quedaron fuera. No quiero ser esa persona. Reconozco que “yo lo reviso todo” es exactamente lo que diría alguien que se está quedando atrás y necesita una explicación noble para no moverse.
Pero cuando trato de ser honesto conmigo mismo, hay una diferencia que me parece real. Adoptar un framework era delegar trabajo. Aprobar sin leer es delegar responsabilidad. Y la responsabilidad no se delega, porque cuando el sistema se cae, el que responde soy yo. No puedo escribir en el postmortem que el agente lo aprobó.
También noto que no soy lento en adoptar. Uso IA en todo el ciclo, mantengo el contexto de los repos, la meto en mis revisiones, y estoy soltando la lectura completa donde el error es barato. Lo que no adopto es un punto muy específico: ejecutar sin comprender. Si eso es quedarse atrás, entonces la definición de estar al día cambió a algo que no quiero.
Visto así, mi respuesta a la pregunta del título es incómoda: probablemente sí soy demasiado cauteloso en algunas cosas, y probablemente el resto del mundo lo es demasiado poco en las que importan. Las dos pueden ser verdad a la vez.
Mi postura: la IA es una herramienta, no un sustituto del criterio
Después de darle muchas vueltas, es donde estoy:
La IA es una herramienta extraordinaria y no es un sustituto del criterio ni de la experiencia técnica. Amplifica al que sabe y esconde por más tiempo el error del que no.
En concreto, lo que sostengo:
- Leer lo que se genera, sin importar lo convincente que se vea. Lo plausible es más peligroso que lo obviamente roto. Y si voy a leer menos, que sea porque puse algo mejor en su lugar, no porque me dio pereza.
- Usar la IA para entender, no solo para producir. Pedirle que explique es tan válido como pedirle que escriba.
- No delegar la aprobación. La IA acelera mi comprensión; la decisión y la responsabilidad siguen siendo mías.
- Invertir en contexto. Un
AGENTS.mdbien hecho vale más que diez prompts largos. - Escalar la cautela al costo del error. En un side project, mueve rápido. En producción con dinero encima, comprensión antes de ejecución.
- Menos herramientas, más entendimiento. Lo que salva un incidente es saber cómo funciona el sistema.
¿Qué opinas tú? Te leo
Y aquí es donde de verdad quiero abrir la conversación, porque no escribí esto para dar una lección. Lo escribí porque no estoy seguro.
Puede que estas medidas sean justamente lo que corresponde cuando administras sistemas donde dos horas de downtime cuestan lo que cuestan. O puede que me esté aferrando a un proceso que la tecnología ya volvió innecesario, y que me esté costando velocidad sin comprar seguridad real.
Lo que me interesa saber de ti:
- ¿Revisas línea por línea el código que te genera la IA, o ya te acostumbraste a confiar en ciertos tipos de cambio?
- Si dejaste de revisar todo, ¿qué te hizo cambiar? Me interesa más esa respuesta que cualquier otra.
- ¿Le darías permisos de ejecución en producción a un agente? ¿Con qué límites?
- ¿Dónde pondrías tú la línea entre cautela sana y freno innecesario?
Escríbeme por LinkedIn o Twitter. Si tu experiencia contradice lo que escribí aquí, es la que más quiero escuchar.