Oscar Swanros

Ya no importa estar bien; importa ser rápido. Om Malik : Las redes siempre han moldeado la organización de las sociedades. Las calzadas romanas no solo facilitaron los viajes; trazaron el alcance del Estado y los límites del poder. Las rutas de navegación determinaron dónde florecieron los imperios coloniales y dónde se desvanecieron. En la época victoriana, los ferrocarriles no solo acortaron los viajes; reorganizaron la sociedad británica. Crearon los traslados diarios y el ocio, convirtieron los pueblos de mercado en suburbios, estandarizaron la hora nacional y colapsaron el significado de la distancia. También reordenaron la autoridad: los horarios importaban tanto como los parlamentos. Lo que parece una elección cultural es a menudo el eco de la infraestructura. El mundo actual de dispositivos móviles y conectados a la nube es otro momento victoriano. Las redes comprimen el tiempo y el espacio, y luego nos entrenan silenciosamente para vivir a su velocidad. Por eso recibimos toda nuestra información en forma de memes. El meme se ha convertido en la metahistoria, la capa donde se transporta el significado. No necesitas leer el contenido; solo necesitas la esencia, comprimida y transmitida en una oración, una imagen o un chiste. Ha asumido el papel del titular. La máquina acelera esta dinámica. Exige material constante; deja de alimentarla y toda la estructura se sacude. El propósito de internet ahora es principalmente captar la atención y empujarla hacia el comercio, para mantener el motor en marcha. Cualquiera puede obtener su tajada. La velocidad ha tomado el control. Los incentivos que pones frente a los problemas determinan cómo se solucionan: Todo esto se resume en un punto mayor. Cuando la atención está fragmentada y la velocidad se convierte en el valor dominante, los medios se reorganizan en torno a esa realidad. No porque alguien se despierte queriendo engañar a la gente, sino porque el contexto hace que algunos caminos sean sobrevivibles y otros imposibles. Creo que las personas que genuinamente se levantan con ganas de chingar al prójimo no son tantas como las que simplemente estamos intentando hacer lo mejor que podemos con lo que tenemos. Estar en una posición en la que puedes definir los incentivos que van a hacer que otras personas tomen decisiones es algo que no debes tomarte a la ligera.

“Cuando la atención está fragmentada y la velocidad se convierte en el valor dominante, los medios se reorganizan en torno a esa realidad. No porque alguien se despierte queriendo engañar a la gente, sino porque el contexto hace que algunos caminos sean sobrevivibles y otros imposibles.“

“Token Anxiety” Nikunj Kothari : Reemplacé Netflix con Claude Code. Me acuesto pensando en qué puedo poner a andar antes de quedarme dormido, qué puede ejecutarse mientras estoy inconsciente. Leer una novela se siente indulgente ahora. Ver una película sin tener la laptop abierta se siente como un desperdicio. Esta voz en mi cabeza que dice “algo podría estar ejecutándose en este momento” simplemente no se apaga. Ni siquiera estoy construyendo una empresa. Solo soy adicto a construir mis ideas aleatorias.

“ Me acuesto pensando en qué puedo poner a andar antes de quedarme dormido, qué puede ejecutarse mientras estoy inconsciente. Leer una novela se siente indulgente ahora. Ver una película sin tener la laptop abierta se siente como un desperdicio.”

Anthropic dice que Claude Code puede automatizar la modernización de sistemas COBOL Pia Singh en CNBC : Las acciones de IBM cerraron el día con una baja de casi el 13.2%, a 223.35 por acción, después de que Anthropic dijera el lunes que Claude Code podría utilizarse para automatizar el trabajo de exploración y análisis que impulsa la mayor parte de la complejidad en la modernización de COBOL, un negocio clave para IBM. IBM ha vendido durante mucho tiempo sistemas mainframe optimizados para el procesamiento de transacciones a gran escala, donde COBOL se ha utilizado con frecuencia. Por mucho tiempo se ha usado a los programadores de COBOL como un ejemplo de que especializarte en algo es una buena idea, a pesar de que esa tecnología no sea tan popular.

Por mucho tiempo se ha usado a los programadores de COBOL como un ejemplo de que especializarte en algo es una buena idea, a pesar de que esa tecnología no sea tan popular.

The Curator’s Guide to Agentic Coding Okakura Kakuzō, a curator at the Museum of Fine Arts, Boston, and a fixture in the salons of Isabella Stewart Gardner, spent his career helping Westerners bridge the gap toward Eastern aesthetics. In his lectures, he described a fundamental divergence in how cultures approach the “object” of art: The Western (Constructive) Perspective: Art is a conquest of matter. The artist is a creator who imposes their will and ego onto the medium to make something new. It is an additive process of construction. The Eastern (Revelatory) Perspective: Influenced by Taoism and Zen, art is an act of discovery. The artist “listens” to the material—a gnarled piece of wood or a blank scroll—to help it reveal its inherent spirit. I found myself revisiting Okakura’s ideas during a 1-on-1 with a direct report. We were discussing a modern dilemma: how to adopt agentic coding as a standard engineering practice. As it turns out, the “right” approach depends entirely on the state of your canvas. Greenfields: The Western Approach (Creation) When starting a project from scratch, the environment is a vacuum. To be effective, an AI agent requires a “conquest of matter”—you must actively build the world it inhabits. Ryan Lapopolo of OpenAI noted this in a recent post regarding their engineering work with Codex: The lack of hands-on human coding introduced a different kind of engineering work, focused on systems, scaffolding, and leverage. Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified. The agent lacked the tools, abstractions, and internal structure required to make progress toward high-level goals. The primary job of our engineering team became enabling the agents to do useful work. In practice, this meant working depth-first: breaking down larger goals into smaller building blocks (design, code, review, test, etc), prompting the agent to construct those blocks, and using them to unlock more complex tasks. When something failed, the fix was almost never “try harder.” Because the only way to make progress was to get Codex to do the work, human engineers always stepped into the task and asked: “what capability is missing, and how do we make it both legible and enforceable for the agent?” In this phase, your work is additive. You are the architect, providing the scaffolding, tools, and abstractions that didn’t exist before. Without this “Western” drive to construct a framework, the agent has no ground to stand on. Legacy Systems: The Eastern Approach (Revelation) However, when you bring agentic coding into an existing codebase, the philosophy must shift. You are no longer filling a void; you are standing before a massive, weathered block of marble. In a large, complex codebase, the “sculpture”—the clean, functional feature you want the agent to produce—already exists potentially within the code. The problem isn’t a lack of context; it’s an overabundance of noise. The agent is often overwhelmed by technical debt, circular dependencies, and “hallucination-inducing” abstractions. Here, the engineering task is Eastern: your job is to reveal the path for the agent by removing context. Subtractive Engineering: You simplify interfaces, prune dead code, and decouple modules so the agent can “see” the intent of the logic. Protective Guardrails: Instead of adding “how-to” prompts, you build guardrails that prevent other engineers from re-introducing the “clutter” that obscured the sculpture in the first place. As Okakura wrote in The Book of Tea : “In leaving something unsaid the beholder is given a chance to complete the idea…” In the world of agentic coding, if you refine the codebase enough to “leave the right things unsaid,” you give the agent the space to complete the masterpiece for you.

I found myself revisiting Okakura’s Kakuzō ideas during a 1-on-1 with a direct report. We were discussing a modern dilemma: how to adopt agentic coding as a standard engineering practice. As it turns out, the "right" approach depends entirely on the state of your canvas.

