Cuando todos tienen IA pero la empresa aún no aprende nada

• Mejorar la productividad individual de los empleados con IA no se traduce automáticamente en aprendizaje a nivel organizacional, y el desafío clave es el camino por el que los hallazgos reales pasan del individuo al equipo y a la capacidad de la organización
• En la compleja etapa intermedia de la adopción de IA, el uso de herramientas como Copilot, ChatGPT Enterprise, Claude, Gemini y Cursor ya está muy extendido, pero la profundidad de uso varía entre equipos, y parte del aprendizaje queda oculto, lo que dificulta compararlo y difundirlo
• Los métodos tradicionales de gestión del cambio —comunidades, redes de champions, demos, encuestas y dashboards— tienen dificultades para capturar suficientemente el contexto, los fallos, la validación y la intervención humana que surgen en el uso de IA dentro del trabajo real
• La ingeniería agentiva reduce el costo de iterar y permite pasar rápidamente de la intención al prototipo y la evaluación, pero los procesos organizacionales de Scrum, sprints y handoffs todavía pueden seguir basados en la premisa de que iterar es algo poco frecuente
• Las organizaciones necesitan en conjunto Agent Operations, Loop Intelligence y Agent Capabilities; lo importante no es vigilar a los empleados, sino contar con un arnés de retroalimentación que entienda los loops reales de trabajo y los convierta en capacidades reutilizables y aprendizaje más rápido

---

La compleja etapa intermedia de la adopción de IA en la que la organización no logra aprender

• Desde la perspectiva de Ethan Mollick en Leadership, Lab, and Crowd, aumentar la productividad individual con IA no se convierte automáticamente en resultado a nivel organizacional
  • Los empleados pueden escribir más rápido, analizar más, automatizar y trabajar como “cíborgs”, pero la empresa puede no aprender casi nada
  • Herramientas como GitHub Copilot, ChatGPT Enterprise, Claude, Gemini y Cursor ya entraron a la empresa, y en cada equipo hay personas que van mucho más adelante que los materiales oficiales de capacitación
  • La dirección puede ver uso de licencias, cantidad de prompts, encuestas, PoC internos y materiales de comités de dirección, pero casi no puede ver dónde ocurre realmente el aprendizaje
  • En algunas empresas, la IA pasa directamente al área de TI y después ya no avanza más
• La compleja etapa intermedia de la adopción de IA comienza cuando el uso de IA ya está extendido, pero de forma desigual, parte está oculto, es difícil de comparar y todavía no está conectado con el aprendizaje organizacional
  • La unidad de adopción ya no es toda la organización, y quizá ni siquiera el equipo, sino el loop dentro del trabajo real

Lo que pasa después de que todos tienen Copilot

• La primera etapa de adopción de IA se parece a un rollout empresarial tradicional y resulta relativamente familiar
  • Se compran asientos, se define el uso permitido, se da capacitación, se crean redes de champions y se comparte casos de uso en canales de Teams
  • Estos canales pueden estar activos por un tiempo y luego terminar pareciendo una bodega interna llena de buenas intenciones
• En la segunda etapa, la forma de usar IA se divide fuertemente incluso dentro de la misma empresa
  • Algunos equipos usan Copilot solo como autocompletado
  • Otros hacen correr Claude Code en loops cerrados con pruebas, revisión y ajustes continuos
  • Personas de producto prototipan software real en lugar de solo crear pantallas en Figma
  • Un ingeniero senior delega a un agente el análisis de causa raíz, obtiene una solución válida en una hora y acorta una tarea que sin IA habría tomado dos semanas
  • Un junior puede producir código pulido, pero quizá no entienda qué supuestos de arquitectura se metieron en el sistema
  • El equipo de soporte convierte silenciosamente tickets repetitivos en automatización de workflows y conoce los verdaderos puntos de dolor que el Center of Excellence no logró preguntar
