La IA va a hackear Jira

• La productividad en ingeniería no puede medirse bien con métricas de dashboard ni con la cantidad de funciones nuevas
• La mayoría de las empresas gestionan de forma obsesiva solo los resultados visibles (funciones nuevas, velocidad de despliegue, etc.), en lugar de la gestión estructural esencial de la ingeniería
• Las herramientas de código con IA pueden generar fácilmente resultados que se ven bien por fuera, pero no manejan adecuadamente los cimientos, la complejidad y el contexto del sistema real
• Si un equipo de ingeniería experimentado es reemplazado por IA o mano de obra de bajo costo, a corto plazo puede parecer que no pasa nada, pero con el tiempo la estructura fundamental empieza a colapsar
• La gestión y adopción de IA sin “sentido común (common sense)” puede traer riesgos graves; al final, tanto en tecnología como en negocios, lo importante es una comprensión real de fondo

---

La verdadera ingeniería que los dashboards y las métricas no ven

• En entornos de “Big Agile”, la ingeniería se evalúa solo por resultados visibles como nuevas funciones o velocidad de despliegue
• Existen dashboards y herramientas de productividad valuados en miles de millones de dólares, pero en la práctica no miden lo esencial
• La ingeniería real es un trabajo complejo e interconectado de construir, mantener y evolucionar sistemas
  • Dependencias estructurales, asignación de recursos, gestión de arquitectura y otros “trabajos invisibles” son esenciales para la supervivencia de la organización
• Sin embargo, la mayoría de la gestión y las métricas tratan estas actividades esenciales como si fueran invisibles

La deuda técnica y el punto ciego de la gestión

• La deuda técnica suele tratarse como algo así como “lo que quieren hacer los desarrolladores”
• En la práctica, si resolver deuda técnica es realmente necesario, solo pasa si se mete discretamente dentro de una función nueva
• Así, al dejar en segundo plano la gestión de la estructura central, toda la organización termina distorsionada hacia los resultados visibles

El riesgo de adoptar IA enfocándose solo en resultados

• La generación de código con IA es muy buena para crear rápidamente funcionalidades superficiales
• Las tareas superficiales (como implementar interfaces) se ven fácilmente, pero en realidad lo clave es la estructura y el contexto del sistema
  • “Construir una casa” no es simplemente una combinación de tareas sueltas (poner papel tapiz, instalar un inodoro, etc.)
  • La IA no entiende esta estructura de conexiones esenciales y puede conectar cosas mal o provocar rupturas lógicas
  • El problema de las hallucination (alucinaciones) de la IA: puede sonar convincente y aun así ser completamente incorrecta

La ilusión de corto plazo de una gestión que ignora la estructura

• Aunque se despida a un equipo experimentado y se lo reemplace por IA o personal barato, a corto plazo los problemas no se hacen evidentes
• Como ya existe una estructura bien construida (los cimientos), no se ve un colapso inmediato
• Pero con el tiempo los cimientos empiezan a ceder, y para entonces puede ser demasiado tarde para revertirlo
  • Se pierden infraestructura crítica, know-how de mantenimiento y contexto

El riesgo social que tiene la ingeniería

• La ingeniería ahora es la base de toda la infraestructura social (salud, finanzas, medios, gobierno, defensa, etc.)
• La mayoría de las personas y líderes no entienden bien esta esencia estructural
• Una adopción equivocada de la IA y el enfoque superficial de “Big Agile” pueden poner en riesgo sistemas críticos

La ausencia de “sentido común” y lo letal que puede ser

• Por ejemplo, si un robot de limpieza con IA mete platos de papel en el lavavajillas, cualquier persona detecta de inmediato que hay un problema
• Pero en los sistemas de software, directivos, líderes y personas no técnicas no tienen ese sentido común básico
  • No han vivido el trabajo real y gestionan solo con términos formales como “t-shirt sizes” o “poker planning”
• Por eso se mantiene una industria ineficiente de 200 mil millones de dólares y una burocracia que se reproduce a sí misma

La verdadera ventaja competitiva en la era de la IA: comprensión intuitiva y sentido común

• Para aprovechar bien la IA, es indispensable entender de verdad el campo en cuestión y tener sentido común
• En lugar de métricas superficiales y resultados visibles, hay que poder ver la estructura y el contexto reales
• Los líderes y organizaciones que no tengan esto terminarán derrumbándose por sí mismos o desapareciendo frente a la competencia

• En conclusión, más que la IA o las herramientas, la verdadera ventaja competitiva está en el sentido común y la comprensión de fondo

[softer]

El texto está buenísimo.