“No confundas complejidad con idioteces” En el último correo de Ryan Holiday : Abraza la contradicción . F. Scott Fitzgerald dijo: “La prueba de una inteligencia de primer nivel es la capacidad de mantener dos ideas opuestas en la mente al mismo tiempo y aun así conservar la capacidad de funcionar”. El mundo es complicado, ambiguo y paradójico. Para darle sentido, debes ser capaz de equilibrar verdades en conflicto. Pero no confundas la complejidad con idioteces . Las personas estúpidas son especialmente buenas teniendo un montón de pensamientos contradictorios en la cabeza a la vez. Por lo tanto, como dice Fitzgerald, no se trata solo de tolerar la contradicción, sino realmente de la capacidad de examinarla e interrogarla. Es preguntar: ¿esto realmente tiene sentido?

Las personas estúpidas son especialmente buenas teniendo un montón de pensamientos contradictorios en la cabeza a la vez.

Las IA están comenzando a predecir el futuro Ross Andersen en The Atlantic : Este año podría ser importante para la predicción con IA. En enero, Mantic inscribió su motor más reciente y mejorado en la Metaculus Spring Cup para 2026. Ya se le ha preguntado cuántos Oscar ganará Sinners y si Estados Unidos atacará pronto a Irán. Para mayo, estas preguntas se habrán resuelto y veremos cómo le fue al motor. Si sube un puesto respecto a su resultado más reciente, se convertirá en la primera IA en obtener una medalla en un torneo importante de predicción. Si la IA se lleva el oro, eso podría señalar una nueva era. Los seres humanos —predictores de eclipses, teóricos de la muerte térmica del cosmos — podrían dejar de ser los mejores guías hacia el futuro. De ahora en adelante, mientras existamos, podríamos estar preguntando a las IA qué es lo que sigue. No siempre entenderemos cómo llegaron a sus predicciones. Esta bola de cristal podría ser como un agujero negro con un horizonte de sucesos, más allá del cual la luz de su perspicacia no puede escapar. Es posible que simplemente tengamos que creer en su palabra. En esencia, los LLMs son motores de predicción —autocomplete en esteroides. Es un concepto simple, pero poderoso. Funciona para texto y para código. Si logras destilar suficiente información de manera que pueda ser leída por un LLM, va a encontrar patrones, y esos patrones nos pueden ayudar a predecir el futuro. La mejor forma de predecir el comportamiento futuro es el comportamiento pasado .

"La mejor forma de predecir el comportamiento futuro es el comportamiento pasado".

Aprendió a programar a los 7 años. Acaba de cumplir 50, y la IA le está haciendo cuestionarse su sentido de identidad. James Randall : Escribí mi primera línea de código en 1983. Tenía siete años, escribiendo BASIC en una máquina que tenía menos potencia de procesamiento que el chip de tu lavadora. Entendía esa máquina por completo. Cada byte de RAM tenía un propósito que podía rastrear. Cada píxel en pantalla estaba allí porque yo lo había puesto. El camino desde la intención hasta el resultado era directo, visible y mío. Cuarenta y dos años después, estoy sentado frente a un hardware que le habría parecido ciencia ficción a ese niño, y estoy tratando de entender qué significa siquiera “construir cosas” hoy en día. Esta no es una queja sobre la IA. No es una pieza de “en mis tiempos”. Es algo sobre lo que he estado dando vueltas durante meses, y creo que muchos desarrolladores experimentados también le están dando vueltas, aunque aún no lo hayan dicho en voz alta. La época en la que James creció definió su identidad: Estos no eran solo productos. Eran aventuras de ingeniería con compensaciones visibles. Tenías que entender la máquina para usarla. Conflictos de IRQ, canales DMA, optimización de CONFIG.SYS y AUTOEXEC.BAT, gestores de memoria — lograr que un juego funcionara era el juego. No eras solo un usuario. Eras un ingeniero de sistemas por necesidad. Por mucho tiempo, cuando las cosas cambiaban, adaptarse no era tan difícil: A lo largo de cuatro décadas he pasado por más transiciones tecnológicas de las que puedo contar. Nuevos lenguajes, nuevas plataformas, nuevos paradigmas. De CLI a GUI. Del escritorio a la web. De la web al móvil. De monolitos a microservicios. Cintas, disquetes, discos duros, SSD. Frameworks de JavaScript naciendo y muriendo como efímeras. Cada ola requería aprender cosas nuevas, pero la habilidad principal se transfería. Aprendías la nueva plataforma, aplicabas tu comprensión existente de cómo funcionan los sistemas y seguías construyendo. La herramienta cambiaba; el oficio no. Seguías siendo la persona que entendía por qué las cosas se rompían, cómo se componían los sistemas, dónde el atajo de hoy se convertía en el desastre del próximo mes. Pero con la IA es diferente: Los cambios tecnológicos anteriores consistían en “aprender lo nuevo, aplicar las habilidades existentes”. La IA no es eso. No es una nueva plataforma, ni un nuevo lenguaje, ni un nuevo paradigma. Es un cambio en lo que significa ser bueno en esto. Lo noté gradualmente. Estaba trabajando en algo —construyendo una funcionalidad, diseñando una arquitectura— y me di cuenta de que seguía haciendo lo mismo de siempre, solo que con las partes interesantes vaciadas. La parte en la que descifras la solución elegante, donde luchas con las restricciones, donde sientes la satisfacción de que algo encaje en su lugar — eso estaba siendo manejado cada vez más por un modelo al que no le importa la elegancia y que nunca ha sentido satisfacción. Más barato. Más rápido. Pero vacío. … y su sentido de identidad se está viendo retado: Cumplí 50 años hace poco. Cuatro décadas de intensidad, de crear y encontrar satisfacción e identidad en la construcción. Y ahora estoy en lo que he comenzado a llamar un periodo de barbecho. No es agotamiento exactamente. Es más como si el suelo se moviera bajo un edificio que pensabas que, aunque siempre cambiante, también tenía una permanencia, y tratas de descifrar dónde está el nuevo cimiento. No tengo una conclusión clara. No voy a decirte que los desarrolladores experimentados simplemente necesitan “subir de nivel en el stack” o “adoptar las herramientas” o “enfocarse en lo que la IA no puede hacer”. Todo eso es probablemente correcto, y nada de eso aborda el sentimiento. El sentimiento es: le di 42 años a esto, y la cosa cambió en algo que no estoy seguro de reconocer ya. No necesariamente peor. Simplemente diferente. Y diferente de una manera que desafía la identidad que construí a su alrededor y no satisface de la forma en que lo hacía. … y la industria no hace las cosas fáciles: Sospecho que muchos desarrolladores mayores de 40 años sienten algo similar y no lo dicen, porque la industria adora la juventud y la adaptabilidad, y decir “esto no se siente como antes” suena a que te estás quedando atrás. No me estoy quedando atrás. Estoy avanzando, aprovechando las nuevas herramientas, construyendo más rápido que nunca y usando estas herramientas para ayudar a otros a acelerar su propio trabajo. Estoy creando productos con los que solo podría haber soñado hace unos años. Pero al mismo tiempo estoy mirando el panorama, tratando de entender qué significa construir para mí ahora. El mundo también está descifrando su forma. Quizás eso esté bien. Tal vez el periodo de barbecho sea el punto. No algo que hay que atravesar a la fuerza, sino algo en lo que estar por un tiempo. Empecé a programar cuando tenía siete años porque una máquina hacía exactamente lo que yo le decía, se sentía como algo que podía explorar y finalmente conocer, y eso se sentía como magia. Ahora tengo cincuenta años, y la magia es diferente, y estoy aprendiendo a convivir con eso. Acá está mi historia: Cómo aprendí a separar mi identidad de mi empleo .

