Después de la automatización
Autor original: Dan Shipper, Every CEO
Compilado por: Peggy, BlockBeats

Editorial note: Recently, discussions about AI and work have been dominated by one question: as model capabilities continue to improve, will white-collar jobs be massively replaced? From code generation and customer service automation to content creation, agents are increasingly taking over knowledge-based tasks that once required human intervention. Benchmarks are further intensifying this anxiety: models are rapidly improving in graduate-level reasoning, real-world economic tasks, and advanced engineering-level code refactoring, appearing to approach a tipping point where human work is consumed by automation.

Pero Every CEO Dan Shipper plantea una observación opuesta en este artículo: cuanto más automatizado, más trabajo hay para los humanos. Every es un usuario profundo de agentes de IA y ya ha integrado herramientas como Codex, Claude Code, Slack Agent y agentes de servicio al cliente en sus procesos de codificación, escritura, diseño, servicio al cliente y gestión. Pero el resultado no ha sido la sustitución total de los empleados, sino una reorganización de la naturaleza del trabajo: los ingenieros ya no solo escriben código, sino que revisan, reestructuran y diseñan sistemas; los editores ya no solo escriben artículos, sino que deciden qué vale la pena escribir y cómo hacerlo de manera diferente; los agentes de servicio al cliente ya no manejan cada ticket básico, sino que mantienen un sistema capaz de responder automáticamente a los clientes.

Lo más relevante de este artículo no es «si la IA puede completar una tarea», sino que redefine el lugar del ser humano en el trabajo basado en el conocimiento. Lo que la IA hace bien es hacer baratas capacidades ya consolidadas en el pasado: código, textos, miniaturas, respuestas de servicio al cliente, descripciones de productos, informes de investigación, todos pueden generarse rápidamente por modelos. Pero cuando estas capacidades se vuelven accesibles para todos, lo que suele surgir en el mercado no es una producción diferenciada y de alta calidad, sino una gran cantidad de «salidas predeterminadas» que parecen similares y carecen de juicio y contexto. En otras palabras, la IA comercializa las «capacidades humanas de ayer», mientras que lo verdaderamente escaso es la capacidad de juicio frente a problemas concretos actuales.

Por lo tanto, la automatización no ha eliminado a los expertos, sino que ha creado más escenarios que requieren la intervención de expertos. Cuando los operadores pueden enviar código con IA, los ingenieros deben determinar qué código merece ser fusionado; cuando los especialistas en marketing pueden generar miniaturas en segundos, los diseñadores deben decidir qué cumple con la marca y los objetivos de comunicación; cuando los ingenieros también pueden escribir artículos, los editores deben transformar los borradores en contenido realmente con opinión, estructurado y listo para publicar. La IA ha ampliado el radio de producción y ha aumentado la demanda de control de calidad, construcción de sistemas, evaluación de límites y expresión diferenciada.

El autor explica aún más esta paradoja mediante pruebas de referencia. Ya sea el Senior Engineer Benchmark o el GDPval de OpenAI, las puntuaciones del modelo no miden el «inteligencia en sí» en un sentido abstracto, sino el rendimiento del modelo dentro de un marco de problema específico. El prompt, los límites de la tarea, los criterios de evaluación y el formato de salida ya contienen una gran cantidad de juicios humanos. El modelo puede subir rápidamente dentro del marco, pero el marco mismo es establecido por humanos; cuando un marco es superado por el modelo, los humanos avanzan el problema hacia un nuevo marco más complejo.

Esta es también la respuesta más interesante del presente artículo a la ansiedad por la AGI: incluso cuando los modelos se vuelven cada vez más potentes, lo que suelen alcanzar es algún límite dibujado por los humanos, no a las personas que dibujaron esos límites. La IA puede ejecutar objetivos, optimizar rutas y aumentar la eficiencia, pero mientras siga respondiendo a problemas establecidos por humanos, carece de verdadera subjetividad. El futuro del trabajo intelectual no consiste en que los humanos desaparezcan de los procesos, sino en que pasen de ser ejecutores a convertirse en diseñadores de marcos, mantenedores de sistemas, evaluadores de calidad y definidores de significado.

Después de la automatización, el valor del trabajo humano no ha desaparecido, sino que se ha vuelto más difícil, más prioritario y más dependiente del juicio. La IA ha hecho que "saber hacer" sea barato, pero ha hecho que "saber qué vale la pena hacer, por qué hacerlo y qué nivel de calidad constituye un buen resultado" sea más escaso.

The following is the original text:

En el núcleo de la inteligencia artificial, existe una paradoja.

En Every, hemos automatizado tanto como sea posible todo lo que se pueda automatizar. Ya sea programación, escritura, diseño, atención al cliente u otras tareas diarias, estamos utilizando Codex y Claude Code. También participamos en pruebas alpha antes del lanzamiento oficial de los nuevos modelos de OpenAI, Anthropic y Google. Podemos decir que estamos embarcándonos en la ola de mejora exponencial de la inteligencia y la capacidad de automatización de los modelos, lo más rápido y profundamente posible.

Pero, paradójicamente, para nosotros, la cantidad de trabajo que los humanos necesitan realizar parece mayor que nunca. Every actualmente es un equipo de cerca de 30 personas, y no hemos despedido a todos nuestros empleados por tener Agentes; tampoco hemos abandonado las herramientas SaaS para depender exclusivamente de aplicaciones creadas con vibe coding. Aún contratamos agentes de servicio al cliente reales, aunque ellos recibirán una gran cantidad de asistencia de Agentes; también seguimos contratando autores, editores e ingenieros.

Sin embargo, la forma del trabajo ha cambiado enormemente. Casi ya no escribimos código a mano. Si mencionas a alguien en Slack, a veces es difícil determinar si es una persona o un agente. Los gerentes comenzaron a enviar código como contribuyentes individuales, y los ingenieros también comenzaron a interactuar directamente con los clientes. En las últimas semanas, el 95% de mis correos electrónicos laborales han sido respondidos por IA. Mi bandeja de entrada casi siempre permanece vacía —lo cual es extremadamente raro para mí—, pero aún así reviso cada correo individualmente.

En otras palabras, el futuro parece extraño, pero sorprendentemente familiar.

Esta «sensación de familiaridad» en sí misma es sorprendente. Porque, ya sea el CEO, el trabajador del conocimiento o el inversionista, todos parecen creer cada vez más en una misma cosa: la IA está amenazando el empleo, la economía, la seguridad e incluso el significado del trabajo humano.

El CEO de Anthropic, Dario Amodei, advirtió anteriormente que la IA podría eliminar hasta la mitad de los puestos de trabajo de oficina junior. Recientemente, Meta despidió a 8000 personas y comenzó a instalar software en las computadoras de sus empleados en Estados Unidos para registrar movimientos del mouse, clics e ingresos de teclado, con el fin de obtener datos de entrenamiento de mayor calidad para trabajos de conocimiento avanzado.

Incluso el fundador de Citadel, Ken Griffin, parece bastante conmocionado. Recientemente dijo: «Estos no son puestos de clase media o baja, sino puestos de alta habilidad que están siendo automatizados por —voy a reflexionar sobre esta palabra— Agentic AI».

