Retomamos hoy un tema que quedó pendiente hace unos meses, cuando comentábamos que con la IA iríamos a hombros de gigantes pero que eso nos tendría que obligar a repensar cuál es nuestro papel, no tanto en términos de «el humano en el bucle» como en términos de ganarnos la vida pura y dura: ¿qué puedo hacer que sea algo por lo que otros estén dispuestos a pagarme?
Al hilo de esto siempre recuerdo a Tim Harford y su Economista camuflado. Si no lo han leído, es un libro de esos que abren la mente, sobre todo si sois de formación (o deformación, según se mire) técnica. Ha envejecido bien, sobre todo comparado con otras obras clásicas como Padre rico, padre pobre.
Los costes de oportunidad y la ventaja comparativa
En The Undercover Economist, Tim Harford recurre a una aparente paradoja para explicar la teoría del coste de oportunidad de David Ricardo en la cual a una persona se le da muy bien escribir libros de biología pero puede ganar muchísimo más dinero escribiendo libros de economía, de modo que no le merece la pena escribir el primero, aunque se le dé bien, porque el tiempo invertido le rinde mucho más escribiendo el segundo. No importa si sabe de biología y puede escribir un libro de texto suficientemente bueno; el mercado y el sentido común le animan a escribir libros de economía.
Llevamos un par de años atrapados en una discusión equivocada en la industria del software. El debate dominante sigue anclado en la ventaja absoluta: «¿Escribe el modelo mejor código que un senior?», «¿Genera bugs sutiles?», «¿Me sustituirá un agente en dos años?».
Al plantear la cuestión en términos de ventaja absoluta, caemos en dos reacciones igualmente estériles: el cinismo del artesano que se niega a usar herramientas porque «el código generado es mediocre» y ridiculiza lo que la herramienta posibilita (el chiste sobre localhost del que hablamos en Deja de mirar el código), o la sumisión del optimizador que acepta cualquier ayuda agéntica para inflar métricas de commits y velocidad aparente.
Ambas posturas ignoran la lección básica que explica Harford y de la que hemos hablado: la clave está en entender tu coste de oportunidad, ¿qué estás dejando de hacer, que aporta más valor relativo, por estar horas enfocado en hacer lo que la máquina hace realmente rápido y, por tanto, a bajo coste por unidad (¿Story?) producida?
La caída del coste marginal de la sintaxis
Escribir código ha dejado de ser una actividad escasa. Traducir una intención mental a instrucciones sintácticamente válidas para la computadora, levantar el andamiaje de un microservicio para servir un par de CRUDs, escribir tests unitarios estándar o migrar un modelo de datos son tareas que tienen ahora un coste marginal de producción que, sin ser cero (los tokens aún hay que pagarlos), ha bajado muchísimo en tres años.
Sabemos también que cuando un bien complementario se abarata de forma radical, los bienes que lo rodean multiplican su valor de inmediato:
- Del tecleo al diseño: Modularizar, fijar contratos limpios entre servicios y establecer invariantes de dominio son tareas donde el criterio humano no es prescindible. Es el prerrequisito para que la propia generación de código tenga sentido, y la parte del oficio que con mayor solvencia pasa el test de PACO del que hablábamos en el post anterior.
- De la solución al problema: Cuando implementar una funcionalidad es rápido, definir bien lo que queremos es imprescindible para no terminar implementando algo inútil. Entender el problema real del usuario al que se quiere servir, diseñar bien lo que hace falta, ponerlo todo en el marco de las premisas del negocio y, más que nunca, racionalizar el backlog con el sentido crítico suficiente para decir «esto no lo vamos a hacer».
- Auditoría forense y propiedad operativa: El código quizá lo hace tu agente, pero al final de la cadena, cuando algo se tuerza en producción, la responsabilidad va a caer en alguien, no en algo; siquiera en alguien que lo que haga sea orquestar agentes. Esa responsabilidad sobre un sistema en producción va a seguir siendo profesional y humana.
La colisión con la realidad organizativa
Todo lo anterior suena muy bien en el vacío. Pero, como nos enseñó von Moltke, ningún plan sobrevive al contacto con el enemigo, y aquí el enemigo es el organigrama. La ventaja comparativa es la misma para todos; lo que cambia es dónde se te pide que la apliques según tu silla.
Si programas: ahora eres las riendas
Tu valor ya no está en rellenar el archivo en blanco. Está en cortar. En saber decir “esto no lo hacemos” mientras el harness te propone, con paciencia infinita, otra tarea y otro corner case, terminando cada implementación con un “¿quieres que continuemos con…?”.
Tienen ese sesgo igual que el algoritmo de YouTube te sugiere un vídeo más para mantenerte ahí, tu agente te sugiere un paso más para que sigas gastando tokens. Cualquier chatbot, incluso el más básico, te da la respuesta que le pides y un par de preguntas al final, para que no te vayas. Y volvemos, por inercia, como en el doomscroll. Antonio Ortiz lo llamó el Ozempic de la atención, y no puedo mejorarlo.
El resto de tu ventaja está en lo que la máquina no firma: fijar contratos limpios entre servicios, entender el problema real del usuario y responder cuando algo se rompa en producción. Porque alguien tendrá que responder, y no será el agente.
Si gestionas: vas más rápido hacia una cola
Aquí está el problema que casi nadie quiere mirar: implementamos más rápido y el cliente no lo nota.
El tiempo que antes se iba en programar se va ahora en esperar. A que alguien revise, a que alguien apruebe, a que alguien despliegue. Es Conway en estado puro: el organigrama se está tragando el aumento de productividad. Según el último informe de Atlassian State of Product 2027, un 80% de los equipos termina antes y los clientes no reciben las mejoras antes. No shit, Sherlock.
Párrafo aparte, porque esto es un momento Yo ya lo dije de manual. Me he ganado el párrafo aparte. En muchos casos, la organización se está tragando el incremento de productividad.
En términos económicos es peor que antes. Si ya teníamos N funcionalidades terminadas esperando en el limbo, y ahora producimos tres veces más rápido (me quedo corto a propósito), sin cambios de gobernanza solo estamos multiplicando el inventario sin entregar. Capital invertido que todavía no rinde nada. Si además tu empresa está apalancada, que es lo normal, quizá esté sobrefinanciada por culpa de esa ineficiencia. Si tu organización se resiste al cambio, igual no es mala idea que tu CFO lea este post. Ahí lo dejo.
Y apretar a la gente para tener algo antes del viernes, en lugar de repensar cómo se entrega, tiene un coste de oportunidad brutal. Una vez más, Harford. O Ricardo, como gusten.
Si diriges: más software exige más filtro
Cuando producir software es barato, se produce más, como dice la paradoja de Jevons: la eficiencia no reduce el consumo, lo dispara. No vamos a tener menos software, vamos a tener más del que jamás habíamos soñado.
Tu ventaja comparativa, entonces, es de filtro y de sistema: frenar iniciativas marginales, romper los silos que anulan cualquier ganancia y medir el impacto por resultados de negocio, no por volumen de commits.
Criterio über sintaxis
David Ricardo no pretendía que nuestro economista despreciase la biología. Simplemente señalaba que la asignación de nuestras horas de vigilia depende de entender qué es irreemplazable y qué es prescindible.
En el software de hoy, la sintaxis ha dejado de ser lo escaso. Quienes insistan en competir en velocidad contra modelos estadísticos estarán librando una batalla perdida por la ventaja absoluta. Nadie compite por levantar más kilos que la grúa, ¿verdad? Pues eso.
El trabajo, ahora más que nunca, consiste en ser el garante del sistema: entender el contexto, define las reglas del juego y responder cuando falla. Todo lo demás es, sencillamente, teclear.