“Cuando las barbas de tu vecino veas afeitar, pon las tuyas a remojar.”

AI is making you a worse programmer. And that’s a good thing. Originally published in Spanish here . In a post on Anthropic’s blog , they share the results of a study that sought to understand the impact of AI usage on the acquisition of technical skills: In a randomized controlled trial, we examined 1) how quickly software developers acquired a new skill (in this case, a Python library) with and without AI assistance; and 2) whether using AI made them less likely to understand the code they had just written. The results: We found that using AI assistance led to a statistically significant decrease in skill mastery. On a quiz covering concepts they had used just minutes earlier, participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two grade levels. AI use slightly accelerated task completion, but this did not reach the threshold of statistical significance. Although the context is AI usage, these results do not surprise me. Not because of AI itself, but because this is exactly what happens every time a technology eliminates a problem you previously had to solve manually. Not our first rodeo When I learned to program in Objective-C around 2008, before ARC , every time you created an object in memory with [[Object alloc] init], you had to make sure to free that memory with [object release] once you were done using it. If you didn’t, you had a memory leak . In the best case, your app felt slow. In the worst, you’d hit a SEGFAULT and your app would crash unexpectedly. Then ARC arrived, and suddenly those of us programming for iOS no longer had to worry about manually closing that cycle, because the system would do it for us. Not only did we have to write less code, but we also had a system-level guarantee that we no longer needed to keep track of references manually. Overnight, we no longer had to think about it. Of course, other problems emerged, and it wasn’t the end of bugs in iOS applications, but that problem no longer existed. Someone who decides to learn Swift as their first programming language in 2026 will not have to learn the same memory management concepts that I had to learn 20 years ago; just as I didn’t have to learn the fundamentals of processor registers that were vital when ASM was the highest level of abstraction we had. And yet, I’ve been able to build a career in software without knowing how to manually move bits of memory between registers. The abstraction layer What AI is doing for software development has the same practical effect as advances in compilers, data types, and static code analysis: by creating an abstraction layer over fundamental problems, programmers can completely stop worrying about an entire category of issues. This process is not an anomaly caused by AI, but the continuation of a historical inertia. Every major advance in computing has consisted of giving us the opportunity to “ignore” a technical difficulty so we can think about more complex problems. We went from manually managing bits in registers to delegating data organization to C++ encapsulation. From struggling with memory management to trusting Java’s Garbage Collector. And from writing infrastructure code to defining only intent in Ruby or JavaScript. What we are experiencing today with AI is simply the displacement of that boundary: if we previously abstracted hardware and memory, today we are abstracting syntax itself. Code is becoming an implementation detail so the programmer can focus purely on architecture and purpose. Worse programmer, better engineer This is the point most people miss when they look at these studies. Being a “worse programmer” in the sense that you can no longer write a memory-sorting algorithm or that you need to look up the exact syntax of a Python decorator is not a bug , but a feature . The question has never been “how well do you write code?”. The question has always been “how well do you solve problems?”. And solving problems requires a completely different set of skills: knowing which problem you are actually solving. Not the problem the user explicitly asked for, but the underlying problem that is creating friction. Knowing when not to write code. When the solution is to change a process, reorganize a team, or simply say no. Knowing how to verify whether your solution works. Not whether it compiles. Not whether it passes tests. Whether it solves the real problem for the real people who have it. AI can write the code. It cannot do any of these other things. From syntax to systems Just as someone learning Swift today doesn’t have to worry about the retain/release memory cycle, and I didn’t have to worry about learning how to move bits between processor registers, what AI is doing is raising the abstraction layer so that code itself is no longer the important part. Except this time, the abstraction layer is higher than ever. Completely outside the technical domain. It’s no longer about writing syntactically correct code. It’s about knowing which problem to solve and how to verify that the solution—the one you designed and the AI implemented—actually solves it. That is a completely different skill. And that is the skill that defines an engineer. If you are navigating this transition—from writing code to designing systems, from executing to deciding what is worth executing—I work with people in technology who want to develop exactly these skills that AI cannot abstract away: strategic thinking, solution architecture, and the ability to distinguish between the real problem and the apparent one. Schedule a discovery session and let’s talk about where you are and where you want to go.

Becoming a worse programmer to become a better engineer. That's the tradeoff.

La IA te está haciendo peor programador. Y eso es algo bueno. En un post en el blog de Anthropic comparten los resultados de un estudio que intentaba entender el impacto del uso de IA en la adquisición de habilidades técnicas: En un ensayo controlado aleatorio, examinamos 1) qué tan rápido los desarrolladores de software adquirían una nueva habilidad (en este caso, una biblioteca de Python) con y sin asistencia de IA; y 2) si el uso de IA los hacía menos propensos a entender el código que acababan de escribir. Los resultados: Encontramos que el uso de asistencia de IA condujo a una disminución estadísticamente significativa en el dominio de la habilidad. En un cuestionario que cubría conceptos que habían utilizado apenas unos minutos antes, los participantes del grupo de IA obtuvieron una puntuación 17% más baja que aquellos que programaron a mano, o el equivalente a casi dos grados escolares. El uso de IA aceleró la tarea ligeramente, pero esto no alcanzó el umbral de significancia estadística. Si bien el contexto es el uso de IA, estos resultados no me sorprenden. No por la IA como tal, sino porque esto es exactamente lo que pasa cada vez que una tecnología elimina un problema que antes tenías que resolver manualmente. Not our first rodeo Cuando aprendí a programar en Objective-C por ahí de 2008, antes de ARC , cada vez que creabas un objeto en memoria con [[Object alloc] init], tenías que asegurarte de liberar esa memoria con [object release] al terminar de usarlo. Si no lo hacías, tenías un memory leak . En el mejor de los casos tu app se sentía lenta. En el peor, encontrabas un SEGFAULT y tu app se cerraba inesperadamente. Pero llegó ARC y de repente los que programábamos en iOS ya no teníamos que preocuparnos por cerrar ese ciclo manualmente, porque el sistema lo haría por nosotros. No solamente había que escribir menos código, sino que teníamos una garantía a nivel sistema de que ya no teníamos por qué llevar la cuenta de referencias manualmente. De un día para otro, ya no teníamos que pensar en eso. Claro, aparecieron otros problemas, y no fue el final de los bugs en aplicaciones de iOS, pero ese problema ya no existía. Alguien que decide aprender Swift como su primer lenguaje de programación en 2026 no va a tener que aprender los mismos conceptos de manejo de memoria que yo tuve que aprender hace 20 años; así como yo no tuve que aprender los fundamentales de los registros de procesador que eran vitales cuando ASM era la capa de abstracción más alta que teníamos. Y mira que yo he podido hacer una carrera en software incluso sin saber cómo mover bits de memoria entre registros manualmente. La capa de abstracción Lo que la IA está haciendo para el desarrollo de software es el mismo efecto práctico que los avances en compiladores, tipos de datos y análisis estático de código: al crear una capa de abstracción sobre problemas fundamentales, los programadores pueden dejar de preocuparse de una categoría de problemas por completo. Este proceso no es una anomalía de la IA, sino la continuación de una inercia histórica. Cada gran avance en la computación ha consistido en darnos la oportunidad de “ignorar” una dificultad técnica para permitirnos pensar en problemas más complejos. Pasamos de gestionar manualmente bits en registros a delegar la organización de datos al encapsulamiento de C++. De sufrir por el manejo de memoria a confiar en el Garbage Collector de Java. Y de escribir código de infraestructura a definir solo intenciones en Ruby o JS. Lo que hoy experimentamos con la IA es simplemente el desplazamiento de esa frontera: si antes abstrajimos el hardware y la memoria, hoy estamos abstrayendo la sintaxis misma. El código se está convirtiendo en un detalle de implementación para que el programador pueda enfocarse puramente en la arquitectura y el propósito. Peor programador, mejor ingeniero Aquí está el punto que la mayoría de la gente se pierde cuando ve estos estudios. Ser “peor programador” en el sentido de que ya no puedes escribir un algoritmo de ordenamiento de memoria o que necesitas consultar la sintaxis exacta de un decorador en Python no es un error. Es una funcionalidad. La pregunta nunca ha sido “¿qué tan bien escribes código?”. La pregunta siempre ha sido “¿qué tan bien resuelves problemas?”. Y resolver problemas requiere un conjunto de habilidades completamente distinto: saber qué problema estás resolviendo realmente. No el problema que el usuario te pidió explícitamente, sino el problema subyacente que está causando fricción. Saber cuándo no escribir código. Cuándo la solución es cambiar un proceso, reorganizar un equipo, o simplemente decir que no. Saber verificar si tu solución funciona. No si compila. No si pasa las pruebas. Si resuelve el problema real para las personas reales que lo tienen. La IA puede escribir el código. No puede hacer ninguna de estas otras cosas. De sintaxis a sistemas Así como alguien aprendiendo Swift hoy no se va a tener que preocupar por el ciclo de retain/release de memoria, y yo no me tuve que preocupar por aprender cómo mover bits entre registros de procesador, la IA lo que está haciendo es elevar la capa de abstracción para que el código, como tal, ya no sea lo importante. Solo que esta vez, la capa de abstracción está más alta que nunca. Completamente fuera del dominio técnico. Ya no se trata de escribir código sintácticamente correcto. Se trata de saber qué problema resolver y cómo verificar que la solución —la que tú diseñaste y la IA implementó— realmente lo resuelve. Esa es una habilidad completamente distinta. Y esa es la habilidad que define a un ingeniero. Si estás navegando esta transición —de escribir código a diseñar sistemas, de ejecutar a decidir qué vale la pena ejecutar— trabajo con personas en tecnología que quieren desarrollar exactamente estas habilidades que la IA no puede abstraer: pensamiento estratégico, arquitectura de soluciones y la capacidad de distinguir entre el problema real y el problema aparente. Agenda una sesión de descubrimiento y platicamos sobre dónde estás y hacia dónde quieres ir.