• En el marco de Mollick, el liderazgo define dirección y permisos, el Crowd hace el trabajo real y por eso descubre casos de uso, y el Lab convierte esos hallazgos en prácticas compartidas, herramientas, benchmarks y nuevos sistemas
  • La dificultad central está en cómo esos descubrimientos pasan realmente del individuo al equipo y del equipo a una capacidad organizacional

La gestión del cambio tradicional es demasiado lenta

• La mayoría de las empresas intenta manejar la adopción de IA con mecanismos tradicionales de gestión del cambio
  • Se usan comunidades de práctica, sesiones de almuerzo, redes de champions, materiales de enablement, office hours, demos mensuales, encuestas y dashboards
  • En organizaciones donde todavía hace falta permiso incluso para experimentar, estos métodos también ayudan
• Pero los usos interesantes de la IA no esperan a la próxima reunión de la comunidad: aparecen dentro del trabajo real
  • Surgen en code reviews, propuestas comerciales, trabajo de investigación, prototipos de producto, incidentes operativos, estrategias de testing y preguntas de compliance
  • En ciertos tipos de componentes de producto puede formarse un patrón cercano a una “dark factory”
    • Se escribe la intención
    • Se deja que el agente recorra un loop flexible
    • Se aplica suficiente backpressure para mantenerlo en curso
    • Se evalúa el resultado con escenarios sólidos
    • Se refina la intención y se obtienen resultados de alta calidad de manera iterativa
• El aprendizaje que fue útil suele perder filo cuando se resume en slides de best practices
  • Porque el valor real vino del contexto que faltaba, las pruebas fallidas, el comportamiento extraño de una API y la fricción con la que una persona hizo volver al agente cuando se desvió hacia el absurdo
• Desde la perspectiva del elastic loop, la colaboración con IA no es un solo modo
  • Va desde una co-conducción cerrada y sincrónica hasta una delegación más suelta y asincrónica
  • La pregunta importante no es “¿la gente usa IA?”, sino qué tamaño de loop debe usar el equipo, dónde hace falta resistencia, qué artefactos deben sobrevivir después del loop y cómo esos artefactos se convierten en aprendizaje organizacional
  • Son preguntas mucho más difíciles que medir uso de herramientas o contar tokens

Scrum fue creado bajo la premisa de que iterar era caro

• Gran parte de los procesos modernos de software existen porque la iteración humana era costosa
  • Ahí entran la planificación de sprints, estimaciones, standups, historias de usuario, ordenamiento de tickets, handoffs y rituales para coordinar y reducir riesgos
  • Si una iteración tardaba días o semanas, hacía falta una estructura para evitar iteraciones desperdiciadas
• La ingeniería agentiva cambia la economía de iterar
  • Permite materializar más opciones en la práctica
  • Hace posible pasar más rápido de la intención al prototipo y la evaluación
  • Permite que producto vea software funcionando antes
  • Permite que ingeniería pruebe más hipótesis antes de decidir
  • No vuelve mágica la entrega en sí, pero desplaza las restricciones de la implementación hacia la intención, la validación, el juicio y la retroalimentación
• Muchas organizaciones llevan 20 años llamándose ágiles, pero conservaron los reflejos organizacionales que Agile quería eliminar
  • La IA hace más plausible la agilidad real, pero el sistema todavía exige compromisos de sprint de dos semanas, documentos de handoff y procesos basados en la idea de que iterar es raro
  • Los loops pueden moverse más rápido de lo que la organización puede digerir lo que aprende de ellos

El costo de usar IA obliga a hacer mejores preguntas en la organización

• Es probable que el uso de IA se vuelva mucho más medible
  • El ambiente empresarial actual de “todos tienen acceso y el costo no preocupa demasiado” puede no durar mucho
  • El model routing, los presupuestos de tokens, los precios por uso, el costo de inferencia y la gobernanza sobre qué modelo permitir para qué trabajo se volverán más explícitos