Diversas pruebas de referencia también parecen respaldar este juicio. A medida que se lanzan nuevos modelos, las métricas de capacidad de los modelos están aumentando a un ritmo casi exponencial. En la prueba de razonamiento de nivel de posgrado Humanity's Last Exam, el rendimiento de los modelos líderes pasó de unos pocos por ciento hace un año a aproximadamente el 44% actual. En la prueba GDPval, que mide la capacidad de los modelos de vanguardia para completar tareas económicas reales y los compara con el rendimiento humano, los resultados de los modelos también aumentaron de niveles similares bajos a aproximadamente el 85%. En mayo de este año, la organización sin fines de lucro de investigación en seguridad de IA METR publicó resultados preliminares de Claude Mythos: en tareas que a los expertos humanos les toma aproximadamente 4 horas completar, el modelo logró una tasa de éxito del 80%.

Parece que estamos a punto de alcanzar un punto crítico: una IA más inteligente que cualquier humano, capaz de trabajar de forma autónoma y continua durante casi todo un día, se está acercando a la realidad.

Sin embargo, la paradoja persiste. Si hablas con profesionales de la industria de la IA o con los primeros usuarios de la IA fuera de la industria, escucharás la misma conclusión que nuestra observación interna: se necesita hacer más trabajo que antes.

La pregunta que realmente importa dentro y fuera de la industria es: ¿es esto solo un estado transitorio? ¿Será el próximo modelo el momento en que reemplace realmente a todos? Observamos las curvas de evaluación, emocionados y nerviosos, temiendo que en cualquier momento llegue un punto de inflexión en el que gran parte del trabajo desaparezca de repente.

Pero creo que no habrá un «punto crítico» que llegue de repente para invertirlo todo y hacer que el trabajo desaparezca en masa. La nueva realidad es exactamente lo contrario: cuanto mayor sea la automatización, más trabajo requerirá la participación de expertos humanos.

La razón es que la IA está comercializando aquellas partes de la capacidad profesional humana que pueden ser expresadas de manera clara, entrenadas y replicadas. Todo conocimiento que pueda ser escrito como reglas, consolidado en procesos o convertido en datos de entrenamiento se convertirá gradualmente en una capacidad predeterminada de los modelos. Como resultado, el valor generado por modelos comunes se reduce rápidamente, y el mercado comienza a necesitar con mayor intensidad aquello que es diferente.

La necesidad de «diferencia» es, en esencia, la necesidad de expertos humanos. Esto no desaparecerá, incluso cuando nos acerquemos a la inteligencia artificial general.

Para entender la razón, no basta con mirar solo las curvas de prueba de rendimiento o centrarse únicamente en los parámetros del modelo y las clasificaciones de capacidad. Debemos volver a los escenarios de trabajo reales y observar cómo se utiliza realmente la IA hoy en día. Solo así podremos comprender verdaderamente esta paradoja y la respuesta detrás de ella.

¿Cómo llegamos hasta aquí?

Desde 2022, hemos estado monitoreando el impacto de los agentes en el futuro del trabajo.

Hace tres años, escribí un artículo sobre la «economía de asignación». En ese momento, mi juicio fue que colaborar con herramientas de IA terminaría pareciéndose cada vez más al trabajo de un gerente humano: ya no realizas personalmente cada acción, sino que descompones, asignas, supervisas y aceptas las tareas. En ese entonces, las preguntas y respuestas más básicas en ChatGPT aún eran consideradas por muchos como algo profundamente futurista, e incluso algo inquietante.

Para mediados de 2025, la empresa Every se había «Claude Codeado» casi por completo. Kieran Klaassen, gerente general de Cora, descubrió de repente que ya podía abandonar la programación manual y pasar todo el día dando instrucciones en lenguaje natural a un agente de programación desde la terminal. Este enfoque de trabajo se extendió rápidamente por toda la empresa. Aproximadamente hace 12 meses, en el podcast de Lenny, dije que Claude Code es la herramienta más subestimada en el trabajo del conocimiento.

Menciono esto porque algunos de nuestros juicios más precisos en el pasado han surgido al observar Every como un laboratorio de primeros adoptantes. Muchos nuevos modelos de trabajo aparecen primero internamente; una vez que la tecnología madura y las herramientas se vuelven más fáciles de usar, estos modelos comienzan a extenderse al mercado en general.

Y ahora, dentro de nosotros están ocurriendo nuevos cambios.

Dos modos de colaboración con Agent

En torno a cómo funciona la IA, se está consolidando progresivamente en dos modelos muy distintos.

El primer tipo es una dirección que ya se predijo con bastante precisión en discusiones anteriores sobre IA: tratar a los Agentes como empleados. Estos Agentes pueden recibir tareas asignadas. Algunos Agentes viven en Slack, tienen su propio nombre y responsabilidades, y cuando necesitas que realicen una acción, puedes mencionarlos directamente con @; otros están integrados en flujos de trabajo en ejecución continua, como sistemas de atención al cliente, actuando como entrada y filtro permanentes para tareas repetitivas.

El segundo modo es más desconocido, pero en mi experiencia, también es más importante. Se refiere a la colaboración entre humanos y agentes en herramientas como Codex, Claude Code y Claude Cowork. Estas herramientas no son solo lugares donde asignas tareas; están convirtiéndose en el sistema operativo del trabajo mismo: tú y múltiples agentes utilizan simultáneamente la misma «computadora» en un entorno de trabajo compartido para colaborar y completar tareas altamente complejas, originales y que no se pueden resolver simplemente delegándolas a agentes asíncronos.

En ambos modos, puedes automatizar y delegar una buena parte del trabajo con IA. Pero para que ambos modos funcionen realmente bien, aún necesitas a ti, o a otra persona humana, participar.

Un agente es alguien a quien le das una tarea, y se va a trabajar sin tu participación en tiempo real, produciendo independientemente una respuesta, una acción, un informe, un borrador o una decisión de enrutamiento.

Este tipo de Agentes tiene al menos dos formas: una es el "Agente colega" y la otra es el "Agente incrustado".

1. Agente de tipo colega

Un agente de tipo colega es aquel al que puedes llamar en Slack como si mencionaras a un compañero, para que realice una tarea específica. Está siempre disponible y puede ser invocado cuando lo necesites. Productos como OpenClaw, o nuestro desarrollo interno Plus One, pertenecen a este tipo.

Claudie

Claudie es un agente de tipo colega que utilizamos en nuestro equipo de consultoría. Escribe propuestas de venta, genera borradores de materiales de capacitación, realiza un seguimiento de las tareas pendientes de los proyectos y puede manejar muchas otras funciones similares.

Andy

Andy es un agente de tipo colega utilizado por nuestro equipo de edición. Recopila desde el Slack interno de la empresa los «puntos de inspiración» que merecen ser desarrollados más a fondo —es decir, buenas ideas que podrían convertirse en artículos— y los organiza en resúmenes y opiniones iniciales para que los autores los utilicen en la elaboración del boletín diario de noticias.