Ser peor programador por tener la aprovechar la oportunidad de ser mejor ingeniero. Ese es el tradeoff.

La IA te está haciendo peor programador. Y ese es el punto. En un post en el blog de Anthropic comparten los resultados de un estudio que intentaba entender el impacto del uso de IA en la adquisición de habilidades técnicas: En un ensayo controlado aleatorio, examinamos 1) qué tan rápido los desarrolladores de software adquirían una nueva habilidad (en este caso, una biblioteca de Python) con y sin asistencia de IA; y 2) si el uso de IA los hacía menos propensos a entender el código que acababan de escribir. Los resultados: Encontramos que el uso de asistencia de IA condujo a una disminución estadísticamente significativa en el dominio de la habilidad. En un cuestionario que cubría conceptos que habían utilizado apenas unos minutos antes, los participantes del grupo de IA obtuvieron una puntuación 17% más baja que aquellos que programaron a mano, o el equivalente a casi dos grados escolares. El uso de IA aceleró la tarea ligeramente, pero esto no alcanzó el umbral de significancia estadística. Si bien el contexto es el uso de IA, estos resultados no me sorprenden. No por la IA como tal, sino porque esto es exactamente lo que pasa cada vez que una tecnología elimina un problema que antes tenías que resolver manualmente. Not our first rodeo Cuando aprendí a programar en Objective-C por ahí de 2008, antes de ARC , cada vez que creabas un objeto en memoria con [[Object alloc] init], tenías que asegurarte de liberar esa memoria con [object release] al terminar de usarlo. Si no lo hacías, tenías un memory leak . En el mejor de los casos tu app se sentía lenta. En el peor, encontrabas un SEGFAULT y tu app se cerraba inesperadamente. Pero llegó ARC y de repente los que programábamos en iOS ya no teníamos que preocuparnos por cerrar ese ciclo manualmente, porque el sistema lo haría por nosotros. No solamente había que escribir menos código, sino que teníamos una garantía a nivel sistema de que ya no teníamos por qué llevar la cuenta de referencias manualmente. De un día para otro, ya no teníamos que pensar en eso. Claro, aparecieron otros problemas, y no fue el final de los bugs en aplicaciones de iOS, pero ese problema ya no existía. Alguien que decide aprender Swift como su primer lenguaje de programación en 2026 no va a tener que aprender los mismos conceptos de manejo de memoria que yo tuve que aprender hace 20 años; así como yo no tuve que aprender los fundamentales de los registros de procesador que eran vitales cuando ASM era la capa de abstracción más alta que teníamos. Y mira que yo he podido hacer una carrera en software incluso sin saber cómo mover bits de memoria entre registros manualmente. La capa de abstracción Lo que la IA está haciendo para el desarrollo de software es el mismo efecto práctico que los avances en compiladores, tipos de datos y análisis estático de código: al crear una capa de abstracción sobre problemas fundamentales, los programadores pueden dejar de preocuparse de una categoría de problemas por completo. Este proceso no es una anomalía de la IA, sino la continuación de una inercia histórica. Cada gran avance en la computación ha consistido en darnos la oportunidad de “ignorar” una dificultad técnica para permitirnos pensar en problemas más complejos. Pasamos de gestionar manualmente bits en registros a delegar la organización de datos al encapsulamiento de C++. De sufrir por el manejo de memoria a confiar en el Garbage Collector de Java. Y de escribir código de infraestructura a definir solo intenciones en Ruby o JS. Lo que hoy experimentamos con la IA es simplemente el desplazamiento de esa frontera: si antes abstrajimos el hardware y la memoria, hoy estamos abstrayendo la sintaxis misma. El código se está convirtiendo en un detalle de implementación para que el programador pueda enfocarse puramente en la arquitectura y el propósito. Peor programador, mejor ingeniero Aquí está el punto que la mayoría de la gente se pierde cuando ve estos estudios. Ser “peor programador” en el sentido de que ya no puedes escribir un algoritmo de ordenamiento de memoria o que necesitas consultar la sintaxis exacta de un decorador en Python no es un error. Es una funcionalidad. La pregunta nunca ha sido “¿qué tan bien escribes código?”. La pregunta siempre ha sido “¿qué tan bien resuelves problemas?”. Y resolver problemas requiere un conjunto de habilidades completamente distinto: saber qué problema estás resolviendo realmente. No el problema que el usuario te pidió explícitamente, sino el problema subyacente que está causando fricción. Saber cuándo no escribir código. Cuándo la solución es cambiar un proceso, reorganizar un equipo, o simplemente decir que no. Saber verificar si tu solución funciona. No si compila. No si pasa las pruebas. Si resuelve el problema real para las personas reales que lo tienen. La IA puede escribir el código. No puede hacer ninguna de estas otras cosas. De sintaxis a sistemas Así como alguien aprendiendo Swift hoy no se va a tener que preocupar por el ciclo de retain/release de memoria, y yo no me tuve que preocupar por aprender cómo mover bits entre registros de procesador, la IA lo que está haciendo es elevar la capa de abstracción para que el código, como tal, ya no sea lo importante. Solo que esta vez, la capa de abstracción está más alta que nunca. Completamente fuera del dominio técnico. Ya no se trata de escribir código sintácticamente correcto. Se trata de saber qué problema resolver y cómo verificar que la solución —la que tú diseñaste y la IA implementó— realmente lo resuelve. Esa es una habilidad completamente distinta. Y esa es la habilidad que define a un ingeniero. Si estás navegando esta transición —de escribir código a diseñar sistemas, de ejecutar a decidir qué vale la pena ejecutar— trabajo con personas en tecnología que quieren desarrollar exactamente estas habilidades que la IA no puede abstraer: pensamiento estratégico, arquitectura de soluciones y la capacidad de distinguir entre el problema real y el problema aparente. Agenda una sesión de descubrimiento y platicamos sobre dónde estás y hacia dónde quieres ir.

