Estaba viendo la entrevista a Jensen Huang desde mi oficina en Hong Kong hace dos días, tomando un café tibio a las 11 PM, cuando soltó esa frase: *"La IA no está causando despidos. Los ejecutivos poco imaginativos sí."*
Pausé el video. Quería aplaudir.
Él tiene razón técnicamente. Si le das a un equipo una herramienta de productividad 10x, un líder creativo expande la producción 10x, no despide al 90% del equipo. Pero Huang estaba en un escenario en Santa Clara, mirando al mundo a través de la lente de un visionario que crea demanda de la nada. Para aquellos de nosotros en las trincheras—dirigiendo empresas, gestionando equipos de producto, pagando alquiler en Tokio y Hong Kong—su consejo se sentía como decirle a una persona que se ahoga que nade más fuerte sin reconocer que la piscina se está vaciando.
Aquí está la incómoda verdad que explica por qué tantas personas brillantes están actualizando actualmente su LinkedIn a "Abierto a Oportunidades": Sin mencionar el trabajo absurdo.La mayoría de los trabajos no son realmente trabajos. Son servicios de traducción.
Y la traducción es exactamente lo que la IA acaba de aprender a hacer de forma gratuita.
Las Tres Capas de Realmente Útil
Si quitas los títulos y el teatro de LinkedIn, solo hay tres tipos de trabajo que crean valor:
Capa 1: Creando la Demanda
Este es el momento de Steve Jobs: sosteniendo un rectángulo de vidrio en 2007 y convenciendo a la gente de que lo quiere antes de que sepa que existe. Esto requiere una combinación aterradora de intuición y tolerancia al riesgo. No estás resolviendo un problema declarado; estás inventando la categoría. Quizás el 0.1% de las personas puede hacer esto de manera consistente sin destruirse a sí mismas.
Capa 2: Definiendo el Requisito
Aquí es donde realmente está el dinero en este momento. Una vez que alguien quiere el iPhone, tienes que definir: ¿Qué hace realmente? ¿Cuál es la especificación de la batería? ¿Qué características están en la V1 frente a la V2? ¿Cómo medimos el éxito?
Esta es la capa del Arquitecto. No estás ejecutando el plano; lo estás dibujando. Estás mirando la ambigüedad (dolor del cliente, brechas en el mercado, restricciones técnicas) y cristalizándola en problemas específicos y solucionables.
Capa 3: Cumpliendo el Requisito
Aquí es donde el 85% de nosotros pasamos nuestras carreras. La capa "Traductor".
El ingeniero de software que toma el ticket de Jira ("Construir página de inicio de sesión") y lo traduce en componentes de React. El abogado que toma la disputa ("El cliente quiere demandar por incumplimiento") y la traduce en documentos legales. El gerente de marketing que toma la directiva ("Aumentar los leads del tercer trimestre") y la traduce en mecánicas de campaña.
Si tu trabajo requiere esperar a que alguien te entregue un requisito bien definido, y luego usar tu habilidad especializada para convertir ese requisito en un resultado—eres un traductor. Y GPT-4 es un traductor que no duerme, no negocia salario y no necesita seguro de salud.
Cómo dejar de ser un traductor (y volverse útil)
No entendí esta distinción hasta que casi me volví obsoleto yo mismo. Hace tres años, Mercury era esencialmente un servicio de traducción sofisticado. Los clientes venían a nosotros con problemas definidos: "Construyanos un sitio web." "Migren nuestro CMS." "Arreglen nuestro SEO."
Éramos traductores hábiles—tomando sus requisitos y convirtiéndolos en código limpio y entregables. Cobrábamos por hora, que es el modelo de negocio perfecto para el trabajo de traducción. Más horas = más valor, supuestamente.
Luego, a finales de 2023, uso ChatGPT para escribir el script de Python que normalmente les cobraríamos cuarenta horas por construir. No era un código perfecto. Era desordenado, lleno de errores, inseguro. Pero era *direccionalmente correcto*, y le tomó a la IA treinta segundos.
Ahí fue cuando me di cuenta: Ser bueno en la ejecución ya no es una ventaja competitiva.
Así que en los últimos tres años, me forcé a mí mismo—y a mi empresa— a migrar hacia arriba en la cadena. Así es como se vio eso en realidad:
1. Aprender a tolerar la ambigüedad
A los traductores les desagrada la ambigüedad. Necesitan entradas claras para producir salidas claras. Los arquitectos viven en la ambigüedad.
Empecé a obligarme a asistir a reuniones donde el cliente no sabía lo que quería. No solo incómodo, sino existencialmente incierto. Un cliente del sector de la hospitalidad diría: "Necesitamos ser más digitales." Eso es todo. Sin especificaciones. Sin KPIs.
El viejo James habría insistido en un documento de requisitos. El nuevo James tuvo que aprender a decir: "Creo que tu verdadero problema es que tu programa de lealtad está perdiendo huéspedes de alto valor hacia las OTA porque tu CRM actual trata a un huésped de $5,000 igual que a un huésped de $50. Aquí te muestro cómo redefinimos la lógica de segmentación..."
Ya no estaba cumpliendo un requisito. Estaba definiendo uno que ellos no sabían que tenían.
2. Tomando decisiones con datos incompletos
La IA es excelente en la ejecución porque la ejecución requiere información completa. Necesitas todas las variables para escribir la función.
Pero definir problemas ocurre en la niebla. Tienes el 40% de los datos, una corazonada y una fecha límite.
Hace tres años, tomé la aterradora decisión de pivotar Mercury de "agencia de transformación digital" a "arquitecto de infraestructura de IA" antes de tener un solo cliente de IA. Los datos decían que el modelo antiguo estaba muriendo, pero el nuevo modelo aún no existía. Tuve que construir arquitecturas de agentes antes de que alguien pagara por ellas. Pasé seis meses quemando dinero sin pruebas de que funcionaría.AI infrastructure architect" before we had a single AI client. The data said the old model was dying, but the new model didn't exist yet. I had to build agent architectures before anyone would pay for them. I spent six months burning cash with no proof it would work.
Ese es trabajo de arquitecto. Estás apostando antes de que la pista esté construida.
3. Coincidencia de Patrones entre Dominios
Los traductores operan dentro de un dominio. El desarrollador de React se queda en React. El especialista en SEO se queda en SEO.
Arquitectosroban patronesde todas partes.
Cuando construimos el pipeline de agentes autónomos que migró 18,000 artículos (el sistema de 11 agentes del que hablé recientemente), no estaba simplemente "haciendo una migración de CMS". Estaba aplicando conceptos de arquitectura de sistemas distribuidos, teoría del diseño organizacional e incluso estructuras de mando militar (el modelo de "fuerzas especiales") a un problema de contenido.
El valor no estaba en el código.El valor estaba en reconocer que la migración no es un problema técnico, es un problema de coordinación organizacional, y los agentes son mejores coordinadores que los humanos para ciertos tipos de cognición repetitiva.
4. Poseer el Resultado, No la Tarea
Este fue el cambio mental más difícil. Como traductor, puedes decir: "Construí la función que pediste. Si no funciona en el mercado, ese es tu problema."
Como arquitecto, dices: "Necesitas aumentar la retención de clientes en un 15%. Definiré el espacio del problema, identificaré los puntos de intervención y desplegaré la solución. Si no alcanzamos el 15%, no me pagan completamente."
Pasamos de facturar por horas (unidades de traducción) a facturar por resultados (resultados arquitectónicos). Algunos meses ganamos menos dinero porque apostamos mal. Algunos meses ganamos 3x porque apostamos bien. Pero ya no somos intercambiables con el software.
Lo que realmente hice durante tres años
Déjame ser específico sobre los últimos 36 meses, porque "convertirse en arquitecto" es un consejo abstracto hasta que ves las cicatrices.
Año Uno (2023): La Panique
Todavía estaba vendiendo producto/solución. Pero comencé a notar que los clientes estaban utilizando IA para escribir su propio contenido, generar sus propios fragmentos de código, diseñar sus propios logotipos. Mis servicios de traducción estaban siendo commoditizadosen tiempo real.
Comencé a pasar mis noches leyendo sobre arquitecturas RAG, orquestación de agentes y gráficos de conocimiento, no porque quisiera convertirme en ingeniero nuevamente, sino porque necesitaba entender hacia dónde se estaba moviendo la ambigüedad. La ejecución se estaba volviendo automatizada. La arquitectura de *qué ejecutar* se estaba volviendo valiosa.
Año Dos (2024): El Brutal Cambio
Despedí a la mitad de mi equipo. No porque fueran malos, sino porque eran excelentes traductores en un mundo que ya no necesitaba traducción.
Mantuve a las personas que discutían conmigo sobre la estrategia. Aquellos que decían: "No creo que este cliente necesite un nuevo sitio web. Creo que necesitan dejar de existir." (Perdimos a ese cliente, pero ganamos tres que realmente necesitaban existir.)
Dejamos de aceptar proyectos con RFPs detallados.Si un cliente sabía exactamente lo que quería hasta la lista de características, iba a comprar una plantilla y una suscripción a IA. Comenzamos a dirigirnos a clientes que decían: "Algo está roto. No sabemos qué. Arreglalo."
Año Tres (2025-2026): El Nuevo Modelo
Ahora desplegamos agentes autónomos que manejan el trabajo de traducción. ¿El sistema de migración de 11 agentes que describí recientemente? Ese es el nuevo modelo. Los agentes son los traductores. Mi equipo humano son los Arquitectos que definen el espacio del problema, establecen las restricciones y verifican que los resultados coincidan con el objetivo empresarial.
Paso mis días en cosas que suenan vagas y no facturables: "definiendo la ontología del gráfico de conocimiento de un cliente", "negociando las implicaciones políticas de una migración de datos con su equipo ejecutivo", "decidiendo si un problema vale la pena resolverlo dadas sus restricciones presupuestarias."
Ninguno de este trabajo puede ser introducido en un LLM porque las entradas son demasiado desordenadas, demasiado humanas, demasiado políticas. Ya no estoy escribiendo código. Estoy definiendo el espacio del problema de tal manera que *se* pueda escribir código.
La Dura Verdad
Jensen Huang hace que suene como un fracaso de imaginación. No lo es. Es un fracaso de valentía.
Alejarse del rebaño de traductores es aterrador. Hace tres años, mis compañeros estaban ganando dinero de manera constante construyendo sitios web y gestionando campañas de Google Ads. Yo estaba perdiendo dinero, aprendiendo sobre bases de datos vectoriales y preguntándome si había destruido mi empresa.
Los programadores que se quedaron en el rebaño—que seguían traduciendo tickets de Jira en código limpio—están siendo optimizados fuera de la existencia por GitHub Copilot y Cursor. Los mercadólogos que seguían traduciendo "directrices de marca" en publicaciones de Instagram están siendo reemplazados por herramientas generativas.
Los que sobrevivieron son los que se adentraron en la niebla y empezaron a dibujar mapas.
Cómo empezar hoy
Si estás leyendo esto y te reconoces en la categoría de "Traductor", aquí está el cambio concreto:
Deja de preguntar: "¿Cómo puedo ejecutar este requisito mejor/más rápido/más barato?"
Empieza a preguntar: "¿Quién definió este requisito? ¿Qué problema están tratando realmente de resolver? ¿Apostaría mi salario a que este es el problema correcto a resolver?"
Si la respuesta a esa última pregunta es "no", tienes dos opciones: convertirte en la persona que redefine el problema, o volverte obsoleto.
La piscina se está vaciando. Nada hacia arriba.
*— James Huang, Mercury Technology Solutions, abril de 2026*
