Sean Cho : Algunas mañanas olvido mi gafete. O el baño del tercer piso está cerrado por razones que nadie puede explicar. O traigo folletos para la sección equivocada. Me distraigo a mitad de la clase intentando recordar la palabra para esa cosa que es casi una sinécdoque. Alguien levanta la mano para hacer una pregunta que no sé cómo responder y digo lo incorrecto. O digo lo correcto pero demasiado rápido, y alguien se sobresalta y me doy cuenta —demasiado tarde— de que no era la pregunta lo que importaba, sino el silencio detrás de ella. Y aun así: vuelven la semana que viene. Se sientan. Abren computadoras portátiles y cuadernos y escuchan a medias con ese tipo de atención distraída que sigue siendo, de alguna manera, real. La IA nunca sabrá cómo interpretar ese tipo de escucha. En la gran mayoría de nuestra comunicación es no verbal. Tu capacidad de ver a los ojos a otra persona y reconocer su humanidad sentada enfrente de ti es lo que te hace diferente de un chatbot. Y eso no se va a poder reemplazar ni automatizar ni hacer más eficiente. Y creo que ni siquiera deberíamos intentarlo. Lo que la IA no puede hacer es sentir la forma del silencio después de que alguien dice algo tan honesto que olvidamos que estamos aquí para aprender. Lo que no puede hacer es pausar a mitad de una frase porque recordó el olor de la vieja silla de su padre. Lo que no puede hacer es sentarse en una habitación llena de personas que están intentando —y fallando— dar sentido a algo que tal vez no pueda tener sentido. Ese es el trabajo de enseñar. No se trata de saber. Se trata de estar presente. De quedarse lo suficiente para saber qué preguntar. De decir: “Creo que sé a qué te refieres”, incluso si estamos equivocados. Especialmente si estamos equivocados. Y así: olvido mi gafete. Olvido en qué página estamos. Olvido la contraseña del proyector. Pero recuerdo la mirada en los ojos de alguien cuando finalmente dice lo que ha estado intentando escribir durante semanas. Y recuerdo al primer estudiante que preguntó si podía escribir sobre su perro muerto, y al que preguntó si podía escribir sobre las pastillas. Y al que dijo: “Esta clase es la única razón por la que vengo al campus”. Recuerdo las partes humanas. Y el error humano es el punto. Me hace pensar sobre lo que hace que el arte sea una forma de expresión tan universal. Leonardo Bertinelli : ¿Cuándo se volvió tan aburrido el arte? El enfoque ha cambiado del arte en sí a lo perfecto y pulido que se ve, lo controlable que puede ser. Las herramientas y la tecnología modernas crean la ilusión de que cada detalle puede ser moldeado, corregido y domesticado. Pero incluso si todo pudiera ser controlado, eso no es lo que hace que el arte sea grande. El poder del arte vive en sus defectos. Las imperfecciones le dan a una pieza su valor. Lo hacen singular. Humano. Cuentan historias, dejan huellas y provocan preguntas. Maria Popova : Cuando la IA empezó a colonizar el lenguaje —que sigue siendo nuestro mejor instrumento para salvar el abismo que nos separa, un contenedor de pensamiento y sentimiento que moldea el contenido—, le pedí a ChatGPT que compusiera un poema sobre un eclipse solar al estilo de Walt Whitman. El resultado fue un conjunto de clichés en pareados rimados. Equivocarse en la forma —Whitman no rimaba— parecía una corrección fácil con una línea de código. Equivocarse en la poesía misma era la pregunta interesante, la pregunta que llega al corazón de por qué hacemos poemas (o pinturas, novelas o canciones): una pregunta fundamentalmente sobre qué significa ser humano. Le pregunté a una amiga poeta por qué pensaba que ChatGPT sonaba hueco mientras que Whitman podía condensar infinitud de sentimientos en una sola imagen, podía desarraigar el alma en una palabra. Hizo una pausa y luego dijo: «Porque la IA no ha sufrido».

Stephen Lewarne en el WSJ : Washington se está preparando para un choque en el empleo por la inteligencia artificial que es poco probable que llegue y, por lo tanto, el gobierno corre el riesgo de gastar miles de millones de dólares preparándose para el problema equivocado. Los políticos en pánico están cometiendo el error de tratar las clasificaciones ocupacionales basadas en tareas —que estiman qué proporción de las tareas de varios trabajos podría realizar la IA— como pronósticos de desempleo. La historia sugiere el enfoque opuesto: es probable que la IA aumente la productividad y los salarios de muchos de estos roles mucho antes de eliminarlos. La automatización de tareas normalmente reorganiza el trabajo mucho antes de destruir empleos, si es que hace esto último. Este malentendido está empujando la política en la dirección equivocada. Sin clavarnos en política, el punto que quiero tocar es este: A medida que la tecnología acelera las tareas y reduce los costos, las empresas también crean roles que las clasificaciones basadas en tareas, como las de Goldman Sachs y la OCDE, no pueden ver. Los bufetes de abogados dependen cada vez más de gerentes de apoyo en litigios y especialistas en revisión de IA que supervisan el análisis automatizado de documentos en lugar de revisar los papeles manualmente. Las firmas de contabilidad han ampliado sus funciones en el aseguramiento de datos, supervisión de modelos y servicios de asesoría, que conviven junto con los informes automatizados. En los equipos de software, los ingenieros ahora se especializan en arquitectura de sistemas, integración de modelos y control de calidad —roles que se expanden a medida que la codificación rutinaria se automatiza. En el sector salud, la documentación asistida por IA ha aumentado la demanda de empleados que puedan liderar operaciones clínicas mediante la gestión de flujos de datos, cumplimiento y diseño de flujo de trabajo. Estos trabajos existen gracias a la forma en que la IA reorganiza el trabajo. En 2021 escribí : La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales. Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar. Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc. Si estás en la industria del software y piensas que tu único trabajo es programar, heads up . Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales. De nuevo, chamba relacionada con desarrollo de software sí va a haber, y mucha. Chamba de programador, ya no tanto.

Mike Swanson : Una de las cosas más peligrosas de las métricas es que se sienten objetivas. Un gráfico es un gráfico. Un número es un número. Tienen la estética de la verdad. Siempre me ha gustado esta frase de William Bruce Cameron (a menudo atribuida erróneamente a Albert Einstein): “No todo lo que puede contarse cuenta, y no todo lo que cuenta puede contarse”. Las métricas no miden la realidad. Miden lo que tu producto facilita actualmente. Existe una advertencia muy conocida sobre esto, que a menudo se resume así: cuando una medida se convierte en un objetivo, deja de ser una buena medida . Se conoce comúnmente como la Ley de Goodhart, y el punto más amplio aparece en múltiples campos, porque les sigue sucediendo a los humanos en sistemas con incentivos. Cuando estaba en Microsoft, un equipo quería eliminar una función porque “las métricas muestran que nadie la usa”. Si mirabas la interfaz de usuario, sin embargo, esa función se había movido cada vez más profundo con el tiempo: antes era fácil de encontrar luego se movió a un menú luego a un submenú luego a un panel de configuración luego detrás de una sección “avanzada” luego era básicamente invisible ¡Por supuesto que nadie la usaba! Las métricas no demostraban que la función no fuera deseada. Las métricas demostraban que la enterramos. Peor aún, una vez que una métrica se convierte en un objetivo, las personas son ascendidas por moverla. Eso no requiere que nadie sea malicioso. Solo requiere incentivos y un tablero de control. Muéstrame los incentivos, y te mostraré los resultados.

Lucas Pauker : Cada línea de código en producción es una apuesta entre velocidad, seguridad y corrección. Cuando envías software, estás equilibrando: Hacerlo rápido → enviar más rápido significa que la funcionalidad aparece antes para los clientes y, en última instancia, el negocio gana más dinero. No introducir bugs → los bugs pueden causar caídas de servicio u otros errores que llevan a pérdidas. El problema es que cualquiera que haya trabajado con software sabe que, pase lo que pase, no puedes garantizar que el software que envías no tendrá bugs. De hecho, tu software siempre tendrá bugs. No importa cuántos “lgtm” reciba tu pull request, los bugs siempre encuentran la manera de colarse. La habilidad más importante a desarrollar lo antes posible si quieres trabajar en software: resiliencia. No se trata de si falla, sino de cuándo va a fallar. Propongo que, como ingenieros de software, cambiemos nuestra mentalidad de “no debería haber bugs en mi código” a “debería gestionar el riesgo de nuevos bugs”. Deberías tener bugs en tu código si quieres enviar el mejor software. Un equipo de software tiene capacidad limitada, y el intercambio entre nuevas funcionalidades y la reducción de bugs debería considerarse seriamente. Necesitamos un marco para tomar decisiones sobre cuánto tiempo deberías dedicar a una tarea para gestionar el riesgo de bugs. Lucas propone que los ingenieros comencemos a factorizar el riesgo en nuestra toma de decisiones (las negritas son mías): El valor que aporta una funcionalidad es proporcional al tiempo que está disponible para los usuarios. En otras palabras, cuanto más retrases una nueva funcionalidad, menor será el valor total que aportará a la empresa. El riesgo de la funcionalidad es difícil de cuantificar, ya que es desconocido. Sin embargo, con base en la experiencia, existe un rango de bugs posibles para un cambio de código determinado. En general, deberíamos pensar en el peor escenario posible que podría ocurrir al implementar una nueva funcionalidad. Una vez que tenemos una idea del valor que aporta una funcionalidad y del riesgo de bugs, podemos sopesarlos entre sí . Debería existir un punto en el que esperar más para lanzar una funcionalidad no reduzca el riesgo de bugs lo suficiente, y ese es el momento en el que deberíamos lanzar la funcionalidad. Muchos ingenieros se quedan en el riesgo técnico de su trabajo e ignoran el riesgo para el negocio de no lanzar la funcionalidad. Si no tienes la capacidad de entender el impacto de tu funcionalidad en el negocio y en el usuario, no estás haciendo tu chamba como desarrollador de software: buscar la manera de resolver problemas .