• La pregunta importante no es reducir el costo de tokens de forma abstracta
  • Igual que en la entrega de software la pregunta importante no era minimizar la cantidad de teclas presionadas
  • La mejor pregunta es: “¿qué cambió porque se gastaron esos tokens?”
• Hay que evitar medir solo la cantidad de pull requests
  • ¿Qué loops se cerraron más rápido?
  • ¿Qué decisiones mejoraron?
  • ¿Qué análisis de causa raíz se volvió más preciso?
  • ¿Qué revisiones detectaron más problemas?
  • ¿Qué equipo aprendió patrones reutilizables?
  • ¿Qué idea de producto se descartó antes porque el prototipo expuso sus debilidades?
  • ¿Dónde la IA generó aprendizaje y dónde solo generó más entregables?
• “Output por token” es un reflejo de medición viejo con ropa nueva
  • Lo más importante se parece más a aprendizaje por token

Loop Intelligence como ruta de retroalimentación faltante

• En la compleja etapa intermedia de la adopción de IA, la empresa necesita tres capacidades

• Agent Operations

  • Gestiona qué agentes y herramientas de IA están en ejecución, qué sistemas pueden tocar y qué datos pueden ver
  • También incluye qué acciones requieren aprobación, dónde están la identidad, la auditoría, los permisos y la visibilidad de runtime
  • Como el trabajo agentivo termina tocando sistemas reales, el aspecto de control es importante

• Loop Intelligence

  • Identifica qué loops asistidos por IA o completamente agentivos están generando aprendizaje real
  • Observa qué loops quedan abiertos, cuáles se degradan, dónde los agentes generan leverage y dónde se desvían por ramas secundarias
  • Permite juzgar qué equipos están atados a supervisión estrecha por falta de pruebas, contexto o criterio, y cuáles están listos para una delegación más flexible

• Agent Capabilities

  • Distribuye capacidades útiles en toda la organización sin asumir que tres agentes gigantes pueden hacer el trabajo de todos
  • La IA empieza a comportarse más como una tecnología base fluida que como una sola categoría de aplicación
  • No encaja bien con el modelo de poner un “agente de RR. HH.”, un “agente de ingeniería” y un “agente de ventas” en el zoológico empresarial
  • Las capacidades deben fluir hacia donde ocurre el trabajo real
    • harness del empleado
    • agentes en segundo plano
    • equipos de producto
    • servicios de plataforma
    • skills locales
    • servidores MCP
    • suites de evaluación
    • runbooks
    • ejemplos
    • procedimientos por dominio

La pregunta de plataforma y el arnés de retroalimentación

• A nivel de plataforma, la pregunta importante es cómo se poseen y se mueven las capacidades útiles
  • Hace falta una forma de transferir a otros equipos una skill agentiva útil descubierta por un equipo, sin que se convierta en una plantilla muerta
  • El harness del desarrollador, el harness de producto, los agentes en segundo plano del equipo de soporte y los workflows de compliance deben reforzarse de maneras distintas
  • Algunas capacidades deben estar cerca del equipo, otras en la capa de plataforma, y otras no deben generalizarse porque su contexto local es justamente lo esencial
• Si solo existe una de las tres capacidades, todo se vuelve raro rápidamente
  • Agent Operations sin Loop Intelligence se vuelve una burocracia de control
  • Loop Intelligence sin Agent Capabilities se vuelve una capa analítica que descubre patrones útiles, pero no logra reinsertarlos en el trabajo
  • Agent Capabilities sin Operations ni Loop Intelligence se vuelve proliferación de herramientas con mejor branding
  • El camino de control, el camino de aprendizaje y el camino de capacidades tienen que encontrarse en algún punto
• Internamente, esto puede llamarse un arnés de retroalimentación
  • Lo que el cliente compra no es un mecanismo elegante, sino confianza, mejores decisiones, aprendizaje más rápido, menos desperdicio y delegación más segura
  • Un concepto más útil para el cliente podría ser Loop Intelligence Hub