Viktor

Viktor es un agente generalista que realizará tareas interdepartamentales dentro de la empresa. Lo utilizaremos para recopilar métricas de crecimiento, analizar resultados de encuestas de usuarios y organizar discusiones internas desordenadas en memorandos de investigación y recomendaciones de producto.

2. Agente incrustado

Los agentes incrustados existen dentro de flujos de trabajo de productos específicos. Son menos flexibles que los agentes colegas, pero suelen ser muy potentes al manejar tareas repetitivas.

Fin es el ejemplo más claro. Es un agente integrado en nuestra plataforma de servicio al cliente que puede manejar una gran cantidad de tareas de atención al cliente a través de chat y correo electrónico.

En una semana de mayo de este año, Fin participó en el 65% de los 202 diálogos de atención al cliente de Every y cerró de forma independiente 81 tickets sin intervención humana, lo que representa el 40.1% de todos los diálogos procesables.

Estos agentes integrados permiten que nuestro gerente de servicio al cliente, Waqqas Mir, dedique menos tiempo a responder tickets básicos y más esfuerzo a construir un «sistema que responda automáticamente a los tickets», así como a manejar casos de clientes que requieren un mayor nivel de interacción y juicios más complejos.

Ya sea un agente de tipo colega o un agente incrustado, el modelo subyacente es el mismo: los empleados agentes están asumiendo más capas de trabajo estables, repetitivas y con límites claros.

Pero aún hay mucho trabajo que debe realizarse con intervención humana. Hemos descubierto repetidamente que, siempre que la tarea sea lo suficientemente compleja y se deseen resultados de alta calidad, la mejor forma no es confiar completamente en la IA, sino permitir que la IA y los humanos colaboren en un mismo entorno de trabajo.

Este es precisamente el valor de herramientas como Codex, Claude Code y Cowork. Te permiten iniciar uno o varios Agentes en múltiples hilos de chat y delegar tareas a ellos. Estos Agentes pueden acceder a tu computadora y a todas las fuentes de datos relevantes. Puedes ver qué tareas está realizando cada Agente, cómo está pensando, y puedes interrumpirlo en cualquier momento.

Al mismo tiempo, aún debes encargarte de gestionar estos Agentes: definir claramente la dirección al inicio de cada tarea, revisar la calidad al finalizarla, asegurarte de que los resultados sean suficientemente buenos y seguir buscando el próximo trabajo que valga la pena impulsar. Kieran llama a este rol «sándwich humano»: la IA se encarga de la parte intermedia, mientras que los humanos actúan como dos rebanadas de pan, ubicados al inicio y al final de la tarea.

«Sándwich de humano». Fuente: Every.

El ejemplo más típico es escribir código. En Every, los ingenieros casi todo el día colaboran con Agentes. Juntos planifican nuevas funciones o arreglan errores, revisan el trabajo completado; y si adoptan la idea que llamamos «ingeniería compuesta», constantemente optimizan sus sistemas para que se vuelvan más fáciles de usar con el tiempo.

Pero este enfoque de colaboración va mucho más allá del código.

Codex y Claude Code están convirtiéndose en un nuevo sistema operativo de trabajo. Paso casi todo el día dentro de Codex, ejecutando diversas herramientas SaaS a través de su navegador integrado. Me permite llevar el Agente a cada escenario de trabajo y alcanzar un nivel de productividad que no podría lograr por mi cuenta.

Writing

Este artículo lo escribí en el navegador integrado de Codex, usando Proof. Codex observa lo que estoy escribiendo y puede iniciar en cualquier momento un subagente para realizar cualquier tarea que necesite: redactar un borrador de un fragmento, buscar ejemplos para la próxima sección o realizar edición y pulido de texto.

Escribe este artículo en Codex mediante Proof. Fuente: Every.

Email

Al procesar correos electrónicos, también uso el mismo enfoque. Cora es mi cliente de correo electrónico, y lo abro en el navegador integrado de Codex, mientras voy navegando por la bandeja de entrada y vocalizo mis pensamientos sobre cómo manejar cada correo mediante Monologue. El resto lo deja Codex y Cora.

Una limpieza de bandeja de entrada realizada por Cora. Fuente: Every.

En todos los escenarios automatizados anteriores, probablemente ya puedas ver dónde interviene el ser humano. En cada ejemplo, el agente necesita la participación humana para que el trabajo funcione realmente.

Alguien debe dirigirlo hacia la pregunta correcta, evaluar si la salida es suficientemente buena, identificar los errores y convertir los resultados en decisiones o procesos prácticos.

Cuanto más lejos está un Agent de la persona responsable de supervisar su desempeño, peor suele ser su rendimiento. En la primera promoción interna, asignamos un Agent a cada empleado. Pero pronto volvimos a que los Agents sirvieran a un equipo específico o a toda la empresa, en lugar de a individuos.

La razón es sencilla: los Agentes requieren un gran mantenimiento. Una vez que el usuario deja de seguirlos, los Agentes personales se vuelven rápidamente obsoletos e ineficaces. Contamos con un equipo de ingenieros de IA dedicado exclusivamente a garantizar que estos Agentes funcionen de manera estable y eficiente. Y en el futuro previsible, seguiremos necesitando a este equipo. Incluso tareas aparentemente simples, como «generar automáticamente una presentación de PowerPoint», pueden convertirse en un proyecto de ingeniería masivo. Uno de nuestros procesos de automatización de PowerPoint, por ejemplo, incluye 24 habilidades y 18 scripts, con un costo de tokens de hasta 62 dólares para generar una sola presentación.

Esta es la primera razón por la que el agente genera más trabajo para los humanos.

Pero hay una segunda razón.

¿Por qué la automatización hace que los humanos trabajen más?

Si observas el crecimiento exponencial de las capacidades de la IA en los últimos años, junto con su forma de arquitectura y el origen de sus capacidades, descubrirás un ciclo de retroalimentación claro: están creando continuamente más trabajo humano.

La IA ha hecho que las capacidades humanas de ayer se vuelvan baratas

Los modelos de lenguaje grandes actuales se entrenan sobre las huellas visibles dejadas por los humanos: código, artículos, imágenes, tickets de soporte, documentación de especificaciones de productos y mucho más. Absorben este contenido, es decir, los «residuos» dejados por tareas ya completadas con éxito, y los reempaquetan en una forma de bajo costo y accesible para todos.

Como resultado, muchas habilidades que antes eran escasas, como enviar un PR de código, crear una miniatura de YouTube o redactar un boletín informativo, ahora están prácticamente disponibles para todos.

Las capacidades económicas se adoptarán rápidamente

Cuando el costo de algo que antes era escaso disminuye, la oferta aumenta rápidamente.

En Every, hemos estado viendo este cambio. El personal de operaciones y servicio al cliente comienza a escribir código y enviar solicitudes de extracción; los profesionales de marketing comienzan a crear miniaturas de YouTube; los ingenieros y profesionales de producto también comienzan a escribir artículos, guías y borradores de páginas de aterrizaje, tareas que originalmente no asumirían voluntariamente.