Karissa Bell, en Engadget : La empresa se ha asociado con Replit, Lovable, Descript y Relay.app para esta función, y está trabajando en integraciones con GitHub, también propiedad de Microsoft, así como con Zapier. LinkedIn siempre ha permitido a los usuarios añadir diversas habilidades y certificaciones a sus perfiles. Sin embargo, la última actualización es un poco diferente: los usuarios no informan sus propias cualificaciones. En su lugar, LinkedIn permite que las empresas responsables de las herramientas de IA evalúen las habilidades relativas de cada persona y asignen un nivel de competencia que se aplica directamente a su perfil. Básicamente, es un badge que te certifica como alguien capaz de razonar problemas, y descomponerlos para expresarlos de una manera accionable. Imagínate tener en tu perfil que eres medio bueno en eso… Mejor no pongas nada. El siguiente badge que deberían poner es el de “Sé Prepararme Solo el Desayuno”.

Imagina que acabas de terminar la planeación del sprint con tu equipo. Todo está cuadrado: todo mundo tiene tareas asignadas, los objetivos son claros y entre todos están de acuerdo en el scope . Entonces, de la nada, cae un mensaje. Un manager de otra área o un director necesita meter un “pequeño bug” que, en realidad, requiere un refactor completo. Tu líder técnico, en lugar de defender el plan, responde con un “claro que sí, nosotros nos encargamos”. Y así somos así: todo el empeño que le habían puesto a armar el plan de las siguientes dos semanas se siente igual de satisfactorio que un papel mojado. El sentimiento de control se evapora y lo que queda es una mezcla de frustración y la certeza de que te vas a tener que quedar tarde otra vez para sacar la chamba extra. Esta situación es más común de lo que nos gustaría admitir. Y el problema no es solo la carga de trabajo; el problema es que tienes un líder que no sabe decir que no. Hay un tipo de líder que ha acostumbrado a la organización a que él o ella lo soluciona todo. Se ven a sí mismos como los salvadores , los “bomberos” que siempre apagan el incendio de último minuto. Al ego le encanta este rol: recibir elogios de arriba por “salvar el día” genera una dopamina difícil de soltar. Pero esa medalla que se cuelga el líder la paga el equipo. Cuando un líder no pone límites, lo que le dice a la organización es chequen, el equipo es un recurso infinito y nuestra planeación es opcional y prescindible . Los de arriba siguen pidiendo imposibles porque nunca han experimentado una consecuencia negativa. Abajo, el equipo empieza a sufrir los efectos reales: por trabajar bajo presión y a las prisas, se pasan detalles, se omiten tests y se introduce deuda técnica que alguien tendrá que pagar después; el proceso de QA se vuelve eterno porque las entregas llegan con errores básicos, generando rondas infinitas de corrección; modificar el plan sobre la marcha hace que el trabajo sea más riesgoso y que el despliegue a producción se convierta en un volado. Lo que tienes que entender es que, por más chingón que sea escribiendo código, tu tech lead también es humano y, como todos, va a responder a los incentivos que le ponen enfrente. Anteriormente escribí sobre por qué deberías darte a la tarea de entender cómo funcionan los incentivos en una empresa: En algunos lugares, se gana siendo el que más vende. En otros, resolviendo la mayor cantidad de tickets . Desafortunadamente, en algunas organizaciones se gana siendo el favorito del jefe. ¿Cómo se “gana” en la cultura de tu empresa? Esta es la pregunta más importante que deberías contestar. Si te das cuenta de que en tu organización se gana siendo el que más vende en números brutos, pero tú trabajas como desarrollador de productos internos, y no como vendedor, tienes un problema. Porque tu usuario hará lo necesario por vender más, independientemente de lo que tú y tu equipo estén haciendo o quieran hacer. Tomarán atajos, desarrollarán sus procesos por fuera, y tu trabajo será cada vez más difícil: crear un producto para personas que no quieren ni tienen que usarlo. Es posible contrarrestar esta situación, sí; sin embargo, requiere que la persona al frente de tu equipo tenga bastante capital político dentro de la organización para poder influenciar el comportamiento de otras áreas. Si en tu empresa se “gana” siendo el que más vende, ¿qué significa eso para ti, que no vendes nada? ¿Cuál es realmente la probabilidad de que tu tarea sea factible? ¿Tiene tu líder el suficiente capital político para poder influenciar otras áreas de la organización y alinear sus incentivos con los suyos? En corto: si tu líder se comporta así, es porque de algún lado está recibiendo feedback positivo que le indica que está bien comportarse así. Probablemente, sus jefes lo felicitan por su “disponibilidad” y su “compromiso”. Chance, lo que a tu tech lead le gusta es sentirse útil, y esta es una manera de lograrlo a expensas de su equipo. Tal vez le lograron lavar la cabeza muy cabrón y trae bien puesta la camiseta. Quién sabe. La cosa es que, cuando no hay un contrapeso que ponga ese refuerzo positivo en perspectiva, es cuando las cosas pueden evolucionar hasta el punto en el que quieres agarrarlo de las greñas. Así que toca darle visibilidad de que lo que hace no está del todo bien: generar ese contrapeso. Si a tu líder no le toca sufrir las consecuencias de decir que sí a todo, ¿por qué habría de cambiar? Es como intentar entrenar a un perro para que no se haga adentro: si nunca hay una consecuencia clara y directa en el momento adecuado, el comportamiento se va a repetir indefinidamente. Para lograr cambiar esta situación, el líder tiene que ser parte de la chinga. No se trata de ser combativo ni de armar un berrinche. Se trata de hacer evidentes las consecuencias y darle oportunidad de corregir el comportamiento. Si tu líder decide cambiar el sprint a la mitad, lo que puedes hacer es involucrarlo en el costo de esa decisión. Ejemplo: si meten una tarea nueva sin análisis, invita a tu líder a la llamada de discovery. Que sea él quien escriba el ticket, quien investigue los casos de borde y quien entienda por qué ese “ajuste de 5 puntos” en realidad es un 15. Si el equipo se tiene que quedar tarde o si el calendario se vuelve un caos, su calendario también debe reflejarlo. Si no está presente en las trincheras viendo cómo se rompe el proceso de QA o cómo se atoran los Pull Requests, nunca va a valorar el costo real de su “sí”. Documenta qué pasa cada vez que se modifica el sprint de forma arbitraria. ¿Se caen más servidores? ¿Los PRs tardan tres veces más? ¿El equipo reporta mayor agotamiento? La percepción subjetiva es fácil de ignorar; los datos no. Crear una carrera sostenible significa saber qué batallas vas a pelear. Intentar cambiar a un líder (o a toda una cultura organizacional pasiva) es un esfuerzo desgastante. A veces, después de intentar involucrarlos y mostrar las consecuencias, te das cuenta de que el ecosistema completo está diseñado para premiar ese caos. En esos casos, tienes que ser muy estratégico: ¿vale la pena gastar tu capital de influencia ahí? Tu trabajo es transitorio. Tus habilidades y tu salud mental no. Si estás en un lugar donde la norma es el sacrificio mal planeado, tal vez la lección que te toca aprender es identificar esas señales a tiempo para que, en tu próxima chamba, no permitas que te pasen la factura de un sí que tú no diste. Al final del día, el liderazgo efectivo se basa en la confianza y en la delegación inteligente. Y no hay nada que destruya más rápido la confianza que un líder que no es capaz de proteger a su equipo de sus propios impulsos. Si te encuentras atrapado en este ciclo de urgencias constantes y quieres aprender a navegar la política organizacional para recuperar tu tranquilidad y tu impacto real, podemos trabajarlo en una sesión uno a uno. Aplica a mi programa de coaching aquí.