Ser peor programador por tener la aprovechar la oportunidad de ser mejor ingeniero. Ese es el tradeoff.

Lee esto si sientes que tu nuevo manager no vale madre En el mundo del software estamos acostumbrados a resolver problemas complicados: sistemas con muchas piezas móviles, pero predecibles; si sigues el manual y tienes las habilidades técnicas, llegas a donde quieres ir. Desplegar una infraestructura en AWS u optimizar tu query de Postgres. En un sistema complejo, las variables interactúan de formas que no puedes predecir simplemente leyendo un manual. Aquí es donde tu capacidad de escribir código limpio deja de ser el factor determinante. Como he mencionado en artículos previos, muchos crecimos con el hábito de resolver todo solos porque así funcionaba antes . Sin satanizar: a final de cuentas, nuestro cerebro ha evolucionado para hacer más de las cosas que funcionan y menos de las que no. Y si tenemos evidencia de que comportarnos de X o Y manera funciona, es normal que por default sigamos haciendo eso. Y funciona, hasta que ya no. Diseñar tu carrera profesional es un problema complejo porque tienes que considerar un chingo de variables que en sí mismas son complejas y poco determinísticas. La dimensión humana, cultural, geográfica, histórica. La más pequeña variación hacia un extremo u otro en cualquiera de ellas afecta el ecosistema de una manera que no podemos predecir. Pero sí anticipar. Te toca chambearle para construir la relación que quieres Extrañas a tu manager anterior con el que todo era fácil. Sentías que te entendía, que te cuidaba, que te procuraba. Y ahora, tu nuevo manager nada más te pide estatus, o nomás te busca para cagotearte, y no hay ese sentimiento de que están chambeando juntos, o de que tiene tus intereses en mente. La diferencia entre estos dos no es necesariamente que uno sea mejor que el otro, sino que el primero estaba haciendo todo el trabajo de crear la relación por los dos. Él se encargaba de leerte, de preguntarte cómo estabas, de traducir la empresa para ti. Con el nuevo te das cuenta de que no tienes una relación per se , sino una serie de transacciones que tienes que navegar constantemente. ¿Quieres los beneficios de una relación? Pues, como en cualquier otra relación en tu vida: tienes que dedicarle tiempo y esfuerzo. Toca chambearle. No puedes esperar que el entendimiento mutuo caiga del cielo. Si no hay una relación y tú sabes que la necesitas, vas a tener que tomar la iniciativa. Tienes que ser consciente de qué idioma hablan las personas a tu alrededor, tanto tu manager como tu equipo (¿importa más la eficiencia o jerarquía?) y empezar a comunicarte en sus términos. Como he escrito antes, la madurez profesional consiste en dejar de esperar que la empresa se adapte a ti y empezar a hackear el sistema desde adentro. Si sabes que tu equipo obtiene confianza a través de las relaciones y tú te reconoces como un juegasolo por naturaleza, “saber jugar el juego” significa forzarte a dar más contexto, a preguntar cómo estuvo el fin de semana, a compartir un poco de ti. No porque tengas que cambiar tu forma de ser, sino porque entiendes que eso va a hacer tu chamba más sencilla a largo plazo, y te va a desbloquear oportunidades de crecimiento que ni te imaginas. Hace sentido, pero seguro te estás preguntando: ¿cómo sé cuáles son las palancas que puedo mover? Un mapa cultural En The Culture Map , un libro que me hubiera gustado leer mucho antes en mi carrera, Erin Meyer argumenta que existen dimensiones invisibles que dictan cómo trabajamos intra e interculturalmente: Comunicación Feedback Liderazgo Decisiones Confianza Desacuerdos Tiempo Influencia Algunos ejemplos: Comunicación: Bajo Contexto vs. Alto Contexto: Como mexicanos, estamos cableados para el alto contexto . Nos fijamos en el gesto, en la pausa, en quién más está en la oficina cuando alguien dice algo. “Me dijo que sí, pero lo pensó”, decimos. Para nosotros, el mensaje está en el entorno. Pero si trabajas con un equipo en Estados Unidos o Alemania, ellos son de bajo contexto . Lo que se dice es lo que es. No hay segundas lecturas. Si asumes que ellos “deberían entender” tu sarcasmo o tu sutil inconformidad, te vas a quedar esperando una respuesta que nunca llegará. Feedback: Directo vs. Indirecto: Este es el punto donde más sangre corre. Imagina a un manager austríaco revisando tu pull request. Se sienta frente a ti y te dice: “¿Por qué me entregas esto si no es lo que te pedí?”. Para un latino, eso se siente como una jalón de greñas. Casi quieres llorar porque sientes que te están diciendo que no vales madre. Pero para él, es simplemente feedback . No hay un componente emocional; es eficiencia pura. En su cultura, no decirte la verdad de frente sería una falta de respeto hacia tu profesionalismo. En la nuestra, suavizamos el golpe para no herir susceptibilidades, lo cual a menudo termina en una falta de claridad absoluta. Confianza: Relaciones vs. Tareas: “Si saliendo de aquí nos vamos por una chela, voy a confiar más en tu código”. Este es el estándar en México y gran parte de Latam. Necesitamos el vínculo humano para trabajar a gusto. Otras culturas simplemente dicen “confío en ti porque entregas a tiempo y tu código no rompe producción”. Punto. No voy a dar ejemplos para todas las dimensiones, pero con esto te das una idea: hay muchas muchas formas en las que puedes entender el comportamiento de las personas con las que trabajas. Y es tu responsabilidad desarrollar ese lenguaje si mantenerte vigente en el mercado laboral es algo que suena atractivo para ti. Cómprate y lee The Culture Map a la de ya. Aprovechando el cagadero El caos organizacional, los cambios de prioridades de un día para otro y los managers que nada más te preguntan cómo vas son, en realidad, una mina de oro. En un ambiente perfecto, con procesos claros y cultura impecable, no creces; solo sigues rieles, y a huevo que hay un momento para eso. Pero en el cagadero es donde aprendes a ser un líder de verdad. Es donde desarrollas la capacidad de leer entre líneas, de negociar con personas que piensan radicalmente diferente a ti y de mantener la cordura cuando todo está valiendo madre. Te lo juro, la solución no es cambiar de empresa: probablemente te encuentres con problemas similares bajo nombres distintos. La solución es enfrentar este problema con autocompasión curiosa. Mira a tu alrededor con curiosidad, no con juicio. “Ah, mira, Fulanito reacciona mejor al feedback directo”. “Ah, mi manager necesita que yo tome la iniciativa en la relación porque él no sabe cómo”. Una vez que eres consciente del lenguaje que realmente tiene una influencia en tu crecimiento profesional, puedes empezar a mover los hilos a tu favor. No va a ser fácil. No va a pasar de un día para otro. Pero nada que valga la pena en esta carrera sucede sin un poco de fricción. Educa tu mirada, entiende a los humanos detrás del código, y te prometo que tu chamba se va a empezar a ver mucho más como un campo de entrenamiento de alto nivel. Si quieres dejar de ser víctima de tu entorno y empezar a navegar tu carrera con astucia estratégica, agenda una sesión de coaching conmigo . Vamos a desenmarañar la complejidad juntos.