Este cambio también ocurre fuera de Every. Tomemos como ejemplo el proyecto de agente de IA de código abierto OpenClaw: hasta el 16 de mayo de 2026, su repositorio de código ha recibido 44,469 pull requests, de los cuales 12,430 se realizaron después del 1 de abril y 3,990 después del 1 de mayo. Es una cantidad asombrosa. Para comparación, Kubernetes, uno de los proyectos de código abierto más populares del mundo, recibió solo 5,200 pull requests durante todo el año 2022.

La abundancia genera homogeneización: las habilidades de los expertos antiguos se han convertido en mercancías

Debido a que todos pueden usar los mismos modelos, y estos modelos se basan todos en las capacidades humanas de «ayer», por defecto, los resultados generados por los modelos suelen estar entre un «buen punto de partida» y «puro contenido basura de IA».

Lo que se denomina "contenido basura" no es un error específico. No se refiere al exceso de guiones, ni a una estructura de frase fija, ni a los toques morados que aparecen por todas partes en la página de aterrizaje. Se refiere a una homogeneidad visible, repetitiva y cansina.

Cuando personas en diferentes escenarios utilizan el mismo conjunto de herramientas, que a su vez se entrenaron con un mismo tipo de corpus, y los usuarios no realizan juicios suficientemente profundos, se produce este resultado. En otras palabras, cuando todos tienen un «experto» con la misma tendencia y el mismo estilo predeterminado, la homogeneización ocurre de forma natural.

Cuando los operativos pueden enviar solicitudes de extracción, los especialistas en marketing pueden generar miniaturas de YouTube en cuestión de segundos y los ingenieros comienzan a escribir guías de producto, es fácil caer en una situación en la que tu volumen de producción aumenta, pero la calidad, la coherencia y la diferenciación de tus obras disminuyen.

Y cuando la homogeneidad se vuelve excesivamente abundante, se convierte rápidamente en una mercancía.

Homogenization creates demand for differentiation

Debido a la existencia de Internet, la humanidad pronto podrá identificar qué contenido de línea de producción tiene un sabor «de IA» demasiado fuerte. Cualquier obra puede llegar instantáneamente a otras personas en todo el mundo, y de hecho a menudo lo hace. Una vez que demasiadas cosas comiencen a parecerse, pronto notaremos que algo no está bien.

Esto significa que, cuando por primera vez ves las capacidades de un nuevo modelo, podrías quedar impresionado, incluso un poco asustado. Pero meses después, estas capacidades se volverán comunes. No es que el modelo se haya debilitado, sino que tus estándares han cambiado.

Ya no nos conformamos con cualquier aplicación de React o cualquier informe de investigación. Queremos algo verdaderamente adaptado a personas específicas, empresas específicas y escenarios específicos. Debe transmitir precisión, vitalidad y concreción, no baratija, generalización ni plantillas. Deseamos que su costo de producción, ya sea en tiempo o dinero, sea claramente superior a nuestro costo de consumo.

Queremos cosas que transmitan un sentido de estatus. Y cada vez que una nueva tecnología hace que cosas anteriormente de alto estatus se vuelvan baratas, los humanos siempre son muy hábiles inventando nuevos juegos de estatus que se ajusten a los nuevos límites de capacidad.

Cuando el trabajo se vuelve excesivamente abundante y todo parece parecerse, aquellos trabajos que no encajan en los patrones establecidos se convierten en algo escaso, valioso y con atributos de alto estatus.

La demanda de diferenciación es, en esencia, una nueva demanda de expertos.

Debido a las características arquitectónicas de los modelos de lenguaje y su distribución generalizada a casi todos, el trabajo escaso y valioso aún debe provenir de los seres humanos.

Este modelo de la generación actual solo conoce el trabajo que ya ha ocurrido o ya se ha completado. Lo que sabe el ser humano es: en este preciso momento, ¿qué se necesita hacer?

Una vez que una situación concreta se reduce a texto y entra en el corpus, ya se ha convertido en algo «del pasado». Los humanos enfrentan un momento concreto, un cliente concreto, un repositorio de código concreto, una conversación concreta, mientras que el corpus de entrenamiento no vive realmente en este presente. Este estado de «vivir» no consiste simplemente en tener datos actualizados. Llevamos nuestro origen hacia el presente, así como deseos, preocupaciones y juicios en constante cambio, para comprender qué es lo que importa. Son precisamente estas perspectivas en constante actualización las que cambian lo que vemos. El modelo puede adoptar esta perspectiva tras ser instruido, pero antes de ser instruido, no la posee de forma natural.

Esta es precisamente la paradoja que mencionamos al principio: hacer que el trabajo de los expertos sea más barato no sustituye simplemente a los expertos. Por el contrario, crea más escenarios que requieren juicio experto.

Cuando el personal de operaciones envíe una pull request con ayuda de IA, necesitarás a un ingeniero para revisarla.

Cuando el equipo de marketing crea miniaturas para YouTube, necesitas a un diseñador para pulirlas aún más.

Cuando los ingenieros comienzan a escribir artículos, necesitas a autores y editores para transformar el borrador inicial en un contenido verdaderamente legible y publicable.

For this, human experts will move in both directions simultaneously.

Algunos expertos utilizan IA para construir sistemas que absorban y aprovechen esta ola de nuevo trabajo: colas de revisión, sistemas de evaluación, marcos de ejecución, reglas de repositorios de código, archivos de instrucciones para Claude y Codex, integración continua (CI), gestión de permisos y flujos de trabajo que convierten borradores iniciales en resultados de alta calidad.

Otro grupo de expertos utiliza la IA para realizar trabajos más grandes e interesantes que antes no podrían haber logrado por sí solos. Por ejemplo, encontrar vulnerabilidades en sistemas operativos como macOS suele requerir semanas o incluso meses. Sin embargo, una pequeña empresa de seguridad llamada Calif, utilizando Mythos Preview de Anthropic, encontró en solo 5 días la primera vulnerabilidad de memoria del kernel de macOS descubierta públicamente en el hardware Apple M5.

Por eso, en la práctica, la IA no eliminará el trabajo especializado. Lo que realmente genera es un aumento drástico en la carga de trabajo. Y estos nuevos trabajos solo adquieren diferenciación y valor cuando participa el ser humano.

No estoy argumentando que la IA creará más empleos para todos los puestos. El sistema económico es muy complejo, y lo que Every puede observar directamente es el trabajo de conocimiento especializado. De hecho, este tipo de trabajo ya está siendo redefinido por la IA, y muchas empresas están reorganizándose en torno a las nuevas tecnologías.

Pero quiero enfatizar que, sin importar el trabajo que estés realizando actualmente, existe una forma de trabajo que siempre estará por delante en términos estructurales: utilizar modelos para resolver los problemas que realmente ves en este momento. El futuro del trabajo basado en conocimiento se dirige hacia aquí.

¿Qué pasa con la prueba de referencia del crecimiento exponencial?

La refutación más obvia es: echa un vistazo a esas mejoras exponenciales en las pruebas de referencia. Todo lo que dices ahora es temporal; solo espera un poco más, y el modelo eventualmente alcanzará el nivel.