Después de publicar El Dr. Simi del software (que si no has leído, deberías darle una checada), me quedé con ganas de extraer algunas ideas fundamentales de esa analogía. Ahí te van: 1. El título ya no alcanza El Dr. Simi es médico. Estudió seis años. Pasó exámenes. Tiene un diploma colgado en la pared. No es “menos doctor” que otros. Lo que cambió no fue su formación, sino el valor de mercado de la consulta general. Durante décadas, ser médico era casi garantía de estabilidad económica y estatus social. Suficiente gente vio ese futuro y tomó la misma decisión al mismo tiempo. El resultado fue una sobreoferta que el mercado resolvió a su manera: bajando precios, estandarizando servicios y separando con mucha más claridad a los generalistas de los especialistas. En software pasó exactamente lo mismo. Durante años, saber programar era una credencial casi mágica. Bastaba con “entrar a tech” para que la narrativa prometiera sueldos altos, estabilidad y una carrera ascendente. Bootcamps, cursos, carreras universitarias reconfiguradas. Mucha gente llegó al mismo lugar… y el título dejó de comprar lo que compraba antes. Dale clic aquí si quieres que te explique por qué creo que “la industria de la tecnología” ya no existe. 2. Cuando algo se vuelve accesible, se vuelve commodity. Farmacias Similares no destruyó la medicina. La volvió más accesible. Bajó el costo de entrada para millones de personas y resolvió una enorme cantidad de casos cotidianos. Eso empujó los precios hacia abajo en todo el mercado de la consulta general, incluso fuera del Simi. En software está pasando lo mismo. Frameworks maduros, plantillas, APIs para todo, no-code y ahora modelos de IA que escriben código “suficientemente bueno”. Producir software funcional para muchos casos ya no es raro ni caro. Y cuando el mercado puede obtener un resultado 80 % bueno, 80 % más rápido y 80 % más barato, no hay discurso técnico que compita contra eso. Pelearte con esa realidad es como quejarte de que la insulina ya no es artesanal. La evidencia está allá afuera . 3. El valor se movió del acto técnico al criterio profesional. El médico del Simi no es valioso porque haga diagnósticos complejos desde cero. Es valioso porque sabe reconocer patrones comunes, aplicar protocolos, descartar señales de alerta y, sobre todo, saber cuándo no le toca resolver el problema. Su trabajo no es genialidad; es criterio. En software, cada vez pasa más eso. El cliente ya no llega en blanco. Llega con un diagnóstico a medias, con una idea sacada de Google, de un SaaS que vio por ahí o de una conversación con ChatGPT. El trabajo del ingeniero ya no es demostrar que sabe más, sino encuadrar el problema, ajustar expectativas y decidir qué vale la pena construir y qué no. El valor ahora no está en escribir más código , sino en saber cuándo no hacerlo. 4. Especializarse sigue siendo una opción válida, pero es una apuesta distinta. En medicina, los especialistas existen porque resuelven problemas raros, caros o críticos. Pagan el precio: más años de formación, más presión, más competencia y cero garantías. No cualquiera llega, y no cualquiera se queda. En software, esa frontera existe también. Infraestructura fundamental, sistemas distribuidos pesados, compiladores, runtimes, seguridad, sistemas de tiempo real que no se pueden dar el lujo de desperdiciar microsegundos en latencia. Lugares donde un error no es un bug menor, sino millones perdidos o riesgos reales. Ahí, por ahora, no puedes soltar a una IA y esperar que diseñe sola la solución. Pero esa no es una salida “natural” ni automática. Es una decisión consciente de carrera, parecida a elegir una especialidad médica difícil. Decidir no tomarla no te hace menos profesional ni demerita tu trabajo; solo te coloca en otro juego, con otras reglas. 5. Desarrollar software no es lo mismo que escribir código. El Dr. Simi no “cura enfermedades” en el sentido romántico de la medicina. Alivia síntomas, orienta decisiones, filtra casos y ayuda a la gente a seguir con su vida. Y para muchísimas personas, eso es exactamente lo que necesitan. En software, pasa igual. Resolver problemas usando tecnología cada vez implica menos escribir tú mismo cada línea y más diseñar sistemas, procesos y decisiones. Si tu identidad profesional está atada únicamente a ser “el que escribe el mejor código”, estás en una posición frágil. Porque el código, como la consulta general, se está volviendo abundante. 6. El cliente ya llega informado, confundido y ansioso. El paciente que llega con el diagnóstico de ChatGPT no es un error del sistema; es el sistema. El médico que entiende eso no pelea con internet, sino que maneja expectativas, calma miedos y toma decisiones pragmáticas. En software, el ingeniero que aprende de esto deja de pelearse con clientes que “ya creen saber la solución” y empieza a hacer el trabajo más difícil: escuchar, traducir y decidir. Muchas veces, el mejor resultado no es el más elegante, sino el que reduce fricción y permite avanzar. Nada de esto significa que la industria del software esté “muerta”. Así como en la medicina, trabajo va a haber. Siempre hay problemas. Siempre hay gente que necesita ayuda. Lo que sí murió es la idea de que el mercado te debe una carrera glamorosa solo por tener un título o dominar un framework popular. El Dr. Simi no es una degradación de la medicina. Es una adaptación brutalmente honesta a lo que pasa cuando el conocimiento se democratiza. Y el Dr. Simi del software ya está aquí. La pregunta no es si te gusta o no. La pregunta es qué tipo de doctor del software quieres ser ahora que existe. Si quieres, podemos pensar esa respuesta juntos. Llena este formulario para programar una llamada exploratoria y ver si mi programa de coaching te podría ayudar.

Natallie Rocha, para el NYT, entrevistó a varias personas “normales”, es decir, que no trabajan en tecnología, con código ni en nada relacionado, sobre cómo están usando Claude Code en el mundo real: Sam Hindes, 38 años, Melbourne, Australia El Sr. Hindes, subdirector en una escuela para niños autistas, tiene cuatro hijos menores de 9 años y recurrió a la IA para ayudarle a organizar la ropa de su familia. La semana pasada, le pidió a Claude Code que creara un programa para identificar a cuál de sus tres hijas pertenecía cada prenda, de modo que pudiera separar la ropa limpia en montones sin su ayuda. Tomó fotos de la ropa para enseñarle a Claude Code qué camiseta pertenecía a cada hija. Ahora simplemente muestra la prenda a la cámara de su laptop y el programa le dice a quién pertenece. “Todo el proceso se completó en una hora, y las niñas estaban muy emocionadas”, dijo. El Sr. Hindes comentó que ahora está creando un programa con Claude Code para ayudar a sus hijas a completar de forma independiente los pasos de su rutina matutina, como si fuera un juego. Llevo diciéndolo mucho tiempo : desarrollar software se trata de resolver problemas, no de escribir código: Anne Haubo Dyhrberg, 35 años, Newark, Delaware Durante la pandemia de coronavirus, la Sra. Haubo Dyhrberg, profesora adjunta de finanzas en la Universidad de Delaware, tuvo la idea de crear un simulador de trading bursátil para su clase. Consultó a su esposo, ingeniero de software, pero “la tarea parecía demasiado abrumadora”. El lunes descargó Claude Code y, en un par de horas, ya tenía un demo funcional de un simulador de trading que sus estudiantes podían usar para operar valores en un mercado simulado. Ha creado cinco escenarios distintos para que los estudiantes exploren diversos retos de los mercados financieros. “Nunca pensé que sería tan fácil”, dijo. “No puedo esperar a probarlo cuando el semestre comience en dos semanas”. Esta experiencia es relevante para quienes sí trabajamos con software: Joe Bacus, 38 años, St. Louis El Sr. Bacus, dueño de un negocio de soldadura y fabricación de metal, recurrió a Claude Code el mes pasado para crear un asistente de IA que gestionara su calendario y le ayudara a encontrar nuevas oportunidades de negocio. El negocio es solo él y tres personas más, así que “no estamos en una posición para poder costear un equipo administrativo”, dijo. “Todo recae en mí”. Con Claude Code, creó un asistente personal de IA que se conecta a su calendario, Google Sheets y Gmail, lo que le permite crear cotizaciones fácilmente, dar seguimiento al progreso de los trabajos y organizar contratos. “Soy un trabajador especializado que apenas pasó la preparatoria a principios de los 2000”, dijo el Sr. Bacus, y agregó: “Pero en los últimos meses me he enseñado a mí mismo a crear herramientas reales para mi negocio”. Esta es una radiografía del potencial que realmente tiene la IA en relación con lo que nosotros hacemos, y debería ser una llamada de atención para cualquier persona que trabaje en la industria del software y que siga pensando que el mercado todavía valora la habilidad de escribir código. Observa cómo ninguna de las personas mencionadas arriba habló de la versión de Ruby o JavaScript que usaron, ni de la arquitectura ni del patrón de diseño. Porque no importa: usaron una herramienta para resolver el problema que tenían. Seguramente si alguien con experiencia en desarrollo de software revisa el código que escribió Claude, encontrará maneras de optimizarlo. Pero para cuando se complete esa auditoría, importará todavía menos, porque el usuario ya usó la solución. Es esto: Ponte en los zapatos de la empresa: ¿qué me importan tus 20 años de experiencia si puedo obtener un resultado comparable —tal vez no igual, pero comparable— con un ahorro del 90 % al contratar a alguien menos experimentado, pero que sepa hacer las preguntas correctas a un LLM? Un principio bastante popular de la programación es: primero haz que funcione, luego hazlo elegante. La realidad es que a la gran mayoría de las empresas lo único que les importa es que funcione. Y ya. Y si pueden lograr que algo funcione (y ya) por menos dinero, van a elegir esa opción una y otra vez. Felicidades por tus 20 años de experiencia programando, by the way . Todavía estás a tiempo de hacer el cambio, pero necesitas ponerte a chambear en desarrollar otras habilidades ya. Agenda una sesión de coaching ; yo te ayudo. Los comentarios en el artículo del NYT ofrecen una ventana interesante a cómo reaccionamos ante estos avances desde diferentes perspectivas. Margory : Usamos a Claude para ayudar a diseñar juegos y actividades para una gran reunión familiar de fin de semana durante las vacaciones de invierno, y fue increíble. Rendó en cuenta todos los grupos de edad, discapacidades, intereses y clima. Todos estaban felices y se lo pasaron muy bien, ¡y me quitó mucho estrés de todo el arreglo! . Por otro lado, Bill : Codificador retirado hace mucho tiempo aquí. Todavía soy escéptico, a pesar de todos los entusiastas relatos de chicos y chicas. Todavía tengo que ver algo real. Y he buscado bastante.