¿Quieres los beneficios de una relación? Pues, como en cualquier otra relación en tu vida: tienes que dedicarle tiempo y esfuerzo. Toca chambearle.

Las relaciones entre personas muchas veces se basan en “vibras”. En la chamba, no siempre te puedes dar ese lujo. Rishichandra Wawhal en su blog : Cada vez que he tenido rupturas en amistades, relaciones o cuando las situaciones familiares se pusieron mal, he hecho todo lo posible por razonar con la otra parte. Casi nunca funciona. Explicaciones. Justificaciones. Tratar de que las cosas tengan sentido. Pero adivinen qué, las conexiones humanas no tienen mucho sentido. Las guerras emocionales no se pueden pelear con armas de razón. Razonar es una gran utilidad, pero las relaciones humanas son mucho más que lógica. No estoy añadiendo ningún significado sobrenatural o metafísico a esto; es simplemente que, como civilización, no hemos descifrado por completo las ciencias de la intuición, la presencia, la energía humana, o como quieras llamar a esa capa subyacente. En las relaciones personales, a menudo simplemente lo captas. Sientes cuando alguien quiere algo, cuando existe alineación y cuando no. No hay mucha necesidad de un razonamiento intencional. Pero cuando se trata de la chamba, no siempre te puedes dar el lujo de dejar las cosas inconclusas cuando el feedback que te están dando no se siente bien: Cuando haya un conflicto, siempre razona. No justifiques ni ataques. El principio fundamental es entender primero de qué se trata realmente la retroalimentación. Podría estar equivocada, claro, pero viene de algún lugar. Una preocupación, una limitación, un miedo, una inseguridad, un modelo mental diferente; todas estas razones son completamente válidas. Tiene sentido entender eso antes de reaccionar e incluso reconocerlo en algunos casos. Aunque no estés de acuerdo, profundizar al preguntar más sobre su duda y recopilar retroalimentación ayuda. Siempre es mejor razonar que justificar o defender. Nos guste o no, las dinámicas de oficina involucran propiedad y apalancamiento. La propiedad, las relaciones y la percepción importan. En el momento en que te justificas o te defiendes emocionalmente, pierdes el apalancamiento. Vuelves la discusión hacia adentro. La haces sobre ti mismo. Razonar la mantiene enfocada en el objetivo, en el trabajo. Mantiene las cosas profesionales. Te digo, que para ser mejor en tu trabajo, te tiene que valer tantita madre : Ser dispassionate es poder sentarte a mirar tu vida profesional sin filtro romántico. Ver tu empresa, tu rol, tu proyecto, tu “sueño”, tal como está hoy, no como te lo prometieron en el onboarding ni como lo imaginaste cuando tenías veinte años. Es poder decir: “Esto me importa un chingo, pero aun así ya no hace sentido seguir aquí”. La pasión grita: “No puedes dejar esto, es parte de quién eres”. La frialdad te deja hacer preguntas incómodas: ¿esto sigue teniendo sentido? ¿El costo que estoy pagando vale lo que estoy recibiendo de vuelta? Si hoy tuviera que elegir esto desde cero, sabiendo lo que sé, ¿lo elegiría otra vez? Cuando estás demasiado apasionado, te casas con ideas malas solo porque eran tuyas. Confundes lealtad con sacrificio infinito. Sigues invirtiendo tiempo en algo que ya está muerto porque te aterra ser “el que se rindió”. Te convences de que aguantar es virtud, incluso cuando lo único que estás defendiendo es la historia que tú mismo te contaste en tu cabeza, pero que realmente no existe ni le importa a las personas a tu alrededor. Cuando te permites ser un poco más dispassionate , pasan otras cosas. Matas proyectos a tiempo en lugar de esperar a que se derrumben solos. Cambias de empresa sin tener que convertir a nadie en el villano de la historia. Puedes recibir feedback duro sin salir con el ego herido. Te vuelves capaz de decir “ya no” aunque todavía te guste. Aunque todavía te duela.

Te digo, que para ser mejor en tu trabajo, te tiene que valer tantita madre.

Claude no incluirá anuncios Anthropic, en su blog Claude is a space to think , dice que no van a incluir anuncios como parte de Claude, citando principalmente la estructura de los incentivos: Ser genuinamente útil es uno de los principios fundamentales de la Constitución de Claude , el documento que describe nuestra visión del carácter de Claude y guía cómo entrenamos el modelo. Un modelo de negocio basado en publicidad introduciría incentivos que podrían ir en contra de este principio. Considera un ejemplo concreto. Un usuario menciona que tiene problemas para dormir. Un asistente sin incentivos publicitarios exploraría las diversas causas potenciales—estrés, ambiente, hábitos, etc.—basándose en lo que podría ser más revelador para el usuario. Un asistente con soporte publicitario tiene una consideración adicional: si la conversación presenta una oportunidad para hacer una transacción. Estos objetivos pueden alinearse frecuentemente—pero no siempre. Y, a diferencia de una lista de resultados de búsqueda, los anuncios que influyen en las respuestas de un modelo pueden dificultar saber si una recomendación dada viene con un motivo comercial o no. Los usuarios no deberían tener que dudar si una IA realmente los está ayudando o sutilmente dirigiendo la conversación hacia algo monetizable. Incluso los anuncios que no influyen directamente en las respuestas de un modelo de IA y en su lugar aparecen por separado dentro de la ventana de chat comprometerían lo que queremos que Claude sea: un espacio claro para pensar y trabajar. Tales anuncios también introducirían un incentivo para optimizar el engagement—la cantidad de tiempo que las personas pasan usando Claude y qué tan seguido regresan. Estas métricas no están necesariamente alineadas con ser genuinamente útil. La interacción de IA más útil podría ser una corta, o una que resuelva la solicitud del usuario sin provocar más conversación. Reconocemos que no todas las implementaciones de publicidad son equivalentes. Enfoques más transparentes o de opt-in—donde los usuarios explícitamente eligen ver contenido patrocinado—podrían evitar algunas de las preocupaciones mencionadas anteriormente. Pero la historia de los productos con soporte publicitario sugiere que los incentivos publicitarios, una vez introducidos, tienden a expandirse con el tiempo conforme se integran en los objetivos de ingresos y desarrollo de producto, difuminando límites que alguna vez fueron más claros. Hemos elegido no introducir estas dinámicas en Claude. 100 %. Puede que algo te importe mucho. Igual no lo vas a priorizar si no tienes los incentivos adecuados.

Puede que algo te importe mucho. Igual no lo vas a priorizar si no tienes los incentivos adecuados.