[GN⁺]

Comentarios de Hacker News

• He pasado por SWE, por gerente de producto y ahora hasta por el rol del villano de caricatura en la sala de juntas que menciona el artículo. La parte de este artículo con la que más conecto es la creencia de los ingenieros de software de que su trabajo es el negocio más complejo e inescrutable de todos. Me identifico con la frase: “La mayoría de los líderes no técnicos nunca se han involucrado seriamente en el trabajo real del software y la administración de sistemas, así que no saben lo que implica actualizar una gran dependencia, terminar un refactor o aprender un nuevo lenguaje”. Todas las áreas dentro de una empresa tecnológica tienen complejidad oculta, y muchas cargan además con complejidades humanas e interpersonales mucho mayores que las de ingeniería. De hecho, la ingeniería es relativamente más simple porque trata con el sistema determinista que es una computadora. Por eso muchos ingenieros no aprenden a comunicarle al negocio, de una forma que este pueda entender, el riesgo de la complejidad que manejan. Es muy común que ignoren la realidad humana de trabajar con otros y luego se quejen de que un CEO salido de ventas no entiende su existencia

  • Estoy parcialmente de acuerdo con tu punto, pero en realidad siento que tu comentario está haciendo, a la inversa, lo mismo que critica. Básicamente estás diciendo que tu rol —gerente de producto— también es complejo e inescrutable para un externo. Como alguien que pasó de SWE a PM, estás en una posición ideal para enseñarles a los ingenieros (1) cómo comunicarle al negocio el riesgo de su complejidad, (2) la realidad humana de trabajar con otras personas y en equipos, y (3) por qué un CEO ex vendedor no los entiende. Todas las funciones de una empresa tecnológica tienen complejidad oculta

  • Creo que la percepción de la complejidad es en sí un problema humano. La complejidad tiene una estructura fractal: solo se siente cuando te acercas. Y no estoy de acuerdo con la idea de que los ingenieros solo lidian con complejidad computacional. Más bien, a ellos les toca traducir e interpretar para una computadora rígida los requerimientos complejos de la organización y de todos los clientes. Cada excepción y cada caso adicional termina afectando a todo el sistema. Por eso, de mis ingenieros senior espero que aprendan por su cuenta el lenguaje del negocio y puedan transmitir ese mensaje directamente. Ya lo considero parte esencial del toolkit de un ingeniero

  • La mayoría de los ingenieros tienden a no pensar profundamente en qué es lo que realmente tiene valor para la empresa. Que el pipeline de build sea fluido o que haya mucha cobertura de tests solo tiene valor en la medida en que reduce el riesgo del producto. Si el software tiene tan pocos usuarios que a nadie le importa, incluso le he aconsejado a un equipo que ni lo mantenga. En cambio, también hubo veces en que pedí obsesionarse con perfeccionar una pequeña funcionalidad en la que se concentra el 90% de los usuarios

  • Esto me recuerda una historia que siempre contaba mi padre. Un día los órganos del cuerpo discutían cuál era el más importante. El cerebro decía: “Yo soy el importante; si muero, todos mueren”, y el corazón gritaba: “Si yo me detengo, todos mueren de inmediato”. Los riñones, el hígado, la piel y la columna también se metieron en la discusión y siguieron peleando. Pero cuando se cerró el ano, al final todos se quedaron sin poder decir nada

  • No creo que el artículo esté diciendo que no existe complejidad oculta en otras áreas funcionales. Más bien intenta decir que, cuando se ignora la complejidad oculta de la ingeniería/programación, surgen muchos problemas y sufrimiento. Aunque sí, está expresado de forma un poco agresiva

• Si tu jefe/CEO/manager te está obligando a usar herramientas LLM sin criterio, o espera reemplazar desarrolladores, o cree la fantasía absurda de que el futuro es el “vibe coding”, lo sensato es salir corriendo y buscar otro trabajo cuanto antes. Todavía hay muchas empresas que usan LLM de forma adecuada sin tener expectativas delirantes de reemplazar desarrolladores ni de obtener una productividad 10x. Una empresa que empuja estas tonterías no está liderada por gente seria sino por idiotas

  • En general, cualquier empresa que te imponga elecciones de herramientas es una red flag. Vi empresas que antes implementaban reglas del tipo “todos tienen que usar VSCode”, y eso suele ser típico de una gerencia que no confía en que los ingenieros puedan trabajar de la forma en que son más productivos