Por mucho tiempo, tu chamba se ha sentido relativamente cómoda porque cuando de escribir código se trata, la verdad es que tienes las reglas bien claras. Haces algo y pasa algo. No lo haces y no pasa nada. El código compila o no compila. Los tests pasan o fallan. El deploy sube o se cae. Incluso cuando algo se rompe, sabes dónde puede encontrar respuestas: hay logs, métricas, dashboards. Tienes un lugar concreto donde meter las manos. Tu entorno te regresa feedback inmediato, y ese feedback casi siempre es binario, o si no, por lo menos predecible, determinístico. Ese tipo de trabajo entrena al cerebro para pensar de una forma muy específica: asumir que los problemas tienen una solución clara y que, con suficiente habilidad técnica, siempre es posible encontrarla. Igualito que un cachorro eventualmente entiende que levantar la patita == galleta, gracias a tanta repetición internalizaste que escribir código es una manera segura de esperar algún tipo de recompensa —económica, social, intelectual, organizacional. Esto funciona, y muy chingón, mientras estás operando en un ambiente donde lo único que te tiene que preocupar es cómo haces las cosas, más que el por qué las haces. Cuando tienes que comenzar a preocuparte por cosas menos claras, como estrategia de negocios, priorización de proyectos, resolución de conflictos, etc., este modelo mental deja de ser efectivo. Y es cuando comienzas a valer madre. Cuando se trata de “dar el siguiente paso” en una carrera en software, lo que nos mueve el tapete a muchos es que los problemas que nos ponen enfrente ya no se pueden resolver escribiendo más o mejor código. Yo sé que me costó trabajo, y es algo que le digo a otros managers y líderes en sesiones de coaching : hacer las paces con que mi chamba ya no es lineal ni puedo mandar un Pull Request para resolver un problema fue de las adaptaciones más grandes que me tocó hacer en mi transición hacia Engineering Manager . Pero ojo: no es que necesites convertirte en Engineering Manager para pasar por esta transición. En 2026, mucho más marcado que en años anteriores, comenzar a lidiar con estas ambigüedades es una tarea que cada vez más va a ser una expectativa de contribuidores individuales. En La definición de Full Stack Developer cambia para el 2026 escribí: Cuando escribir código se vuelve barato, abundante y automatizable, lo que empieza a importar es todo lo demás: entender el problema correcto, navegar organizaciones, influir en decisiones, traducir necesidades humanas en sistemas que funcionen. Dicho de otra forma: ser un Full Stack Developer ya no se trata de lenguajes de programación y frameworks, sino de habilidades sociales, políticas y de desarrollo de producto; de qué tan bueno eres hablando con personas que no tienen background técnico; de tu capacidad integral de resolver problemas. A veces ni sabes que estás pasando por esta transición Uno de los primeros síntomas de este cambio te agarra de bajada: las respuestas empiezan a sentirse incompletas. Haces preguntas razonables y recibes respuestas que no terminas de comprender. No es que te estén queriendo atorar a propósito, sino el hecho de que el problema ya no vive en un dominio técnico. Preguntas qué es importante y te hablan de preocupaciones, de riesgos, de cosas que podrían pasar si no le pones atención no a un problema, sino a una categoría de problemas. No hay una lista concreta de tareas, ni un “haz esto y listo”. Y, más críticamente, tampoco hay garantías de que la dirección en la que vas sea la correcta. Se siente ambiguo. Poco accionable. Como si te estuvieran dejando demasiado espacio para interpretar. Para el ingeniero con I mayúscula, acostumbardo a pensar en problemas determinísticos, esto no tiene sentido. Pero cuando se trata con personas, nada es determinístico. Cuando alguien es responsable de un resultado, su forma de pensar y de hablar cambia. Ya no se enfoca tanto en lo que hay que hacer, sino en lo que podría salir mal. Ya no optimiza únicamente para ejecución, sino para reducir (y no necesariamente eliminar) incertidumbre. Para alinear objetivos. Para prevenir que se descarrile el progreso. Eso suele confundirse con falta de claridad, cuando en realidad es una señal de que el problema ya no se resuelve en el mismo nivel que antes. El valor deja de estar en ejecutar bien lo que te dicen y empieza a estar en entender lo suficiente el contexto como para anticiparte. En leer lo que no está escrito. En notar riesgos cuando todavía no son obvios, y cuando todavía es barato hacer algo al respecto. El trabajo deja de ser puramente reactivo. Se vuelve interpretativo. Y eso incomoda, sobre todo cuando vienes de un entorno donde la certeza era parte fundamental del día a día. El impulso natural es intentar resolver esta nueva etapa con las herramientas de la anterior. Seguir buscando instrucciones claras, validación explícita, alguien que te diga exactamente qué hacer y cuándo hacerlo —lo que antes podías ver en tu test suite en verde, o en el compilador sin warnings . Pero ese alguien ya no puede existir de la misma manera. Y no mames cómo da miedo darse cuenta de esto. Aquí es donde muchos ingenieros se atoran, porque se abren dos caminos: o cachas que más y mejor código no es ni será la herramienta que te ayude a darle la vuelta a la situación y te pones en serio a desarrollar otras habilidades; o te montas en tu macho y compras otro curso de arquitectura en Platzi. Cómo bajar la pelota Una forma útil de entender este cambio es observar cómo se transforman las preguntas que importan. Durante mucho tiempo, casi todo gira alrededor del qué : qué hay que construir, qué falta, qué se rompió, qué sigue. Después, el centro de gravedad se mueve al por qué : por qué esto importa ahora y no después o viceversa, por qué este riesgo es aceptable y este no, por qué vale la pena invertir tiempo aquí y no en otra cosa. Estas preguntas no tienen respuestas definitivas. No pasan test suites  ni se validan con un dashboard. Se sostienen en criterio, contexto y experiencia acumulada. Y el criterio no se delega fácilmente. Otro síntoma claro de esta transición es que ciertas actividades dejan de sentirse “extra” y se vuelven parte central del trabajo. Leer documentos de planeación, entender iniciativas antes de que se conviertan en tareas, revisar propuestas cuando todavía están formándose. Llegar un paso antes cambia la naturaleza del impacto. Te permite hacer mejores preguntas, señalar riesgos cuando todavía no son problemas y evitar fricciones que nunca van a aparecer en un postmortem porque alguien las vio venir. Ese tipo de trabajo no siempre se mide bien, pero suele notarse cuando falta. Es la misma naturaleza de un equipo de plataforma: si hace bien su chamba pasa desapercibido, lo que hace que alguien que no entienda el valor que ese equipo aporta se comience a cuestionar si debería existir en primer lugar. Los efectos de haber deshecho el equipo solamente se vuelven evidentes meses después, cuando ya alguien no puede mandar un parche a producción sin tirar el servicio completo. Durante años, sobre todo en entornos técnicos, confundimos profesionalismo con neutralidad. Como si mostrarse como persona fuera una distracción, o como si lo ideal fuera operar como piezas intercambiables dentro de un sistema bien diseñado. Las organizaciones intentan funcionar así. Las personas no. ¿Entonces cómo es, si no escribiendo código? Cuando el trabajo se vuelve más ambiguo, la confianza deja de ser un nice to have y se convierte en una condición necesaria. Es lo que permite decir “esto me preocupa”, “no estoy seguro”, o “creo que aquí hay un riesgo” sin que eso se lea como incompetencia. Sin confianza, todo se vuelve defensivo. Con confianza, los equipos se vuelven adaptables. No estoy hablando de esa “confianza” que más bien es convicción de que tú estás bien y otros mal. Me refiero a la confianza de saber que todos los que están colaborando quieren lo mismo, están trabajando hacia el mismo objetivo, y que nadie te va a echar en cara el error que inevitablemente vas a cometer. Se construye con herramientas. Se construye humanizando la relación y recordando que del otro lado hay alguien con contexto, cansancio, intereses y límites. No es un tema de ser más amable. Es un tema de crear las condiciones organizacionales para que esta confianza nazca y crezca: incentivos correctos, procesos definidos, oportunidades de aportar y evolucionar la forma de operar. Pero nada de eso importa si no cambiamos también la definición de éxito: el output tiene que dejar de ser únicamente el proyecto, y tenemos que voltear a ver al equipo. Features , deadlines y resultados siguen importando, pero se vuelven efectos secundarios de algo más fundamental: un grupo de personas que confía lo suficiente entre sí como para operar sin fricción constante. Un equipo así puede absorber cambios, adaptarse y seguir funcionando incluso cuando alguien clave no está disponible. Cuando todo depende de una sola persona, el sistema es frágil. Cuando la confianza está distribuida, el sistema escala. Nada de eso ocurre por accidente. Nada de esto se siente natural al inicio. Venimos de años entrenando el cerebro para buscar certeza, feedback inmediato y validación clara. De pronto, las respuestas tardan más, el feedback se vuelve difuso y las decisiones pesan distinto. No es que seas peor en tu trabajo. Es que el trabajo cambió. La incomodidad no es una señal de incompetencia, sino de transición. Estás dejando un mundo donde casi todo era binario y entrando a otro donde el valor está en el juicio, no en la ejecución perfecta. Ese es el verdadero cambio de nivel. Eso, por lo menos para mí, es la verdadera marca de alguien sénior.