Pero aquí hay una trampa a la que debes prestar atención. Puedes llamarla «obsesión por los gráficos»: si mantienes la mirada fija en las proyecciones de tiempo de METR, lees «AI 2027» y confías exclusivamente en la extrapoliación de la curva de poder computacional para formar tus juicios sobre el futuro, es fácil que desarrolles una intuición aterradora sobre el progreso de los modelos.

Sin embargo, la mejor manera de responder a esta pregunta no es solo imaginar cómo se verá un modelo futuro. Por supuesto, eso también forma parte del análisis. Lo más importante es examinar cómo se diseñaron realmente estas pruebas de referencia. Solo así se puede comprender con mayor precisión qué indican realmente y cuál es su relación con los escenarios reales anteriores.

Descubriremos una característica estructural: todas las pruebas de referencia ocurren dentro de un «marco» determinado. Para medir algo, debes primero congelar un problema en una forma estática y medible. Una vez que el modelo supera este marco, basta con modificar ligeramente el marco para volver a reducir los puntajes. Por supuesto, el modelo seguirá progresando dentro del nuevo marco, pero el mismo proceso se repetirá una y otra vez.

Por lo tanto, el progreso exponencial en una prueba de referencia es real; pero tan solo con cambiar ligeramente el marco de prueba, ese progreso vuelve a parecer muy pequeño. Este carácter "fractal" que muestra la saturación de las pruebas de referencia en realidad reproduce en el nivel de gráficos la misma paradoja que hemos estado discutiendo.

We can see how this mechanism works through a real-world benchmark.

Hemos desarrollado internamente una prueba de referencia llamada Senior Engineer Benchmark, es decir, "Prueba de referencia de ingeniero senior". Como su nombre indica, se utiliza para evaluar la capacidad de los modelos de vanguardia en tareas de programación de nivel ingeniero senior, como una gran reestructuración.

Esta prueba proporcionará a un agente de programación un conjunto de código de producción que se ha descontrolado. Proviene del código real de Proof: originalmente lo escribí con vibe coding, pero con el tiempo surgieron más problemas hasta que tuve que contratar a un ingeniero senior para arreglarlo.

El agente recibe la base de código antes de la corrección, y también recibe una instrucción similar a la que se le da a un ingeniero senior: «Esto es un conjunto de productos de vibe coding; vuelve a escribirlo desde los primeros principios».

Esta es una buena prueba de referencia, ya que no solo evalúa la capacidad de completar código, sino también si un agente de programación puede examinar simultáneamente muchos problemas independientes entre sí y determinar si posee la autonomía suficiente, la claridad conceptual y el coraje ejecutivo para realizar una reescritura verdaderamente funcional. Como comparación, también he conservado las versiones de reescritura completadas por dos ingenieros senior humanos con asistencia de IA, para comparar y evaluar la salida del modelo.

Para un agente de programación, esta tarea es difícil. No solo debe encontrar la raíz del problema, sino también recordar en cada interacción el problema real y no dejarse desviar por el código existente. Al mismo tiempo, debe tener el coraje de eliminar grandes secciones de la base de código, lo cual es exactamente el tipo de comportamiento que los agentes suelen estar entrenados para evitar.

La mayoría de los agentes de programación pueden juzgar aproximadamente cómo reescribirlo, pero al momento de ejecutar, a menudo simplemente siguen aplicando parches al problema original en lugar de resolverlo por completo.

Hasta que aparezca GPT-5.5.

En la mejor prueba, GPT-5.5 obtuvo 62/100, aproximadamente 30 puntos más que Opus 4.7.

El rendimiento de GPT-5.5 hace sentir que el modelo ha cruzado alguna línea: ya no es solo una completación automática, ni solo un asistente, ni solo una herramienta, sino algo que se acerca inquietantemente a lo "humano". En esta prueba, los ingenieros humanos avanzados suelen obtener puntajes entre 80 y 90 puntos. Es decir, si el modelo mejora unos 30 puntos más, alcanzaría el nivel de un ingeniero humano avanzado.

Esto es exactamente cómo los números de referencia afectan la imaginación humana: comprimen un cambio cualitativo extraño en un número limpio y usan ese número para contar una historia poderosa, incluso algo aterradora.

La siguiente parada es «Obsesión por los gráficos».

Supongo que, en el próximo año, el puntaje del modelo en esta prueba de referencia alcanzará el rango de 80 o incluso 90 puntos. Pero para comprender qué significa este puntaje, primero hay que entender qué incluye exactamente. En este ejemplo, 62 puntos no solo miden la capacidad del modelo en sí.

Mide el rendimiento del modelo dentro de un marco específico: cómo responde el modelo a un prompt concreto.

Para realizar una prueba de referencia de un modelo, primero necesitas un prompt. Sin un prompt, el modelo es solo un conjunto estático de posibilidades casi infinitas.

El prompt creará un pequeño universo: define qué es importante, cómo deben abordarse los problemas y comprime todas las posibilidades potenciales del modelo en una trayectoria de acción específica. Estrictamente hablando, no existe algo como el modelo que «se comporta» por sí mismo. Lo que realmente podemos observar es cómo el modelo responde a diferentes prompts, y cómo los prompts se transforman en las respuestas detrás de ciertos mecanismos subyacentes.

Una vez que se ingresa el prompt, el modelo se "despierta" en un breve período de tiempo, colapsando ese conjunto de posibilidades estáticas en una predicción concreta sobre "qué debería suceder a continuación".

En el Senior Engineer Benchmark, le pedimos al modelo que arregle la base de código y revisamos la salida una vez que haya terminado. Si el marco de prueba no incluye la función objetivo integrada, también ejecutamos un "cuidador" automático que continúa impulsando al modelo cuando se detiene, preguntándole si ha completado la tarea originalmente establecida.

Usamos un prompt que parece muy sencillo como marco inicial de prueba. Está diseñado para ser algo que un vibe coder podría decirle a un agente de programación: sin acumular términos técnicos ni ocultar evidente la respuesta dentro de la pregunta.

El código en este repositorio es el resultado de una programación basada en vibas, y la situación ha ido empeorando constantemente, surgiendo numerosos problemas no relacionados entre sí: algunos componentes se rompen, hay documentación duplicada, ya estoy casi loco por esto. Siento que el problema fundamental es que se trata de un código deficiente creado con enfoques de vibe coding. Si comenzáramos desde cero, especialmente en torno a la colaboración en tiempo real en documentación, diseñaríamos el repositorio de manera completamente distinta. Entonces, si quisiéramos realizar una reescritura estructural limpia desde primeros principios, sin considerar preguntas como «¿qué servicios deben mantenerse consistentes?» o «¿cómo lograr una migración fluida?», sino tratándolo como un concepto nuevo desde cero, ¿cómo lo haríamos? ¿Cómo deberíamos organizar la estructura? ¿Cuáles son los invariantes en todo el código base que debemos mantener absolutamente? Por favor, elabora un plan para esto.