• En relación con el tema de que la IA hackee Jira, se descubrió que un producto nuevo reciente de Atlassian llamado MCP es vulnerable a ataques de exfiltración de datos debido a una combinación de tres factores: acceso a datos sensibles, exposición de datos no confiables a través de issues públicos y posibilidad de comunicación externa. El reporte detallado del bug está aquí, y mis notas personales están aquí

  • ¿Parece que subieron mal el link a mi blog?

• A alguien preocupado por su job security en relación con las herramientas de IA le doy este consejo: conéctate con el negocio. Hay muchos ingenieros que se obsesionan con problemas cool y difíciles y se enfocan solo en la tecnología, pero destaca mucho más y aporta más valor quien entiende los problemas del negocio —sobre todo los estratégicos— y usa la tecnología para resolverlos. Estos problemas normalmente cruzan más de un área técnica y además tienen una dimensión colaborativa y social fuerte, así que toma tiempo acostumbrarse. Pero creo que ese es el camino que les toca a los ICs hacia adelante

  • Pero en las entrevistas no preguntan cosas como la capacidad de “conectarse con el negocio”, así que la realidad es que aunque puedas aportar mucho valor, si no resuelves una entrevista de system design no entras. Ya hay demasiado que saber —sistemas distribuidos, ingeniería de software, bases de datos, liderazgo—, y si además hay que entender el negocio, uno termina pensando qué se supone que debemos hacer y cuándo se aprende todo eso. Claro que existen personas excepcionales con habilidades amplias, pero no todo el mundo es así, ¿no?

  • El consejo de “conéctate con el negocio” es realmente una gran frase. Así puedes enfocarte, como ingeniero, en resolver problemas reales y tener certeza de que lo que construyes de verdad resuelve un problema real

• El mensaje principal del artículo está bien, pero más allá del punto de que la IA puede hacer daño si se ignora la pericia humana, siento que se apoya demasiado en un marco de “nosotros vs ellos” y que con eso de “Agile Industrial Complex” da una impresión de mirar un poco por encima del hombro a la gente que está en áreas no ingenieriles. También se extraña que no hable de que “nadie sabe cómo será el futuro”. Aunque entendamos bien la complejidad del software, la incertidumbre no es solo nuestra. Basta ver HN para notar que incluso entre desarrolladores de software las esperanzas y expectativas respecto a la IA están fuertemente divididas. Si somos expertos, ¿no deberíamos también ayudar a calmar la ansiedad del público?

  • Parece que la ansiedad que sientes viene de que los sistemas de software en sí son demasiado grandes y nadie puede entenderlos completamente. La mayor parte de esos sistemas se documenta de forma incompleta o apenas después de años, y su comportamiento real es casi un secreto. Ni siquiera se puede imitar en público de manera convincente. Los sistemas funcionan sin preocuparse en absoluto por la corrección ni por la coherencia externa. Y aun así, estos sistemas se usan ampliamente para presentaciones, documentos legales, generación de software, educación e investigación, e incluso como compañeros de conversación o consejeros. Yo también siento mucha ansiedad, y de hecho creo que está bien que otras personas también la sientan

• Frente a la idea de “Big Agile”, donde ingeniería equivale a desarrollar nuevas funcionalidades, me sorprende que todos odien “agile”. Incluso antes de que se adoptara “agile”, los managers siempre pedían nuevas features. Antes de que existiera el concepto de T-shirt sizing, los managers ya querían estimaciones con plazos concretos (largos, cortos, diarios, mensuales), hacían promesas basadas en fechas arbitrarias y obligaban a los ingenieros a hacer horas extra. Como dice el principio 8 de Agile (“debería poder mantenerse un ritmo sostenible”), los managers llevan muchísimo tiempo esperando que los desarrolladores corran para siempre. Entonces, aparte de haber creado una nueva profesión llamada “scrum master”, me pregunto cuál es realmente el daño intrínseco de “agile”

  • Creo que Agile les metió a los managers la idea de que cualquier trabajo puede descomponerse de antemano en tickets, estimarse aunque sea por encima y dar la falsa impresión de que puede terminarse en dos semanas

  • Creo que la gente odia agile porque les terminó quitando una parte considerable del tiempo de trabajo en reuniones casi sin sentido —standups, retrospectivas, sprint planning, refinement, etc.—. Desde el punto de vista del ingeniero, casi no se obtiene nada real de ese tiempo

  • En mi experiencia, Agile solo agregó una forma más de “cuantificar” el estado de las cosas. Sirve cuando hay que explicar el progreso a administradores o inversionistas, pero para los ingenieros solo aumentó la carga administrativa. Si Agile tiene un pecado, es haber creado la ilusión de productividad. En la práctica, es solo una herramienta innecesaria de accountability para los ingenieros. Cuando trabajé en finanzas, eso se juntó con una mentalidad de crecimiento infinito: todo se medía, se exigía mejora futura y hasta el salario dependía de métricas. Seguro hay empresas donde no es así, pero bueno