Cuando dice que algo está “brutal”; o que “fulanito un crack”; o que “tal equipo la está rompiendo”; o que el suyo es el “dream team”. Con base en experiencia propia, y sin ánimos de agraviar a los aquí presentes, pero: no, gracias — seguro los contactos que hiciste en tu MBA en Stanford o el MIT tienen a alguien que será un mejor fit que yo para trabajar contigo.

Jeffrey Selingo en Intelligencer : El hecho de que los pasantes universitarios de la Generación Z y los recién egresados sean los primeros trabajadores afectados por la IA resulta sorprendente. Históricamente, los grandes cambios tecnológicos favorecían a los empleados junior, porque suelen ganar menos dinero y ser más hábiles y entusiastas al adoptar nuevas herramientas. Pero un estudio del Laboratorio de Economía Digital de Stanford, publicado en agosto, mostró algo muy distinto. El empleo para egresados universitarios de la Generación Z en trabajos afectados por la IA, como el desarrollo de software y el soporte al cliente, ha caído 16 % desde finales de 2022. Mientras tanto, los trabajadores con más experiencia en las mismas ocupaciones no están sintiendo el mismo impacto (al menos todavía), dijo Erik Brynjolfsson, economista que lideró el estudio. ¿Por qué la diferencia? Los trabajadores senior, me dijo, “aprenden trucos del oficio que quizá nunca se escriben”, lo que les permite competir mejor con la IA que quienes son nuevos en un campo y carecen de ese “conocimiento tácito”. Por ejemplo, ese conocimiento práctico podría permitirles entender mejor cuándo la IA está alucinando, es incorrecta o simplemente no es útil. Es un buen punto, que no había considerado antes. Las universidades no la están viendo más sencilla: Recién ahora las universidades se están dando cuenta de que las implicaciones de la IA son mucho mayores y que ya están superando su capacidad institucional de respuesta. Mientras las escuelas luchan por actualizar sus planes de estudio y políticas en el aula, también enfrentan un problema más profundo: la enorme brecha repentina entre lo que dicen que sirve un título universitario y lo que ahora exige el mercado laboral. En ese desajuste, los estudiantes son quienes absorben el riesgo. Alina McMahon y millones de otros integrantes de la Generación Z como ella están atrapados en un momento intermedio confuso: universidades que apenas comienzan a pensar cómo adaptarse y redefinir su misión en el mundo post-IA, y un mercado laboral que está cambiando mucho, mucho más rápido. No hay mejor momento para tener hambre de conocimiento y para querer aprender; no hay peor momento para poner los prospectos de una carrera detrás de un título universitario. En Estudiar una carrera no hace que tengas una carrera escribí: Estudiar una carrera no hace que tengas una carrera. A muchos les toca aprender a la mala: un título universitario no te hace acreedor de absolutamente nada en el mundo real. Una carrera se construye, poco a poquito, estudiando y aprendiendo, con constancia, dedicación y propósito. Lo que sea que estudies en una universidad (o donde sea) puede ayudarte a construir tu carrera, pero no es tu carrera. Hay muchas razones para pensar seriamente si la universidad vale la pena, incluido el prospecto de una deuda asfixiante y la opción de aprender un oficio. En general, sin embargo, las personas con licenciatura ganan considerablemente más que aquellas que no la tienen. Correlación no implica causalidad. Sí, ganan más, ¿pero es por tener un título universitario? ¿O tienen un título universitario porque socialmente ya estaban predispuestos a tener acceso a una educación universitaria que los expone a mejores oportunidades profesionales? Otro artículo de Intelligencer (curiosamente) me hizo reflexionar sobre la industria de la educación hace unos meses: Durante muchísimo tiempo, la educación se ha basado en medir qué tan buenos somos memorizando cosas. No es sorpresa que, cuando llega una herramienta que hace redundante la necesidad de memorizar datos, el sistema se rompe. Cuando entré a la universidad en 2011 (unos meses después de que Apple presentara el iPad), el plan de estudios que me correspondía era de 2008 (cuando nació el App Store). Obviamente sé que no es razonable esperar que una universidad diseñe un plan de estudios en unos meses, pero se pasaron: mi plan de estudios no era muy diferente al que mi mamá había llevado ahí mismo en los años ochenta. ¿Qué esperanzas había de que pudiera aprender algo que me acercara a mi meta de hacer una carrera en desarrollo móvil? Ese fue mi último semestre en la escuela. Históricamente, muchas universidades no han tenido los incentivos —o la necesidad— de actualizar sus planes de estudio para reflejar la realidad social a la que están enviando a sus egresados. Tal vez estamos viendo esta necesidad aparecer en tiempo real. En el artículo original, Selingo ofrece un poco de esperanza para las universidades: A finales de los años noventa, las universidades trataron internet primero como una enciclopedia digital. Luego, como una herramienta de correo electrónico. Solo de forma gradual construyeron páginas de cursos en la web, después sistemas completos de gestión del aprendizaje, luego cursos en línea y, eventualmente, programas enteros diseñados en torno a trabajos que no existían cuando yo era estudiante. Internet no solo añadió una herramienta: reconfiguró la forma en que interactuamos con la información y entre nosotros. Entiendo el punto que quiere hacer, pero creo que falta un entendimiento fundamental de la tecnología para hacer esa comparación: internet habilitó la comunicación entre humanos, mientras que los LLMs lo que hacen es aislarlos; la idea de un LLM es que no necesites de un humano.

Kiran Stacey en The Guardian : Los ministros han lanzado una consulta para evaluar si se debe prohibir el uso de redes sociales a menores de 16 años, como parte de un paquete de medidas diseñadas para reducir el uso de teléfonos móviles entre jóvenes. A finales del año pasado Australia hizo lo mismo : Los menores de 16 años en Australia ahora tienen prohibido usar los principales servicios de redes sociales, incluidos TikTok, X, Facebook, Instagram, YouTube, Snapchat y Threads. No pueden crear nuevas cuentas y los perfiles existentes están siendo desactivados. Aunque no tengo hijos, estoy de acuerdo con esta decisión. Lo que me llamó la atención del artículo en The Guardian es que también están contemplando prohibir algunos features en las aplicaciones: La consulta explorará una variedad de opciones, incluyendo si se debe introducir un límite de edad para las redes sociales, cómo hacer cumplir dicho límite, impedir que las empresas tecnológicas accedan a los datos de usuarios jóvenes y limitar herramientas adictivas como el “scroll infinito”. Imagínate en tu próxima entrevista de trabajo cuando te pidan que implementes un feature ilegal para saber si neta sí le sabes al iOS.