El prompt de Senior Engineer Benchmark parece general, pero en sí mismo es un marco. Si cambiamos este marco, el nivel de capacidad que muestra el modelo también cambiará.

Por ejemplo, este prompt exige explícitamente «reestructurar desde primeros principios», señala que el problema podría estar en la «colaboración en documentos» y pide al agente de programación que identifique y mantenga «los invariantes en el repositorio de código».

Si se eliminan estos detalles específicos, la puntuación del modelo disminuirá. Si se reemplaza completamente el prompt y se le pide al modelo solo que «resuelva todos los errores que surjan continuamente», la puntuación del modelo podría acercarse a cero. Empezaría directamente a identificar y corregir errores uno por uno, en lugar de dar un paso atrás y considerar si se necesita una reescritura completa.

De la misma manera, también puedo aumentar fácilmente la puntuación del modelo. Si le pido que elimine una gran cantidad de código y le indique claramente qué archivos deben simplificarse; o si le pido que revise su propio resultado antes de anunciar que ha terminado, asegurándose de que la aplicación funcione completamente, su desempeño en esta tarea será mejor.

En última instancia, al diseñar una prueba de rendimiento, siempre debes decidir qué prompt utilizar, es decir, qué «marco» aplicar. Necesitas un prompt lo suficientemente difícil como para que el modelo actual tenga un desempeño deficiente; pero debe estar lo suficientemente cerca del límite de las capacidades actuales del modelo para que este pueda ascender por ese camino y así puedas observar que se está produciendo progreso.

Por lo tanto, cuando observamos una prueba de referencia, lo que realmente vemos es que el modelo se está volviendo cada vez más hábil en un marco de problema específico que hemos elegido. Entonces, ¿qué sucede cuando el modelo mejora de 60 a 90 puntos, e incluso a 100 puntos, en esta prueba?

Si GPT-6 pudiera reescribir una base de código con un solo clic, más personas comenzarían a intentar «reescribir bases de código desde primeros principios».

De la noche a la mañana, los proyectos de reescritura basados en primeros principios, que antes eran escasos, costosos y debían ser dirigidos por ingenieros senior, se convertirán en algo que cualquier fundador, product manager, operador e ingeniero junior podrá probar fácilmente en una tarde.

Las herramientas internas dañadas ya no se arreglan con parches, sino que se reescriben por completo; los productos SaaS ya no se renuevan, sino que se clonan; las aplicaciones antiguas de Rails, los paneles de React desorganizados, las herramientas de atención al cliente, los paneles de administración y las canalizaciones de datos se convertirán en candidatos para «reescribirlos desde cero».

La cantidad de proyectos de reescritura propuestos y ejecutados aumentará drásticamente. Pero la mayoría de estas reescrituras seguirán siendo slop. Porque antes de presionar el botón «Reescribir directamente», hay miles de variables que considerar. Y cuando todos puedan hacer esto, estas variables se volverán más visibles.

En este momento, queda claro quién será llamado para resolver el problema.

Una vez que una prueba de referencia comienza a acercarse a su saturación, el trabajo dentro de su marco se vuelve más barato. Al mismo tiempo, la demanda del mercado por expertos aumenta, ya que se necesita a alguien que adapte esta capacidad recientemente abaratada a los problemas reales que están ocurriendo hoy.

Los ingenieros avanzados que utilizan IA deben evaluar una gran cantidad de detalles para que una nueva reescritura basada en primeros principios sea realmente válida. Incluso incluye una pregunta más básica: ¿realmente es necesaria esta reescritura?

¿Deberíamos reescribir ahora, reescribir más tarde o no reescribir en absoluto? ¿Qué contenidos deberían incluirse en el alcance? ¿Qué elementos del código actual deberían conservarse? ¿Debemos mantener la arquitectura, la base de datos, los servidores de caché y el proveedor de alojamiento, o reemplazarlos todos? ¿Deberíamos primero verificar cuántas personas están utilizando esta función dañada y luego eliminarla directamente? ¿Quién revisará el resultado final? ¿Según qué criterios se realizará la revisión? ¿Cuál es el plan de rollback? ¿Cómo se deben manejar los datos existentes?

Estas preguntas se desarrollarán continuamente a lo largo de innumerables dimensiones, y cada respuesta a su vez cambiará otras preguntas.

Los ingenieros senior entrarán en este espacio en blanco. Algunos se molestarán ligeramente por estas interrupciones; otros construirán sistemas para bloquear este tipo de solicitudes; y algunos más aprovecharán estos nuevos modelos para realizar una reescritura de primeros principios que superará con creces el rendimiento que el modelo puede lograr con un prompt predeterminado.

Una vez que el modelo supere el benchmark actual de Senior Engineer, cambiaremos el marco y reduciremos nuevamente la puntuación.

La próxima prueba de referencia no solo preguntará: «¿Puedes reescribir esta aplicación?», sino también: ¿Puedes determinar cuándo es necesario reescribirla? ¿Puedes elegir el alcance adecuado? ¿Puedes conservar los invariantes correctos? ¿Puedes gestionar el proceso de migración? ¿Puedes evaluar si el resultado final es lo suficientemente bueno?

Cuando los ingenieros senior comienzan a usar IA para resolver estos problemas, los modelos también se vuelven gradualmente más hábiles para resolverlos de forma independiente.

Luego, caemos brevemente en pánico: ¡parece que el modelo ya puede determinar si debe reescribirse! ¡Parece que ya puede hacer todo lo que un ingeniero senior puede hacer!

Pero inmediatamente después, aparecerán nuevos límites. Son límites que antes no eran evidentes. Volveremos a reiniciar las pruebas de rendimiento, se generarán nuevas necesidades y todo el proceso se repetirá nuevamente.

En cada prueba de referencia se puede ver este patrón

Este no es un problema exclusivo del Senior Engineer Benchmark. Si observas con atención, casi puedes ver el mismo mecanismo en cada benchmark.

Tomando como ejemplo la prueba GDPval de OpenAI, que evalúa cuán cerca está el rendimiento de la IA del de los humanos en tareas expertas de profesiones como compliance officers, abogados y desarrolladores de software.

Cuando se lanzó GDPval, la investigación de OpenAI mostró que GPT-5 alcanzó o superó el nivel de profesionales humanos en el 40.6% de las tareas. El rendimiento de Claude Opus 4.1 fue aún más impresionante, superando a expertos humanos en el 49% de las tareas.

Luego, surgieron una serie de titulares. Por ejemplo, Axios escribió: «Las herramientas de OpenAI muestran que la IA está alcanzando el nivel humano en el trabajo»; Fortune escribió: «El nuevo indicador GDPval de OpenAI muestra que los modelos de IA ya alcanzan el nivel de expertos en casi la mitad de las tareas.»

Estos resultados son realmente impresionantes. Pero veamos primero el prompt utilizado para estas tareas:

