El nuevo juego del área de tecnología con IA
La IA vuelve tratable un backlog que siempre fue infinito: ticket, bug, deuda, incidente. Eso es una gran noticia. Solo que, sin revisión de verdad, esa misma velocidad se convierte en deuda técnica escondida e incidente en producción.
Lunes por la mañana, el board del equipo tiene 340 ítems abiertos: bug, pedido de feature pequeña, ítem de deuda técnica que nadie priorizó nunca. Eso siempre fue así, y siempre va a seguir llegando más rápido de lo que cualquier equipo logra cerrar. Antes, ese volumen se manejaba a machetazos: los diez ítems más ruidosos de la semana, el resto esperando un milagro de capacidad. Hoy la IA lee el board entero, agrupa duplicados, sugiere severidad y ya propone el primer borrador de corrección para un tercio de los ítems simples. El board que parecía una montaña se convierte en una lista que se puede atacar. La pregunta que decide si esto se vuelve ganancia o se vuelve problema ya no es "¿hay tiempo de mirar todo?": es "¿quién revisa lo que la IA decidió sola antes de que eso se convierta en producción?".
El área legal pide una lista de todas las librerías de código abierto usadas en el producto, con la licencia de cada una, porque un inversor va a auditar eso en la due diligence de mañana. Antes, esto era un día cruzando archivo de dependencias con sitio de licencia uno por uno. Hoy la IA lee el archivo de dependencias del proyecto entero y devuelve la lista con la licencia de cada librería en minutos. La lista parece completa y lista para adjuntar al informe. Solo que clasificó como "MIT, sin restricción" una librería que en realidad está bajo una licencia con cláusula de copyleft que puede obligar a abrir parte de tu propio código si se redistribuye de la forma en que ustedes lo hacen. Confirmar la licencia real antes de que entre al informe del inversor sigue siendo del equipo técnico revisando junto con el área legal.
Necesitas contratar a dos ingenieros sénior para el equipo de plataforma antes de que termine el trimestre, y el volumen de currículums se triplicó desde que la vacante quedó remota. Antes, esto era una semana leyendo currículum por currículum. Hoy la IA lee los 400 currículums, señala los quince más afines al perfil técnico y ya sugiere preguntas de entrevista específicas para cada uno. El triage que era imposible se convierte en una lista corta. Pero la IA valoró años de experiencia con un stack específico del que tu equipo ya se está alejando, una señal que solo quien conoce el roadmap técnico logra ver. Decidir quién entra a la entrevista final sigue siendo del gerente que sabe hacia dónde va la arquitectura.
El trimestre cierra y necesitas decidir cuáles de las veinte ideas del roadmap entran al próximo ciclo, con el CPO esperando la priorización para el jueves. Antes, esto eran días cruzando datos de uso, tickets de soporte y opinión de stakeholder a mano. Hoy la IA lee todo eso y devuelve un ranking con puntaje de impacto por iniciativa. El ranking parece objetivo y listo para convertirse en decisión. Solo que la IA puntuó alto una feature cuyo "impacto" vino de un pedido de un único cliente grande, sin notar que el equipo de ingeniería ya avisó que la base de código ahí está demasiado frágil para tocar sin romper otra cosa. Decidir qué entra al ciclo, sopesando viabilidad técnica real, sigue siendo tuyo.
Un prospecto grande pregunta, en la llamada de mañana, si tu plataforma soporta integración vía webhook en tiempo real, y el vendedor te llama a último momento para confirmar. Antes, esto era abrir el repositorio y leer la documentación técnica a las apuradas. Hoy la IA lee el código y responde, segura, "sí, el endpoint de webhook ya soporta eso". Ella leyó un endpoint que existe, pero está marcado como deprecated hace dos meses y va a salir de circulación en el próximo release. Si el vendedor repite esa respuesta al cliente sin verificar con el equipo técnico, la venta cierra sobre una promesa que ya no existe. Confirmar lo que la plataforma realmente soporta, hoy, sigue siendo del equipo que mantiene el código.
Recibiste una alerta de que el proceso de facturación automática falló para 40 clientes esta madrugada, y necesitas una corrección antes del horario comercial. Antes, esto era despertar a alguien del equipo y esperar que esa persona recordara dónde está ese script viejo. Hoy la IA lee el log de error, propone un parche y ya tendría el pull request listo para revisión en minutos. La corrección parece lista para subir directo. Solo que el parche de la IA resuelve el síntoma (el error que apareció en el log) sin tocar la causa real, un límite de conexión simultánea en la base de datos que solo vuelve a estallar en la próxima madrugada de pico. Aplicar la corrección correcta, no solo la que calla la alerta, sigue siendo del equipo que entiende el sistema.
La auditoría de LGPD del trimestre exige probar que ningún log de producción guarda CPF de cliente en texto plano, y el auditor llega mañana. Antes, esto era un día escaneando repositorio y configuración de logging a mano. Hoy la IA escanea el código y los archivos de configuración de logging en minutos, y señala tres servicios como conformes. Solo que ella no tuvo acceso a los logs que ya están almacenados hace dos años en el sistema de observabilidad, solo al código que los genera hoy, así que el pasivo real (dato sensible ya guardado) sigue ahí, invisible para su escaneo. Confirmar lo que efectivamente está guardado, y no solo lo que el código actual generaría, sigue siendo del equipo técnico junto con compliance.
El equipo de diseño pregunta si se puede saber, hoy mismo, en qué etapa del checkout los usuarios más abandonan después del último deploy, porque la reunión de prioridad es mañana temprano. Antes, esto era un día cruzando eventos de analytics con log de error a mano. Hoy la IA cruza los dos y señala, en minutos, que el abandono se concentra en la pantalla de pago. El diagnóstico parece listo para convertirse en prioridad de sprint. Solo que la IA cruzó los datos sin notar que la mitad de ese abandono ocurrió en una ventana de treinta minutos en la que el gateway de pago externo se cayó, un problema puntual y ya resuelto, no un problema de flujo. Decidir si esto se convierte en prioridad de rediseño o si ya quedó atrás sigue siendo del equipo que conoce el historial del sistema.
El directorio pregunta si la plataforma aguanta duplicar de tamaño en doce meses sin reescribir nada, y tienes hasta el viernes para responder. Antes, esa respuesta venía de una semana de reunión entre arquitectos tratando de estimar el límite de capacidad. Hoy la IA lee métricas de uso, señala los tres servicios más cerca del límite y devuelve una respuesta confiada: "la plataforma aguanta, con ajuste puntual". Ella nunca vio el contrato del proveedor de infraestructura que vence en seis meses, ni el cuello de botella de base de datos que solo aparece en el Black Friday. La decisión estratégica de invertir o no en una reescritura, que el directorio va a respaldar con presupuesto real, sigue siendo del CTO, no del informe bonito.
Oye, todo equipo de tecnología carga el mismo peso: un board de tickets que nunca llega a cero, un montón de deuda técnica que nadie tiene tiempo de atacar, y una guardia que vive apagando incendios. Piensa conmigo: ¿y si el backlog infinito dejara de ser infinito? La IA cambia esa cuenta de un modo real. Solo que cambia la cuenta equivocada si dejas que la velocidad corra sin que nadie esté mirando de verdad lo que está pasando.
La idea central de esta lección. Por primera vez, un backlog que siempre fue más grande que la capacidad del equipo (bug, ticket, deuda técnica, incidente) se vuelve algo tratable en volumen: la IA hace triage, propone el primer borrador de corrección, resume el incidente, escribe el esbozo de la documentación. Esa es una buena noticia de verdad. Lo que sigue siendo del equipo, y se volvió más crítico justamente porque la parte mecánica desapareció, es la arquitectura, la prioridad real detrás del ticket, la evaluación de riesgo y la firma de quien manda algo a producción. Y existe una salvedad que esta área no puede ignorar: velocidad sin revisión de verdad se convierte en deuda técnica invisible e incidente en producción. Esta trilla trata de operar esta área en el nuevo juego, sin pagar esa cuenta.
01Lo que la IA vuelve tratable en el área
Nombremos bien el cambio. Estas cosas, que siempre desbordaron la capacidad de cualquier equipo, la IA ya las ataca en volumen:
- Triage de tickets a escala. Agrupar duplicados, sugerir severidad, señalar el equipo correcto, en el board entero, no solo en los diez más ruidosos.
- El primer borrador de corrección. Para bug simple y conocido, un pull request inicial listo para revisión, no para merge directo.
- El resumen de incidente y de log. Cruzar panel de observabilidad, log de error e historial de deploy para señalar al sospechoso más probable.
- El borrador de documentación. Describir lo que hace un servicio, generar el primer esbozo de runbook, actualizar lo que quedó desactualizado.
La cuestión central es simple: cuando el trabajo de escanear volumen se vuelve barato, deja de ser el cuello de botella. El equipo que solo lograba reaccionar a los diez ítems más urgentes de la semana ahora logra atacar los trescientos. Eso es un giro real en el área. Y hay un lado que exige atención redoblada, que es exactamente el tema de la sección tres.
Lo que cambia en la capacidad de atacar el backlog:
¿Listo? La buena noticia es sólida. Pero solo sigue siendo buena si la próxima sección también es verdad en tu equipo.
02Lo que sigue siendo del equipo, y se volvió más crítico
Aquí está lo que la IA no decide por ti, y que pasó a valer más justamente porque la parte mecánica se abarató:
- La arquitectura. La IA compara opciones y sugiere un camino, pero nunca operó tu sistema un viernes de pico. Decidir la dirección estructural sigue siendo de quien vive con la consecuencia.
- La prioridad real detrás del ticket. Un ítem "de severidad baja" puede estar bloqueando al cliente que más paga. Eso es lectura de negocio cruzada con lectura técnica, y es tuya.
- La evaluación de riesgo. La IA señala lo que parece explotable o frágil. Decidir qué es crítico de verdad, en tu contexto específico, sigue siendo del equipo.
- Quién firma lo que va a producción. La IA propone el parche, el pull request, el rollback. Quien aprueba el merge y responde si sale mal es una persona. Siempre.
Nota que todo esto es criterio, no triage. Y el criterio es exactamente lo que se vuelve más caro cuando el triage se abarata. El trabajo del equipo, de aquí en adelante, vive mucho más en "esto realmente importa y es seguro subirlo" que en "logré con el volumen".
03La salvedad mortal: velocidad sin revisión se convierte en deuda e incidente
Ahora la parte que no se puede dejar pasar, porque en el área de tecnología cuesta muy caro. Un agente de IA logra abrir pull requests rápido, corregir bugs pequeños, proponer refactorización, en un volumen mucho mayor de lo que cualquier equipo logra revisar con el mismo cuidado de siempre. Esto no es hipotético: es el patrón que ya se ve en equipos que adoptaron agentes de código sin rediseñar la revisión.
El mecanismo del problema es fácil de ver y fácil de ignorar. Si la revisión de cada cambio se vuelve un sello rápido, porque hay demasiada gente para revisar y poco tiempo, la complejidad sutil se va acumulando sin que nadie lo note: una dependencia circular acá, una excepción mal manejada allá, un test que pasa pero no cubre el caso real. Nada de esto se rompe solo. El sistema sigue de pie, y la deuda se va apilando invisible, hasta que un día la combinación equivocada de factores aparece en producción, y se convierte en incidente.
Sabe más: por qué la deuda técnica generada por agente es distinta de la deuda de siempre
Todo equipo ya convive con deuda técnica, eso no es novedad. Lo que cambia con un agente de código operando en volumen es la velocidad de acumulación y la dificultad de rastrear el origen. Un humano cansado escribe un atajo malo de vez en cuando, y el patrón suele repetirse de un modo que el equipo reconoce con el tiempo. Un agente puede generar decenas de pull requests por semana, cada uno pequeño y aparentemente correcto por sí solo, pero la interacción entre ellos es lo que nadie revisó con atención, porque revisar la interacción entre cambios pequeños exige más tiempo que revisar cada cambio de forma aislada. El riesgo no está en ningún pull request específico. Está en la suma que nadie sumó. Por eso esta trilla vuelve a este punto dos lecciones más adelante, en la deuda técnica visible y en la auditoría del código que no leíste: el antídoto no es desacelerar la IA, es rediseñar la revisión para dar abasto con el volumen nuevo.
04El mapa de esta trilla
Esta lección fue el cuadro general. Las próximas bajan a lo concreto, una pieza a la vez:
- Conectar la IA al estado de tu sistema, sin filtrar secretos ni credenciales.
- El backlog que se hace triage solo, con tú decidiendo la prioridad real.
- La deuda técnica que nadie veía, volviéndose visible y priorizable.
- Incident response con copiloto, sin perder de vista la causa raíz.
- La decisión de build versus buy, con criterio, no con euforia.
- La auditoría del código que no leíste, antes de que se vuelva tuyo.
- Y, al final, tu OS del área de tecnología: los flujos y criterios que quedan trabajando por ti.
Cada una toma un pedazo real del trabajo del área y lo rediseña con la IA adentro, sin perder el control de vista. ¿Vamos?
Hazlo ahora
Toma una entrega técnica reciente de tu área, tu tarea real u otra (un pull request, un incidente resuelto, una decisión de arquitectura pequeña). Divide en una hoja en dos columnas:
- Mecánico (lo que la IA haría por ti): triage, primer borrador de corrección, resumen de log, esbozo de documentación.
- Criterio (lo que sigue siendo del equipo): la decisión de arquitectura detrás, la prioridad real considerando el negocio, la evaluación de riesgo, quién firma el merge o el deploy.
Ahora mira la proporción. ¿Cuánto del tiempo del equipo fue a la columna de la izquierda, al ritmo de hoy? Ese es el tiempo que esta trilla devuelve, para reinvertir en la columna de la derecha, que es donde vive el criterio que ya nadie más hace por ustedes.
Practica
1. En el nuevo juego del área de tecnología, ¿qué vuelve la IA tratable por primera vez en volumen?
2. ¿Por qué la velocidad sin revisión de verdad es especialmente peligrosa cuando un agente de IA genera muchos pull requests?
3. ¿Por qué el área de tecnología no puede tratar la revisión humana como opcional, aun con la IA acelerando el trabajo mecánico?
Para la pizarra
Sobre lo que se volvió tratablela triage en volumen, el primer borrador de corrección y el resumen de incidente. El board deja de ser una montaña.
Sobre el peligro de la velocidadnada se rompe solo en el camino. La deuda se apila invisible hasta que la combinación correcta estalla en producción.
Sobre la revisiónla IA acelera el borrador. La revisión es lo que garantiza lo que sube, y la firma final siempre es humana.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.