Alexandra Stevenson en el NYT : El gobierno informó el lunes que el año pasado nacieron 7.92 millones de bebés, frente a los 9.54 millones de 2024. El número de personas que murieron en 2025, 11.31 millones, continuó aumentando. Las cifras más recientes de población se reportaron junto con datos económicos que mostraron que la economía de China creció 5 por ciento en 2025. Breakneck de Dan Wang ahonda en la historia de cómo China ha jugado con la población durante los últimos 80 años. Los esfuerzos de los últimos 10 años por intentar cambiar la trayectoria de su índice de población están cabrones. Ejemplo: Declarar el parto como un acto patriótico. Acosar a las parejas recién casadas sobre la planificación familiar. Gravar los condones.

Llevo años diciendo que la industria del software está siguiendo los pasos de la de la medicina. No es una analogía perfecta, pero pensarlo así me ha ayudado a entender por qué tantas personas en tecnología se sienten traicionadas por la industria, y por qué escribir código se está pareciendo cada vez más a dar consulta general en una farmacia de la esquina. En una llamada reciente con algunos suscriptores del newsletter (pon tu correo aquí para enterarte de la siguiente) salió este tema, y me di cuenta de que no había escrito algo al respecto, así que aquí está. La medicina y el software Así como la medicina, el software es una industria que: se basa en la relación entre alguien que tiene un problema que no sabe cómo resolver y un experto que sí, y se sostiene sobre una enorme asimetría de información: el paciente/cliente no tiene forma real de evaluar la calidad técnica del servicio, solo los resultados y cómo se sintió en el proceso, por mucho tiempo premió con estatus social y económico a las personas que estaban calificadas para prestar el servicio, atrajo a muchas personas y creó una saturación de oferta para un mercado que no tiene tanta demanda, ha ido protocolizando el trabajo: cada vez más cosas se resuelven siguiendo guías, checklists o frameworks estándar, y menos desde el genio individual del experto, depende más de la confianza y la reputación que de la “pieza” concreta que se entrega: la gente elige doctores y devs por recomendación, prestigio o marca, no porque pueda auditar el código o el diagnóstico, vio nacer versiones “low cost” del servicio (Farmacias Similares, no-code, IA, consultoría barata) que resuelven un montón de casos simples y empujan hacia abajo el precio de todo el mercado, produce mucho desgaste emocional en quienes la habitan: burnout, cinismo, sensación de traición por parte de una industria que ya no cumple el trato implícito con el que se vendió la profesión. … entre otras cosas. “Si estudias esto, tu vida está resuelta” Durante mucho tiempo, estudiar medicina era casi garantía de cierto tipo de vida. Muchos crecimos viendo al tío doctor que cambiaba de coche cada pocos años, se iba de viaje, tenía consultorio propio y, en general, proyectaba estabilidad y respeto. Dos o tres generaciones completas decidieron meterse a estudiar medicina porque vieron ese futuro de manera muy tangible. Años de estudio, guardias, residencia, exámenes… con la creencia de que al final del túnel estaba ese paquete completo: buen ingreso, estatus, trabajo asegurado. Pero no está alcanzando para todos. En los últimos 20 o 30 años, un montón de personas tomaron la misma decisión al mismo tiempo. El resultado fue un exceso de médicos generalistas: de acuerdo con la ANUIES (Asociación Nacional de Universidades e Instituciones de Educación Superior), de 2012 a 2017 a nivel nacional egresaron de la carrera de medicina 89,256 alumnos y 75,950 presentaron su examen profesional. Estos son 75,950 nuevos médicos que están buscando la forma de posicionarse en el mismo mercado. No me quiero meter en los matices sociales y políticos que ponen a los médicos en esta situación (México tiene 2.4 médicos por cada 1,000 habitantes, cifra inferior al promedio de la OCDE, que es de 3.5), pero a lo que voy es esto: el título por sí solo ya no compra lo que compraba antes, y con software está pasando algo muy parecido. Durante una década, la narrativa dominante era que lo único que tenías que hacer era saber programar para conseguir una buena chamba, con un sueldo aparentemente desproporcional al esfuerzo físico que requería el trabajo. Bootcamps, cursos, plataformas, universidades adaptando planes de estudio para meter “programación” en todos lados. Y era cierto que había mucha oportunidad… hasta que suficiente gente llegó al mismo lugar. Hoy no compites solo con quien estudió ingeniería en sistemas. Compites con quien se metió a un bootcamp durante la pandemia (si persistió, hoy tendrá por ahí de seis años de experiencia, que muchos considerarían suficiente como para ponerse el título de Senior en LinkedIn), con la generación que viene detrás de ti y, ahora también, con la IA que escribe tres cuartas partes del código repetitivo mejor, más rápido y por mucho menos dinero que tú. Dar consulta se volvió un commodity La otra parte de la historia de la medicina es el Simi. Farmacias Similares, consultorio al lado, médico con bata, diploma en la pared, consulta barata. Es accesible, está en todas partes y resuelve la mayoría de los problemas cotidianos de salud, y, lo más importante, quienes dan consulta ahí también son médicos. Estudiaron, se titularon y cargan con la misma carrera de seis años que cualquier otro doctor. Lo que cambió fue el valor de mercado de la consulta general. Antes, por el simple hecho de ser médico, podías cobrar caro. Hoy, para poder cobrar entre MXN $800 y $1,000 la consulta, necesitas años extra de especialidad, subespecialidad, investigación, contactos, haber publicado en medios de la industria, reputación… y aun así no hay garantía. Hay que añadir más contexto: la medicina, igual que la tecnología, ha avanzado muchísimo. El médico que te atiende hoy no usa los mismos procedimientos ni las mismas medicinas que el de hace 30 años. El límite se empuja hacia abajo, haciendo la medicina mucho más accesible para todos. Eso trae más competencia, sí, pero no necesariamente menos calidad. Por ejemplo, voy regularmente al Simi cuando me siento mal, porque sé que probablemente no tengo algo que requiera un especialista. Tengo mis vacunas, estoy sano, como razonablemente bien. Afortunadamente, la gran mayoría de las veces que he ido al Simi he tenido razón: lo que me receta el doctor resulta que sí me cura o, por lo menos, me quita los síntomas. Y muchas veces eso es realmente lo que quiero: ya queda a mi criterio si voy a un especialista a ver qué sigue después. Por más que quieras, no puedes hacerle competencia a las dinámicas de mercado: mientras algo es más accesible, su precio baja, y las personas que operan en esa industria se tienen que enfrentar a la realidad de jugar por un ticket más bajo, con más volumen y también más presión. En software estamos viendo una versión muy parecida a la que los doctores llevan años viviendo, con la única diferencia de que, como suele suceder con la tecnología, está siendo más rápido. “Avanza rápido y rompe cosas”, ¿no? Opciones no-code , frameworks ultra maduros, plantillas, APIs para todo y ahora modelos de IA que escriben código decente a partir de texto. Cada vez es más fácil producir software “suficientemente bueno” para muchísimos casos. Ese es nuestro Simi del software. La habilidad de producir en un stack popular ya no es tan diferenciadora. Y el mercado se da cuenta: si puede obtener un resultado 80 % bueno, 80 % más rápido y 80 % más barato, lo va a hacer. Especialistas, generalistas y la capa que se está deshaciendo Cardiología, neurología, pediatría, oncología. Cada especialidad implica años extra de estudio, guardias, exámenes y certificaciones. Y aun después de eso, toca construir reputación. Puedes cobrar más porque estás en la frontera de algo. Porque resuelves problemas que no cualquier médico puede resolver. Si no te vas por ahí, te quedas en el mundo de la consulta general. No es indigno ni “menos”. Simplemente opera con otras reglas: volumen alto, márgenes pequeños, más presión y menos control sobre tus condiciones. En software, la división se está pareciendo peligrosamente a eso. Abajo, en la frontera técnica, está la gente que trabaja en cosas que casi nadie ve pero de las que todo depende: compiladores y runtimes, arquitectura de CPU y chips, infraestructura de modelos, orquestación y optimización. Sistemas donde un error no significa un error 500 que se arregla con un redeploy, sino perder millones o, en el peor de los casos, poner en riesgo vidas. Ahí no hay IA que hoy, por hoy, puedas soltar para diseñar sola la solución. Ahí siguen haciendo falta humanos con entendimiento profundo, años de oficio y una tolerancia rara al dolor. Arriba, en la frontera de producto, hay otra tribu distinta. Gente que entiende problemas de negocio, que sabe hablar con clientes y leer entre líneas, detectar oportunidades donde otros solo ven requerimientos. Personas que pueden usar IA, herramientas sin código y bloques tecnológicos para montar soluciones completas. En medio queda la capa de “sé React, sé Node, sé armar una arquitectura estándar y optimizar un poco la base de datos”. Y cada vez es más difícil justificar por qué alguien debería pagarte caro y con urgencia por eso. El paciente/cliente ya viene con diagnóstico de Google (o de ChatGPT) Otra similitud incómoda es el paciente que llega con el diagnóstico listo. Antes ibas al doctor a que te dijera qué tenías. Ahora llegas habiendo leído artículos, visto videos de 30 segundos en TikTok y teniendo una conversación con ChatGPT que ya confirmó todas tus sospechas de que te vas a morir pronto si no se te quita el dolor de garganta. En software, el cliente llega diciéndote que ya vio un SaaS que hace eso por 20 dólares al mes, que con Zapier y n8n funciona, o que ChatGPT ya hizo la chamba y nomás hace falta hacer el deploy. La chamba del ingeniero de software, igual que la del médico, ya no es partir de cero, sino manejar expectativas, tratar con pacientes que vienen con soluciones preconcebidas y con diagnósticos a medias. El valor se mueve de “yo sé escribir este algoritmo” a saber escuchar, cuadrar el problema y entender que lo que el paciente quiere es que no le duela la cabeza y que no va a cambiar sus hábitos por más que le expliques que no puede seguir durmiéndose a las 4am todos los días y desayunando una coca con cigarro, así que realmente no hay mucho más que puedas hacer que darle un paracetamol. ¿Quieres escribir código o quieres desarrollar software? Todo esto lleva a una pregunta que te tienes que hacer: ¿quieres escribir código o quieres desarrollar software? En 2021 escribí : La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales. Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar. Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc. Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales. 5 años después todo apunta a que tenía razón: si lo que quieres es seguir escribiendo código como actividad principal, va a tocar bajar a problemas fundamentales que requieren alta especialización: lenguajes, compiladores, runtimes, infraestructura básica, sistemas distribuidos pesados, rendimiento serio, seguridad, criptografía. Situaciones con consecuencias reales donde un error no es nada más un error menor. Eso se parece mucho más a hacer una especialidad médica difícil. No cualquiera llega, no cualquiera se queda y no es algo que vayas a obtener con un par de cursos de fin de semana o viendo videos en línea. Si lo que quieres es desarrollar software—resolver problemas usando tecnología—, entonces toca moverse hacia arriba. Aprender de producto, negocio, diseño de experiencias y mejorar habilidades sociales: comunicación , influencia , liderazgo . Y hacer las paces con que “desarrollar software” cada vez menos significa escribir tú mismo todas las líneas de código. Tienes que desapegarte de que tu identidad dependa únicamente de ser “el que escribe el mejor código de la empresa”. Porque, te digo, la neta eso ya no importa. Elegir qué tipo de “doctor del software” quieres ser Nada de esto significa que ya no habrá trabajo en la industria del software. Así como en la medicina, trabajo va a haber. Siempre hay personas con necesidades. Siempre hay alguien que necesita ayuda. El tema es entender que lo que antes nada más necesitaba un título, hoy exige mucha más inversión de tiempo, dinero, experiencia y talento. También dónde te quieres posicionar en el ecosistema es más importante que nunca. Puedes aspirar a ser el cardiólogo de referencia, vivir en la frontera técnica y aceptar un camino largo y muy especializado. Puedes ser el médico general que resuelve problemas cotidianos rápido, apoyado en protocolos y herramientas cada vez mejores. O puedes ser quien diseña la cadena completa de clínicas: producto, negocio y operación. Lo que parece menos sostenible es seguir creyendo que, solo por tener un título o saber un framework, el mercado te debe la versión glamorosa de la profesión que viste hace diez años. La industria del software está siguiendo el camino de la medicina. La pregunta es si vas a seguir peleándote con esa realidad o si la vas a usar para tomar una decisión más sobria sobre qué tipo de doctor del software quieres ser en los próximos años. Y si quieres, podemos tomar esa decisión juntos: mándame un mensaje .