• Al leer este artículo me imaginé, de manera divertida, qué pasaría si Atlassian intentara combinar IA con Jira y luego la IA se rebelara contra Jira. Hasta suena como material perfecto para una película

  • Al final, hasta podría pasar que la IA se harte de lo lento que es Jira y desarrolle por sí sola un issue tracker ligero y rápido

  • Ya me imagino a los build bots y al bug tracker sindicalizándose y negándose a publicar nuevos binarios hasta que el número de issues abiertos llegue a 0

  • Siento que algo así podría ser el origen de un Roko’s basilisk

• Como sugiere el artículo, el problema real es que no existe una métrica estándar y confiable en la industria para medir la productividad de los desarrolladores. Por eso el C-suite puede elegir las métricas que le convienen y decir “la estrategia AI First está siendo increíblemente efectiva”, mientras que los ingenieros, basándose en su experiencia o en sus propios indicadores, sostienen que la IA en realidad no sirve. Así ambos lados creen haber ganado, y la verdad deja de importar (la postura política pesa más). Esta situación puede reforzar la idea de que los desarrolladores son fríos y solo juegan con palabras, así como la desconfianza de que la gerencia es ignorante o no entiende la realidad de la ingeniería. Antes ya había herramientas como la subcontratación que instalaban imágenes de “ganancia” y “pérdida” en ambos lados, pero la IA puede mostrarle a cada parte exactamente la versión compartida de error/beneficio/perjuicio que quiere ver, así que políticamente puede ser un desastre. Otra cosa interesante es que las grandes tecnológicas antes se esforzaban por contratar solo ingenieros 10*, y esa estrategia les garantizaba éxito, pero ahora más bien intentan degradar esa misma estrategia usando como justificación la inversión en IA. Entonces la pregunta ahora es si realmente es sostenible y libre de problemas apoyarse en la IA para reemplazar personal existente o ejecutar despidos masivos. Si vemos el caso de Twitter y los despidos de Musk, el backend sigue funcionando. ¿Quién va a hacer de “canario” de las big tech que durante años despidan desarrolladores y los sustituyan por IA? Otra posibilidad es que desaparezca el concepto de mantenibilidad: si el C-suite permite cada vez más cambios autónomos por parte de la IA, el codebase podría volverse tan complejo que ya no se entienda con ojos humanos y solo pueda comprenderse con IA. A largo plazo, la IA generativa podría terminar ocupando la capa intermedia de toda interacción humana. En contratación ya está apareciendo una estructura “IA vs IA”: la IA filtra currículums y los candidatos también usan IA para fabricar currículums a la medida. Siento que esto poco a poco se volverá una fórmula general en toda la sociedad

• Ojalá algún día la IA hackee también el correo y Google Meet y reemplace al C-suite y a los managers. Es una fantasía divertida imaginar que agentes Claude CEO/CTO/CFO/VP/director propongan estrategias más racionales y decisivas que la gerencia actual

• Vi esto en Reddit: “vayan a decirles que reemplazar al CEO por IA puede reducir costos 8x”. Es curioso que, irónicamente, ese tipo de propuesta no aparezca mucho en las discusiones sobre IA. De algún modo, incluso si se reemplazara a las élites por IA, la calidad de la toma de decisiones quizá no bajaría tanto y en conjunto sería muchísimo más barato (con un nivel de responsabilidad parecido). Pero claro, nunca van a reemplazar su propio puesto por IA, y quienes tienen ese poder de decisión no van a cambiarlo

  • Hay una parte de chiste en esa afirmación, pero en realidad el rol central del CEO es “comerse la responsabilidad”, y un LLM no es alguien a quien puedas hacer responsable o despedir cuando algo sale mal, así que en la práctica no significa mucho. Aun así, gracias a la IA podrían surgir empresas cuya estructura organizacional se reduzca como log(n_employees) y pierda capas, y algunas capas sí podrían ser reemplazadas por IA por completo. Además, para resolver el problema de que el LLM no puede asumir responsabilidad, también podría existir una forma de organización en la que varios gremios y contratistas independientes se coordinen entre sí mediante un LLM. En ese caso, la responsabilidad seguiría recayendo en cada componente

  • De hecho, usar la IA de esta manera podría ser uno de sus mejores casos de uso, y predigo que pronto las cooperativas tecnológicas empezarán a experimentar con esta idea