• El arnés de retroalimentación es un dispositivo para escuchar los loops reales de trabajo
  • Observa tareas, prompts, especificaciones, revisiones, escenarios, hipótesis adoptadas o descartadas, señales operativas, retrabajo y decisiones e intervenciones humanas
  • No es para vigilar personas, sino para entender los loops
  • La primera versión no necesita ser una plataforma gigantesca
  • Basta con elegir algunos workflows reales, instrumentar los puntos donde la intención, el trabajo del agente, la validación y la decisión humana ya dejan huella, y reunir suficiente feedback cualitativo para entender por qué el loop tuvo éxito o fracasó y convertirlo en artefactos de aprendizaje iterables
• Loop Intelligence Hub transforma las señales en formas sobre las que la organización puede actuar
  • backlog de enablement
  • radar de capacidades
  • briefs de inversión
  • vacíos de gobernanza
  • workflows reutilizables
  • necesidades de capacitación
  • prioridades de evaluación
  • No hace falta un dashboard único para todo, sino salidas ajustadas a la relevancia
• El artefacto interesante no es el dashboard en sí, sino la decisión que viene detrás
  • Algunos equipos necesitan mejor backpressure antes de delegar más
  • Algunos grupos de producto ya tienen un patrón repetible de dark factory para un tipo estrecho de componente
  • Algunos workflows de compliance necesitan límites de herramientas con gobernanza aplicada
  • Algunas skills deben moverse a plataforma porque cinco equipos ya las reinventaron mal
  • El harness recopila, el hub ayuda a decidir a la organización y la capa de capacidades vuelve a meter el aprendizaje en el trabajo

Si se convierte en vigilancia de empleados, fracasa

• Si esta estructura se convierte en un sistema para calificar empleados, todo se derrumba
  • Si los empleados creen que la organización está midiendo si usaron suficiente IA, manipularán la señal
  • Si creen que todo experimento se convertirá en una expectativa de productividad, ocultarán los experimentos
  • Si creen que el mejor workflow se convertirá de inmediato en la nueva carga base de trabajo, lo mantendrán privado
  • La empresa obtendrá la peor forma de adopción posible: cumplimiento visible y aprendizaje invisible
• La pregunta útil no es “¿quién usa suficiente IA?”
  • ¿Dónde la IA cambió el trabajo de una forma de la que la organización pueda aprender?
  • ¿Qué loops se volvieron más saludables?
  • ¿Qué equipos necesitan mejor backpressure antes de delegar más?
  • Si los prototipos ya se están convirtiendo en software real, ¿qué equipos de producto necesitan un entorno distinto?
• Las políticas hacen falta, pero la gobernanza, igual que el aprendizaje, solo se vuelve real a través del uso
  • Cuando los agentes tocan tareas cercanas a operaciones
  • Cuando producto construye prototipos en vez de escribir especificaciones
  • Cuando un desarrollador delega análisis de causa raíz
  • Cuando el gasto en tokens crece y la dirección quiere respuestas
  • La organización descubre entonces si construyó un sistema de aprendizaje o si solo compró muchos asientos

La compleja etapa intermedia no es una etapa para aguantarla

• La primera etapa de adopción de IA trataba sobre acceso
  • Importaba quién recibía la herramienta, quién obtenía permiso, quién negociaba el contrato y quién podía probar el modelo más reciente sin abrir un ticket de compras
  • Esa etapa sigue siendo importante, pero no será un diferenciador por mucho tiempo
  • El acceso a inteligencia de frontera se puede tomar prestado, pero el control operativo y el aprendizaje organizacional no se pueden tomar prestados de la misma manera
• La siguiente ventaja es la velocidad de aprendizaje
  • ¿Quién encuentra patrones reales más rápido?
  • ¿Quién logra mover hallazgos del individuo al equipo y del equipo a una capacidad organizacional?
  • ¿Quién introduce backpressure en los loops agentivos para evitar que los agentes se dispersen?
  • ¿Quién distribuye capacidades agentivas útiles sin convertirlas en un agente empresarial gigante que supuestamente sirve para todos?
  • ¿Quién usa la ingeniería agentiva para acercar Agile a la realidad, en vez de simplemente añadir IA a los rituales existentes?