Lalit Maganti, en su blog Why Senior Engineers Let Bad Projects Fail , escribe: Cuando era un ingeniero junior, mi manager ocasionalmente me confiaba sus frustraciones durante nuestras 1:1 semanales. Señalaba un proyecto en el que otro equipo estaba trabajando y decía: “No creo que ese proyecto vaya a llegar a ningún lado, están resolviendo el problema equivocado”. Yo me preguntaba: “Pero eres muy senior, ¿por qué no vas y hablas con ellos sobre tus preocupaciones?”. Me parecía un desperdicio de su influencia no decir nada. Es la misma vibra de cuando ves a alguien que va caminando todo absorto en su celular y sin ver el poste que tiene enfrente. Porque eres buena persona, piensas, no mames, debería decir algo. Pero luego tu instinto de preservación de tus genes te pone un alto: que se pegue ‘pa que aprenda a no caminar sin ver por dónde va. Le escuché a un terapeuta una vez: no les niegues a las personas el privilegio de aprender de sus propios errores. Pero volviendo al punto original — ingeniería de software. Lalit habla más desde la perspectiva de un desarrollador, y cómo ser el que se la pasa advirtiéndoles a otros que van por un mal camino puede afectarles: Una o dos veces puedes ser visto como alguien que está defendiendo la “calidad”. Pero si lo haces con demasiada frecuencia, rápidamente pasas a ser visto como una “persona negativa”, alguien que constantemente genera problemas, no que los soluciona. Rara vez recibes crédito por los desastres que evitaste. Como no pasó nada, la gente lo olvida rápidamente. Finalmente, también está el impacto psicológico. Hay una sola persona como tú y cientos de ingenieros trabajando en espacios donde tu experiencia podría ayudar. Tu atención es finita, pero la capacidad de una gran empresa para generar malas ideas es infinita. Por experiencia, involucrarte demasiado en detenerlas puede volverte muy cínico respecto al estado del mundo. Y ese no es un buen lugar mental para estar. El mejor consejo que da sobre cómo manejar estas situaciones —cuando sabes que alguien la está cagando, pero no sabes si deberías decir algo o no— es manejar tu influencia como una cuenta de banco: Entonces, si no puedes detener todos los malos proyectos, ¿qué haces? Te vuelves estratégico. En lugar de intentar arreglar todo, ve tu influencia como una cuenta bancaria. Cada mes tienes cierta cantidad de “influencia” que entra conforme haces tu trabajo, ayudas a otras personas, entregas proyectos exitosos y, en general, te mantienes como alguien de baja fricción. Luego, cuando importa de verdad, debes estar listo para hacer “retiros”. Cada vez que bloqueas algo o levantas una preocupación, por pequeña que sea, estás escribiendo un cheque contra tu balance. Pero no todos los cheques cuestan lo mismo: El cheque de $5: Un detalle menor en un code review. Gasto barato y cotidiano. El cheque de $500: Cuestionar una decisión arquitectónica o presionar contra un timeline. Requiere ciertos ahorros. El cheque de $50,000: Intentar matar el proyecto favorito de un VP. Es un gasto enorme. Quizá solo puedas permitirte uno de estos cada varios años. El problema aparece si gastas $5 en cada pequeña ineficiencia que ves. Si constantemente estás diciendo “no” a cosas pequeñas, tu cuenta estará vacía cuando necesites escribir el cheque grande para detener un verdadero desastre. Si te “sobregiras”, entras en bancarrota política. La gente deja de invitarte a reuniones, deja de pedir tu opinión y, en esencia, empieza a trabajar alrededor de ti. Una vez en bancarrota, tu influencia cae a cero y no solo dañas tu capacidad de influir, sino también tu habilidad para hacer que las cosas sucedan. Esto resuena con lo que escribí hace unos meses en Deja de optimizar tu stack, empieza a optimizar tu influencia : Lectura de contexto: Qué está intentando lograr el negocio de verdad, más allá del OKR bonito en Notion. Cartografía de poder: Quién decide qué, cómo se reparten recursos, quién tiene veto silencioso, quién tiene influencia informal. Traducción entre mundos: Cómo explicar riesgos técnicos en lenguaje que finanzas, producto y leadership puedan usar para decidir. Diseño de apuestas: No solo “hacer features”, sino proponer apuestas con impacto en métricas y tradeoffs claros. Narrativa y visibilidad: Hacer que el trabajo importante se vea, se entienda y se cuente en los foros correctos. Ese es el stack que te lleva de “buen senior” a alguien que realmente mueve sistemas completos (técnicos y humanos). Esta es la perspectiva de lo que significa “ganar experiencia” en la industria, más allá de cuántos lenguajes de programación sabes: Cuando estás al inicio de tu carrera, quieres creer que las buenas ideas ganan por mérito propio; que si simplemente explicas las cosas con suficiente claridad, la gente entrará en razón. A mí me tomó bastante tiempo aceptar que las grandes empresas no funcionan así. Pero eso no significa que dejes de preocuparte. Significa que te vuelves estratégico respecto a cuándo gastar tu credibilidad. Elige las batallas donde realmente puedes cambiar el resultado, donde tu equipo se verá afectado si guardas silencio, donde el costo de estar equivocado es bajo, pero el costo de que el proyecto falle es alto. Conocimiento ≠ sabiduría. Cuando escribí que la definición de Full Stack Developer cambia para 2026 , me refería justamente a esto: Lo que está cambiando no es solo el stack técnico. Está cambiando el tipo de valor que las organizaciones necesitan. Cuando escribir código se vuelve barato, abundante y automatizable, lo que empieza a importar es todo lo demás: entender el problema correcto, navegar organizaciones, influir en decisiones, traducir necesidades humanas en sistemas que funcionen. Dicho de otra forma: ser un Full Stack Developer ya no se trata de lenguajes de programación y frameworks, sino de habilidades sociales, políticas y de desarrollo de producto; de qué tan bueno eres hablando con personas que no tienen background técnico; de tu capacidad integral para resolver problemas. Hace unos años podías darte el lujo de ser más pasivo al demostrar habilidades que no estuvieran relacionadas con escribir código. Le dejabas el desmadre “político” a las personas encargadas de eso. Eso era posible porque tu habilidad para producir código todavía no era un commodity . Lo que dice Lalit en su blog es cierto: tienes que volverte más estratégico al decidir en qué batallas gastas tu capital de influencia. Lo que yo agregaría es que eso ya no aplica solo para seniors, sino para cualquiera que quiera seguir siendo relevante en la industria durante los próximos años.