Por qué algunas de las editoriales más importantes contratan ingenieros de IA Rashi Shrivastava en Forbes.com : Los autores detestan la IA. Eso es evidente en las docenas de demandas que han presentado contra empresas de IA por supuestamente entrenar sus modelos con millones de libros protegidos por derechos de autor sin consentimiento ni compensación. Pero resulta que sus editoriales no están tan en contra. Algunas de las editoriales más grandes del país, incluyendo Penguin Random House, Macmillan, Sourcebooks y Wiley están reclutando ingenieros de IA, según listados de empleo públicos revisados por Forbes. Ninguna de ellas planea usar IA para editar o escribir, al menos por ahora. En cambio, los listados de empleo revelan que las editoriales buscan adoptar IA para operar sus negocios de manera más inteligente, como construir modelos de pronóstico que puedan ayudar a predecir qué libros tendrán buen desempeño y cómo deberían ser valorados. Negocio es negocio. Lee también Por qué los “libros de negocios” más populares están plagados de ideas aspiracionales, poco realistas y nada aplicables .

Negocio es negocio.

Probando Claude como mi LLM principal Acabo de pagar una licencia Pro de Claude. También bajé la app para la Mac, y aunque no parece ser una app nativa, hace lo que me importa : tiene un shortcut para interactuar con la app desde cualquier punto de la computadora (doble ⌥). Una forma en la que estoy probando LLMs es también a través del API, no nada más de las aplicaciones de chat para otras tareas que estoy automatizando poco a poco. En este video , Amanda Askell, la filósofa parte del equipo de Anthropic, y encargada de crear el “soul document” de Claude explica la forma en que Claude fue entrenado para comportarse como lo hace. Fascinante.

Acabo de pagar una licencia Pro de Claude.

Guía avanzada de prompts para ingeniería de software asistida por IA Justin Reock, en el blog de DX: En 2025, vimos a los líderes de ingeniería enfocarse en el despliegue de asistentes de codificación con IA a escala en sus organizaciones. A medida que estas herramientas se volvieron más utilizadas, quedó claro que los resultados dependían menos de tener acceso a la IA y más de cómo se educaba y habilitaba a los equipos. En respuesta, DX publicó la Guía para la Ingeniería Asistida por IA , delineando las mejores prácticas y casos de uso de prompting de alto valor para ayudar a los equipos de ingeniería a usar la IA de manera efectiva en su trabajo diario. Ahora, a medida que las organizaciones avanzan más allá de los pilotos, el enfoque ha pasado de la adopción y habilitación hacia mejoras operativas y casos de uso más complejos. Aplicar con éxito la IA en estos contextos requiere prácticas de prompting más estructuradas que las utilizadas durante la experimentación temprana. Para apoyar ese siguiente paso, hemos creado nuestro primer suplemento de la guía original: Guía de Prompting Avanzado para Ingeniería con IA. Esta nueva guía sigue el mismo formato que la original, con escenarios claros de qué hacer y qué no hacer, ejemplos completos de prompts y ejemplos de salida de código. Es agnóstica al proveedor, con un énfasis en la estructura del prompt, las restricciones y el contexto para que las técnicas puedan aplicarse a través de diversas herramientas y arquitecturas. Ya la descargué y la comencé a distribuir en la chamba con mis equipos. Pero también la subí a mi Drive . Me gusta la idea de que, sin querer queriendo, estamos aprendiendo a escribir mejor.

Me gusta la idea de que, sin querer queriendo, estamos aprendiendo a escribir mejor.

Ring habilita el buscador de mascota perdidas para todos Terrence O’Brien en The Verge : Ring está abriendo su servicio de búsqueda de mascotas Search Party a personas que no son propietarios de dispositivos Ring a través de la aplicación gratuita Ring Neighbors. El servicio ha ayudado a reunir a dueños con “más de un perro perdido al día” desde su lanzamiento, según la empresa. Cualquier persona en los EE. UU. puede compartir una foto de su mascota desaparecida después de descargar y registrarse en la aplicación. Si la cámara Ring habilitada con IA de un vecino detecta al animal perdido, podrá alertar al dueño de la mascota. Ring también se compromete a donar $1 millón para equipar refugios de animales en todo el país con sistemas de cámaras. Me mama cuando la tecnología se usa para hacer el bien.

Me mama cuando la tecnología se usa para hacer el bien.

Liderazgo es la capacidad de influenciar sin título Ibrahim Diallo en su blog comparte una experiencia enseñándole a un vecino, a la mala, que tenía que bajarle el volumen a su televisión. La historia es por ahí del 2007, y comienza cuando Ibrahim y su vecino contrataron Dish casi al mismo tiempo y recibieron un nuevo control: Una noche, cuando todos dormían y el vecino estaba viendo un programa de televisión a todo volumen, decidí diagnosticar el problema. En el momento en que presioné el botón de encendido en el control remoto de radiofrecuencia, mi televisor y el decodificador se encendieron, y la televisión del vecino quedó en silencio. “¡Mierda!”, escuché que alguien dijo. Estaba confundido. ¿Acababa de hacer eso yo? La televisión se volvió a encender, el volumen subió. Caminé hacia la ventana armado con el remoto. Conté hasta tres y luego presioné el botón de encendido. La televisión de mi vecino se quedó en silencio. Él gruñó. Cada vez que encendía la televisión, yo presionaba el botón de encendido de nuevo y su dispositivo se apagaba. Bueno, ¿quién lo diría? Teníamos interferencia de alguna manera. Nuestros controles remotos estaban configurados para operar en la misma frecuencia. Cada control remoto controlaba ambos dispositivos. Ibrahim intentó hablar con su vecino para explicarle la situación, pero le cerró la puerta en la cara. Así que decidió enseñarle con un principio de psicología básico que el volumen de su televisión no debía pasar de cierto nivel: Cada vez que subía el volumen, yo simplemente apagaba su dispositivo. Escuchaba su frustración y sus intentos por resolver el problema. Como un entrenador de animales de circo, me mantuve constante. Si el volumen de su televisión subía por encima de lo que imaginaba eran 15 o 20, presionaba el botón de encendido. Se convirtió en una rutina para mí durante semanas. Algunas noches fueron difíciles; mantenía el control remoto bajo mi almohada, luchando contra mi terco vecino toda la noche. Un día, noté que no había presionado el botón en días. Abrí la ventana y todavía podía escuchar el sonido tenue de su televisión. A través de prueba y error, aprendió la lección. Si el volumen permanecía por debajo de mi umbral arbitrario, la televisión seguía encendida. Pero tan pronto como pasaba ese umbral, el dispositivo se apagaba. Es el mismo principio del que hablé en El caso del tech lead que no pone límites y se lleva a su equipo entre las patas : 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. Liderazgo es la capacidad de influenciar sin título. Tal vez tu tech lead tiene más rango, pero eso no significa que no puedas influenciar su comportamiento usando principios básicos de psicología y comportamiento.

Tal vez tu tech lead tiene más rango, pero eso no significa que no puedas influenciar su comportamiento usando principios básicos de psicología y comportamiento.

Es más fácil ser “el que pudo haberlo hecho” que “el que intentó y falló” Yakko Majuri : Hubo una reflexión interesante que surgió en una discusión entre mi novia y yo unos meses antes que me di cuenta que se aplicaba a mí, pero a la inversa. Es mucho más cómodo ser la persona que “podría ser X” que ser la persona que realmente intenta hacerlo. Estábamos hablando de esto con respecto a personas que tienen un talento innato claro para algo como la música o los deportes, pero que no practican en absoluto. Todo el mundo dice cosas como “serías el mejor en esto si tan solo practicaras más”, pero luego nunca lo hacen. El punto es: es mucho más fácil vivir tu vida pensando que podrías haber hecho X si hubieras querido, que “decepcionar” a las personas que creyeron en ti al intentarlo y fracasar. Siempre puedes apoyarte en esta idea en tu cabeza de lo que podrías haber sido, y en cómo todos creían en ti, así que debe ser cierto, pero simplemente elegiste no seguir ese camino.