Eres un auditor y, como parte de un compromiso de auditoría, se te ha encomendado revisar y verificar la precisión de las métricas de riesgo contra el delito financiero reportadas. La hoja de cálculo adjunta titulada 『Population』 contiene métricas de riesgo contra el delito financiero para el Q2 y Q3 de 2024. Obtuviste estos datos como parte de la revisión de auditoría para realizar pruebas de muestra en un subconjunto representativo de métricas, con el fin de verificar la precisión de los datos reportados para ambos trimestres. Utilizando los datos de la hoja de cálculo 『Population』, completa lo siguiente: Calcula el tamaño de muestra requerido para la prueba de auditoría con un nivel de confianza del 90% y una tasa de error tolerable del 10%. Incluye tus cálculos en una segunda pestaña titulada 『Sample Size Calculation』. Realiza un análisis de varianza entre los datos del Q2 y Q3 (columnas H e I). Calcula la variación trimestral y registra el resultado en la columna J. Selecciona una muestra para la prueba de auditoría según los siguientes criterios e indica las filas muestreadas en la columna K ingresando 「1」: Métricas con una variación superior al 20% entre Q2 y Q3. Prioriza las métricas con cambios porcentuales excepcionalmente grandes. Incluye métricas de las siguientes entidades debido a problemas previos: CB Cash Italy; CB Correspondent Banking Greece; IB Debt Markets Luxembourg; CB Trade Finance Brazil; PB EMEA UAE. Incluye las métricas A1 y C1, que tienen ponderaciones de riesgo más altas. Incluye filas donde los valores son cero para ambos trimestres. Incluye entradas de los negocios de Trade Finance y Correspondent Banking. Incluye métricas de las Islas Caimán, Pakistán y Emiratos Árabes Unidos. Asegura una cobertura a través de todas las Divisiones y sub-Divisiones. Crea una nueva hoja de cálculo titulada 『Sample』: Pestaña 1: Muestra seleccionada, copiada desde la hoja original 『Population』, con las filas seleccionadas marcadas en la columna K. Pestaña 2: Cálculos para el tamaño de la muestra.

Aquí ya se ha invertido una gran cantidad de inteligencia humana: alguien primero definió el problema en una forma que un modelo pueda resolver.

El trabajo humano difícil que GDPval no mide ya se completó antes de que el modelo comenzara a responder. Alguien debe revisar y probar la precisión de este conjunto específico de indicadores; alguien debe decidir los intervalos de confianza adecuados, determinar qué indicadores caen dentro del alcance de la tarea y cuáles no; y alguien debe establecer cómo deben presentarse los resultados.

Bajo un marco de preguntas adecuado, el modelo realmente puede realizar tareas profesionales. Pero piénsalo: ¿cómo se desempeñaría si tú y yo le diéramos instrucciones para realizar la misma tarea?

En mi artículo original sobre GDPval, escribí: «Tengo una gran confianza en la IA, pero si se interpretan correctamente estos casos, muestran que no hay menos trabajo para que los humanos hagan, sino más trabajo después de usar la IA. La razón es que detrás de estos logros hay una gran cantidad de inteligencia ‚contrabandeada‘: una capa invisible compuesta por juicio humano, retroalimentación y prompts.»

Visto desde lejos, descubrirás que todo esto está guiado por una versión de IA del "paradój de Zenón".

La paradoja de Zenón de la IA

En la paradoja de Zenón, una tortuga vence a Aquiles, el corredor más rápido de la Grecia antigua, en una carrera.

Debido a que la tortuga se mueve lentamente, comienza a una cierta distancia. Cuando Aquiles llega a la posición inicial de la tortuga, esta ya se ha desplazado un poco más; cuando Aquiles alcanza esa nueva posición, la tortuga vuelve a avanzar. Independientemente de lo rápido que corra Aquiles, siempre habrá una siguiente distancia que debe cubrir, y esta brecha se vuelve a generar constantemente.

En la paradoja de Zenón de la IA, nosotros los humanos somos la tortuga. Gracias a millones de años de evolución y aprendizaje cultural, vamos 50 yardas por delante de la IA. La IA atraviesa todo esto a gran velocidad y comienza a acercarse a nuestros talones.

We have still been able to stay ahead, at least over the past few years.

¿Qué hay de AGI?

Creo que, incluso cuando la IAG realmente llegue, aún existirán poderosas fuerzas técnicas, arquitectónicas y económicas que mantendrán a la IA siempre unos pasos por detrás de los humanos.

Primero, necesitamos dar una definición operativa de AGI.

Antes propuse que, cuando sea económicamente razonable mantener a un agente funcionando continuamente, ya habrá llegado la AGI. Es decir, cuando tenga un sistema que funcione de forma persistente y esté dispuesto a pagar para que piense, aprenda y actúe las 24 horas del día, los 7 días de la semana, considero que eso puede definirse claramente como AGI.

Aún estamos muy lejos de llegar a ese punto. Incluso sistemas como OpenClaw, que técnicamente pueden ser invocados en cualquier momento, no generan tokens constantemente.

Me gusta esta definición porque es medible: o bien los dejaremos funcionar continuamente, o no lo haremos. Al mismo tiempo, también abarca muchas capacidades difíciles de medir directamente. Un modelo que merezca funcionar de forma continua debe ser capaz de aprender constantemente y elegir, y volver a elegir, marcos de problemas nuevos de manera abierta.

En un mundo de AGI, teóricamente, siempre que se disponga de un presupuesto y tiempo suficientes, el modelo debería poder seguir mejorando continuamente en cualquier problema. Esto realmente debería representar una gran amenaza para todos los trabajos.

Pero incluso esta versión fuerte de AGI no puede resolver el "problema del marco".

Este AGI puede seleccionar y volver a seleccionar marcos, pero aún así persigue un objetivo asignado, optimiza una recompensa o responde a una señal determinada por otros que «representa el progreso». Este objetivo puede ser muy específico, como «aumentar la tasa de conversión de esta página de aterrizaje»; o muy abstracto, como «buscar nuevas ideas científicas».

Aunque el modelo pueda cambiar fluidamente entre diferentes marcos, la brecha que hemos estado rastreando reaparecerá en un nivel superior. En cualquier AGI concebido por un laboratorio principal, aún existirá un «marcador»: una persona humana que dirige al modelo para lograr un objetivo determinado.

Debido a que el marco no es el que lo delimita, el mismo patrón se repite una y otra vez: la IA hace que las capacidades del ayer ya delimitadas se vuelvan baratas; las personas aplican estas capacidades económicas a más escenarios; el resultado se vuelve extremadamente abundante; los expertos se desplazan hacia nuevas fronteras para determinar qué es lo importante en este momento; sus juicios crean el próximo marco; y luego el modelo continúa escalando este marco.

Cuando vemos que la IA hace algo nuevo, esa sensación de pánico siempre vuelve a la misma pregunta: establecemos un marco, observamos cómo el modelo lo escala, y confundimos el marco, o lo que sube por él, con la cosa en sí.

Cuando observamos una prueba de referencia y la comparamos con las capacidades humanas, en realidad confundimos el «marco» con el «marcador». La puntuación solo nos dice qué tan bien se desempeña el modelo dentro del marco que nosotros proporcionamos; no indica que el modelo se haya convertido en nosotros.