En LinkedIn y en todos lados últimamente veo a mucha gente subiéndose al tren del mame de que ya no usan ChatGPT para nada, porque Claude o Gemini son mejores modelos. Mi take: el rendimiento del modelo importa, sí, pero no tanto como qué tan fácil puedes comenzar a usarlo. Aunque Gemini sea un mejor modelo, si es más fácil usar Claude Code en la terminal, la banda va a usar Claude Code en la terminal.* Aunque Gemini sea un mejor modelo, si Xcode 26 trae por default ChatGPT, la banda va a usar ChatGPT. Aunque Gemini sea un mejor modelo, OpenAI tiene una aplicación nativa que se integra súper bien con otras apps y hace el manejo de workflows mucho más sencillo. El rendimiento del modelo solo le importa a las personas que tienen un interés a nivel de ingeniería. El resto de las personas, el 98 % de los usuarios de estas herramientas, solo quieren algo que funcione y están dispuestos a usar algo que sea suficientemente bueno, no importa que no esté en el bleeding edge . Un Alt-Space me abre una ventana flotante de ChatGPT en donde sea que esté, sin usar el mouse, y para algunas aplicaciones automáticamente se conecta con ellas para leer el contexto. Es eso, o abrir una pestaña de Chrome, ir a Gemini, pegar el contenido y escribir el prompt. Si funciona y está donde lo necesito, el rendimiento del modelo no importa tanto.** Aplica para modelos LLM y muchas otras cosas. * Lo bueno aquí es que Claude parece ser el mejor modelo para tareas de programación. Pero si ChatGPT hubiera sacado su agente de programación en la terminal antes que Anthropic, creo que también habrían ganado esa carrera. ** Además: funcionalmente, para la mayoría de tareas, los modelos actuales son prácticamente intercambiables en términos de performance y capacidades.

Robin Sloan dice que la AGI (Artificial General Intelligence , la supuesta meta a la que todas las empresas de IA están buscando llegar) ya está aquí: La encuesta de 2025 sobre interpretaciones de la AGI de Jasmine Sun es lectura obligatoria sobre el tema, y no solo por su ya inmortal frase… La IA descubrió proteínas completamente nuevas antes de poder contar las “r” en “strawberry”, lo que la convierte en algo que no es ni vaporware ni un semidiós, sino una tercera cosa secreta. … y aun así, al final Jasmine deja la pregunta abierta, y yo preferiría cerrarla. El truco está en leer literalmente. La palabra clave en Artificial General Intelligence es General . Esa es la palabra que hace que esta IA sea distinta de cualquier otra: porque todas las demás IA fueron entrenadas para un propósito específico y, incluso cuando lo lograron de forma espectacular, no hicieron nada más . Considera modelos emblemáticos a lo largo de las décadas: Mark I Perceptron, LeNet, AlexNet, AlphaGo, AlphaFold… estos sistemas eran distintos entre sí, pero todos compartían esta característica. Los modelos de lenguaje también fueron entrenados con un propósito… pero, sorpresa: el mecanismo y la escala de ese entrenamiento hicieron algo nuevo: abrieron un túnel, a través del cual se puede acceder a un vasto campo de acción y respuesta. Bibliotecas gigantescas de escritura humana, reunidas a lo largo del tiempo y el espacio, por todas las razones más tontas… eso es un combustible riquísimo, si puedes mantenerlo todo en la cabeza. Aunque un LLM todavía no puede hacerlo todo, sí puede hacer mucho: Los modelos grandes todavía tienen limitaciones severas: el amplio dominio de lo físico —es decir, la mayor parte del universo— les está cerrado, y aun dentro del cómodo reino de lo simbólico, muchas tareas y procesos los confunden. Podría decirse que los modelos grandes poseen una generalidad inmediata prodigiosa, distinta de la generalidad eventual e implacable de un ser humano diligente. En esto, por ejemplo, se enfoca el investigador François Chollet: rompecabezas nunca antes vistos que tú y yo podemos resolver en cuestión de minutos , mientras que un modelo grande se atasca y se sobrecalienta. Y aun así, puedes leer el artículo de François de 2019, On the Measure of Intelligence —y deberías hacerlo—, estar mayormente de acuerdo con él —yo lo estoy—, y aun así notar que, en los años desde su publicación, los modelos grandes se han vuelto REALMENTE MUY SALVAJEMENTE GENERALES. La AGI ya está aquí, y aún quedan muchos objetivos jugosos por delante. ¿Por qué alguien esperaría lo contrario? François plantea exactamente este punto en su artículo: la universalidad no es un requisito para la generalidad. No puede serlo, porque no es posible. Si seguimos cambiando el definition of done con cada commit , nunca vamos a terminar el chingado proyecto.

Ben Thompson de Stratechery entrevistó al CEO de United Airlines sobre la transformación que una mejor tecnología ha traído al negocio: La entrevista de Stratechery de esta semana es con Scott Kirby, CEO de United. Kirby ha tenido una carrera notable en la industria de la aviación. Fue uno de los principales arquitectos de la consolidación del sector a principios de este siglo y, durante la última década, ha transformado a United Airlines en un gigante consistentemente rentable y agresivamente en crecimiento.

Wesley Yin-Poole en IGN: El creador de Warhammer, Games Workshop, ha prohibido el uso de inteligencia artificial en la producción de contenido y en sus procesos de diseño, insistiendo en que ninguno de sus directivos senior está actualmente entusiasmado con la tecnología. Parece que la industria creativa se está poniendo las pilas en contra del uso de la IA. El CEO de Games Workshop dice:

La inteligencia artificial está obligando a replantear los límites legales de la creatividad, la identidad y la propiedad intelectual. Desde marcas personales hasta patentes asistidas por IA, el marco jurídico comienza a adaptarse a una tecnología que avanza más rápido que la ley.

En r/bandcamp, Bandcamp anunció nuevas reglas sobre el uso de IA generativa en música, reforzando su compromiso con la creatividad humana y la protección de los artistas. ¡Feliz Año Nuevo, r/bandcamp! Esperamos que hayan disfrutado la Guía de Fiestas (bandcamp.com/2025) y sus resúmenes de Bandcamp 2025. Algo que siempre nos llama la atención cuando armamos un resumen como este es la enorme cantidad de creatividad y pasión humana que los artistas expresan en Bandcamp todos los días.

Dries Buytaert, el fundador de Drupal, escribe sobre la situación de Tailwind: La historia que circula es que la IA está acabando con los negocios de código abierto. No creo que eso sea del todo correcto. La IA no mató el negocio de Tailwind. Lo puso a prueba bajo estrés. Su modelo de negocio no superó la prueba, pero eso no es una acusación contra todos los modelos de negocio de código abierto.

Soy empático con la situación de Tailwind. Es desafortunado que personas hayan perdido su sustento de un día para otro. Pero creo que este es un ejemplo claro de lo que he venido diciendo en los últimos años : vender código no es un medio viable para construir una carrera —ni un negocio— sostenible.

La programación ya no es el valor diferencial. En un mercado donde el código es cada vez más barato, la ventaja competitiva está en resolver problemas, entender el negocio y generar confianza. La IA no está reemplazando carreras: está exponiendo quién aporta valor real.

En The Washington Post: Comparar cómo los sistemas de IA y los humanos se desempeñan en trabajos reales muestra qué tan cerca están herramientas como ChatGPT de quitarle el trabajo a las personas. Compararon el performance de humanos vs. IA en diferentes proyectos. El primero: digitalizar un sketch arquitectónico hecho a mano. El humano produjo un plano con apariencia profesional.