• Esperar un playbook de adopción definitivo dificulta entender este cambio
  • En lugar de esperar la respuesta final de vendors, consultoras o laboratorios de IA, hay que instrumentar el trabajo real, compartir el aprendizaje desordenado, dejar que otros le encuentren grietas y iterar en público

[GN⁺]

Opiniones de Hacker News

• En entornos de grandes empresas, la adopción de IA casi no ha salido de los equipos de desarrollo, y solo los desarrolladores pueden usar GitHub Copilot
  Que el código pase del commit al despliegue en producción toma entre 6 y 12 meses, y la velocidad de desarrollo nunca fue el cuello de botella principal
  Lo que consume tiempo son procesos como el aprovisionamiento de infraestructura, las pruebas, las aprobaciones, la gestión de cambios y los calendarios de despliegue, y la IA empeora aún más el cuello de botella posterior al desarrollo al hacer que los cambios se acumulen frente al tren de lanzamientos
  Si una gran empresa quiere obtener retorno sobre la inversión del costo de los tokens, tiene que aprender a desplegar software más rápido, y el código no desplegado no es un activo sino una deuda

  • La dirección sigue viendo el software como una línea de ensamblaje, y piensa: “hacemos software como Ford fabrica autos”
    Es cierto que el desarrollo de software es ineficiente, pero lo central no es escribir código sino investigar y diseñar para descubrir qué código hay que escribir, y eso casi no se toma en cuenta
    Cuando Microsoft grita “¡50% más rápido escribiendo código!”, la dirección lo interpreta como “producto 50% más rápido, dinero 50% más rápido”
    En cuanto exijan retorno sobre la inversión, es muy probable que se vuelva un desastre, y por ahora todos solo están evitando medirlo
    En algún momento los inversionistas dirán: “gastamos 2 millones de dólares, así que dennos 4 millones en utilidad neta”, pero es difícil que eso ocurra
    Copilot y Claude no resuelven los verdaderos cuellos de botella: conocimiento organizacional antiguo, soluciones especiales no documentadas y posibles usos futuros
    El código no es el producto real ni el trabajo real; en una base de código sana, es casi un subproducto gratis del proceso de diseño e investigación
    Una vez que conviertes “al equipo de compras le cuesta usar la búsqueda” en un ticket práctico, el componente de filtro de búsqueda en React ya está básicamente decidido, y programarlo se parece más a un trámite formal de 10 minutos
    Aunque Copilot lo reduzca a 5 minutos, no impresiona mucho si antes ya invertiste 6 horas en reuniones y llamadas
  • Las grandes empresas todavía no aprenden ni lo básico de que menos código es mejor, así que cuesta esperar que de pronto aprendan conceptos más avanzados como desplegar software más rápido
  • En sistemas lo bastante grandes, llega un punto en que tener más código va en contra de lo que realmente se necesita
    La nutrición y las calorías también solo son útiles hasta cierto punto; después el rendimiento disminuye y al final aparecen efectos negativos
    No es una analogía perfecta, pero ayuda a formar un modelo mental donde producir más termina generando menos valor
    Recibimos comentarios de clientes diciendo que la documentación era completa y detallada, pero demasiado abrumadora, y al final descubrimos que unos pocos bullet points breves transmitían mejor lo esencial que un documento de 5 páginas
  • Lo viejo solo volvió a ser nuevo: una versión para la era de la IA de la teoría de restricciones
    [0] https://en.wikipedia.org/wiki/Theory_of_constraints
    [1] https://www.goodreads.com/book/show/113934.The_Goal
    [2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
  • Hoy, en entornos de grandes empresas aún más grandes, la adopción de IA parece haberse torcido hacia algo peor
    Desde finanzas nos preguntaron si podían vibe codear una app de planificación financiera con Copilot, Cursor y Claude, e incluso dijeron que “el CFO probó Lovable, quedó convencido y nos pidió vibe codear una app”
    Como saben que la dirección se congela en cuanto aparece la frase “lo dijo el CFO”, usaron esa lógica como escudo
    Al final hasta lo envolvieron con una frase elegante del tipo “tenemos que validar si una app hecha con vibe coding puede existir en el ámbito financiero corporativo con la seguridad de datos y mantenibilidad adecuadas”
    Lo más sorprendente es que este razonamiento salió de una empresa con más de 20 mil millones de dólares en ingresos anuales

• Para un ingeniero común como yo, usar IA en la empresa no tiene una ventaja real
  La empresa nos está hirviendo lentamente, y la élite de HN —inversionistas, ejecutivos, celebridades y los ingenieros top— dirá “¿cómo puedes oponerte a la innovación?”
  La IA/LLM no es una innovación del tipo TCP/IP, Linux o Postgres
  Claude, Codex, Gemini, Grok y similares existen para generar ganancias; son herramientas para exprimir la productividad hasta la última gota y luego poder despedirte cuando ya no seas necesario
  Si la IA te parece buena, mejor usar modelos open source y aplicarlos en proyectos personales

  • El juego no se está acabando, se está transformando
    La IA puede generar mucho código, pero siguen haciendo falta ingenieros que entiendan qué está pasando de verdad, y ese siempre fue el cuello de botella
    Puede que desaparezcan los puestos junior, pero los ingenieros senior parecen estar bien por un tiempo
    Yo también soy medio contrera por naturaleza, así que esta fue una lección dura: una vez que estás contratado, te contrataron para hacer lo que la dirección quiere
    Si te resistes, solo puedes esperar que no lo noten o que no les importe, porque generar un cambio grande es difícil
  • ¿No será que la ventaja es que el trabajo se vuelve muchísimo más fácil? No sé qué me estoy perdiendo
  • Existe una narrativa sobre cómo los capitalistas explotan a los ingenieros, pero incluso desde la perspectiva de un ejecutivo, quitando el tema del “bono del próximo trimestre”, todo esto parece una locura
    No sé si recuerdan lo que SCO le hizo a la industria mientras se hundía
    Sigo sin entender cómo las empresas entregan a startups y a megacorporaciones poco confiables su información confidencial interna: código, procesos, requerimientos de clientes, política interna, ideas del liderazgo
    Microsoft también fue famosa en su momento por abusar de acuerdos de confidencialidad y de su poder comercial
    No creo ni por un segundo que las grandes empresas de LLM no vayan a entrenar con materiales corporativos, ni que no vayan a mentir diciendo que no lo hacen
    Si empiezan a derrumbarse, esta fiebre del oro puede dejar una cola larga y fea
  • En Hacker News parece haber ideas distorsionadas sobre cómo ve un CEO a sus empleados y por qué ocurren los despidos, y esta es una interpretación muy mala
    En la práctica, a quienes despiden es a los que no adoptan estas tecnologías; si actúas así, te estás metiendo tú mismo en la zona de despido
    Basta ver el caso de Coinbase hoy: están sacando a quienes no aceptan el futuro
    No ayudan al avance, no empujan hacia adelante y además frenan a quienes sí lo hacen

• El texto acierta exactamente en ese messy middle
  Un desarrollador cuya responsabilidad y empleo están en juego casi no tiene incentivos para crear esos bucles de inteligencia
  Por muy amablemente que lo pida la dirección, no pienso compartir de forma altruista y gratis con toda la empresa mis aumentos de productividad
  Si es una herramienta útil, quizá la comparta, pero el know-how de cómo trabajar con IA o configurar agentes es mejor guardárselo si no hay reconocimiento por compartirlo
  En nuestra empresa crearon premios al “prompt de la semana” y sesiones durante el almuerzo para expandir la adopción, y hasta hay equipos desarrollando esos flujos
  Pero sin una compensación económica real ni seguridad laboral, el riesgo y el costo de difundir ese conocimiento recaen por completo sobre los desarrolladores

  • Me cuesta entender por qué tanta gente no piensa así
    Mucho antes de que la IA llegara a este nivel, yo ya había creado un CLI personal para facilitarme el trabajo y para escribir scripts de automatización
    Mis compañeros vieron la herramienta y me pidieron que la compartiera, pero mi respuesta diplomática fue no
    Compartirla implicaba una carga de soporte y además un rendimiento negativo: todos pasarían a ser tan productivos como yo y perdería mi ventaja
    Encima, el liderazgo no reconoce mi creatividad como un activo, así que tampoco aumenta mi seguridad laboral
    Igual me pueden despedir en un futuro cercano, así que no tengo intención de ayudar a la empresa por buena voluntad
    Si hoy los desarrolladores están preocupados por sus empleos, sus flujos de trabajo personales deberían tratarse como secretos comerciales
    Este ejemplo no se limita a la IA, pero aplica igual a los flujos de trabajo con IA
    En un mercado favorable para los trabajadores, compartir ese conocimiento con la organización a veces hasta era entretenido, pero en un mercado favorable para el empleador, si quieren acceso a mis decisiones personales, tienen que pagar
  • No me encanta tener que ver el trabajo como algo hostil, pero mientras la empresa mantenga esa mentalidad de suma cero de “si todos son así de productivos y logran tanto, ¿por qué necesitamos a tanta gente?”, no hay mucho que hacer
    No soy de los que ven el trabajo como una familia, pero sí me gustaría poder colaborar y compartir sin preocuparme por estar cavando mi propia tumba
  • Si tu empleador espera que compartas tu tiempo de forma altruista y gratis, entonces te están explotando
    A la mayoría le pagan por trabajar, y durante el horario laboral por supuesto deben trabajar para el empleador
  • Esos supuestos “secretos” ocultos suelen estar al nivel de la lista de prompts superpotentes de Gary Tan
    En realidad casi nunca hay algo tan increíble que los demás no puedan imaginar por su cuenta
    En mi experiencia, incluso cuando compartes prompts o técnicas, casi nadie las usa, o eran tan básicas que todos ya tenían su propia versión
    Si antes de la IA a alguien no le interesaba xyz, no va a interesarle de repente después de la IA aunque se lo sirvas en bandeja de plata
  • Otra forma de verlo es que las herramientas de IA al principio benefician al individuo, y el usuario se queda con ese aumento de productividad en forma de tiempo libre
    El trabajo aburrido casi desaparece, y algunos problemas se pueden dejar corriendo mientras te devuelven entre 1 y 4 horas al día
    ¿Esa persona va a usar racionalmente ese tiempo para buscar más trabajo que hacer? Salvo que sea su propia empresa o tenga una motivación especial, lo más probable es que no

• Como analista de sistemas retirado desde hace 3 años, me dan pena mis colegas más jóvenes
  En 2023 fui de los primeros del equipo en usar IA para descifrar código legado basado en Perl cuyo autor original se había ido hacía mucho y casi no dejó comentarios ni documentación
  Ese código hacía un trabajo importante, y la IA nos sacó del apuro, así que todos quedamos impresionados con esta nueva tecnología
  Pero cada vez se siente menos como una herramienta que yo pueda usar y más como algo que se me está imponiendo
  Nadie pidió esto
  No sé desde cuándo, en nombre de resolver todo al instante, la inspiración y el pensamiento pasaron a devaluarse y volverse inútiles, pero el trabajo perdió su alma

• La IA por sí sola no sirve de tanto
  Los agentes olvidan cosas y se equivocan lo suficiente como para que haya que revisar todo su trabajo, y al final la productividad hasta puede bajar
  Donde realmente muestra su valor es cuando tratas la IA como una herramienta para construir otras herramientas
  Por ejemplo, hacer que construya herramientas que obliguen a que una tarea continúe hasta alcanzar cierto nivel de calidad, o que ejecuten verificaciones de cumplimiento sobre la salida y te indiquen qué corregir
  Recién ahí puedes confiar en el trabajo
  Hoy la mayoría de los roles y flujos de trabajo están diseñados alrededor de operar herramientas dadas para lograr tareas específicas, y en ese esquema la IA solo puede meterse en los márgenes

• Buen texto, y me llamó especialmente la atención la parte sobre cómo cambia la forma en que las organizaciones definen el trabajo
  En el modelo anterior, el desempeño y los OKR estaban atados al área funcional, al puesto y a las expectativas del rol
  En la era de la IA, esos límites empiezan a derrumbarse
  El problema más profundo es psicológico y organizacional: la gente sigue negociando dónde está la línea entre “esto es mi trabajo” y “esto no es mi responsabilidad”
  Ahí aparece el problema central de adopción: ¿cuál es la ventaja de volverte visiblemente reconocido como un usuario avanzado de IA?
  Si descubro que puedo trabajar más rápido, mejor y a través de más funciones, ¿por qué habría de mostrarlo si la empresa no crea un sistema claro de reconocimiento, recompensa y crecimiento profesional?

  • Al final, la propiedad la termina teniendo quien es responsable de arreglar y mantener las fallas operativas
    En un mundo donde los agentes cruzan esos límites, eso puede volverse bastante desordenado
    ¿Un ingeniero de IA con una manada de agentes se hará responsable también de mantener todo funcionando? Lo dudo bastante, pero habrá que verlo
  • Si creas un sistema para recompensar a los usuarios avanzados de IA, esa misma carrera podría volverse el problema
    Si alguien atraído por ese nuevo trabajo combina unas semanas de asesoría sobre el contexto específico de una empresa con enfoques más actualizados, al final esa persona quedará en el rol de experto de dominio que será eliminado
  • Si un miembro del equipo empieza a hacer esas cosas por defecto, todo parece estar bien hasta que se hace visible la brecha entre esa persona y el resto del equipo

• La respuesta a “¿dónde está el retorno sobre la inversión de los 2 millones de euros que le pagamos a Anthropic el año pasado?” es la placa de tokens de platino estilo YouTube colgada en la oficina del CEO

• El sesgo de suposición detrás de la pregunta “¿dónde está el retorno sobre la inversión de los 2 millones de euros que le pagamos a Anthropic el año pasado?” es realmente absurdo
  El problema es que la IA generativa no logra producir un retorno visible de la inversión
  Pero la “solución” sería reorganizar toda la organización de desarrollo alrededor de esa tecnología e inventar nuevas herramientas
  El verdadero propósito de textos así no está en el contenido que tratan superficialmente, sino en la normalización de las suposiciones sobre las que descansa la discusión

  • Es como si los LLM no pudieran fracasar, y si fracasan es solo porque tú hiciste que fracasaran

• Trabajar en este campo ahora mismo es realmente horrible
  En la empresa donde trabajo, los jefes dejan que hasta la gente que no es desarrolladora use IA
  De verdad quisiera renunciar y trabajar en otra cosa, pero donde vivo no podría pagar la renta con un salario inicial y además ya me estoy haciendo mayor

• Comparar la promesa de la IA con el boom puntocom me ayudó a entenderla, y hay bastantes similitudes
  Pero internet era un concepto más simple desde la perspectiva empresarial
  Básicamente significaba que ahora la gente podía comprar cosas desde su propia computadora
  ¿Cuál es la promesa de la IA? ¿Que puede aproximar el razonamiento sobre las cosas?
  Este es un rompecabezas de implementación mucho más difícil de resolver de verdad
  Fuera de las tareas de programación, todavía no siento haber visto algo realmente sustancial