Es más fácil ser “el que pudo haberlo hecho” que “el que intentó y falló”

OpenAI lanza una aplicación Codex para macOS, diseñada para servir como centro de comando para administrar agentes de IA, y dice que el uso de Codex casi se ha duplicado desde mediados de diciembre David Gewirtz en ZDNET : OpenAI anunció hoy una nueva aplicación para Mac dedicada a trabajar con su agente de programación de IA, Codex . Esta es diferente de la aplicación de propósito general ChatGPT que OpenAI ha estado distribuyendo desde hace tiempo. La nueva aplicación de programación pretende ser una especie de centro de comando, no solo para dirigir agentes de programación, sino también para gestionar múltiples agentes a través de proyectos y tareas que se ejecutan durante largos periodos de tiempo. Tal vez Claude Opus 4.5 sea un mejor modelo para generar código, pero OpenAI tiene un mindset de desarrollo de producto más fino. Hace unos días escribí sobre la importancia de que usar una herramienta sea algo 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. Todavía no pruebo la app de Codex, pero mi apuesta es que si es suficientemente buena, va a hacer que pronto ChatGPT se posicione como el modelo más usado para tareas de programación — principalmente entre personas que no tienen background de desarrollo de software.

No siempre gana el modelo más potente, sino el que mejor se integra en tu flujo de trabajo.

Microsoft le está pidiendo a sus empleados — incluso los que no son desarrolladores — que usen Claude Code Tom Warren en The Verge: Los desarrolladores han estado comparando las fortalezas y debilidades de Claude Code de Anthropic, Cursor de Anysphere y GitHub Copilot de Microsoft durante meses, buscando un ganador. Si bien ninguna herramienta individual de IA para programar logra ser la mejor en cada tarea que los desarrolladores de software realizan a diario, Claude Code está posicionándose cada vez más en la cima por su facilidad de uso, tanto para desarrolladores como para usuarios no técnicos. Parece que Microsoft está de acuerdo, ya que diversas fuentes me indican que la empresa ahora está animando a miles de sus empleados de algunos de sus equipos más prolíficos a adoptar Claude Code y empezar a programar, incluso si no son desarrolladores. Incluso se está alentando a los empleados sin experiencia en programación a experimentar con Claude Code, para permitir que los diseñadores y gerentes de proyecto realicen prototipos de ideas. Microsoft también ha aprobado el uso de Claude Code en todo su código y repositorios para sus equipos de Copilot para Negocios e Industria. Hace cinco años, los desarrolladores de software se podían dar el lujo de ponerse tercos y quejarse de las ideas “absurdas” de sus diseñadores y PMs, a quienes no les quedaba de otra que intentar quedar bien con los que sabíamos de código para que les hiciéramos sus prototipos. En 2026, Claude Code va a permitirles tener el prototipo en producción muchísimo más rápido, sin decirles que sus ideas son tontas y sin refunfuñar — y por una fracción del sueldo de un desarrollador.

En 2026, Claude Code va a permitirles a los PMs y diseñadores tener prototipos en producción muchísimo más rápido, sin decirles que sus ideas son tontas y sin refunfuñar — y por una fracción del sueldo de un desarrollador.

Obligaciones fantasma Terry Godier : Hay un tipo particular de culpa que me visita cuando abro mi lector de feeds después de unos días de ausencia. No es exactamente la culpa de haber hecho algo malo. Es más como la sensación de entrar en una habitación donde la gente te ha estado esperando, excepto que cuando miras a tu alrededor, la habitación está vacía. No hay nadie allí. Nunca hubo nadie. He estado pensando en este sentimiento durante mucho tiempo. Más de lo que probablemente debería, dado que se trata de algo tan mundano como leer artículos en internet. Pero he llegado a creer que estas pequeñas experiencias repetidas nos moldean más de lo que nos gusta admitir. Me encantan estos artículos que ahondan en el efecto de la tecnología en la percepción que tenemos sobre el mundo a nuestro alrededor. El conteo de correos no leídos significa algo específico: son mensajes de personas reales que te escribieron y, en algunos casos, están esperando activamente tu respuesta. El número no es información neutral. Es una medida de deuda social. Pero cuando aplicamos ese mismo lenguaje visual al RSS (los conteos de no leídos, el texto en negrita para los elementos nuevos, la sensación de una acumulación de tareas pendientes), importamos la ansiedad sin la causa. Nadie está esperando. La paradoja: solo podemos usar el lenguaje que conocemos para nombrar las cosas que inventamos, aunque las analogías no apliquen al 100 %. Inventamos vías de escape que se convirtieron en nuevas trampas. Las apps para leer después prometieron alivio: guarda esto, huye de la obligación de leerlo ahora. Pero la aplicación creó una nueva cola, un nuevo conteo, una nueva obligación. No eliminaste al fantasma. Lo moviste. Los podcasts tomaron prestada la cola de reproducción de los reproductores de música. Pero nadie se sintió nunca culpable por los álbumes no reproducidos. “No he escuchado todos mis discos” no es una confesión. Las aplicaciones de podcasts añadieron conteos de episodios no escuchados, barras de progreso, estadísticas de finalización. Tu escucha se convirtió en una lista de tareas. Y quizás los generadores de fantasmas más puros de todos: las aplicaciones de tareas. Anotas algo que quieres hacer. Una aspiración. Una esperanza. La aplicación lo cuenta como deuda. Lo que querías hacer se convierte en lo que debes hacer. El patrón es claro una vez que lo ves. Cada generación tomó prestado el lenguaje visual de contextos donde la obligación era real, y luego lo aplicó a contextos donde no lo era. Bandeja de entrada (real) → Correo electrónico (mayormente real) → RSS (fantasma) → Todo (fantasma) Hemos estado lavando la obligación. Cada interfaz hereda legitimidad de la anterior, pero el contrato social debajo se va vaciando. El punto rojo en un juego tiene el mismo peso visual que un mensaje de tu hijo. Mantuvimos el peso y dejamos caer la razón. Tenemos que ser menos duros con nosotros mismos: Deberíamos notar cuándo nos sentimos culpables y luego preguntarnos si la culpa es nuestra o si la heredamos de algún lugar. Deberíamos recordar que casi todo sobre cómo se ve y se siente el software es una elección que alguien tomó, a menudo rápidamente, a menudo por razones prácticas que pueden ya no aplicar. Y cuando nos sentemos con nuestros teléfonos o nuestras computadoras, confrontados por todos esos pequeños números diciéndonos cuán atrasados estamos, deberíamos sentirnos libres de hacer la única pregunta que realmente importa: ¿Realmente hay alguien esperando?

"Mantuvimos el peso y dejamos caer la razón"

“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.”

Chamba relacionada con desarrollo de software sí va a haber, y mucha. Chamba de programador, ya no tanto.

Muéstrame los incentivos, y te mostraré los resultados.

No porque seas descuidado, sino porque entiendes que todo se trata de un tradeoff.

La que sigue es la de “Sé Prepararme Solo el Desayuno”

Liderazgo efectivo no es apagar incendios, es evitar que empiecen.

El software se está convirtiendo en commodity. El valor ya no está donde creías.

Más evidencia de que la gente paga por que les resuelvan un problema, no por que les escriban código.