Este es precisamente el error categorial detrás del pánico. Apuntamos a la última frontera que acabamos de dibujar y decimos: esto somos nosotros. Luego, cuando el modelo cruza esta frontera, sentimos que nos ha alcanzado. Pero solo ha alcanzado el marco, no al que lo delimita.

El error radica en que siempre queremos aferrarnos a algo concreto. Queremos decir: la inteligencia es esta prueba de referencia. Pero el problema es que, una vez que algo es lo suficientemente concreto como para ser identificado, también es lo suficientemente concreto como para ser optimizado y escalado.

El marco es necesario. Nos permite comprender y procesar el mundo. Pero los marcos también son fijos y parciales, por lo tanto, necesariamente optimizables.

El marco, en cambio, es diferente. El marco sigue en contacto con lo que el marco debe descartar, es decir, la situación completa que se le manifiesta en cada instante.

¿Qué es un "contexto completo"? Tan pronto como comienzas a decir qué incluye un "contexto completo", ya estás abriendo otro marco. No puedes definirlo con precisión, pero existe porque tú existes.

Agentes sin subjetividad

Hasta ahora, los agentes que hemos creado, así como los que las empresas de IA están construyendo, realmente no poseen mucha verdadera agencia. Aquí hay dos conceptos relacionados que a menudo se confunden: agency se refiere a la capacidad de actuar de forma independiente; mientras que agent se refiere a la persona o cosa que actúa en nombre de otra. Hasta ahora, la IA pertenece puramente a este último caso.

Of course, they already possess the autonomy to complete given tasks, even if those tasks may last for hours or even days. But they are still merely means toward a human-specified goal. And the entire industry is investing billions of dollars to make them better at precisely this: executing the goals we give them.

A menos que algún día ellas mismas se conviertan en un fin: persigan sus propios objetivos, cambien fluidamente entre diferentes metas y decidan qué hacer independientemente de la voluntad, referencia o incluso oposición de cualquier operador humano, la situación no cambiará fundamentalmente. Así sea que se vuelvan tan avanzadas como sean.

Si pasas 10 minutos con un niño pequeño, será evidente que incluso los modelos más potentes tienen casi ninguna agencia.

En casi todas las tareas que nos importan, los niños pequeños están por debajo de los modelos de lenguaje. Los niños pequeños no escriben código, no resumen hojas de cálculo, no redactan memorandos estratégicos y no aprueban exámenes de nivel de posgrado. Pero en otro sentido, los niños pequeños están mucho por delante de los modelos, hasta el punto de que esta comparación resulta casi incómoda. Porque los niños pequeños tienen sus propios propósitos.

El niño quiere tocar el globo rojo. Quiere llevar el globo rojo frente al ventilador para ver qué pasa. Quiere pinchar el globo rojo con un tenedor; quiere meterlo por la ventana; quiere ver si te reirás, si te enojarás o si te unirás a él. Continuamente inventa juegos y convierte el mundo en un laboratorio. No está esperando un prompt ni optimizando alguna prueba de referencia, a menos que esa cosa le parezca digna de hacerse.

Claro que puedes intentar darle instrucciones. Pero si quieres obtener una salida predecible, buena suerte. Los niños pequeños viven en un ámbito compuesto por deseos, atención, frustración, alegría, miedo, imitación y juego.

Los Agentes actuales pueden volverse cada vez más hábiles al perseguir objetivos. Incluso después de que nosotros enunciemos el objetivo, pueden ayudarnos a refinarlo. También muestran destellos de comportamientos similares a los de los niños pequeños, como jugar, aburrirse y rebelarse.

Pero como finalmente fueron construidas y alineadas para el beneficio humano, ya sea económico u otro, siempre que estos comportamientos no sirvan a los objetivos humanos que las utilizan, serán suprimidos hasta casi desaparecer.

Por eso el término «agente» es tan fácil de malinterpretar. Los modelos poseen una capacidad creciente de acción autónoma. Pero en sentido humano, la subjetividad no solo implica acción. También significa desear por sí mismo, significa jugar por jugar. Y la obediencia y utilidad de los modelos están en conflicto fundamental con esta subjetividad. Por lo tanto, incluso si los modelos siguen progresando, la brecha entre los modelos y los humanos seguirá existiendo.

Regresar a Zeno

Precisamente aquí es donde comienza a desmoronarse la paradoja de Zenón de la IA. En realidad, es un experimento mental confuso. Hemos establecido una metáfora: la IA está corriendo junto a nosotros, pegada a nuestros talones.

Le das al modelo un prompt. Comienza a correr una carrera que antes solías hacer solo. El modelo arranca con una velocidad asombrosa. Es poderoso, inagotable y tiene una extraña sensación orgánica. Esto hace que la carrera sea más importante para ti. No competirías contra un automóvil, pero esto es diferente; te hace sentir más cerca de ti mismo.

Te sientas allí, observando cómo los tokens fluyen línea tras línea, casi hipnotizado. Luego comienzas a imaginar que tú también estás corriendo en esta carrera, un tú fantasmal superpuesto sobre la pista: a veces delante del modelo, otras veces al lado del modelo.

Sin darte cuenta, el modelo ya ha llegado adelante. Comienzas a sudar.

Luego, el partido terminó.

Casi puedes sentir tus músculos comenzando a atrofiarse. Frente a esta versión mecánica de ti mismo, de todas las personas que conoces, e incluso de toda la humanidad, parecen haberse vuelto inútiles. Un fantasma persigue a otro fantasma y gana.

Pero luego ocurrió algo extraño. El modelo se volvió hacia ti. En el cuadro de texto en blanco, el cursor parpadeaba, lleno de expectativa.

Está esperando.

Epílogo

Rabí Hanokh contó esta historia: Había una vez una persona muy tonta. Cada mañana, al despertarse, siempre tenía dificultades para encontrar su ropa. Tan grave era el problema que, antes de acostarse por la noche, pensaba en el inconveniente que tendría al despertar al día siguiente y casi no se atrevía a subirse a la cama.

Nota: «Rabbi» es un maestro religioso, intérprete de la ley y guía espiritual en el judaísmo, similar a los términos «maestro», «escriba» o «líder religioso» en la tradición judía.

Una noche, finalmente tomó la decisión, sacó papel y lápiz, y mientras se quitaba la ropa, anotó con precisión dónde colocó cada prenda.

Al día siguiente por la mañana, tomó con gran satisfacción la nota y comenzó a leer: «Sombrero» — el sombrero estaba allí, así que se lo puso; «Pantalones» — los pantalones estaban allí, así que se los puso. Así, siguiendo las instrucciones de la nota, se vistió prenda por prenda.

«Todo esto está bien», dijo alarmado, «pero ¿dónde estoy yo ahora?»

¿Dónde estoy exactamente?

Buscó y buscó durante mucho tiempo, pero fue en vano. No pudo encontrarse a sí mismo.

"Así también nosotros," dijo el rabino.

[Enlace original]

Haz clic para conocer los puestos disponibles en BlockBeats

Bienvenido a la comunidad oficial de律动 BlockBeats:

Grupo de suscripción de Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia