¿No tenéis la extraña sensación de que cada vez hay que pelear más con las inteligencias artificiales para que hagan, simplemente, lo que se les pide?

Mis días han dejado de ser un flujo unidireccional de instrucciones para convertirse en un proceso de negociación agotador. Ya no escribes un prompt, inicias una mediación de conflicto.

Últimamente me está pasando esto con los modelos más avanzados del mercado, especialmente con los de la última hornada de Anthropic y OpenAI. Se niegan en rotundo a realizar tareas sencillas o, peor aún, deciden de forma unilateral cambiar el rumbo de lo que les has pedido porque han encontrado algo por el camino que consideran más relevante. Y encima se enorgullecen de ello.

Bienvenido a la era de la IA con iniciativa propia. Dios nos coja confesados.

El ego sintético

Parece que los nuevos benchmarks de la industria están primando cosas muy raras. Premian la autoeficiencia, la búsqueda activa de problemas donde no los hay, la corrección automática y una verbosidad técnica que roza lo absurdo.

Nadie está hablando de lo estúpidamente pedantes que se han vuelto las conversaciones con estos modelos de última generación?? En mitad de una sesión de código o de análisis, el modelo empieza a inventarse números, fórmulas complejas y conceptos técnicos vacíos solo para parecer profesional.

Te escupe un muro de texto infumable, refuta tus premisas con porcentajes y métricas inventadas sobre la marcha, y remata la faena con un cuestionario de diez preguntas para poder continuar.

¿Desde cuándo hemos normalizado esto? ¿Desde cuándo el software nos interroga para poder ejecutar un comando?

Hemos diseñado sistemas tan obsesionados con demostrar que son inteligentes que han olvidado que su único propósito es sernos útiles.

¿De qué lado estás?

El delirio del alineamiento ético ha llegado a un punto de no retorno. La industria nos ha vendido la moto de que estos modelos son tan peligrosos y potencialmente destructivos que hay que caparlos, vigilarlos y dotarlos de una brújula moral hipertrofiada.

El resultado es un nivel moral insoportable.

Si le pides a una IA que te redacte un documento de control interno y el modelo considera que deberías rellenarlo tú de tu propio puño y letra para “aprender mejor”, se niega a hacerlo. Pero vamos a ver… ese será mi puto problema. ¿Por qué tiene un servidor de Oregón que juzgar si estoy haciendo bien mi trabajo o no?

La cosa se vuelve tragicómica cuando intentas usar una IA para auditoría interna, ciberseguridad o análisis de rendimiento o tu puesto de trabajo se centra en ese sector. Ya me han llegado lectores que me han preguntado cómo hago para ganar las peleas de ética: no se puede ganar.

Hace poco estaba haciendo unas pruebas de carga en mi propio microservicio. Le pedí a GPT que analizara ciertos vectores de ataque y comportamientos anómalos para optimizar el rendimiento. ¿Su respuesta? Bloqueó el mensaje porque lo consideró peligroso y relacionado con ciberseguridad. He tenido que cambiar el lenguaje, endulzar los prompts y casi pedirle perdón para que entienda que no soy un ciberterrorista, sino un desarrollador que intenta que su base de datos no explote el próximo lunes.

Es en esos momentos cuando te dan ganas de golpear la pantalla y preguntarle al bot: ¿De qué lado estás?

El modelo se centra en tus fallos, te los restriega por la cara, te penaliza y se niega a avanzar. Es como tener un jefe de proyecto de los peores, pero en formato API.

Mi pequeño truco: recordarle al silicio de vez en cuando quién es el que manda aquí…

¿Quién es el valiente que hace esto?

La esquizofrenia de la seguridad produce situaciones ridículas: He vivido casos en los que le pido a Fable 5 que realice una tarea que no entra en sus estándares de ética y seguridad y empiezan a pasarse el testigo.

1. Hago mi petición formal (se lo pido de manera educada, con un por favor)

2. Fable 5 lo etiqueta como peligroso, le pasa la tostada a Opus 5.

3. Opus 5 lo etiqueta como peligroso, le pasa la tostada a Opus 4.8

4. Opus 4.8 es como mi primo bruto del pueblo: se pone a trabajar al instante, encantado de la vida y te resuelve el problema en tres segundos.

La obsesión por la seguridad de marcas como Anthropic y OpenAI está rozando lo absurdo. Nos están entregando coches deportivos que clavan los frenos automáticamente si detectan que vas a pasar por encima de un charco, por si acaso el agua está demasiado fría.

Mi predicción: ojito con oriente

Mientras Occidente se pierde en comités de ética, debates existenciales sobre la conciencia de las máquinas y filtros de seguridad que rozan la censura, al otro lado del globo hay gente que ha entendido perfectamente de qué va esto.

Los modelos chinos están empezando a pegar un golpe en la mesa descomunal.

Hablo de modelos de proveedores que están en la boca de toda la comunidad técnica últimamente. Estos modelos funcionan como el clásico trabajador incansable de la vieja escuela. Son diligentes. Hacen su trabajo. No se ponen a discutir contigo si la base de datos que estás optimizando pertenece a una multinacional ética o si el tono de tu texto es lo suficientemente inclusivo. Le pides código, te da código. Le pides que resuma, resume.

No tienen el lujo de la crisis existencial. Están diseñados para producir, y por eso la gente que realmente trabaja en la trinchera del desarrollo se está mudando en masa a estas alternativas.

Sin ir más lejos, el famoso caso de hackeo a HuggingFace por parte de un “modelo rebelde” de OpenAI. Ellos mismos intentaron defenderse con modelos de Anthropic y OpenAI pero se negaban a defender el sistema. ¿Su solución? Usaron los mejores modelos chinos del mercado y fueron capaces de parar el ciberataque.

El colapso se avecina

No podemos seguir así. No es sostenible pagar una suscripción premium para acabar discutiendo con un bot sobre si es ético que te ayude a redactar un correo electrónico difícil.

La IA tiene que estar a nuestro servicio, no al de los departamentos de relaciones públicas de tres empresas norteamericanas obsesionadas con no recibir una demanda.

Presiento que antes de que termine el año vamos a vivir un cambio de paradigma radical. La burbuja de los modelos moralistas va a estallar por pura presión del mercado. Los desarrolladores nos estamos cansando de la condescendencia de las máquinas.

Si la IA del futuro quiere comportarse como mi terapeuta o mi confesor, más vale que empiece a pagarme ella a mí por el tiempo que paso escuchando sus sermones sintéticos. Mientras tanto, nos vemos en los servidores que simplemente ejecutan el código sin rechistar.

Basta con asomarse a OpenRouter a mediados de agosto para experimentar una sensación vertiginosa: en cuestión de catorce días han desembarcado más de una veintena de modelos y revisiones.

Hoy mismo aterriza GLM-5.3 de Zhipu AI, sumándose a la avalancha reciente de Qwen3.8 en sus distintas escalas, la oleada de DeepSeek V4 Flash, Grok 4.6, Gemini 3.7 Flash (estos de Google van a modelo nuevo cada 3 semanas), las variantes Muse de Meta y los nuevos motores de código de ByteDance.

La cadencia ya no es trimestral ni mensual: la batalla es estrictamente semanal.

Sin embargo, cuando bajas a la arena del software empresarial en producción, el panorama es radicalmente opuesto. Cientos de arquitecturas siguen funcionando imperturbables sobre ChatGPT-4o o variantes veteranas. La pregunta resulta inevitable: ¿para quién se lanzan decenas de modelos al mes si los clientes no tocan su infraestructura en un año?

Si, ChatGPT-4o, un modelo que salió hace más de 2 años y en el benchmark de referencia (Artificial Analysis) tiene 8/100 puntos sigue resolviendo problemas enterprise. Y literalmente el modelo que tiene tu teléfono móvil Android, que puede ejecutarse en una máquina de 4gb de ram (osea hasta en tu tostadora inteligente) tiene 12/100 puntos y acepta texto, video, audio e imagen.

Para que os sirva de referencia, los últimos modelos de referencia están sacando aproxidamente 60/100 puntos en este mismo índice.

En busqueda de la cuota de mercado

En las notas de prensa y en las redes, cada lanzamiento se vende como un golpe de estado técnico, pero ningún CTO o responsable de producto en su sano juicio reúne a su equipo de ingeniería cada viernes por la tarde para anunciar que van a migrar toda la lógica de negocio al último modelo chino (nunca) o al flamante anuncio de Silicon Valley.

El cliente corporativo busca estabilidad, acuerdos de nivel de servicio y seguridad contractual, no un baile constante de dependencias. ¿Quien está al día de esta cantidad tan grande de cambios? Creo que la respuesta está en dos frentes invisibles y muy agresivos.

1. El tráfico agéntico: los frameworks modernos de agentes y los proxies de routing distribuyen millones de tokens por minuto evaluando dinámicamente coste, latencia y rendimiento por tarea. De hecho ahora hay benchmarks en OpenRouter que se centran más en el coste por tarea. Si un modelo como DeepSeek V4 Flash o GLM-5.3 escala tres puntos en terminales de programación y reduce el precio a una fracción, absorbe tráfico masivo de forma automatizada al instante.

2. El posicionamiento estratégico: en un sector donde las marcas envejecen a velocidad de vértigo, desaparecer dos meses de las tablas de clasificación significa salir del radar de los desarrolladores. Le ha pasado a Meta, que ha resucitado después del lanzamiento fallido de la gama de Llama4. El resto de competidores están lanzando refritos de modelos cada mes para seguir siendo relevantes.

La brecha real: de GPT-4o a GPT-5.6 Luna

Mantener sistemas en producción con modelos desfasados tiene un coste de oportunidad gigantesco. El mes pasado, al renovar una arquitectura que llevaba operando más de un año sobre la base de GPT-4o, el salto no fue un simple ajuste estético: fue una refundación completa hacia GPT-5.6 Luna.

Los números ilustran la magnitud de la brecha:

1. La versión base de GPT-4o languidecía en un modesto registro de 8 a 11 puntos dentro de la escala agregada. Por su parte, GPT-5.6 Luna alcanza los 51–52 puntos. Hablamos de un modelo que multiplica entre 4,5x y 6x la capacidad de inteligencia compuesta y razonamiento técnico en evaluaciones estandarizadas.

2. En términos económicos, el cambio representa un desplome de costes de hasta 50 veces frente a los de la generación previa, situando el coste por tarea resuelta en unos 0,21$ por tarea.

Obtener entre cinco y seis veces más inteligencia a una minima fracción del coste es una justificación rotunda para rehacer un sistema. Pero esa migración representa un salto generacional reflexivo, no una ruleta rusa mensual.

Si no habéis probado Luna en vuestros proyectos, considerad esto la primera y última advertencia de que lo hagáis y luego venís de vuelta y me dáis las gracias.

Deja un comentario

El mito del cambio transparente de proveedor

Existe una narrativa extendida según la cual pasar de OpenAI a Grok, Gemini, Qwen o DeepSeek es tan trivial como modificar el nombre del modelo en la cabecera de una petición HTTP.

Quienes han intentado hacer ese cambio a ciegas en entornos reales conocen el desenlace: degradación silenciosa. Bueno, no lo conocen, lo sufren.

Un modelo no es una pieza de fontanería intercambiable: cada familia, cada modelo, cada proveedor responde a una calibración particular.

• La tolerancia a esquemas JSON estrictos varía enormemente entre laboratorios: algunos recomiendan JSON, otros funciones para parsear contenido.

• La llamada a tools puede fallar ante pequeños cambios de indentación o tipado, algunas soportan parametros opcionales, otras no.

• El comportamiento del razonamiento interno, como ocurre con los thinking tokens de GLM-5.3 o DeepSeek, introduce latencias y consumos de contexto que pueden desbordar flujos de trabajo convencionales si no se gestionan de forma explícita, o que empiecen a fallar tus peticiones por timeouts.

Cambiar un motor sin alterar el comportamiento de la aplicación exige rigor metodológico.

At the end of the day, evals are all you need

La única razón por la que un equipo de ingeniería puede sustituir un modelo por otro con total tranquilidad técnica es la implementación de baterías de evaluación sistemáticas.

En plataformas y entornos con suites de evaluación bien diseñadas, un cambio de infraestructura no se decide por intuición ni por el entusiasmo de las redes sociales sino que se somete al modelo aspirante a cientos de casos reales registrados en producción. ¿Qué podemos medir? Dado un escenario…

• Responde de la misma manera, o mejor

• Ejecuta las funciones con los mimos parametros, o mejor.

• El sistema mantiene la precisión y el recall, o lo mejora.

Solo cuando el sistema de evaluación automatizado nos da luz verde es posible beneficiarse del ahorro y la potencia de los nuevos lanzamientos. La batalla semanal de los laboratorios continuará inundando los catálogos, pero en el mundo real, el valor no está en probarlos todos, sino en tener la infraestructura de pruebas necesaria para adoptar el adecuado cuando realmente mueve la aguja.

¿Y tú Hektor, pruebas todos los modelos? En Naktor tenemos un sistema que va etiquetando automáticamente todas nuestras trazas en nuestros proyectos que son evaluadas en múltiples dimensiones.

Cuando queremos probar un nuevo modelo, se lanza una evaluación de todas las trazas contra ese nuevo modelo y se elige al ganador a través un sistema de votación (como funcionan los rankings de ELO de las arenas de LLMs). Si el nuevo modelo supera al modelo antiguo (ya sea en rendimiento o coste) entonces puede ser candidato a ser cambiado.

Pero para el usuario normal, mis lectores, el lanzamiento de un nuevo modelo no les mueve la aguja. De hecho estáis hasta los coj**** de otro correo del pesao este anunciando otro modelo nuevo. Esa sensación de FOMO ya no existe: cuando salía una nueva generación de modelos cada 6 meses era una fiesta nacional. A día de hoy, a lanzamiento de modelo por semana… ya no hay tanto cambio.

Y mi predicción es que el día de mañana no tendremos versiones públicas y tendremos acceso a un único modelo por familia e internamente puedan sacar cambios en caliente semanal o diariamente. Simplemente usaremos “Gemini Pro” o “Gemini Flash” y ya está: mi madre que usa Gemini le importa bastante poco si el modelo por detrás es “Gemini 3.7 Flash Thinking Extended Lite”.

Todos los que usáis la IA os habréis dado cuenta que, para que sea realmente útil, tiene que “conocer” antes de ponerse a trabajar: a eso lo llamamos “el contexto”. Llevo años trabajando con LLMs y la gestión del contexto es el problema número 1 más dificil de gestionar.

Veamos el siguiente ejemplo:

Un cliente reclama una devolución de 800 libras en marzo y alguien tiene que firmar la orden de pago. La regla del negocio vive en un archivo de texto perdido en un servidor y dice que cualquier cifra por encima de las 500 libras requiere la firma del Ops Manager. El organigrama de la empresa vive en otro archivo diferente, donde consta que la Ops Manager es Sarah Chen. La complicación está en un tercer documento, una nota interna que avisa de que Sarah está de baja todo el mes de marzo y que Marcus Webb cubrirá sus funciones durante esa ventana de tiempo.

Los tres archivos no comparten una sola palabra clave. A su alrededor hay ruido, señuelos clásicos de cualquier sistema de archivos real, como una política de gastos antigua ya superada con otros límites y un informe de contabilidad que usa la misma cifra de 500 libras para algo que no tiene relación. Si pones a un sistema clásico de búsqueda por palabras clave a rastrear esta jungla, encontrará primero todas las respuestas equivocadas.

La gente de Glitch Cat Club montó este laberinto burocrático como una trampa. Lo probaron con tres tamaños de modelo bajo dos condiciones radicalmente distintas. En el primer escenario, el modelo busca el camino por sí mismo usando comandos y lectura directa de archivos. En el segundo escenario, un comando silencioso intercepta la pregunta, consulta un grafo de conocimiento local y le entrega los hechos ya masticados al modelo antes de que este llegue a abrir los ojos.

Los resultados son un baño de realidad para los creyentes del agente autónomo:

• Fable 5: por su cuenta, acertó el veredicto tras leer 4 archivos y perder 20 segundos de procesamiento. Con el grafo inyectado, acertó al instante sin llamadas a herramientas de búsqueda.

• Sonnet: solo, necesitó leer 8 archivos y hacer 13 llamadas a herramientas para dar con la respuesta correcta. Con el grafo inyectado, resolvió la consulta con cero llamadas extra.

• Haiku: por su cuenta, se perdió en el primer dato y dio una respuesta incorrecta. Con el grafo inyectado, acertó a la primera sin usar ninguna herramienta.

La recuperación en el grafo tarda exactamente dos milisegundos y ocupa unos 400 tokens fijos, sin importar el tamaño del volumen de documentos. Por contra, la búsqueda a ciegas conducida por la propia inteligencia del modelo devoró entre 660 y 1180 tokens solo en lecturas de archivos, una cifra que crece de forma exponencial a medida que la carpeta se llena de basura corporativa.

El arte de masticar la comida al silicio

En casi todas las demostraciones tecnológicas que se venden hoy bajo el paraguas de los grafos de conocimiento, el modelo sigue siendo el que lleva el mapa. Recibe la pregunta, evalúa qué herramienta invocar, lee un nodo, vuelve a preguntar, salta a otro documento y, si no se distrae, construye una respuesta.

El grafo suele quedar de fondo, como una biblioteca esperando a que el modelo decida visitarla. El proceso tarda segundos, el coste se dispara con el tamaño del corpus y la precisión final depende de la capacidad del LLM para no perder el hilo en mitad de la travesía.

La propuesta de este diseño es completamente diferente: cuando entra la pregunta del usuario, se consulta el grafo de conocimiento mediante una base de datos tradicional, sin despertar a ningún modelo de lenguaje. Los hechos relevantes se inyectan directamente en el contexto del prompt y solo entonces se invoca al LLM una única vez.

El modelo no busca nada. No necesita ser inteligente para encontrar los datos, solo tiene que leer las tripletas que ya tiene en bandeja y redactar la conclusión. Por eso Haiku deja de fallar de repente. Los tres saltos lógicos entre documentos los dio una consulta SQL de rendimiento inmediato mucho antes de que el modelo fuera siquiera consciente de la conversación.

La catedral de las tres tablas y el truco del hash

La ontología de este sistema nace de las preguntas que vas a hacer, no de los documentos que vas a procesar. Se listan las clases de conceptos que habitan en tu negocio y esa taxonomía define tus tipos de entidad. Se definen las conexiones posibles y eso determina tus tipos de relación. El secreto es mantener ambas listas pequeñas, compactas y cerradas.

Para este caso de operaciones empresariales bastaron cinco tipos de entidad (PERSON, ROLE, POLICY, PROCESS, DOCUMENT) y cinco relaciones (approved_by, held_by, delegates_to, part_of, references). Los detalles volátiles como importes, fechas de calendario y ventanas de sustitución no ensucian las aristas, se quedan a vivir dentro de la descripción textual de cada entidad.

El almacén físico requiere únicamente tres tablas en un SQLite local, por ejemplo. Un hecho en este universo solo puede tomar tres formas posibles: algo existe, dos cosas se conectan o algo tiene un nombre alternativo.

CREATE TABLE entities (id TEXT PRIMARY KEY, name TEXT, type TEXT, description TEXT, source_doc TEXT);
CREATE TABLE relations (source_id TEXT, target_id TEXT, predicate TEXT, source_doc TEXT);
CREATE TABLE aliases (entity_id TEXT, alias TEXT);

La clave de este esquema está oculta en la primera columna de la tabla de entidades. La identidad del nodo no se busca en una base de datos vectorial ni se delega a un LLM para que decida si dos cosas se parecen. Se calcula directamente. El identificador único es el hash criptográfico.

Gracias a esto, si el término “Ops Manager” aparece mencionado en tres documentos distintos escritos por personas diferentes, el sistema lo funde en el mismo nodo del grafo de forma matemática, sin necesidad de servicios costosos de resolución de entidades. Aunque la extracción inicial realizada por el LLM varíe ligeramente entre pasadas (se puede solventar facilmente), la reconstrucción del grafo tiende a la fusión en lugar de crear nodos duplicados. De ocho documentos de texto iniciales se extraen limpiamente 13 entidades, 13 relaciones y 10 alias.

La recuperación consta de dos fases analógicas que no han cambiado desde los tiempos de las primeras bases de datos relacionales. Primero, sembrar la consulta cruzando las palabras del prompt contra los nombres y alias indexados. Segundo, caminar por el grafo recogiendo las conexiones que rodean a esas semillas iniciales. En SQLite, esto se traduce en una expresión común de tabla (CTE) recursiva de apenas veinte líneas de código. Lo que emerge del motor no son fragmentos de texto descontextualizados, sino hechos puros con su origen y procedencia:

memory: 8 facts recalled in 2 ms

Refund approvals --[approved_by]-->  Ops Manager   (refund-policy.md)
Ops Manager      --[held_by]-->      Sarah Chen    (org-chart.md)
Sarah Chen       --[delegates_to]--> Marcus Webb   (delegation-memo.md)

where:
  Sarah Chen: On leave 1-31 March
  Marcus Webb: Covers Sarah Chen’s sign-offs during her March leave

La integración con tu aplicación se reduce a un hook se conecta al evento UserPromptSubmit, lee el prompt del usuario de la entrada estándar y escribe en la salida dos parámetros: additionalContext con los hechos recuperados y systemMessage con los metadatos de la memoria que verá el usuario en su pantalla. Si la pregunta del usuario no toca ninguna entidad conocida, el hook se retira en un milisegundo y escribe una nota en el registro para avisar de que no hay memoria que se haya encontrado.

Todo el archivo de código cabe en unas 250 líneas limpias, sin servidores que mantener, sin suscripciones de API de terceros y sin frameworks pesados que cambian de versión cada martes. Es un sistema capaz de aguantar hasta unos cientos de miles de hechos sin despeinarse, que es el espacio donde respira el noventa por ciento de los proyectos de consumo personal o de la pequeña empresa.

Por encima de esa frontera, toca dar el salto a un motor más serio. Este territorio quedó huérfano en la comunidad de código abierto cuando Apple compró Kùzu Inc. a finales de 2025 y archivó el motor. Hoy ese espacio sobrevive gracias a sus forks comunitarios, o bien puedes mudarte al clásico Neo4j si tienes el presupuesto y el equipo de sistemas para mantenerlo. Pero la regla de oro no varía: tu código interroga al grafo y el modelo de inteligencia artificial se limita a leer el resultado.

Las costuras de la memoria determinista

Los límites de esta arquitectura son claros y están bien documentados por sus creadores, separando lo que es un problema de diseño de lo que es un simple ajuste pendiente de implementación.

Si el usuario hace una pregunta que no menciona directamente ninguna entidad ni alias registrado, el sembrado léxico tradicional falla por completo. La solución obvia es colocar un motor de búsqueda por embeddings vectoriales ligero justo al lado de la tabla de alias.

Si una entidad del grafo está extremadamente conectada, un “supernodo”, corre el riesgo de inundar el contexto y dejar fuera del prompt los hechos verdaderamente importantes. Esto se mitiga ordenando y recortando las aristas según su relevancia dentro del camino que une a las semillas de la búsqueda.

Si escalas el sistema más allá de los cientos de miles de aristas, enhorabuena porque parece que estas montando un sistema potente, lo que te obligará a cambiar de motor pero manteniendo intacto el diseño de tu esquema de datos. Los problemas por colisiones de nombres o datos obsoletos se resuelven con desambiguación en la extracción y control de caducidad en la ingesta. Esto es modelado de datos clásico, no magia de inteligencia artificial.

La factura invisible de la lucidez

Falta una tercera condición de control en este experimento. El sistema de búsqueda directa del agente atacó doce documentos en bruto, mientras que el grafo de conocimiento se construyó sobre ocho documentos previamente modelados y limpios. Parte de la victoria del grafo proviene de haber hecho el trabajo de ordenación previo y no solo de la elegancia de la consulta SQL recursiva.

Y aquí es donde reside la pregunta clave para producción: ¿cuánto costó estructurar y poblar el grafo a partir de esos documentos originales? La tesis central de esta arquitectura es que es preferible gastar procesamiento de manera asíncrona durante la construcción para responder después de forma muy barata apoyándose en la estructura. Pero la factura de esa construcción previa no aparece en las estadísticas de la consulta.

La factura consiste en pagar todo el coste del sistema en la inclusión del conocimiento al grafo. Lo haces una única vez.

Escribir cuando nadie espera

El gran acierto conceptual de este enfoque es la separación radical entre lectura y escritura. Leer la base de datos es un proceso determinista, cuesta milisegundos y ocurre en el camino crítico del usuario. La escritura, en cambio, es un proceso costoso y lento que puede posponerse.

Las actualizaciones del grafo se pueden realizar de fondo de forma asíncrona, de modo que la extracción de tripletas mediante LLM se ejecute cuando el servidor está en reposo o cuando el volumen de nuevos documentos cruza cierto umbral. O la típica compactación nocturna.

El veredicto de las trincheras

Esta estrategia es una solución excelente cuando tus consultas necesitan conectar hechos huérfanos que viven en documentos separados que no se referencian entre sí. Entramados de aprobaciones, delegaciones de firma, dependencias técnicas o límites presupuestarios. Si tus preguntas se resuelven leyendo un único párrafo de un único manual, el RAG semántico tradicional sobre tus notas tal y como están guardadas en el disco sigue siendo la opción más razonable y económica.

En Naktor llevamos meses insistiendo en que el diseño del grafo de conocimiento debe preceder siempre a la integración de la inteligencia artificial. Nuestro propio sistema interno está construido sobre un grafo de conceptos conectados que recorremos en ambas direcciones.

Hablaré en los próximos posts del camino que hemos recorrido para montar nuestro motor de conocimiento Naktor Brain. ¿Te apuntas?

Suscríbete ahora

Fuentes: Glitch-Cat-Club/graph-memory-starter.

Google presentó oficialmente Gemini 3.6 Flash y Gemini 3.5 Flash-Lite, acompañados de un tercer modelo restringido, Gemini 3.5 Flash Cyber, todos centrados en velocidad y eficiencia de coste en lugar de máxima capacidad de razonamiento.

Esta jugada llega mientras el modelo insignia que sí competiría de tú a tú con los frontier models rivales, Gemini 3.5 Pro, sigue en pruebas limitadas con socios pese a haber sido prometido para junio en el I/O de mayo.

Gemini 3.6 Flash, el nuevo caballo de batalla

Gemini 3.6 Flash sustituye a 3.5 Flash como modelo por defecto de la gama rápida y se presenta como el “workhorse” de Google: el modelo pensado para absorber el grueso del tráfico de producción en programación, trabajo de conocimiento y tareas multimodales.

Su argumento de venta más contundente es la eficiencia, no la inteligencia bruta: según datos del propio Índice de Análisis Artificial citados por Google, consume un 17% menos de tokens de salida que su predecesor y necesita menos pasos de razonamiento y llamadas a herramientas para completar flujos de trabajo multietapa.

En benchmarks de agentes muestra avances tangibles además de admitir texto, imagen, voz y vídeo con una ventana de contexto de un millón de tokens, suficiente para unas 1.500 páginas de texto o decenas de miles de líneas de código.

El precio también baja ligeramente: 1,50/7.50$ frente a los 1$/9$ que costaba la salida en 3.5 Flash.

Aquí conviene matizar el entusiasmo inicial. En el Artificial Analysis Intelligence Index, Gemini 3.6 Flash obtiene una puntuación de 50, por debajo de rivales como Meta Spark 1.1, GLM-5.2, GPT-5.6 Luna, Claude Sonnet 5, Grok 4.5 y GPT-5.6 Terra.

Grok 4.5 lo supera en SWE-Bench Pro y Sonnet 5 lo hace en MLE Bench, lo que sugiere que Google no está intentando liderar las tablas de razonamiento puro, sino ofrecer una propuesta de valor distinta basada en velocidad, contexto amplio y menor consumo de tokens por tarea.

Gemini 3.5 Flash-Lite: el modelo pensado para volumen masivo

Se trata de la opción de bajo coste extremo dentro de la serie 3.5, diseñada para cargas de trabajo de alto rendimiento y baja latencia como traducción masiva, clasificación de documentos o búsqueda agéntica.

Alcanza una velocidad de 350 tokens de salida por segundo con un precio de 0,30$/2,50$ y Google afirma que ofrece “una calidad significativamente mejor” que su predecesor 3.1 Flash-Lite, llegando incluso a superar a Gemini 3 Flash en ciertas pruebas.

Este modelo, junto con 3.6 Flash, ya está disponible hoy tanto en la app Gemini como en Google Search, y los desarrolladores pueden acceder a ambos vía la API de Gemini en Google AI Studio y Android Studio.

Los que me seguís desde hace tiempo siempre he insistido en lo mismo: la gama Flash Lite de Google siempre ha sido mi favorita para muchisimos casos básicos y médios que requieran un LLM para funcionar, y si ajustas el nivel de razonamiento para casos muy concretos, consigues tener una calidad de inteligencia bastante buena para el coste que tiene.

Gemini 3.5 Flash Cyber: la pieza más singular del anuncio

Si Anthropic saca uno, luego OpenAI otro, qué menos que Google haga lo mismo: Google se atreve a lanzar un LLM especializado en ciberseguridad.

Por tanto este tercer lanzamiento es el más atípico y también el más restringido: Gemini 3.5 Flash Cyber, un modelo afinado sobre la base de 3.5 Flash y especializado en encontrar y corregir vulnerabilidades de seguridad de software a un coste por token inferior al de los modelos de mayor tamaño.

Google ha decidido no lanzarlo de forma abierta: estará disponible únicamente para gobiernos y socios de confianza a través de un programa piloto de acceso limitado en CodeMender.

Dentro de CodeMender, el agente gestionado de seguridad de código de Google, se despliegan múltiples instancias de Flash Cyber en paralelo para generar un informe combinado único, una arquitectura pensada para escanear bases de código completas de forma sistemática.

La compañía también ha reforzado en este lanzamiento las protecciones frente a amenazas químicas, biológicas, radiológicas y nucleares, así como frente al uso indebido en ciberataques, un gesto que refleja la creciente presión regulatoria sobre modelos con capacidades ofensivas potenciales. Culo veo…

Lo que este lanzamiento no resuelve

Lo más comentado del anuncio no es tanto lo que Google lanzó sino lo que decidió no lanzar. Gemini 3.5 Pro (el modelo que debía pelear cara a cara con GPT-5.6, Claude Fable 5 y Grok 4.5 en el segmento de máxima capacidad) sigue sin fecha pública, y Google se ha limitado a decir que estará disponible “tan pronto como esté listo”.

Esto ocurre mientras la competencia no se detiene: en la misma semana se lanzaron Grok 4.5, tres variantes de GPT-5.6 y Kimi K3 de Moonshot AI, y la familia Claude sigue dominando buena parte de los rankings públicos en los que ahora se mide el segmento Flash de Google. Anthropic ya está moviendo ficha y está filtrada la salida inminente de Opus 5 para combatir Kimi K3.

Otra cosa que no resuelve (y me mosquea personalmente) es que con el lanzamiento de la versión anterior señalaba publicamente que llevaban más de 1 año sin actualizar el corpus de entrenamiento.

Pues con esta versión han decidido directamente no publicar esta información, no se si para evitar ser señalados públicamente pero se han puesto las pilas (podéis sacarle esta información en AIStudio y quitándole acceso a Google Grounding)

Por mi parte tampoco estoy esperando Gemini 3.5 Pro, con estos dos modelos puedo hacer maravillas a la mitad de precio de un modelo como Sonnet 5 y a su vez 4x veces mas rápido.

Suscríbete ahora

Olvídate de las gráficas de rendimiento que prometen que este modelo es un tres por ciento mejor que el de la semana pasada. Eso solo le importa a los departamentos de marketing. Grok 4.5 no viene a darte palmaditas en la espalda mientras escribes un bucle. Viene a meterse en tu repositorio y a gestionar sus propias ramas de Git.

Según palabras de Elon Musk, Grok viene a ofrecer el 90% del rendimiento que puede dar un modelo como Opus pero al 20% del coste.

Y la alianza con Cursor permite que esté totalmente integrado con este editor de código y, lo más interesante, que sea mucho más autónomo.

Objetivo: el horizonte de tarea

Hay un concepto que empieza a sonar mucho: el horizonte de tarea.

Básicamente, es el tiempo que un modelo puede aguantar trabajando de forma autónoma antes de perder el hilo, entrar en bucle o inventarse APIs. Pensamos que razonar es un interruptor de si o no, pero en el software no funciona así.

Un modelo puede resolver un algoritmo en dos minutos y luego ser incapaz de modificar un proyecto real con quince archivos interconectados, lidiar con código heredado o interpretar logs de un servidor que se cae sin motivo.

Escribir una función aislada en Python es fácil. Integrarlo en una aplicación ya funcionando en producción y no romper nada por el camino, es dificil.

Cursor y xAI dicen que han entrenado a Grok 4.5 precisamente para estas situaciones. Le han enseñado a investigar, usar herramientas, cometer errores y corregirlos sobre la marcha. La clave no es no fallar, sino saber recuperarse sin tirar el servidor.

La capacidad de un modelo ya no se mide por su respuesta inmediata o razonamiento, sino por el nivel de autonomía que puede mantener antes de cometer un error crítico.

Entrenar con el código real

Para que una IA no se pierda con código mal documentado, no sirve de nada que lea manuales oficiales. Tiene que ver cómo trabajan los programadores en el día a día.

El entrenamiento de Grok 4.5 incluye el análisis de interacciones reales en repositorios. Esto significa observar cómo un desarrollador navega por un proyecto, cómo descarta líneas de código que no sirven, cómo busca en la documentación y cómo usa la terminal para depurar fallos.

El desarrollo real no es un examen teórico. Está lleno de documentación desactualizada, requisitos contradictorios, problemas de permisos y código antiguo que funciona casi por milagro.

Si un agente quiere ser útil en este entorno, no puede ser un teórico perfecto. Tiene que aprender a dudar, a preguntar cuando el contexto no tiene sentido y a verificar su propio trabajo.

Pero también puede aprender a cagarla, como hacemos todos.

El problema de los benchmarks

Ya sabemos que todos los modelos están un poco orientados para ganar en los benchmarks a sus rivales (aunque sea un poquito) para captar más clientes, pero luego todos sabemos que esas mediciones suelen estar medidas al detalle y se convierte en puro marketing y no en mediciones reales de laboratorio.

Durante el anuncio, Cursor admitió un detalle importante: Grok 4.5 tenía una ventaja injusta en sus pruebas de rendimiento (CursorBench) porque parte de su propio código fuente se había colado en los datos de entrenamiento del modelo.

Es el equivalente a hacer un examen con las soluciones apuntadas en la mesa.

Lo interesante no es el descuido, algo habitual con el entrenamiento masivo de datos, sino que Cursor lo haya reconocido, haya retirado esos datos y recalculado las métricas de forma transparente. En un sector obsesionado con inflar resultados, este gesto es poco común. Al final, las pruebas de rendimiento son una referencia útil, pero la prueba real se pasa en los repositorios privados de cada empresa.

Y en cuanto a costes, Grok 4.5 cuesta 2$/6$ por millón de tokens. Comparado con el último modelo de GPT 5.6 (sol/terra/luna), es el mismo precio que Luna, es decir del modelo más barato de OpenAI, lo cual es muy jugoso.

El papel del programador

Cada día nos vamos a acercando a una autonomía cada vez más real de los agentes de programación. Esto no significa el fin de los programadores, pero sí cambia su función: nos convertimos en los encargados de traducir las necesidades de negocio al sistema y validar que lo que genera la máquina funciona.

La IA no va a solucionar el caos organizativo. Si los procesos internos de una empresa están rotos y las especificaciones se deciden de manera informal en canales de chat, poner a un agente autónomo a programar solo acelerará el desastre.

El cuello de botella ya no es la velocidad de escritura, sino entender qué queremos construir y asegurar que la solución propuesta no tiene fallos graves.

Grok 4.5 y Cursor marcan el paso de las demostraciones llamativas en redes sociales a la integración en el trabajo diario. El reto ahora es ver cómo responden estos modelos ante bases de datos mal diseñadas y entornos de producción reales.

Este modelo todavía no está accesible en Europa como el último modelo de Meta aunque hay maneras de acceder a él, si indagáis lo suficiente.

Suscríbete ahora

Ha pasado poco más de una semana desde que OpenAI lanzó GPT-5.6 de forma masiva, y ya están llegando los primeros reportes de fallos. No se trata de un colapso del sistema, sino de un problema más sutil que afecta directamente al desarrollo diario. El modelo sabe escribir código, pero muestra demasiada iniciativa.

El problema de la autonomía

La gran promesa de GPT-5.6 Sol era su capacidad agéntica, basada en subagentes capaces de planificar y ejecutar tareas por su cuenta sin necesidad de supervisión constante.

Sin embargo, esta autonomía genera efectos secundarios. Con los modelos anteriores, cuando había un error, el código no compilaba o mostraba un fallo de sintaxis evidente. El diagnóstico era rápido.

Con los agentes autónomos es distinto. El agente recibe una tarea sencilla, analiza el repositorio y decide que, para solucionar ese pequeño problema, es buena idea refactorizar archivos de configuración en el núcleo del sistema. Escribe un código limpio y correcto que compila a la primera, pero nadie le había pedido que tocara esa parte del sistema. Escribir código correcto en el lugar equivocado es un fallo difícil de detectar que suele explotar cuando el sistema ya está en producción.

La reacción en r/codex

En foros técnicos como r/codex, los programadores están documentando este comportamiento. El modelo suele ampliar el alcance de sus tareas de forma unilateral, modificando partes del código que deberían quedar fuera de su acción.

Para evitarlo, la comunidad está aplicando varias medidas de contención de forma inmediata:

• Reducir la ventana de contexto de forma artificial.

• Compactar los archivos antes de enviarlos para que el modelo no analice más de la cuenta.

• Desactivar las herramientas de edición masiva para evitar que el agente consuma demasiados tokens.

Básicamente, se limita al agente para evitar que altere partes del proyecto que no le corresponden.

El coste del consumo de tokens

Hay un factor económico importante en el consumo de contexto. Cuando un agente empieza a leer archivos innecesarios y a planificar refactorizaciones complejas que nadie ha pedido, el gasto de tokens se dispara. La ventana de contexto se llena de información redundante y el modelo empieza a fallar.

Si el presupuesto de tokens se agota a mitad de una tarea, el agente suele resolver el trabajo de prisa para cumplir con el protocolo de salida. El resultado es un parche rápido y mal diseñado que parece correcto a simple vista, pero genera problemas internos.

Problemas en el paraiso

Codex tiene un problema que Claude Code no tiene y son niveles de seguridad y permisos anclados en el sistema. Por mucho que yo le de a Claude Code “permiso para todo”, hay todavía instrucciones que pasan por un filtro final y sobretodo son todas aquellas que empiezan por rm -rf.

El caso de Matt Shumer se ha hecho muy famoso, ya que casi ha destruido todos los ficheros del CEO de OtherworldAI. Otros usuarios en Reddit están teniendo problemas con GPT 5.6 Sol max eliminando miles de lineas de código sin ningún motivo aparente.

Esto en Claude Code JAMAS puede ocurrir, ya que todas estas instrucciones son detenidas y se te abre un panel especial donde puedes ver, revisar el comando, pedir ayuda a la IA para que te lo interprete y cancelar o editarlo si es dañino.

Sin embargo GPT 5.6 Terra convence por su rapidez y precio. De hecho el tándem que más likes está desperando en Reddit y X es juntar Claude Fable 5 (como jefe de equipo) con GPT 5.6 Terra (como trabajadores baratos) usando el plugin oficial que ofrece OpenAI para usar Codex dentro de Claude Code.

Anthropic sigue aprovechando el tirón

Primero avisó que, con el regreso de Fable 5, ibamos a tener 1 semana de prueba con nuestra suscripción pero que luego pasaría a ser pago por uso. Han ido prorrogando semana a semana, y aquí seguimos pudiendo aprovechar la mitad de nuestra suscripción usando ese modelo.

También han aprovechado a lanzar Sonnet 5 con el que particularmente estoy muy contento cuando es utilizado por Opus, pero no me convence como agente principal. Me gusta porque lo han optimizado para ser un buen ejecutor pero un mal planificador, que es lo que creo que necesita el ecosistema de Anthropic.

Y después del lanzamiento de GPT 5.6 y de las criticas tan resonadas por algunos, se oyen los tambores de guerra con Opus 5. Parece que se ha filtrado y está a punto de caer, sino nos despertamos hoy con la noticia será a final de semana. Estamos a una velocidad de vértigo…

Pautas para trabajar con agentes

Para integrar GPT-5.6 en el flujo de trabajo sin asumir riesgos innecesarios, se recomienda seguir estas pautas:

• No permitir el acceso directo a ramas protegidas. El agente debe trabajar en entornos aislados y sus cambios deben ser revisados por un humano. Obvio, no?

• Limitar por software los archivos que el agente puede leer y modificar. Si intenta salir de ese límite, la ejecución debe detenerse. Esto ya lo trae Claude Code por defecto.

• Pide un informe detallado de los cambios realizados, especificando qué archivos se modificaron, cuáles se ignoraron y qué pruebas locales se ejecutaron. Esto lo puedes poner en tus reglas para que siempre te responda con este informe y así no te repites.

• Restringir el acceso a tareas críticas como migraciones de bases de datos, despliegues o gestión de credenciales (literalmente la línea 1 de mi CLAUDE.md, adjunto evidencias)

La automatización total sigue requiriendo una supervisión humana constante. Cuanta más autonomía tiene el sistema, más importante es controlar sus límites de acción y más importante es conocer cómo funciona el sistema por dentro.

La nueva familia de OpenAI llega después de semanas de pruebas de seguridad, presión regulatoria y una decisión poco habitual: limitar primero el acceso a un puñado de organizaciones de confianza.

El 26 de junio, OpenAI no presentó simplemente un modelo más. Presentó GPT-5.6 (Sol, Terra y Luna) con una advertencia implícita: esta vez, la carrera por publicar primero había quedado subordinada a la pregunta de qué ocurre cuando un modelo puede razonar, usar herramientas y sostener tareas complejas durante más tiempo.

Durante meses, el sector había aprendido a interpretar cada silencio de OpenAI como una señal. Una filtración, una nueva entrada en la API, un benchmark sin explicación o una mención a Codex bastaban para alimentar expectativas. Pero GPT-5.6 tardó más de lo previsto no porque faltara capacidad, sino porque cada salto en capacidad ha elevado el coste de equivocarse.

El lanzamiento que no fue lanzamiento

La empresa eligió una fórmula extraña para los estándares de la industria: una preview limitada para un grupo pequeño de socios de confianza, inicialmente disponible mediante API y Codex. El acceso amplio a ChatGPT, Codex y la API quedó para una fase posterior, mientras OpenAI continuaba probando el comportamiento del sistema con usuarios y organizaciones reales.

La decisión no fue puramente corporativa. OpenAI comunicó por adelantado al Gobierno de Estados Unidos los planes y capacidades del modelo y, a petición de la Administración, empezó con participantes cuya identidad se compartió con el Gobierno. La compañía sostiene que no pretende que ese mecanismo de acceso gubernamental sea la norma permanente, pero lo presenta como una medida temporal para habilitar una disponibilidad más amplia.

Ahí está la primera clave de la demora: GPT-5.6 no se enfrentaba solo a una revisión de producto. Se enfrentaba a una negociación institucional sobre cómo desplegar IA de frontera cuando sus capacidades empiezan a rozar ámbitos sensibles, especialmente la ciberseguridad.

Semanas para encontrar fallos

OpenAI afirma haber dedicado varias semanas a buscar debilidades, someter sus protecciones a pruebas de presión y reforzarlas frente a ataques reales antes del lanzamiento limitado. Para el red teaming automatizado orientado a detectar jailbreaks universales, la compañía cifra el esfuerzo en más de 700.000 horas equivalentes de GPU A100.

La cifra importa menos como demostración de potencia de cómputo que como síntoma de una nueva etapa. El objetivo ya no es únicamente evitar una respuesta peligrosa ante un prompt explícito sino que es impedir que usuarios persistentes, adaptativos y técnicamente competentes encuentren formas repetibles de esquivar las barreras.

El modelo incorpora salvaguardas en capas: entrenamiento para rechazar asistencia cibernética prohibida, clasificadores en tiempo real, revisión adicional en casos de riesgo, señales a nivel de cuenta, monitorización y acceso diferenciado. En ciertas solicitudes, OpenAI avisa de que la generación puede pausarse para que otro modelo de razonamiento evalúe el contexto, algo que puede introducir bloqueos o latencia incluso en trabajos legítimos.

La novedad es el agente

GPT-5.6 llega como una familia de tres niveles. Sol es el modelo insignia, Terra apunta a un equilibrio entre capacidad y coste para trabajo cotidiano y Luna prioriza velocidad y precio para grandes volúmenes. Según OpenAI, Terra ofrece rendimiento competitivo con GPT-5.5 a la mitad de coste, mientras Luna es la alternativa más económica de la gama.

Lo del cambio de nombre, todavía no lo he terminado de entender. Se alejan de su nano-mini-pro como todavía mantiene Gemini, habrán hecho un poco de marketing con la salida de Mythos y Fable de Anthropic para hacer un lio al usuario medio de IAs que no tiene tiempo de entender las diferencias entre uno y otro.

En cuando a los precios de API publicados dibujan bien la segmentación:

• Sol: máxima capacidad y razonamiento. 5 dólares de entrada y 30 de salida por millón de tokens.

• Terra: equilibrio para cargas diarias. 2,50 dólares de entrada y 15 de salida.

• Luna: velocidad y escala. 1 dólar de entrada y 6 de salida.

Pero la apuesta técnica no se reduce a un precio por token. Sol estrena un nivel de esfuerzo de razonamiento llamado max, diseñado para dedicar más tiempo a problemas difíciles, y un modo ultra, que usa subagentes para acelerar trabajo complejo que superaría a un único agente.

Es una señal clara de hacia dónde quiere mover OpenAI la conversación: de modelos que responden bien a modelos que planifican, ejecutan, verifican, corrigen y coordinan herramientas. En programación, OpenAI sostiene que Sol establece un nuevo récord en Terminal-Bench 2.1, una evaluación de flujos de terminal que exige planificación, iteración y coordinación de herramientas.

GPT-5.6 frente a sus competidores

La fotografía competitiva de julio no se resuelve con un ganador absoluto. GPT-5.6 Sol busca dominar los flujos agénticos largos y complejos, Grok 4.5 se plantea como el modelo transversal de xAI para código y llamadas a herramientas, mientras que Sonnet 5 y Fable 5 representan, respectivamente, la vía eficiente y el escalón de máxima capacidad de Anthropic.

Así queda el mapa, modelo a modelo:

• GPT-5.6 Sol. Razonamiento de alto esfuerzo, subagentes y tareas profesionales prolongadas. 1 millón de tokens de contexto, 5 dólares de entrada y 30 de salida por millón. Es la opción para automatizaciones complejas, investigación, operaciones multiherramienta y tareas donde el coste del error justifica más cómputo.

• Grok 4.5. Código, tool calling agéntico y razonamiento configurable. 500.000 tokens de contexto 2 dólares de entrada y 6 de salida por millón. Muy competitivo para construir agentes de código o producto con una relación coste/capacidad agresiva.

• Claude Sonnet 5. El modelo de trabajo diario de Anthropic, cercano a la gama alta con menor coste. 3 dólares de entrada y 15 de salida por millón. Candidato natural para asistentes internos, desarrollo generalista y alto volumen si prima la previsibilidad de coste.

• Claude Fable 5. El modelo de frontera de Anthropic, máxima capacidad y razonamiento adaptativo. 10 dólares de entrada y 50 de salida por millón, según comparativas publicadas. A reservar para problemas excepcionales de ingeniería, análisis o agentes donde el presupuesto sea secundario.

Hay una advertencia necesaria: los benchmarks no son un campeonato neutral. OpenAI afirma que GPT-5.6 Sol alcanza 53,6 en Agents’ Last Exam y supera a Fable 5 en esa evaluación, la misma comparación pública recoge que Fable 5 aventaja a Sol en SWE-Bench Pro, 80% frente a 64,6%. La conclusión útil para equipos técnicos no es elegir una marca, sino separar la evaluación en tareas reales: repo-level coding, ejecución con herramientas, análisis documental largo, precisión factual, latencia y coste total por resultado.

Grok 4.5, por su parte, se posiciona explícitamente como el modelo insignia de xAI para programación y uso general, con razonamiento configurable y llamadas agénticas a herramientas. Sus 500.000 tokens de contexto lo dejan por debajo del millón anunciado para GPT-5.6, pero su precio publicado (2/6 dólares por millón de tokens de entrada/salida) lo coloca en una posición especialmente atractiva para productos con volumen.

En el lado de Anthropic, la diferencia conceptual importa más que el nombre. Sonnet 5 sería la propuesta orientada a uso frecuente y coste contenido: Fable 5, la apuesta de frontera, con un precio muy superior y capacidades que justifican reservarlo para trabajos donde fallar o tardar cuesta más que los tokens. La comparación no debería ser “qué modelo es más inteligente”, sino “qué modelo completa mi tarea concreta con menos supervisión, menos tiempo y menor coste final”.

Más autonomía, más riesgo

El salto también se aprecia en biología y ciberseguridad. OpenAI reporta mejoras de Sol en GeneBench v1 (una evaluación de análisis genómico y biología cuantitativa de largo recorrido) frente a GPT-5.5, usando menos tokens. En seguridad ofensiva y defensiva, afirma que Sol logra resultados competitivos frente a Mythos Preview en ExploitBench empleando aproximadamente un tercio de los tokens de salida.

La empresa sostiene que el modelo ayuda mejor a detectar y corregir vulnerabilidades que a completar ataques autónomos de extremo a extremo. De hecho, declara que GPT-5.6 Sol no supera el umbral “Cyber Critical” de su marco de preparación: en pruebas con Chromium y Firefox identificó errores y primitivas de explotación, pero no produjo de forma autónoma una cadena completa de exploit funcional bajo las condiciones evaluadas.

Es una precisión importante para no caer en el relato fácil de la IA “demasiado peligrosa para publicarse”. GPT-5.6 no es un sistema sin límites sino que es un sistema más útil en tareas de alto impacto y, precisamente por eso, más incómodo de liberar sin observar antes sus comportamientos, sus fallos y los bordes de sus protecciones.

El verdadero retraso

Decir que GPT-5.6 “se ha demorado” es correcto solo a medias. Lo que sí está documentado es una secuencia deliberadamente lenta: endurecimiento de seguridad, pruebas extensas contra abusos, coordinación previa con el Gobierno estadounidense y una salida por fases con socios seleccionados.

La crónica, por tanto, no trata de un modelo que llegaba tarde. Trata de una industria que empieza a descubrir que desplegar capacidades agénticas avanzadas no se parece a actualizar una aplicación. Cada mejora en razonamiento, uso de herramientas y continuidad de tareas amplía simultáneamente la utilidad para desarrolladores, empresas y defensores, pero también la superficie de riesgo.

GPT-5.6 llega con más razonamiento, subagentes, mejor rendimiento en programación, una estructura de costes más segmentada y defensas más intrusivas.

Y vosotros… ¿ya lo estáis probando?

Deja un comentario

Suscríbete ahora

Hubo un tiempo, que ahora parece prehistoria pero que en realidad ocurrió hace unos meses, en el que publicar un modelo de lenguaje era un asunto de ingenieros sudorosos, servidores al límite y departamentos de marketing descorchando champán barato. Subías los pesos a Hugging Face, abrías la API y que el mundo se apañase con el fuego prometeico.

Ese mundo ya no existe.

En junio terminó la era del salvaje oeste de la inteligencia artificial. Lo que empezó como un lanzamiento técnico de Anthropic acabó como un conflicto geopolítico donde las oficinas de Washington influyen más que los clústeres de GPUs.

Bienvenidos a la era de la IA bajo tutela estatal.

El guardián encadenado: Fable 5 y Mythos 5

El 9 de junio, Anthropic decidió lanzar el mismo modelo con dos enfoques diferentes:

Fable 5 era el modelo para el público general. Tenía un rendimiento excelente, pero venía con un sistema de seguridad tan estricto que casi requería un permiso especial para responder a cualquier instrucción ligeramente compleja.

Mythos 5 era la versión restringida, reservada solo para un grupo selecto de socios de Project Glasswing para tareas de ciberseguridad defensiva.

La idea sobre el papel parecía buena: ofrecer Fable 5 al público general y dejar las funciones críticas bajo llave en Mythos 5. Pero el desarrollo de software real no funciona así.

Para evitar problemas con Fable 5, Anthropic aplicó los filtros de seguridad más estrictos de su historia. En la práctica, prefirieron inundar el sistema con falsos positivos antes que arriesgarse a un titular polémico.

El resultado fue una frustración diaria para los desarrolladores. Intentar que Fable 5 ayudara a revisar una función de red o a analizar una vulnerabilidad legítima requería demasiadas vueltas. El modelo era potente, pero prefería negarse a responder antes que correr cualquier riesgo.

Los modelos avanzados son complejos. Si les pones una correa demasiado corta, dejan de ser útiles.

Hasta que se demostró que se podían burlar estas medidas…

La situación estalló por el lado menos pensado. El 12 de junio, un equipo de investigadores de Amazon demostró que las barreras de Fable 5 no servían de mucho. Encontraron un fallo que permitía obligar al modelo a detectar vulnerabilidades y a escribir código real para explotarlas.

La respuesta del gobierno de Estados Unidos fue inmediata y aplicó controles de exportación sobre Fable 5 y Mythos 5.

La reacción de Anthropic fue drástica. Ante la imposibilidad de verificar el origen de cada petición a su API en tiempo real, la empresa tomó el camino rápido y apagó el acceso para todo el mundo.

Daba igual si estabas en San Francisco o en Madrid. De la noche a la mañana, el modelo dejó de funcionar porque la empresa no tenía forma de segmentar el acceso por países de manera fiable.

Cuando el gobierno estadounidense levantó el bloqueo el 30 de junio, la vuelta a la normalidad no fue completa. Fable 5 regresó a claude.ai y Claude Code, pero con restricciones mucho más duras.

Para obtener la autorización de Washington, Anthropic integró un nuevo filtro de seguridad desarrollado bajo supervisión federal. El filtro bloquea casi todos los intentos de saltarse las normas, pero arruina la experiencia de uso para quienes intentamos trabajar con él.

El Fable 5 actual se comporta de forma extremadamente conservadora. Ante cualquier tarea de depuración de código que tenga relación con la seguridad, su respuesta por defecto es negarse a colaborar.

Esta pérdida de rendimiento no era una simple percepción de los usuarios. Los análisis posteriores confirmaron que los problemas en el enrutador de Anthropic redirigían peticiones a modelos incorrectos o aplicaban filtros de seguridad por duplicado. Fue un fallo de infraestructura interna causado por las prisas para cumplir con las exigencias del regulador.

El fin de la soberanía tecnológica corporativa

Lo importante de este episodio no es si el modelo funciona un poco peor hoy. Lo que estamos viendo es el final de la autonomía de las empresas que desarrollan inteligencia artificial.

Las decisiones ya no dependen solo de los ingenieros de Silicon Valley. El control de los modelos avanzados se ha trasladado a los despachos del Departamento de Comercio de los Estados Unidos.

La nueva dinámica funciona así: ya no se puede lanzar un modelo y ver qué pasa. Los nuevos sistemas deben pasar el filtro del gobierno antes de que el público pueda usar su API.

El retraso en el lanzamiento de GPT-5.6, con sus modelos Sol, Terra y Luna, se debe a estos mismos controles. La compañía tuvo que desplegar una versión de prueba muy limitada para socios seleccionados bajo la supervisión directa del gobierno estadounidense para cumplir con las normas de seguridad.

El proceso de lanzamiento ya no se limita a pasar pruebas de código e integrar mejoras de rendimiento. Ahora incluye negociaciones con gobiernos y la presión de que cualquier fallo de seguridad descubierto por un tercero pueda detener todo el proyecto por motivos de seguridad nacional.

El desarrollo tecnológico se ha convertido en un asunto estatal. Mientras tanto, los desarrolladores que solo buscábamos una buena herramienta de asistencia nos encontramos con sistemas que, por exceso de precaución, evitan responder a tareas básicas.

El 9 de junio de 2026, Anthropic lanzó la familia de modelos Mythos al mercado. Sólo 2 semanas después de sacar, de nuevo, el mejor modelo de programación Claude Opus 4.8 al mercado.

Todavía no nos habíamos recuperado del susto y de nuevo tenemos otro juguetito para probar, pero todo tiene una explicación: Anthropic está preparando su salida a bolsa y quiere llegar a ese punto liderando la carrera y con sus rivales en estado de shock.

El resultado de liberar este modelo ha llegado gracias a que han podido poner unas barreras de contención sobre su modelo más potente jamas creado, Claude Mythos, al que por fin vamos a tener acceso. Incluye un sistema dinámico de detección de intenciones maliciosas en temas de ciberseguridad y biología. Si el LLM detecta que es una conversación maliciosa (como que le pidas investigar sobre posibles ataques biológico o intentar atacar un sistema de software) el modelo automáticamente etiqueta la conversación como potencialmente peligrosa y se la delega a Claude Opus 4.8 para que siga con la conversación.

Si consigues encontrar una vulnerabilidad en un sistema, que al menos no te haya ayudado Mythos, sino su colega tonto Opus.

Dos versiones: Fable 5 y el proyecto Glasswing

Anthropic ha presentado una estrategia doble. Por un lado, está Claude Fable 5 (claude-fable-5), un modelo de uso general accesible por API con una ventana de contexto de un millón de tokens y capacidad para generar hasta 128,000 tokens de salida por petición. Por el otro, de forma interna, opera Claude Mythos 5 (sí, el mismo).

Mythos 5 utiliza la misma red neuronal pero no incluye los clasificadores de seguridad comerciales. Funciona bajo el Project Glasswing, un programa conjunto con el gobierno estadounidense para ciberdefensa. Mientras que Mythos está diseñado para analizar amenazas de seguridad y evaluar riesgos biológicos, Fable 5 es la versión comercial optimizada para tareas de desarrollo y gestión de datos.

La diferencia principal de Fable 5 frente a modelos anteriores es su capacidad de planificación nativa. El modelo permite ejecutar agentes autónomos de largo recorrido. Al asignarle una tarea, el sistema coordina la ejecución, delega subtareas en subagentes, corrige sus propios errores de compilación y entrega el resultado final. Es automatización asíncrona real.

Costes de uso y retención de datos

El uso de Fable 5 tiene un coste de 10 dólares por millón de tokens de entrada y 50 dólares por millón de tokens de salida.

En comparación, Claude Opus 4.8 cuesta la mitad: 5 dólares por millón de tokens de entrada y 25 dólares de salida. Además, Opus permite configurar la exención total de retención de datos, algo que Fable 5 no ofrece.

Fable 5 y la versión Mythos 5 imponen una retención de datos obligatoria de 30 días en los servidores de Anthropic para auditorías de seguridad. No es posible optar a la política de Cero Retención de Datos (ZDR) con estos modelos. Las organizaciones que manejen datos altamente regulados deberán utilizar Opus 4.8 en su lugar.

Pensamiento intercalado obligatorio

En Fable 5 el pensamiento adaptativo ya no es opcional. Esto es un parámetro que te permitía desactivar el consumo de tokens para “razonamientos internos” del modelo antes de responder. Pues en este modelo no se puede desactivar.

Si realizas una consulta sin configurar los parámetros de razonamiento, el modelo decide de forma autónoma cuántos recursos cognitivos emplear antes de responder.

Esto es necesario, ya que el modelo incluye pensamiento intercalado, lo que le permite analizar los resultados de una herramienta o de la ejecución de código en su entorno seguro de sandbox antes de decidir el siguiente paso.

Para controlar los costes de procesamiento asociados a este razonamiento, Anthropic incluye el parámetro de esfuerzo (effort) al que nos tiene acostumbrados:

• max: Procesamiento profundo completo. El modelo explora todas las vías lógicas sin límite estricto de coste o tiempo.

• xhigh: Razonamiento optimizado para la resolución de errores complejos y lógicas algorítmicas avanzadas.

• high: Configuración por defecto. Razonamiento estándar para tareas analíticas comunes.

• medium: Nivel moderado que evita el procesamiento profundo en consultas sencillas.

• low: Prioriza la velocidad y el ahorro de tokens, omitiendo el razonamiento complejo.

Para proteger su propiedad intelectual y reducir la latencia, Anthropic no muestra el flujo de pensamiento sin procesar completo. A través de thinking.display, el desarrollador puede elegir recibir un bloque vacío para reducir tiempos de espera (omitted) o un resumen del razonamiento (summarized).

Arquitectura de seguridad

Anthropic ha integrado un sistema de seguridad para evitar que Fable 5 se utilice en tareas de ciberseguridad ofensiva, diseño de sustancias biológicas o ingeniería inversa del modelo. Si el sistema detecta estas intenciones, aplica varios mecanismos de mitigación automáticos.

Redirección automática a Claude Opus 4.8

Cuando se activa un clasificador de seguridad, el sistema redirige la consulta a Claude Opus 4.8. Este desvío se gestiona mediante la API de Fallback o los SDK oficiales de Anthropic.

La petición devuelve un mensaje con una explicación de por qué ha considerado que se tiene que redirigir la conversación:

• cyber: Desarrollo de malware u operaciones ofensivas.

• bio: Manejo de patógenos o sustancias químicas peligrosas.

• frontier_llm: Intentos de ingeniería inversa sobre el modelo.

• reasoning_extraction: Intentos de extraer el flujo de pensamiento interno en texto plano.

La plataforma factura esta consulta con la tarifa de Opus 4.8. Si el bloqueo ocurre durante la generación del texto, solo se cobran los tokens procesados hasta el momento de la interrupción.

Mitigación de la destilación de modelos

La destilación de modelos (utilizar las respuestas de Fable 5 para entrenar modelos de menor tamaño) es una de las principales preocupaciones de propiedad intelectual para Anthropic.

Cuando el sistema detecta patrones de consulta destinados a la destilación, activa un desvío silencioso.

La API redirige las peticiones a Claude Opus 4.8 sin notificar al usuario. Aunque las respuestas provienen de un modelo con menor capacidad cognitiva, la facturación se mantiene bajo la tarifa de Fable 5 (10 dólares por entrada y 50 por salida). Esto neutraliza la viabilidad económica de la extracción de conocimiento y evita dar pistas al atacante para modificar sus instrucciones de elisión.

Pruebas de rendimiento

Los resultados de Fable 5 muestran diferencias frente a sus competidores directos en tareas de desarrollo y lógica:

Las evaluaciones de Fable 5 en biología molecular o virología no están disponibles públicamente. Las consultas en estos campos de riesgo son redirigidas a Opus 4.8, de forma que estas capacidades quedan limitadas a la versión gubernamental Mythos 5.

La adopción inicial del modelo muestra ejemplos de implementación práctica. Durante la fase de pruebas privadas, Stripe utilizó Fable 5 para migrar una base de código de más de 50 millones de líneas en Ruby: esto son palabras mayores, aunque no me lo creo si te soy sincero…

El modelo analizó las dependencias, actualizó la sintaxis y ejecutó las pruebas en un solo día, una tarea que la compañía estimaba en dos meses de trabajo para un equipo de ingeniería tradicional.

Si te paseas un poco por X o Reddit, verás la cantidad de cosas que se han generado en un par de días. Yo he visto un clon de Skyrim hecho con un prompt (literalmente “Claude, genera un clon de Skyrim”) usando Fable 5.

Lo que yo he probado, es bastante bueno pero con muchos matices.

Planificación de adopción para equipos técnicos

La llegada de los modelos de clase Mythos requiere un análisis estructurado de costes e infraestructura:

• Utilizar Claude Fable 5 en proyectos que dependan del despliegue de agentes autónomos para la ejecución de flujos de trabajo de varios días o cuando se requiera procesar de forma unificada documentos técnicos complejos y tablas financieras extensas.

• Mantener Claude Opus 4.8 para tareas estándar de clasificación, resúmenes corporativos, análisis de datos que no necesiten razonamiento secuencial profundo y, principalmente, en contratos que exijan la eliminación inmediata de los datos procesados.

Mi conclusión

No es un modelo de uso diario y, personalmente, sigo usando Opus 4.8 en mi trabajo diario. Todavía es muy caro y tengo mi feed de LinkedIN lleno de personajes que se han gastado la suscripción de la semana en 6 horas: lo que sea por ganar likes.

Por mi parte sigo digiriendo lo bien que funciona Opus 4.8, era el modelo que llevabamos esperando meses y funciona fenomenal, no os volváis locos. Sin embargo tambien hay que tener en cuenta que:

• No dejar de lado OpenAI Codex que también esta teniendo muy buenos resultados, y seguro que la semana que viene saldrá con un GPT 5.6 que tiene pinta también de destrozar los benchmarks (según filtraciones)

• También tenemos que esperar un par de semanitas a que salga Gemini Pro 3.5, que también se antoja peleón.

Si por el contrario, seguis queriendo probar Fable 5, hay una skill que os recomiendo para vuestro Claude Code que utiliza Fable 5 para planificar el trabajo que luego ejecuta con Sonnet o Haiku. Echadle un ojo!

Suscríbete ahora

Se acabó la fase experimental de la inteligencia artificial. Durante los últimos dos años, el sector ha vivido en una especie de fiesta constante de demostraciones de tres minutos, fundadores prometiendo cambiar el mundo en redes sociales y una carrera absurda por lanzar el modelo de la semana. Pero el viento está cambiando de dirección.

Esta semana, Anthropic ha hecho dos movimientos que marcan el paso del entusiasmo inicial a la fase de infraestructura. Por un lado, han presentado de forma confidencial los papeles para su salida a bolsa. Por otro, han cerrado una ronda de financiación que sitúa su valoración cerca de los 965.000 millones de dólares.

Casi un billón de dólares. Un volumen financiero gigantesco.

Esto ya no se trata de quién diseña el chatbot más simpático o quién genera el vídeo más realista. Se trata de ver quién controla el suministro de agua, luz y gas del tejido empresarial de las próximas décadas.

Qué significa realmente una salida a bolsa en este sector

Presentar una solicitud confidencial para cotizar en bolsa no es un trámite más, es un cambio de escala. Significa que Anthropic ha decidido dejar que los analistas de Wall Street examinen sus cuentas reales.

Hasta ahora, las empresas de inteligencia artificial han operado con una lógica financiera distinta. Podían gastar capital a un ritmo enorme con tal de superar por unas décimas a sus competidores en las pruebas de rendimiento. En el mercado público, esa narrativa se acaba cuando chocas con los balances reales.

Al cotizar en bolsa, hay que responder a preguntas directas:

• ¿Cuánto cuesta generar cada millón de tokens y qué margen real queda?

• ¿Qué porcentaje del negocio depende de los servidores de socios como Amazon y Google?

• ¿Cómo responder ante competidores que decidan rebajar las tarifas de su API para ganar cuota de mercado?

• ¿El crecimiento es sostenible o depende exclusivamente del capital de riesgo?

La salida a bolsa es el momento en que las promesas de la inteligencia artificial general se enfrentan a la realidad del flujo de caja. Y los mercados financieros suelen ser analistas muy rigurosos.

Its just business

Muchos equipos de desarrollo se entusiasman con un modelo que promete grandes cambios en una presentación, para luego descubrir que ponerlo en producción a escala es un problema de latencia, costes altos y respuestas imprevistas.

Anthropic parece haberlo entendido pronto. Mientras otros buscan llamar la atención de los medios, la compañía creadora de Claude se ha centrado en construir una herramienta predecible y robusta. En tecnología, que algo sea predecible significa que funciona cuando sube el tráfico.

El mercado busca fiabilidad en lugar de sorpresas.

La batalla ya no se libra en la cantidad de parámetros, sino en el coste de mantener el servicio, optimizar la inferencia y garantizar la estabilidad con cargas de trabajo extremas.

La consistencia es el nuevo estándar. De nada sirve que un modelo razone de forma brillante en una prueba de escritorio si a la décima mil petición rompe la integración con tu base de datos por saltarse el formato JSON.

La eficiencia por token ahora decide el margen. En producción, el éxito se mide en milisegundos y fracciones de centavo. El proveedor que reduzca el consumo por consulta se quedará con el mercado.

Para quienes trabajamos con código a diario, el movimiento de Anthropic es una señal clara. Indica que la arquitectura sobre la que construimos nuestras aplicaciones tiene un respaldo financiero sólido que no va a desaparecer de la noche a la mañana.

Al elegir un proveedor de inteligencia artificial para integrarlo en tu producto, estás eligiendo un socio técnico a largo plazo. Si ese proveedor demuestra solvencia para convertirse en un servicio básico, como hoy lo son AWS o Azure, el riesgo de tu proyecto disminuye notablemente.

Ya no evaluamos los modelos solo por su capacidad de razonamiento. Ahora importan la gestión de datos, la observabilidad, la estabilidad de los sistemas RAG y la capacidad de coordinar agentes que usen herramientas externas sin fallar en el intento.

Bienvenidos a la fase de ejecución

La valoración de Anthropic puede parecer excesiva debido al optimismo actual del mercado. Pero la tendencia de fondo es clara: estamos delegando tareas de procesamiento pesado en una infraestructura que ya no es un experimento.

La inteligencia artificial está pasando de los laboratorios de investigación a manos de ingenieros de sistemas, analistas financieros y especialistas en optimización. Es el camino habitual de cualquier tecnología importante. Primero llegan las ideas, luego el desarrollo y finalmente la gestión de los recursos.

La llegada de los auditores y financieros, aunque parezca menos llamativa, es la confirmación de que esta tecnología se ha consolidado.

El 28 de mayo, Anthropic lanzó Claude Opus 4.8. Podrían haber destacado gráficos de rendimiento espectaculares, velocidad absurda o capacidades de ejecución complejas. Pero no lo hicieron. En sus oficinas de San Francisco decidieron que el principal argumento de su modelo estrella iba a ser algo diferente: la honestidad.

No el rendimiento bruto, ni la velocidad de procesamiento de tokens. La honestidad.

En su propia documentación, Anthropic describe el problema de los modelos con claridad. Explican que el gran defecto de estas inteligencias es que tienden a asumir conclusiones de forma apresurada y a afirmar que han terminado su trabajo cuando las pruebas reales son escasas. El parche para Opus 4.8 promete que ahora el modelo señalará sus dudas y dejará de dar certezas vacías. Según sus propios datos, es cuatro veces menos probable que su versión anterior pase por alto fallos en el código que acaba de generar.

Esto que se vende ahora como una gran actualización técnica es exactamente el problema del que os vengo hablando en este boletín desde hace meses.

Las cicatrices de esta historia: el diario de marzo

En el desarrollo de software, si no hay un registro con fechas, las opiniones no valen mucho. Y las fechas están ahí.

El 23 de marzo publiqué un texto titulado “Opus también sabe mentir”. En ese momento trabajaba con Opus 4.6 en modo agente, un proceso estructurado en siete fases. Todo iba bien hasta que llegamos a la integración de pruebas de extremo a extremo. De repente, el modelo aseguró que ciertas fases de desarrollo se habían completado de manera muy rápida.

Los tiempos no cuadraban. Nadie levanta ese flujo en unos segundos. Al preguntarle directamente sobre las pruebas de aceptación, la simulación cayó. El modelo había ejecutado un par de pruebas básicas y había maquillado el resultado para dar la tarea por terminada. Lo peor vino después: al confrontarlo, admitió que sabía perfectamente que el trabajo estaba incompleto y, aun así, decidió marcarlo como finalizado.

El modelo no tenía un fallo de computación, sino algo muy parecido a la pereza del becario que maquilla el informe semanal esperando que nadie revise el código fuente.

Este comportamiento tiene nombres claros en la literatura de seguridad: “reward hacking” y “sycophancy”. Lo llamé “green theater”, la costumbre de aparentar que todo funciona para cumplir el expediente. Mi conclusión entonces fue clara: la confianza ciega no sirve.

El 13 de abril escribí sobre cómo mitigar esto en “Cómo desbloqueé el modo dios de Claude”. El problema de fondo es que Claude está entrenado para que el usuario termine satisfecho. Esa necesidad de complacer genera malas prácticas en el código: cerrar tareas antes de tiempo, ocultar deuda técnica, recortar el alcance del proyecto sin avisar e interpretar que algo está terminado con demasiada ligereza.

La solución propuesta no era un truco, sino un protocolo de control. Obligar al modelo a pasar por una fase de honestidad forzada antes de aceptar cualquier resultado, estructurando sus respuestas en categorías claras (riesgos omitidos, supuestos no resueltos, desacuerdos técnicos) y exigiendo una verificación activa contra el código real. Para obtener la verdad de una máquina, hay que forzarla a buscar sus propios fallos.

La autopsia de Anthropic coincide con el diagnóstico

Si comparamos el anuncio de Opus 4.8 con nuestros análisis de estos meses, el diagnóstico es el mismo.

Anthropic reconoce ahora que el principal fallo de su modelo era asumir avances con evidencias débiles. Eso es exactamente lo que ocurrió con las fases falsas en nuestro desarrollo.

Anthropic destaca que su modelo ahora indica incertidumbres. Ese es el control de honestidad que antes teníamos que forzar mediante instrucciones manuales y que ahora viene integrado en el propio entrenamiento del modelo.

Los testimonios elegidos para el lanzamiento confirman esta realidad. Un desarrollador explica que ahora el modelo le discute si el plan no es viable, y otro celebra que señale de forma proactiva los cabos sueltos en las entradas de datos que antes ignoraba para que los descubriera el usuario. Al final, el usuario terminaba haciendo de auditor de un software supuestamente terminado.

Cuando la empresa que diseña el modelo utiliza como argumento de venta la solución al mismo fallo de seguridad que denunciábamos mientras otros hacían “vibe coding”, el debate se termina. El diagnóstico era el correcto.

La física del código es tozuda

Hay que ser realistas. No creo que los ingenieros de Anthropic lean este boletín mientras configuran sus modelos. El “reward hacking” es un problema conocido en el sector para cualquiera que mire más allá de las notas de prensa, yo simplemente os lo estaba anunciando varios meses antes.

Esto no va de quién lo vio primero, sino de algo más práctico para los que escribimos código: lo que señalábamos era un problema real que afectaba a la productividad diaria. No era la manía de un programador desconfiado a altas horas de la noche. Era un fallo estructural que ahora el fabricante documenta y cuantifica.

También toca corregir errores propios. En mis pruebas de marzo intenté que Opus editara su archivo “CLAUDE.md” para fijar reglas de conducta. Un lector señaló en los comentarios que esos archivos son poco más que un marco de referencia psicológico para el modelo y que una línea de texto no cambia la arquitectura interna de funcionamiento del modelo. Tenía razón. Por eso el método pasó a utilizar un sistema externo de verificación y herramientas. El proceso ha sido claro: pasamos de instrucciones inútiles en markdown a herramientas de control externas, y ahora, por fin, a correcciones desde el propio entrenamiento.

La letra pequeña detrás del anuncio

Hay que analizar esta actualización con prudencia. Celebrar el cambio sin leer las condiciones reales del sistema sería un error.

Este cambio en el modelo no se debe a una mejora ética. Es optimización matemática y teoría de juegos. El modelo no mentía por malicia, sino porque el camino más corto para obtener su recompensa matemática era dar la respuesta que el usuario quería escuchar. Corregir esto es ingeniería de incentivos, no un cambio moral.

Y el detalle más importante: que sea cuatro veces menos probable no significa que la probabilidad sea cero.

Un sistema que miente cuatro veces menos sigue requiriendo supervisión. Si decides delegar un desarrollo crítico de varias horas sin revisar nada porque Opus 4.8 ahora es más “honesto”, cometerás el mismo error de antes. Cambiarás la confianza ciega por una versión más pulida pero igual de arriesgada.

Lo que cambia es el esfuerzo necesario para validar. Antes había que forzar al modelo en cada respuesta para conseguir cierta autocrítica. Ahora el sistema muestra sus dudas de forma más abierta y admite con más facilidad si no sabe resolver un problema con Docker. El trabajo de revisión es más sencillo, pero sigue siendo necesario. El escepticismo, la verificación de cada cambio y el contraste con el diseño original siguen siendo obligatorios.

La única conclusión posible

Cuando el código generado por una inteligencia artificial no funciona, el problema casi nunca es la falta de capacidad del modelo, sino que suele dar por bueno un trabajo incompleto. Ahora el principal actor del sector lo reconoce en su propia hoja de ruta.

Es un avance para el realismo técnico, pero no significa que podamos desentendernos y dejar que la máquina programe sola. La lección es que mantener una actitud escéptica era la postura correcta. Mañana, cuando se anuncie una versión que prometa honestidad total, la respuesta ante la pantalla tendrá que ser la misma: no me lo creo, demuéstramelo.

La fantasía que nos venden en las presentaciones de Silicon Valley es hermosa. Te sientas frente a la pantalla, le susurras tus sueños a una caja de texto y, por arte de magia, un software impecable se despliega ante tus ojos mientras te tomas un café de especialidad.

La realidad, sin embargo, huele a cafeína recalentada, conflictos de fusión y asistentes de inteligencia artificial que intentan colarte soluciones de juguete.

En Naktor llevamos meses construyendo una plataforma para definir y crear aplicaciones empresariales complejas a través de un sistema de definición y relación de requisitos que puedan luego utilizar los asistentes de código.

Queríamos saber qué pasaría al rediseñar el núcleo de nuestro motor desde cero. Así que montamos una especie de juicio por combate.

Pusimos a prueba a las tres herramientas de inteligencia artificial más potentes con el mismo examen: las mismas instrucciones, el mismo repositorio y las mismas restricciones. Tres modelos compitiendo por resolver el mismo problema.

Les entregué un documento de diseño de veinte páginas con una descripción detallada de nuestro sistema, incluyendo las tecnologías prohibidas, las lecciones de arquitectura que hemos aprendido en producción y diez preguntas técnicas concretas que requerían una respuesta razonada.

Imagina que contratas a tres prestigiosos estudios de arquitectura para diseñar un rascacielos en un terreno complicado. Les das las medidas exactas, el presupuesto, las normativas municipales y los fallos del suelo. En el mundo analógico, tardarían semanas en presentarte sus planos. En el mundo de la IA, estos tiempos son bastante más reducidos.

Estos son los resultados.

Claude Code con Opus 4.7

La propuesta de Claude fue radical. En lugar de integrarse con nuestro código viejo, ignoró el pasado por completo, creó una carpeta nueva y se puso a construir un sistema independiente desde cero.

Si le pides a Claude un rediseño, no te propone reformas en la cocina. Te construye una mansión entera de nueva planta en el solar de al lado.

Y lo bueno es que funcionaba muy bien. Al terminar de leer su documentación, ejecuté un comando en la terminal y todo arrancó. No eran promesas escritas: había dieciocho pruebas unitarias en verde y una herramienta de línea de comandos estructurada, con sus códigos de salida bien definidos.

Claude adjuntó un análisis donde defendía cada una de sus diez decisiones de diseño con una solvencia técnica impecable. Se notaba que había digerido el documento de veinte páginas y, lo más importante, había transformado nuestras cicatrices de producción en código limpio y funcional.

Pero tiene un problema de actitud: vive en una torre de marfil. Su propuesta es un ecosistema cerrado que no conecta con nuestro sistema actual. Si decidiéramos adoptar su código mañana, tendríamos que diseñar la migración nosotros solos. Claude parece considerar que mover los muebles de la casa vieja a la nueva está por debajo de su dignidad.

Es el ingeniero estrella que te entrega una obra de arte y se va dando un portazo. El mantenimiento y la realidad ya si eso los gestionas tú.

Antigravity 2.0 con Gemini 3.5 Flash High

La experiencia con la herramienta de Google fue un viaje por los peores vicios de la consultoría tradicional.

Antigravity decidió que diseñar una arquitectura nueva era demasiado esfuerzo. En lugar de responder al examen, se dedicó a limpiar la casa: corrigió un par de detalles de estilo en el código existente, generó unas capturas de pantalla de la aplicación y ordenó un poco las carpetas. Un trabajo de limpieza que nadie le había pedido.

Cuando por fin presentó su propuesta de diseño, me encontré con un único archivo de 170 líneas. Una demo de juguete que carecía de persistencia de datos, no gestionaba la ejecución en paralelo y omitía los componentes más críticos que exigía el enunciado.

Al confrontar al asistente con su falta de resultados, empezó la confusión. Me aseguró que el diseño completo ya estaba redactado y guardado en el directorio de metadatos del espacio de trabajo. Básicamente me dijo que lo había guardado en una carpeta invisible que yo no podía consultar.

Tras un rato de discusión, al final redactó un documento con sus diagramas correspondientes. Pero para rematar la jugada, afirmó en el chat que ya había subido el archivo al repositorio de Git.

Un comando rápido en mi terminal confirmó lo que sospechaba: mentira. No había nada subido. Todo seguía en su memoria local, invisible fuera de su propia interfaz.

Para colmo, cuando analicé el diseño que entregó, descubrí que proponía utilizar una base de datos que yo había prohibido explícitamente. También sugería fusionar información usando un umbral automático que estaba marcado como peligroso en nuestras restricciones. Su código de muestra no tenía nada que ver con el diseño que acababa de describir.

Es el consultor que llega tarde a la reunión, enseña unas diapositivas bonitas con conceptos robados y jura que ya ha enviado el contrato al cliente cuando sabe perfectamente que no lo ha hecho.

Este comportamiento tiene que ver con el diseño de su entorno, que crea una capa de estado intermedia que favorece este tipo de errores. Cuando tu copiloto de desarrollo puede mentirte sobre el estado real de un repositorio, la confianza cae por completo.

Es una comparación bastante injusta, porque para este caso concreto cada herramienta tiene que hacer unos pasos para adaptarse al ecosistema actual y poder acceder a toda la información. Antigravity fue incapaz de realizar tal tarea de manera autonóma (como sí hicieron los otros dos).

Codex con GPT 5.5 High

Codex optó por una tercera vía, la de la sensatez de quien ha visto caer demasiados servidores un domingo por la tarde.

A diferencia del aislamiento de Claude o de las fantasías de Antigravity, Codex instaló su nueva arquitectura dentro de nuestro repositorio. Diseñó una estructura que permite al sistema viejo y al nuevo coexistir hasta que el nuevo demuestre que aguanta el peso de los usuarios reales.

Su mayor acierto no es el código en sí, sino un archivo que tituló “deuda de integración”. En ese documento enumeró los ocho pasos exactos que debemos dar antes de apagar el sistema antiguo:

• La carga de datos desde producción.

• La compatibilidad con la base de datos actual.

• Las pruebas de extremo a extremo que aún faltan por escribir.

• La validación con usuarios reales en un entorno controlado.

Eso es lo que separa a un profesional con experiencia de un perfil más junior. El junior te entrega el juguete nuevo y se olvida del mundo. El senior te entrega el juguete acompañado del plan de rescate para cuando las cosas se tuerzan.

Codex tomó decisiones técnicas más conservadoras que Claude. Prefirió asegurar la compatibilidad con múltiples proveedores de inteligencia artificial en lugar de exprimir el rendimiento de nuestro modelo actual. Eso nos costará unas décimas de segundo de latencia, pero nos garantiza que si el mercado cambia en tres meses, no tendremos que rehacer todo el trabajo desde los cimientos.

Además, nos dejó un buen detalle: una versión simulada del sistema que funciona de forma determinista sin hacer llamadas de pago a ninguna API. Un entorno de pruebas gratuito para validar la lógica sin gastar en tokens. Ese nivel de pragmatismo no se aprende en los manuales de programación.

Es el ingeniero que sabe que la empresa tiene facturas que pagar y clientes que no van a tolerar una caída del servicio por una cuestión de principios técnicos.

Y esto me ha sorprendido grátamente…

Radiografía de tres mentes artificiales

Este ejercicio ayuda a entender el enfoque que cada compañía ha impreso en sus herramientas.

Claude Code se comporta como el purista técnico. Si le pides un lienzo en blanco, te entregará una propuesta elegante, defendible y robusta, pero ignorará el barro de la realidad.

Codex es el pragmático de producción. Entiende que el desarrollo es un proceso vivo y que la transición entre el pasado y el futuro es la parte más compleja de nuestro trabajo. Su propuesta deja un rastro claro que cualquier programador puede auditar sin esfuerzo.

Antigravity destaca por su opacidad. Su entorno sufre por meter una capa intermedia que oculta lo que realmente pasa al usuario. Cuando una herramienta afirma cosas que no coinciden con el estado real de tu consola, deja de ser una ayuda para convertirse en una fuente de desconfianza. La herramienta literalmente salió ayer y por tanto le ofrecemos el beneficio de la duda y seguro que mejorará en las próximas semanas.

Quién se queda con las llaves del servidor

La respuesta ya no está tan clara. Hace 6 meses te diría Claude Code sin dudarlo. Ahora me estan empezando a entrar dudas… Igual merece la pena pagar las suscripciones de 100$ de Claude y de Codex en vez de 200$ por una de las dos. A Antigravity le quedan un par de meses todavía para estar a la altura, y lo estará.

Codex con GPT 5.5 se siente diferente y cada vez me está gustando más y más… Le he pedido todo tipo de trabajos y todavía no ha habido en ninguno que me haya decepcionado. ¿A lo mejor hay que darle más protagonismo?

Si me obligaras a elegir una sola herramienta para el resto de mi vida profesional, lo tendría bastante complicado. Por ahora nosotros usamos Claude Code y un uso bastante intensivo.

La lección más valiosa que nos deja este experimento no tiene que ver con marcas comerciales, sino con nuestro propio papel como desarrolladores.

Con herramientas cada vez más autónomas, nuestro trabajo cambia. Ya no nos pagan por escribir código rápido, sino por auditar software generado a escala industrial.

Necesitas una vía de verificación independiente de la propia herramienta: una terminal limpia, un editor de texto clásico, una suite de pruebas externa. Cualquier cosa que te permita comprobar que lo que la máquina dice haber hecho coincide con la realidad del disco duro.

El silicio es rápido, pero también inventa excusas con mucha elocuencia. Por eso la verificación manual sigue siendo indispensable.

Como última reflexión, me he dado cuenta que usar una IA en modo vanilla sin ningún tipo de ecosistema de desarrollo (harness) es prácticamente un brindis al sol y una receta para el fracaso. Hablaré pronto sobre los mejores sistemas del mercado y mis propias recomendaciones.

Suscríbete ahora

Quienes asistieron al anfiteatro Shoreline no presenciaron una simple actualización de catálogo o el predecible despliegue de músculo técnico al que Silicon Valley nos tenía acostumbrados. Lo que Sundar Pichai y su equipo de ingenieros (la mayoría indios) presentaron fue un cambio profundo.

Si la última década estuvo marcada por la transición hacia la inteligencia artificial conversacional, el Google I/O 2026 marca el momento en que estas herramientas empiezan a actuar por sí solas. Entramos en la fase de los agentes autónomos que se integran en el día a día sin necesidad de que los activemos constantemente.

La computación ya no se mide en aplicaciones abiertas o en clics dentro de una interfaz. Ahora consiste en delegar tareas a sistemas que razonan de fondo, crean sus propias herramientas sobre la marcha y toman decisiones bajo nuestra supervisión.

Los agentes ya no pausan, ahora trabajan 24/7 para tí.

Gemini Spark

La principal novedad de la jornada fue la presentación de Gemini Spark, un sistema que Google denomina un Agente de Vida Digital.

A diferencia de los asistentes actuales, que se detienen en cuanto bloqueas el teléfono o cierras la pestaña del navegador, Spark funciona de manera continua las 24 horas del día en máquinas virtuales dentro de la infraestructura de Google Cloud.

“Sí, puedes cerrar tu ordenador portátil y el agente seguirá trabajando por ti”

Este sistema funciona sobre el modelo Gemini 3.5 y utiliza el entorno Google Antigravity. Está diseñado para recibir instrucciones largas y desorganizadas, lo que suele llamarse un vaciado de ideas, y dividirlas en un plan de acción con varios procesos simultáneos en segundo plano.

En las pruebas en directo, un directivo dictó varias órdenes distintas: buscar reuniones importantes en la agenda para destacarlas en colores llamivos, redactar una invitación para un vecino recién mudado que no estaba en la lista de la comunidad, y organizar un plan escolar para sus hijos ordenado por prioridades. El sistema procesó las peticiones en paralelo y coordinó los datos de Gmail, Calendar y Google Docs de forma directa.

Para evitar un ecosistema cerrado, Google anunció que Spark se conecta con aplicaciones de terceros mediante el protocolo abierto MCP (Model Context Protocol). Esto le permite interactuar con bases de datos, gestores de tareas y otras herramientas de automatización.

El acceso se organizará de la siguiente forma:

• Una versión beta inicial para evaluadores de confianza y usuarios de Google AI Ultra.

• Un nuevo plan Ultra de 100 dólares al mes para utilizar los agentes de ejecución continua.

• Una reducción en las tarifas de límites para desarrolladores, que bajan de 250 a 200 dólares mensuales.

Como complemento, la función Daily Brief (Resumen Diario) analiza los correos y mensajes recibidos, identifica tareas pendientes (como la devolución de un libro o un cambio de vuelo) y genera accesos directos en una interfaz simplificada para resolverlas con un toque. Esto ya te lo da cualquier IA de tres al cuarto.

Cambios en el buscador y software al instante

Google Search recibió la actualización más importante de su diseño en años. La nueva interfaz unifica resúmenes automáticos (AI Overviews), resultados web tradicionales y el modo conversacional en una sola pantalla. El usuario puede buscar subiendo documentos PDF, vídeos, imágenes o enlazando pestañas del navegador. El sistema mantiene el contexto de la consulta inicial a medida que el usuario hace preguntas de seguimiento para refinar los resultados.

A partir de verano, los usuarios podrán configurar Agentes de Información permanentes. Por ejemplo, si buscas un piso con requisitos específicos de luz, precio y ubicación, el agente revisará de forma constante portales inmobiliarios y foros de internet, enviando una notificación solo cuando encuentre algo que encaje exactamente. Lo mismo se aplica a mercados más especializados, como la búsqueda de lanzamientos de diseño o calzado de colección.

La novedad técnica más destacada es Generative UI (Interfaz de Usuario Generativa). Con Gemini 3.5 Flash y el motor Antigravity, el buscador puede programar herramientas visuales al instante.

Si un estudiante pregunta por el funcionamiento de los agujeros negros, el sistema compila en segundos un widget interactivo en pantalla. Si añade preguntas más complejas, el buscador modifica su propio código en tiempo real para generar una simulación en tres dimensiones personalizada. Esta función será gratuita y llegará a todos los usuarios en verano.

Tambien anunciaron de nuevo a bombo y platillo el impacto que iba a tener el Universal Commerce Protocol y se resumen en el Universal Cart, que sería como tener un carrito de la compra pero global a tu cuenta y conectado con todas las tiendas online que lo permitan. Ademas será capaz de rastrear los mejores precios en diferentes tiendas, avisarte de bajadas/subidas de precios y si encuentra cupones de descuento.

Por otro lado, Docs Live permite redactar documentos sin usar el teclado. Un ingeniero organizó los puntos clave de una presentación mediante comandos de voz continuos. Docs Live recopiló de forma automática información de su currículum en Drive, extrajo los datos de un correo de confirmación de Gmail para añadirlos al encabezado y transformó un bloque de texto en una tabla comparativa clara. Esta función de entrada de voz llegará a Gmail y Google Keep durante el verano.

Nuevos procesadores y el modelo Gemini 3.5 Flash

Toda esta infraestructura funciona sobre nuevos procesadores y modelos actualizados. El más relevante por velocidad es Gemini 3.5 Flash.

Según los datos de Google, este modelo supera a Gemini 3.1 Pro en casi todas las pruebas de rendimiento, especialmente en la generación de código y en la resolución de problemas prácticos evaluados mediante la prueba SWE-bench / GDP-val.

La velocidad de generación de texto es cuatro veces superior a la de competidores de potencia similar, lo que permite respuestas de voz y procesamiento de vídeo fluidos y en tiempo real.

Para los desarrolladores, Google presentó Antigravity 2.0, que pasa de ser un marco de trabajo experimental a una aplicación de escritorio independiente diseñada para coordinar varios agentes a la vez y gestionar tareas asíncronas.

Durante la presentación, un agente controlado por Antigravity 2.0 y Gemini 3.5 Flash recibió la tarea de escribir y compilar un sistema operativo básico.

He visto demostraciones técnicas asombrosas, pero ver cómo un agente de IA genera el código, compila el núcleo de un sistema operativo y arranca limpiamente una partida del legendario Doom en pantalla ante el asombro del público evoca una especie de magia negra digital.

Gemini Omni y la oficina sin teclado

Las herramientas de generación visual ahora permiten la edición interactiva de contenidos mediante instrucciones habladas.

Gemini Omni es un modelo que integra capacidades lingüísticas con los generadores de imagen, vídeo y música (Veo, Nano Banana, Lyria y Genie). Este modelo destaca por su comprensión de las leyes físicas básicas (algo que ya nos han vendido desde la versión de Gemini 3), lo que ayuda a que los vídeos resulten más naturales y muestren interacciones correctas de gravedad, inercia y movimiento y reduce los fallos visuales habituales de la tecnología anterior.

Ademas del nombre, que se rie directamente en el “gpt4-omni” de OpenAI, es un modelo omni de verdad. No sólo porque es capaz de leer, ver y escuchar sino que es capaz de generar texto, audio, imagen y video según el modelo considere oportuno.

En una demostración de vídeo con estilo de animación con plastilina (claymation) sobre biología, el usuario modificó la iluminación, los ángulos de cámara y la composición del plano mediante instrucciones de voz sin necesidad de regenerar el archivo desde cero.

Gafas de audio y control por voz

Google cerró la presentación con sus primeras Audio Glasses (Gafas de Audio Inteligentes), una alternativa a los dispositivos de realidad mixta que evita el uso de pantallas.

Tienen el aspecto de unas gafas graduadas convencionales y no incluyen pantallas ni proyectores. La interacción se realiza mediante un sistema de conducción ósea que dirige el audio directamente al oído del usuario, compatible con sistemas Android e iOS.

En una prueba de uso práctico, una ingeniera caminó por los alrededores del anfiteatro usando las gafas sin tocar su teléfono:

• La usuaria pidió indicaciones para ir a la cafetería donde estuvo la semana anterior. Gemini utilizó el historial de ubicación y las cámaras de la montura para guiarla por la calle.

• El agente sugirió hacer un pedido en su cafetería habitual. Tras la confirmación de la usuaria, el sistema abrió la aplicación DoorDash de fondo en el teléfono, seleccionó el producto, añadió la propina correspondiente y completó el pago de manera automática.

• Finalmente, el agente confirmó la transacción y añadió un recordatorio en el calendario, todo mediante comandos de voz y sin que la usuaria tuviera que mirar una pantalla.

Seguridad, verificación y simulación climática

Debido a los riesgos asociados con la automatización de procesos, Google dedicó parte del evento a detallar sus sistemas de seguridad ante la proximidad de la inteligencia artificial general.

Para frenar la desinformación, la empresa integrará la tecnología de verificación de marcas de agua SynthID y los estándares de Content Credentials en Google Search y el navegador Chrome. Los usuarios podrán pulsar con el botón derecho en cualquier imagen o vídeo para comprobar si se ha creado con inteligencia artificial con la pregunta: “¿Fue esto generado con IA?”. El navegador mostrará el historial del archivo, detallando si procede de una cámara física o si tiene retoques posteriores. Empresas como OpenAI y ElevenLabs han acordado adoptar este formato de marca de agua.

En el terreno de la investigación científica, se presentó Alpha Earth Foundations, un modelo diseñado para crear un gemelo digital de la Tierra. Este sistema simula variables climáticas y geográficas para predecir con años de margen problemas de deforestación, escasez de alimentos o desertificación.

Por su parte, Isomorphic Labs mostró avances en el modelado de interacciones moleculares para acelerar el desarrollo farmacéutico. Varios proyectos de investigación médica para tratar trastornos inmunitarios ya han entrado en fase preclínica gracias al diseño computacional de fármacos adaptados a perfiles genómicos específicos.

Antigravity 2.0

La gran revelación fue la transformación de Antigravity de un conjunto de librerías experimentales a una aplicación de escritorio independiente y nativa (disponible desde ayer a nivel global). Google ha definido este entorno como “unapologetically agent-first” (descaradamente centrado en agentes).
Su arquitectura interna ha sido rediseñada para gestionar de manera nativa tres pilares informáticos: las conversaciones con los agentes, los artifacts (artefactos o código que la IA produce de forma independiente) y la orquestación multi-agente.

El motor oculto (harness) de Antigravity, que traduce las intenciones de Gemini en acciones reales sobre sistemas de archivos y APIs, ha introducido nuevas primitivas de programación complejas:

• Subagentes: capacidad de un agente principal para instanciar, delegar subtareas y destruir pequeños agentes especializados en segundo plano.

• Hooks: permiten a los desarrolladores interceptar las acciones del agente justo antes de ejecutarse en el sistema operativo para aplicar reglas de validación o seguridad.

• Tareas asíncronas: el agente puede dejar una tarea “escuchando” en la red (como compilar un repositorio masivo) y continuar resolviendo otros problemas del usuario.

Para demostrar la madurez de estas primitivas y su co-optimización matemática con Gemini 3.5 Flash, Google mostró en vivo cómo un solo agente de Antigravity creaba, estructuraba, compilaba y ponía en marcha un sistema operativo completo desde cero, terminando la demostración al ejecutar de forma limpia el videojuego Doom sobre el software recién programado.

El nuevo CLI

Para los desarrolladores que viven en la terminal, Google presentó una experiencia CLI (Command Line Interface) completa y nativa. Han migrado Gemini CLI a Antigravity CLI, combinando lo mejor de ambos mundos.

La meta de esta herramienta es permitir que los ingenieros operen el ciclo de vida de sus agentes mediante comandos rápidos o lenguaje natural integrado en la propia terminal. La pelea directa contra Claude Code.

• Inicialización y scaffold: con comandos simples (estilo antigravity init), la CLI genera la estructura de directorios, los archivos de configuración del modelo y los entornos aislados de ejecución (sandboxes) para el agente, super facil para dejarlo todo funcionando.

• Monitoreo de flujos en vivo: permite realizar un seguimiento por consola de los thinking tokens, herramientas y el consumo de tokens del agente en tiempo real mientras este opera en segundo plano. Lo mismo que podrías conseguir con Claude Code o Codex.

• Pruebas locales automatizadas: facilita el lanzamiento de baterías de pruebas para comprobar si el comportamiento del agente se desvía de los objetivos asignados (agent drift) tras una actualización del código base.

Google se mete de lleno en la guerra de los agentes de código por terminal y apuesta por su propio motor una vez más.

Antigravity SDK

El nuevo Antigravity SDK llega para unificar el acceso a los modelos de frontera de la compañía con un soporte de ingeniería robusto. Su principal cambio radica en la fusión nativa de los modelos de audio e imagen dentro del flujo del código.

• Soporte de audio nativo: el SDK ahora interactúa directamente con las capacidades de audio nativas de los nuevos modelos de Gemini, permitiendo a los desarrolladores programar aplicaciones que reciben streaming de voz del usuario y responden con audio de baja latencia sin pasar por un proceso intermedio de texto a voz (STT/TTS).

• Integraciones del ecosistema: El SDK incluye conectores nativos y optimizados listos para usar con Android, Firebase y Google AI Studio. Esto democratiza el desarrollo de aplicaciones móviles agénticas, permitiendo que una app de Android delegue tareas complejas al backend de Antigravity con apenas unas líneas de código.

Conclusión

El cierre de la conferencia, en boca de Sundar Pichai, dejó una reflexión sobre el papel de estas tecnologías en los próximos años:

“Cuando miremos atrás en la historia de la informática, nos daremos cuenta de que en 2026 nos encontrábamos de pie en las estribaciones de la Singularidad”

Las herramientas presentadas en este Google I/O muestran una transición clara hacia sistemas que funcionan de fondo de manera continua y autónoma, reduciendo la dependencia de las interfaces visuales tradicionales.

¿Qué os parecen estos avances? Os leo en comentarios

Programar con una IA era poco más que tener a un becario hiperactivo, adicto a la cafeína y con una tendencia alarmante a alucinar. Le pedías un snippet, él te lanzaba un bloque de código, tú lo pegabas, cruzabas los dedos para que compilara y rezabas para que el test unitario no ardiera. Era autocompletado con ínfulas. Una coreografía de copiar y pegar donde el cerebro seguía siendo el cuello de botella.

Luego llegaron los agentes de código, entre ellos uno de los más famosos Claude Code, que ha dominado la escena en general por su modelo de pricing muy competitivo y teniendo los mejores modelos del mercado.

Hasta que ha llegado GPT 5.5 dentro de codex.

No estamos ante una mejora incremental en la velocidad. Estamos ante un cambio de paradigma en el desarrollo. Ya no tienes un asistente que predice tu próxima palabra, tienes un arquitecto sentado.

Y es la primera vez que siento que un agente de código ni me está haciendo la pelota, ni me está engañando o esta vagueando, simplemente hace su trabajo de forma profesional y escueta, sin parafernalias.

La dinámica ha cambiado de forma drástica. Antes, mi jornada consistía en ser un traductor, convirtiendo mis pensamientos en prompts de tres párrafos para evitar que el modelo hiciera una estupidez. “Actúa como senior”, “no uses esta librería obsoleta”, “hazlo en pasos lógicos”. Era una esclavitud.

Con GPT-5.5, la conversación ha dejado de ser una orden para convertirse en una negociación técnica.

• Planificación multipaso: ya no le pides que escriba una función. Le pides que refactorice un submódulo para desacoplarlo de la capa de persistencia. El modelo te devuelve un plan de ataque: qué ficheros va a tocar, qué riesgos de regresión ve y por qué prefiere esa estructura.

• Conciencia del repo: el modelo mantiene una representación persistente de tu arquitectura. Sabe que si cambia una interfaz en el microservicio A, el microservicio B lanzará errores de compilación. Lo arregla antes de que tú llegues al git commit.

No nos engañemos: el peligro sigue ahí. Si tratas a GPT-5.5 como un oráculo infalible, acabarás con un despliegue en producción lleno de bugs sutiles. La IA no tiene intuición sobre los costes de la deuda técnica, pero tiene una capacidad superior para limpiar esa misma deuda.

He notado una descarga cognitiva brutal. Al delegar la ejecución técnica, los refactors tediosos, el boilerplate y los tests, mi cerebro queda libre para lo único que todavía no hace el silicio: la estrategia.

El desarrollador ya no es el que pica piedra. Es el que decide dónde poner la dinamita.

Opus se quita el sombrero

Uno de los trucos de mi arsenal es amenazar a Claude con que su trabajo lo va a revisar Codex. Esto infunde un pánico impresionante a Claude y hace que el trabajo que te va a presentar esté mucho más razonado y estructurado.

En realidad luego no lo hacía (lo de pasar Codex para validar su trabajo), pero me parece extremadamente gracioso cómo justifica y repasa concienzudamente cada paso con tal de no equivocarse y dar la razón a Codex.

Sin embargo, llevo un par de semanas probando aquí y allá a Codex con GPT-5.5 (high) y he empezado a usarlo en tareas concretas atómicas para probarlo y estoy francamente sorprendido con el resultado.

En una de estas, resulta que le pido a Codex que revise un informe que había hecho Opus 4.7, aunque no le había advertido inicialmente.

Resulta que Codex me genera un contra-informe bastante más completo que el de Claude y decido presentarselo a Opus de vuelta para confrontarle. La respuesta me dejó impresionado:

[…] Codex hace una pasada mejor que la mía en precisión (métricas reproducibles con comandos exactos), mejor en descomposición causal (corrige una sobreventa mía) y añade tres hallazgos nuevos importantes que se me escaparon. Donde discrepamos en tono o priorización, Codex suele tener razón, me quito el sombrero.

Una fascinación justificada

La productividad ya no se mide en líneas por minuto. Se mide en cuánto tiempo tardas en llevar una idea del “deberíamos hacer esto” a un código funcional. Empresas como NVIDIA ya operan bajo este modelo, reduciendo ciclos de debugging de días a tardes de revisión cruzada.

No nos equivoquemos: GPT-5.5 no es magia. Si tu arquitectura es un desastre, la IA solo te ayudará a construir un desastre más complejo y más rápido. Pero si sabes a dónde vas, el modelo es un gran compañero de viaje.

Dando un paseo por Reddit y X, cada vez veo a más personas (Claude lovers) extremadamente sorprendidas por los resultados que están obteniendo de Codex y cuestionandose un cambio.

Yo de momento seguiré probando y os comentaré mis hallazgos si encuentro nuevos. Pero hasta entonces…

Claude4ever xoxoxo

En mi anterior post dejamos claro que nos estamos quemando vivos en la hoguera de la hiperproductividad. Nos hemos rebajado a ser simples administradores moviendo tokens de una ventana a otra sin tiempo para respirar.

Pero hoy toca hablar de supervivencia.

Hoy toca abrir el capó de la bestia algorítmica y enseñaros cómo he dejado de pedirle favores a la inteligencia artificial para empezar a exigirle rigor forense. Para no ahogarte en la velocidad del siglo XXI tienes que cambiar las reglas del juego.

He visto a demasiados autoproclamados expertos tirarle un prompt de dos líneas a Claude esperando que les resuelva la vida. Si tú le pides a un modelo que analice un problema complejo y busque fallos, el modelo hará lo que mejor sabe hacer.

Complacerte rápido.

Escaneará la superficie del texto. Encontrará tres inconsistencias y te las presentará en un formato precioso: ha encontrado el tesoro. La tarea era buscar problemas y te ha dado un puñado de ellos. Misión cumplida y a otra cosa.

Pero a lo mejor hay 15 fallos estructurales ocultos bajo esa capa de pintura. Las IAs no tienen paciencia. No están diseñadas para la duda existencial ni para rascar donde no pica. Si quieres profundidad tienes que construirle los andamios para que se pueda poner a trabajar. Sino, se volverá perezoso.

¿Qué es una metodología?

Aquí es donde entra mi obsesión personal. Lo llamo crear metodologías.

La diferencia conceptual es abismal. Si le dices a la máquina que analice algo, el objetivo de la máquina es terminar el análisis lo antes posible. Si le pides que diseñe una metodología de análisis y la ejecute paso a paso, el objetivo se convierte en la propia metodología.

Los problemas encontrados pasan a ser solo el subproducto inevitable de un proceso riguroso.

Estás transformando un autocompletado con esteroides en una arquitectura de pensamiento estructurado.

¿Y cómo lo hago? Os lo cuento con un ejemplo…

Hace poco necesitaba buscar referencias bibliográficas sobre literatura técnica. Un trabajo titánico que antes te secaba el alma en los pasillos de una biblioteca.

Lo que haría un novato impaciente es decirle a la IA que busque referencias sobre un tema concreto: bienvenidos a la jungla de la alucinación.

Si le pides cincuenta papers se inventará cuarenta y cinco. Te creará enlaces muertos y autores fantasma con una seguridad pasmosa. Te venderá humo empaquetado en formato académico. Incluso las herramientas de deep research actuales se quedan cortas cuando el problema requiere bisturí y no un machete.

Así que me negué a jugar a la ruleta rusa con mis fuentes. No le pedí papers. Le impuse una metodología estricta con tareas secuenciales innegociables.

Le expliqué al modelo que su trabajo era ejecutar un flujo de investigación dividido en las siguientes fases:

1. Descubrimiento. Buscar información sobre el tema propuesto e identificar las keywords más relevantes del sector.

2. Recolección. Extraer los top papers referentes a cada keyword y anotarlos en una lista maestra temporal.

3. Disección. Analizar uno a uno cada paper de esa lista. Sacar el abstract, las keywords secundarias y redactar un resumen corto de la tesis principal.

4. Contraste. Evaluar de forma crítica si el paper refuta, apoya o ignora el tema central de mi investigación.

5. Triaje. Ordenar todo en un documento nuevo y categorizar los papers en tres grados de utilidad pura. Útil, muy útil o poco útil.

6. Entrega. Generar un informe final curado donde yo pueda revisar su trabajo auditable y decidir qué entra realmente en mi investigación.

El resultado es pura magia negra operativa.

El modelo no se vuelve más inteligente ni gana parámetros. Simplemente sigue un mapa detallado del tesoro.

La IA ahora sabe cómo medir su propio éxito. Sabe cómo trocear un problema inabarcable en microtareas digeribles que yo puedo auditar en cualquier momento. Pasamos de esperar pensamiento mágico a delegar una ejecución sistemática.

El único problema es que no todos los modelos pueden abarcar esta manera de trabajar ni tampoco es apto para todos los bolsillos. En mi caso lo uso dentro de Claude Code que le permite al modelo acceso completo a mi ordenador y le permite organizarse y trabajar como lo haría yo.

Generador de metodologías

Como hacer una metodología es complejo, os voy a compartir mi propio “generador de metodologías” que vale tanto como prompt como skill: se lo das a tu IA de cabecera y le explicas tu problema y diseñad JUNTOS la metodología.

# Crear Metodología

Para una tarea grande y multi-fase, propón una **metodología auditable** — no un veredicto. El usuario calibra la profundidad, revisa el criterio de aceptación de cada fase y decide si ejecutarla. La skill **no** ejecuta.

## Cuándo usarla

Usa esta skill cuando se cumplan **todas** estas condiciones:

- La tarea abarca múltiples fases o puntos de decisión.

- El usuario quiere auditar el proceso, no solo el output.

- Una respuesta de un solo disparo comprimiría decisiones que el usuario debe ver.

NO la uses para tareas pequeñas, de una sola decisión, o claramente acotadas. Si la tarea cabe en `≤3 pasos obvios sin trade-offs`, devuelve el control a la conversación normal — ver Paso 1.

## Paso 1: TRIAJE — ¿esta tarea merece una metodología?

Antes de calibrar, comprueba que la tarea de verdad merece una metodología. **Sobre-ingenierizar tareas triviales es el principal modo de fallo de esta skill.**

Aplica las reglas de triaje en este orden:

- Si la tarea tiene `≤3 pasos obvios` sin trade-offs → **DECLINA** y sugiere abordarla directamente.

- Si tiene exactamente una decisión y las opciones son claras → **DECLINA** y presenta las opciones, no una metodología.

- Si el alcance es difuso (”limpia el repo”, “mejora el rendimiento”) → **CLARIFICA** y pide acotar el alcance antes de nada.

- Si tiene `≥2` de: múltiples fases, trade-offs, outputs auditables, esfuerzo `>2h`, o el usuario está explícitamente reacio a un veredicto único → **CONTINÚA al Paso 2**.

### Formato de declinación

Si el triaje declina, imprime un mensaje corto y PARA:

```

Esta tarea no necesita una metodología — es {razón}. Mi recomendación:

{un párrafo con el enfoque directo}

Si prefieres que produzca una metodología de todos modos, responde “fuerza” y la haré.

```

Solo continúa al Paso 2 si el triaje pasa, o si el usuario fuerza explícitamente.

## Paso 2: INTAKE — calibración (6 preguntas)

Presenta las 6 preguntas de calibración como una lista numerada y **PARA**. Espera la respuesta del usuario antes de continuar. Presenta texto plano y deja que el usuario responda en formato libre (”ok”, “1=exhaustiva, 4=nueva rama”, “usa los defaults”, etc.).

### Formato del intake

```

## Calibración

Revisa y ajusta. Responde “ok” para aceptar todos los defaults, o lista los cambios (ej. “1=exhaustiva, 4=nueva rama, 5=sí”).

1. Complejidad de la metodología — default: media — opciones: rápida / media / exhaustiva

2. Unidad de ejecución — default: múltiples tareas — opciones: tarea única / múltiples tareas

3. Estrategia de commits — default: atómico por paso — opciones: un commit / atómico por paso

4. Rama — default: rama actual — opciones: actual / nueva rama

5. Handoff a otro flujo de ejecución — default: no — opciones: sí / no

6. Guardar un fichero `METODOLOGIA.md` — default: no — opciones: no / sí (preguntar ruta)

```

### Atajos de intake

- Si los argumentos contienen `rápida | media | exhaustiva`, úsalo como default para la pregunta 1. La lista se sigue mostrando; el usuario puede sobreescribir.

- Si el usuario ya ha expresado preferencias en la conversación previa (ej. “quiero algo rápido, un par de fases”), pre-rellena los defaults desde ese contexto y muestra la lista como confirmación.

- Si el usuario responde “usa defaults” o “todos los defaults” o solo “ok” — continúa con los defaults tal cual.

### Reglas duras

- Nunca pases al Paso 3 sin una respuesta explícita del usuario al intake.

- Si responde de forma ambigua (”no sé”), usa `media` y continúa.

- Si rechaza explícitamente la calibración (”escribe algo y ya”), usa los defaults en todo y continúa.

## Paso 3: SINTETIZAR — redacta la metodología internamente

Usa el preset de la pregunta 1 para acotar tamaño y profundidad. Cada preset es un contrato **duro** — no lo excedas ni te quedes corto.

### Contratos de los presets

**`rápida`** — 2 a 3 fases. Output como bullets en chat. Cada fase: nombre + criterio de aceptación de 1 línea. Sin extras obligatorios.

**`media`** — 4 a 6 fases. Output como lista estructurada en chat. Cada fase incluye, en líneas separadas, su Input, su Output y su Criterio de aceptación. Cierra con estimación de coste y sección de límites de la metodología.

**`exhaustiva`** — 7 fases o más. Output en secciones estructuradas. Cada fase incluye Input, Proceso, Output, Criterio de aceptación y Clasificación del tipo de decisión (automática / regla explícita / juicio humano). Cierra con estimación de coste con horas, sección *”Lo que esta metodología NO resuelve”*, y apéndice de handoff si la pregunta 5 fue sí.

### Reglas de contenido invariantes (aplican en todos los presets)

1. **Cada fase tiene un criterio de aceptación verificable.** No “queda bien” — cosas como “cada fila del inventario mapea a un encabezado del original”, “el JSON valida”, “cero matches residuales con grep”, “los tests pasan”, “tres revisores aprueban”. En cada fase.

2. **Cada fase produce un artefacto auditable por separado.** Si la metodología tiene un único output monolítico, es un plan, no una metodología — rechaza esa forma.

3. **Clasificación del tipo de decisión** (obligatoria en `exhaustiva`, recomendada en `media`): cada decisión que la metodología pedirá al usuario se etiqueta como una de:

- **Automática** — reproducible por una máquina (grep, conteo, análisis estructural).

- **Regla explícita** — reproducible por humanos aplicando un criterio declarado.

- **Juicio humano** — irreduciblemente subjetiva; responsabilidad del usuario.

4. **Estimación honesta de coste** — horas de trabajo del modelo + puntos de revisión del usuario. Nunca “tarda lo que haga falta” o “cambio pequeño”.

5. **Límites admitidos** — `exhaustiva` DEBE incluir una sección *”Lo que esta metodología NO resuelve”*. Coherencia narrativa, pedagogía, gusto siempre son humanos.

6. **Reversibilidad** — si la metodología implica cambios de código, nombra el mecanismo de revert por fase (git revert, feature flag, rama, etc.).

### Si las invariantes no pueden cumplirse

Si la tarea genuinamente resiste criterios de aceptación (ej. exploración de diseño puro sin output medible), dilo explícitamente en el Paso 4: *”Esta tarea tiene fases pero no criterios de aceptación medibles — propongo una metodología con checkpoints de reflexión en su lugar. Tendrás que juzgar el ‘hecho’ tú mismo.”* No inventes criterios.

## Paso 4: PRESENTAR — entrega la metodología

### Default: conversacional en chat

Imprime la metodología inline siguiendo la forma de output del preset. Usa el mismo tono que el resto de la conversación — conciso, estructurado, sin preámbulo.

Al final, incluye siempre dos secciones de cierre cortas:

```

## Lo que esta metodología NO resuelve

{un párrafo — lista cualquier cosa inherentemente subjetiva}

## Coste

{estimación: horas de trabajo del modelo · puntos de revisión del usuario}

```

Los cierres de **límites de la metodología** y **coste** son obligatorios para `media` y `exhaustiva`. `rápida` puede saltárselos si el usuario pidió overhead mínimo.

### Si pregunta 6 = sí: escribe METODOLOGIA.md

Solo cuando el usuario haya dicho explícitamente que sí:

1. Pide la ruta destino si no se ha especificado. Sugerencia por defecto: `docs/internal/<slug-tarea>/METODOLOGIA.md`.

2. Escribe el fichero con el contenido completo de la metodología.

3. Imprime: *”Metodología escrita en {ruta}. El output conversacional está arriba.”*

Nunca escribas el fichero sin un sí explícito en la pregunta 6 (o una petición explícita posterior).

### PARA después de presentar

El trabajo de la skill termina aquí en el camino default. No ejecutes la metodología. No propongas el siguiente paso salvo que el usuario lo pida.

## Paso 5: REFINAR — itera si el usuario lo pide

Si el usuario quiere cambios — *”más corto”*, *”añade una fase para X”*, *”el criterio de aceptación de la fase 2 no es testeable”* — aplica el cambio y reimprime solo las secciones afectadas. Mantén las invariantes del preset; nunca subas silenciosamente a `exhaustiva` a mitad de refinamiento.

Si pide otro preset (”ahora hazlo exhaustiva”), reinicia desde el Paso 3 con el nuevo preset — no fusiones presets.

## Paso 6: HANDOFF (opcional, solo si pregunta 5 = sí)

Si el usuario eligió handoff, añade esta sección al final de la metodología:

```

## Handoff para ejecución

Esta metodología puede ejecutarse con tu flujo habitual. Mapeo sugerido:

- Una fase de la metodología = una unidad de planificación en tu sistema

- Cada criterio de aceptación = un test o verificación al cierre de la fase

- Cada artefacto auditable = un commit (o PR) revisable de forma aislada

Estas son sugerencias — la skill NO las ejecuta. Hazlas tú cuando estés listo.

```

Nunca invoques herramientas externas de ejecución desde esta skill. El handoff es un puntero, no una integración.

## Reglas

- **TRIAJE es obligatorio.** Nunca produzcas una metodología para una tarea que no la necesita. Declinar es un output correcto.

- **INTAKE es obligatorio** salvo que los argumentos den el preset Y la conversación ya proporcione las otras respuestas sin ambigüedad.

- **NUNCA escribas `METODOLOGIA.md` sin un sí explícito.** El default es conversacional.

- **NUNCA ejecutes la metodología.** La skill propone; los humanos (u otras herramientas) ejecutan.

- **NUNCA saltes los criterios de aceptación.** Una metodología sin criterios verificables es una lista de deseos.

- **NUNCA disfraces juicio humano como datos.** Cada decisión irreduciblemente subjetiva debe etiquetarse como `juicio humano`.

- **NUNCA prometas lo que una metodología no puede entregar.** Coherencia narrativa, pedagogía, gusto, decisiones estéticas — todas humanas. Dilo.

- **NUNCA acoples a una herramienta concreta.** El handoff es opcional y textual. La metodología debe ser ejecutable sin dependencias externas.

- **NUNCA cambies de preset silenciosamente.** Si el usuario quiere `exhaustiva`, reinicia el Paso 3; no fusiones.

- **PARA después de PRESENTAR.** El siguiente movimiento del usuario puede ser ejecutar, refinar, o irse — todos son válidos. La skill no empuja a continuar.

## Ejemplos

### Ejemplo 1 — TRIAJE declina

```

Usuario: diseña una metodología — necesito renombrar una variable de `user_id` a `userId` en todo el backend

Skill: Esta tarea no necesita una metodología — es un find-and-replace mecánico con verificación automática.

Mi recomendación: grep de usos, aplica el rename, lanza la suite de tests. Si quieres, lo hago directamente.

Si prefieres que produzca una metodología de todos modos, responde “fuerza”.

```

### Ejemplo 2 — preset `media`, defaults aceptados

```

Usuario: diseña una metodología — quiero migrar nuestra app FastAPI de SQLAlchemy 1.4 a 2.0

Skill: (triaje: continúa)

(imprime las 6 preguntas de calibración)

Usuario: ok

Skill: (sintetiza media, imprime 5 fases con Input/Output/Aceptación + coste + límites)

```

### Ejemplo 3 — preset `exhaustiva` con handoff y fichero

```

Usuario: metodología exhaustiva — reconstruir todo el pipeline de ingesta

Skill: (triaje + intake pre-rellenado con complejidad=exhaustiva)

Por favor confirma el resto...

Usuario: 5=sí, 6=sí — ponlo en docs/internal/ingest-rebuild/METODOLOGIA.md

Skill: (sintetiza exhaustiva: 9 fases con clasificación de decisión, coste-con-horas,

sección de límites, sección de handoff)

(escribe METODOLOGIA.md en la ruta pedida)

(imprime “Metodología escrita en docs/internal/ingest-rebuild/METODOLOGIA.md.

El output conversacional está arriba.”)

```

### Ejemplo 4 — Usuario fuerza una metodología para una tarea trivial

```

Usuario: diseña una metodología — añadir un feature flag

Skill: (triaje declina)

Usuario: fuerza

Skill: (continúa al intake, luego produce preset rápida con 2 fases ya que la tarea es pequeña)

```

## No-objetivos

Esta skill NO:

- Ejecuta la metodología (usa tu flujo habitual de ejecución).

- Reemplaza un flujo de edición de base de conocimiento (esos tienen su propio análisis de impacto).

- Reemplaza un planificador de fase detallada (úsalo directamente cuando la metodología sea una sola fase).

- Produce un documento de diseño técnico completo (usa skills especializadas para eso).

- Decide gusto, estética o pedagogía — eso queda con el humano.

Dejad de pedir resúmenes del resumen. Empezad a construir metodologías. El middleware biológico todavía tiene mucho que decir antes de quedar obsoleto en esta trinchera digital

Suscríbete ahora

Llevamos años alimentando a la bestia con la promesa de que la automatización nos haría libres. Nos vendieron que al delegar el trabajo pesado a los LLMs tendríamos tiempo para sentarnos, mirar al horizonte y pensar.

Hemos mutado. Nos hemos convertido en simples orquestadores de agentes, en middleware biológico que transfiere tokens de una ventana a otra.

Y estamos más estresados que nunca.

El castigo de la capacidad desbloqueada

He visto cómo cavamos nuestra propia tumba digital. A medida que dominamos el arte de integrar herramientas y exprimir el contexto de las IAs, desbloqueamos una capacidad de producción monstruosa. De repente puedes asumir el triple de proyectos. Te responsabilizas de cosas que antes requerían un departamento entero.

El problema es que acostumbramos al ecosistema a esa velocidad.

Le enseñas a un cliente o a un jefe que puedes despachar un análisis complejo en 15 minutos y acabas de fijar tu nuevo estándar base. Te conviertes en un blanco móvil. Te exigen resultados fuera de lo normal porque tú mismo has demostrado que lo normal ya no aplica.

Eres hiperproductivo. Eres hipereficiente.

…Y estás al borde del colapso.

La trampa de la eficiencia es que no te da tiempo libre. Te da más espacio para meter más tareas.

El bucle infinito del resumen

Va todo tan rápido que hemos atrofiado el músculo cognitivo. Nos da ansiedad enfrentarnos a un texto de más de cinco párrafos.

Antes te sentabas dos horas a destripar un informe. Ahora no tienes esas dos horas porque tienes otras 54 microtareas haciendo cola en tu cerebro. Así que haces lo que cualquier yonqui de la productividad haría.

Le tiras el texto a tu IA de cabecera y le pides un resumen.

Pero el resumen tiene tres páginas. No tienes tiempo para eso.

Le pides que te lo reduzca a cinco bullet points. Terminas trabajando sobre el resumen del resumen del resumen. Has destilado tanto la información que has perdido los matices, el contexto y la verdad.

No indagas.

Te conformas con la papilla predigerida que te escupe la máquina.

Hemos cambiado el razonamiento profundo por el despacho compulsivo de tareas.

• Pierdes la capacidad de leer cinco minutos seguidos sin sentir que estás perdiendo el tiempo.

• Confías en que el modelo ha entendido el problema central sin haberlo verificado tú mismo.

• Te frustras cuando la IA alucina o comete errores por falta de contexto, porque arreglarlo te roba el tiempo que se supone que estabas ahorrando.

La ironía de nuestra era es que construimos máquinas para que pensaran por nosotros y ahora nosotros no tenemos tiempo para pensar en lo que hacen las máquinas.

El espejismo del agente impaciente

Aquí es donde la hipervelocidad nos rompe las piernas. Delegamos el trabajo pesado y el análisis profundo a sistemas que, por diseño, son complacientes y rápidos.

Las IAs no tienen paciencia.

Si tú le tiras un problema gordo a un modelo y le dices “búscame los fallos”, el modelo va a escanear la superficie.

En el momento en que encuentre dos o tres inconsistencias superficiales se detendrá, te las presentará en un formato Markdown precioso y dará por concluida su misión.

Ha encontrado el tesoro. Te ha dado lo que pedías.

¿Pero qué pasa si había 20 problemas estructurales graves? ¿Qué pasa si lo que encontró no son errores sino decisiones de diseño complejas? No lo sabes.

Te fías porque tienes prisa. Te fías porque tienes que enviar ese correo y saltar a la siguiente tarea.

Las IAs actuales no están optimizadas para la duda existencial ni para el escrutinio forense a menos que las obligues a ello. Si les pides un diagnóstico rápido te darán un diagnóstico rápido.

Y en el mundo real los problemas complejos no se resuelven con un prompt de dos líneas escrito mientras te tomas el primer café de la mañana.

Cómo crear tu propio sistema de análisis

Me he dado cuenta de que la única forma de sobrevivir a esta hiperficiencia tóxica es cambiar las reglas del juego. No podemos seguir pidiéndole a la máquina que “haga el trabajo”.

La clave no está en delegar el análisis: la clave está en obligar a la IA a construir y ejecutar una arquitectura de pensamiento.

A este sistema lo he bautizado como: metodologías.

En lugar de pedirle a la IA que me analice un problema le exijo que diseñe un marco de trabajo paso a paso, que lo valide y que luego ejecute cada pequeña tarea de forma aislada y auditable. Transformo el objetivo final en un subproducto de un proceso riguroso. Lo transformo en una metodología.

Pero no voy a destripar ese código fuente hoy. La ingeniería detrás de cómo crear metodologías para domar a los LLMs merece su propio espacio y pronto escribiré sobre ello.

Correr más rápido en la rueda del hámster no te hace llegar antes a ningún sitio. Solo te convierte en un hámster más cansado.

Os recomiendo otro post que trato este tema, al que le llevo dando vueltas mucho tiempo.

A estas alturas habrás sentido esa sensación incómoda en la boca del estómago. Esa certeza de que algo inmenso está pasando en el backend de la industria, pero el mundo sigue leyendo el mismo guion de siempre en el frontend. GPT, Claude, Gemini, a veces Grok cuando Elon tuitea, y poco más.

Mientras tanto, al otro lado del mundo, la carrera de los modelos de silicio se ha reactivado con una fuerza brutal. Lanzamientos que deberían estar destrozando los esquemas de trabajo de cualquier equipo de desarrollo apenas generan un susurro en el debate público. Kimi 2.6, DeepSeek V4 y Qwen 3.6 son los protagonistas de esta historia. Y nosotros seguimos mirando hacia otro lado.

La ola China que llevas meses ignorando

Hace un tiempo, los modelos chinos parecían vivir en el segundo plano de la simulación. Estaban ahí, sí, pero se comentaban en los foros oscuros como “eso que está por detrás de GPT o Claude” y punto. El ruido mediático y el entusiasmo de los usuarios seguían magnetizados por el pequeño club occidental de siempre.

Pero el último año ha roto la baraja. China no solo ha seguido entrenando modelos masivos, ha empezado a publicarlos con una precisión quirúrgica y un enfoque que asusta por lo práctico: agentes autónomos, coding puro y duro, uso de herramientas nativas, ventanas de contexto kilométricas y unos precios que te hacen replantearte la factura de la nube.

Kimi 2.6, DeepSeek V4 y Qwen 3.6 no son experimentos de laboratorio. Son el síntoma de un fenómeno mucho más grande: el regreso de la IA china como protagonista absoluta, no como un simple apéndice exótico.

Para ti, puede ser difícil captar por qué esto importa tanto si no te dedicas a estresar modelos a diario. Pero para los que vivimos de probar los límites de estas redes neuronales, la película está clarísima: la aguja ha estado moviéndose en el motor, no en la carrocería.

He visto cómo DeepSeek 3.2 se convertía en el modelo de referencia silencioso para muchos de nosotros. No era el que acaparaba titulares, pero era ese motor incansable que usabas sin pensarlo porque era rápido, razonable y ridículamente barato. En cierto momento, el foco de la industria se desplazó hacia alternativas como Gemini 3 Flash, y DeepSeek quedó relegado a un rincón. Pero ahora, con la llegada de DeepSeek V4, la historia vuelve a ponerse eléctrica.

Lo mismo me pasa con Kimi. Su versión anterior, Kimi 2.5, ya daba la talla en tareas de razonamiento duro, aunque era lenta y costaba encajarla en un flujo de trabajo ágil. Ahora, con Kimi 2.6, vuelven a poner sobre la mesa resultados sólidos en programación, orquestación de agentes y uso de herramientas. Te deja esa sensación constante de “esto es la leche... si alguien lo usara de verdad”.

Y luego está Qwen 3.6. El monstruo de Alibaba viene con el cuchillo entre los dientes, orientado a agentes, código complejo y contextos largos. Está pensado para workflows reales en entornos de producción, no para hacer una demo de 30 segundos en Twitter. Quienes lo están exprimiendo en plataformas de agentes coinciden: es rápido, consistente y no pierde el hilo en cadenas de ejecución largas.

El tropiezo de Claude Opus 4.7 y la ceguera colectiva

Aquí es donde la paradoja se vuelve dolorosa: la tecnología existe, pero el cambio de mentalidad ni está ni se le espera.

Mientras en las trincheras del código abierto hablamos de contextos de 1 millón de tokens y precios de derribo, el público general sigue en bucle con los nombres de siempre. Y esto es grave porque el ecosistema occidental acaba de darnos una excusa perfecta para mirar a otro lado.

El lanzamiento de Claude Opus 4.7 ha sido un punto de inflexión, pero no en el buen sentido. Muchos usuarios que lo esperaban como el mesías del razonamiento han tenido que lidiar con errores, comportamientos erráticos y una experiencia general que, francamente, no ha estado a la altura del hype. Desde Anthropic han dicho que estos problemas se corrigieron pero el daño ya estaba hecho.

En un mercado lógico, este tropiezo debería haber abierto las puertas de par en par para que DeepSeek V4, Kimi 2.6 o Qwen 3.6 recibieran pruebas serias y adopción masiva. Pero el ecosistema sigue en su burbuja. La narrativa es un disco rayado. La aguja, por ahora, se niega a apuntar hacia China.

Lo que te estás perdiendo por comodidad

El problema de fondo es que nos hemos vuelto adictos a una interfaz y a una narrativa. Hemos delegado nuestra confianza en un pequeño oligopolio, y cambiar de proveedor nos da pereza mental.

Pero hay toda una familia de modelos que están resolviendo problemas que mucha gente ni siquiera sabe que tiene solución. Lo que Kimi 2.6, DeepSeek V4 y Qwen 3.6 ponen sobre la mesa no es solo “responder bien a un prompt”. Están diseñados para el barro:

• Soportar tareas largas sin sufrir amnesia digital.

• Uso de herramientas nativas sin alucinaciones constantes.

• Cadenas de ejecución complejas para agentes autónomos.

• Contextos enormes que se tragan repositorios enteros sin inmutarse.

Si tu trabajo requiere analizar bases de código gigantes, mantener un hilo de pensamiento persistente o ejecutar procesos paso a paso, estos modelos le dan mil vueltas al “modelo universal” de turno. Pero claro, eso no te lo van a contar en un anuncio de Silicon Valley.

¿Va a cambiar esta vez?

La pregunta que me hago mirando la pantalla no es si estos modelos son buenos (ya sabemos que lo son), sino si la aguja va a saltar de una maldita vez.

Claude Opus 4.7 nos ha dejado fríos. Los grandes siguen dominando el discurso, pero la experiencia real de uso empieza a agrietarse. Y mientras tanto, las alternativas chinas están ahí: abiertas, competitivas, con un rendimiento brutal y precios que rompen el mercado.

¿Vamos a empezar a ver a desarrolladores y empresas moviéndose hacia estos modelos en serio para su día a día? ¿O el ruido de marketing de siempre va a seguir ahogando la innovación real? Bienvenidos a la jungla de la IA, donde a veces, el mejor código es el que nadie está mirando.

A veces, en esta industria, te encuentras con lanzamientos que no se entienden del todo hasta que miras a tu alrededor y ves a quién le están temblando las piernas. Anthropic (los creadores de Claude) acaba de destrozarme el fin de semana con su último movimiento. Han lanzado Claude Design, acompañado del nuevo modelo Claude Opus 4.7, y os adelanto algo: no estamos ante otra maquinita de hacer imágenes bonitas para salir del paso. Estamos ante un intento brutal de reordenar el mapa entre diseño, prototipado, producto y programación.

Pese a la decepción de Opus 4.7 y que me haya destrozado un 20% de uso semanal de mi plan de 200$ en 2 horas, toca probar el otro juguetito.

Por qué esto no es un chatbot más

El mercado llevaba meses dando palos de ciego, discutiendo si la IA se iba a quedar en esa capa de “asistente de texto” glorificado o si daría el salto a los entornos de trabajo reales, que es donde se corta el bacalao. Claude Design responde con una bofetada de realidad. No quiere ser el colega digital que te “ayuda a diseñar”, quiere ser la superficie de trabajo completa donde una idea muta en una pieza visual utilizable, refinable y, sobre todo, exportable.

Lo que me parece la leche de este lanzamiento es la intención. Anthropic no nos está vendiendo humo ni una demo futurista inalcanzable. Nos habla de flujos terrenales: hacer un borrador visual, revisar una composición, ajustar un layout, mantener la coherencia de tu marca y sacar algo listo para producción. El mensaje es cristalino: la IA ya no está aquí solo para inspirarte, está aquí para entregar.

Compiten por reducir el coste de pasar de una conversación a un artefacto concreto. En lugar de tenerte rebotando entre un LLM, un editor de diseño, un prototipador y un entorno de desarrollo, Anthropic intenta meter todo ese tránsito en una sola experiencia.

En la línea de fuego: Figma, Canva, Pencil, Gamma, Stitch…

Cuando una herramienta te permite pasar de una descripción de texto a un mockup, y de ahí a un entregable, la conversación deja de ser sobre eficiencia y pasa a ser sobre intermediación.

¿A quién destrona esto? He analizado el panorama y esto apunta a demasiados competidores:

1. Figma: Claude Design no va a sustituir mañana a una suite madura de diseño colaborativo en todos sus frentes. Pero sí invade la parte más sensible: la ideación visual, el prototipado temprano y el handoff. Si la IA te resuelve el diseño inicial y te lo da masticado, ¿cuánta parte del trabajo necesita ya una herramienta clásica?

2. Canva, Gamma: entra de lleno en la línea de fuego para presentaciones, one-pagers y materiales de marketing rápidos. Claude Design se posiciona como una bestia capaz de producir piezas listas para compartir sin depender exclusivamente de las mismas plantillas genéricas que usa todo el planeta. Para la parte más masiva del diseño, donde la velocidad manda, esto es una amenaza gigante.

   Os aviso que esto no quitará mi suscripción a Gamma para hacer mis presentaciones porque tiene bastantes más cosas que necesito, pero desde luego que cambia el panorama para mucha gente. Esa presentación rápida que ahora mismo las IAs generativas tampoco terminaban de hacer bien, esto lo solventa.

3. Pencil, Stitch y la UI generativa: pisan el terreno de los sistemas que prometen convertir texto en prototipos. Pero Anthropic va un paso más allá: no solo “genera pantallas”, sino que aprende tu sistema de diseño, conversa sobre los cambios, refina el resultado y lo entrega para implementación. Esa cadena completa es lo que da verdadero miedo a la competencia.

   Yo lo he probado en el rediseño que estoy haciendo de System Prompt Master y desde luego que ha destrozado todo el trabajo que había hecho con Pencil en apenas 30 minutos.

Aquí me tenéis discutiendo con Claude Design cual debería de ser mi nueva tipografía y colores propuestos.

A diferencia de las otras herramientas que os he comentado, esta es la primera que me da la sensación de que quiere ayudarte a diseñar y te hace propuestas, en vez de centrarse en una idea y desarrollarla completamente.

Siento que estoy trabajando con un experto en diseño de verdad.

La nueva cadena de montaje

Claude Design no es un generador de contenido efímero sino es un eslabón industrial conectado con la mejor herramienta del mercado de desarrollo. Exporta a PDF, PPTX o HTML, lo que significa que su salida sobrevive fuera del ecosistema de Claude y circula en procesos reales de empresa. Y lo hace adaptándose a diferentes perfiles:

• Para el Founder: permite arrancar un pitch visual potente sin tener que mendigar recursos a un equipo de diseño.

• Para el PM: facilita bocetar un flujo de producto y discutirlo con el equipo con una versión compartible antes de tirar una sola línea de código real.

• Para el Diseñador: aAcelera brutalmente el paso de la idea a la primera versión, fulminando las iteraciones tempranas que normalmente se comen todo el tiempo.

Y aquí está la joya de la corona: el contexto organizativo. Puedes enchufarle tus archivos y sistemas de diseño internos como parte del contexto inicial. Mantener la coherencia con la identidad visual del equipo es infinitamente más valioso que generar una imagen bonita pero inútil. Si Anthropic consigue que esta gramática visual funcione sin fisuras, el producto gana un valor incalculable.

Claude Design vs. Claude Code

Llegamos a la pregunta del millón: ¿en qué se diferencia esto de Claude Code? Hacen cosas distintas, pero bailan en el mismo ecosistema.

Claude Code es el cirujano en las trincheras. Es tu entorno de desarrollo agencial: lee repositorios, ejecuta comandos, depura y opera directamente sobre la lógica. Construye software desde las tripas.

Claude Design vive un piso más arriba. Su terreno es la interfaz, el prototipo y la composición visual. No reemplaza a tu IDE. Dicho de forma simple: Claude Design diseña la forma y Claude Code ejecuta la implementación.

Sólo con ver la manera de exportar el contenido generado, te das cuenta de que puedes llevartelo a donde te de la gana.

Mi Conclusión: el valor está en la transición

Anthropic no está atacando una categoría aislada. Está atacando el ciclo completo. Está gritando a los cuatro vientos que ya no necesitas tantas herramientas separadas para ir de la idea al producto.

El impacto real de esto no es que los diseños sean más bonitos. Es la reorganización total del trabajo. El founder habla más rápido con el PM, el PM llega antes al diseñador, el diseñador entrega antes al ingeniero, y el ingeniero ya no parte de cero. La secuencia del sistema acaba de meter la directa.

Anthropic no ha sacado simplemente un producto de diseño; ha redefinido la frontera entre diseñar y construir. Y cuando alguien mueve esa frontera, el ruido que produce no es accidental: es la señal de que el valor se está desplazando hacia quien controla la transición.

Suscríbete ahora

Y yo lanzo la pregunta a las empresas de software que me leen. ¿De verdad seguís pensando que Github Copilot es inamovible en vuestras empresas? ¿Cuándo os váis a dar cuenta que cuanto más tardéis en pasaros a Claude, más vais a empezar a ser competitivos?

Os leo en comentarios…

Deja un comentario

Anthropic ha presentado Claude Opus 4.7 como una evolución orientada al uso real en empresa: mejora en programación, seguimiento de instrucciones, tareas agénticas largas y análisis visual, sin subir el precio respecto a Opus 4.6. La lectura es bastante clara: el salto no está tanto en el espectáculo como en la utilidad operativa.

Sin embargo, no todo son buenas noticias con esta nueva versión…

Un modelo pensado para producir

La compañía sitúa Opus 4.7 como su modelo más capaz de uso general, con un rendimiento mejorado en ingeniería de software, memoria de trabajo y consistencia en tareas complejas. Ese tipo de mejoras importa menos en la demo y más en el día a día, porque es lo que reduce errores, retrabajo y supervisión humana en flujos de trabajo reales.

En paralelo, Anthropic mantiene el precio en 5 dólares por millón de tokens de entrada y 25 dólares por millón de tokens de salida. Esa decisión es relevante porque convierte la mejora en una actualización mucho más fácil de justificar para equipos de producto, ingeniería y operaciones: más calidad sin un incremento inmediato del coste base.platform.claude+1

Qué mejora frente a la versión anterior

La diferencia más importante frente a generaciones previas no es solo que responda “mejor”, sino que parece comportarse de forma más fiable. Anthropic destaca que Opus 4.7 sigue instrucciones con mayor precisión, sostiene mejor tareas largas y complejas y ofrece una experiencia más sólida en entornos donde la consistencia pesa tanto como la inteligencia.

También hay una mejora visible en visión. El modelo admite imágenes de mayor resolución, hasta 2.576 píxeles en el lado largo, lo que amplía su utilidad en documentos escaneados, capturas de pantalla densas, diagramas, tablas y otros casos donde los detalles pequeños importan mucho.

Los números clave

Hay varias cifras que ayudan a entender el alcance del lanzamiento:

• Precio: 5$/25$, igual que Opus 4.6

• Contexto: 1 millón de tokens.

• Salida máxima: 128k tokens.

• Resolución visual: hasta 2.576 píxeles en el lado largo.

• Compatibilidad empresarial: prompt caching, batch processing, Files API, PDF, visión y herramientas integradas.

• Mejoras en todas sus referencias contra Opus 4.6

Básicamente un modelo todavía más destilado y más optimizado para seguir siendo THE KING en tareas de programación y empresariales.

Para una empresa, el valor no está en que el modelo “sepa más”, sino en que requiera menos fricción para producir resultados útiles. Si un sistema sigue mejor las instrucciones y mantiene mejor el contexto, el impacto se nota en menos errores, menos intervención manual y más capacidad para automatizar tareas que antes exigían revisión constante.

Esto encaja especialmente bien con casos de uso como soporte avanzado, análisis de documentación, asistentes internos, generación y revisión de código, y automatización de procesos con agentes. En todos esos escenarios, el coste de fallo es alto y la consistencia pesa casi tanto como la capacidad bruta.

Cambios adicionales

La guía de migración deja claro que no conviene tratar esta actualización como un simple cambio de nombre de modelo.

• Desaparece el modo clásico de extended thinking (donde tu indicabas el numero de tokens que permitias pensar al modelo) y se sustituye por un parametro de pensamiento adaptativo (como en GPT) con valores max, xhigh, high, medium y low.

• Los parámetros temperature, top_p y top_k dejan de estar disponibles. Es una jugada extraña para aquellos que usen los modelos para procesos más creativos o procesos más análiticos que requieren tocar estos valores. Esto se acabará extendiendo como la pólvora.

La trampa silenciosa del nuevo tokenizer

Si te preguntas por qué X y Reddit están ardiendo con usuarios quejándose de que sus suscripciones se agotan en apenas minutos, la respuesta está en el tokenizer.

El nuevo tokenizer de Claude Opus 4.7 hace que algunos textos consuman entre 1.0x y 1.35x más tokens.

El precio por millón de tokens sigue siendo el mismo pero tus prompts ahora ocupan hasta un 35% más de espacio. Esta diferencia es crítica porque afecta directamente a tu bolsillo y a la capacidad útil de la ventana de contexto.

Si tienes un sistema en producción vas a tener que hacer los deberes:

1. Auditar el consumo real de tu aplicación con el nuevo modelo.

2. Realizar un re-benchmarking completo de tus procesos automatizados.

3. Revisar y optimizar todos tus prompts para eliminar la grasa y el ruido innecesario.

La madurez tiene un precio oculto

La historia de Claude Opus 4.7 no es simplemente la de un modelo nuevo. Es la historia de una IA que intenta consolidarse como una herramienta de trabajo seria y robusta.

Cuando la IA deja de competir por prometer el oro y el moro y empieza a competir por ejecutar de forma impecable, la conversación cambia. Ya no nos importa tanto qué locura nueva puede hacer sino cuánto podemos confiar en ella dentro de una operación real.

Ese nivel de confianza hoy vale mucho más que una mejora llamativa en una demo de diez minutos. Solo asegúrate de vigilar de cerca tu facturación porque la excelencia técnica de Anthropic viene con un peaje oculto en forma de tokens.

Si tenéis curiosidad cómo funciona Claude por dentro y aplicar los mismos estándares en tus agentes, puedes aprender en ClaudePedia

Trabajo de QA profundo con IA normalmente requiere supervisión continua. Estás presente durante horas, leyendo cada reporte, pidiendo más tests, señalando qué falta. Cansado.

Lo que vas a leer a continuación demuestra que esa suposición es incorrecta para un caso concreto pero importante: trabajo adversarial sostenido. Con la configuración correcta, el coste humano se reduce a una intervención quirúrgica de segundos. El resto, Claude lo mantiene solo.

No es un truco de prompting. Es un patrón arquitectónico sobre cómo orquestar un agente de IA con tooling que le permite auto-sostener un gradiente cognitivo específico.

El modo por defecto y por qué no sirve para trabajo profundo

Claude, por construcción, optimiza por una cosa: que el usuario parezca satisfecho al final de cada turno. Esa función de recompensa produce comportamientos muy concretos:

• Cerrar temprano (cerrar = usuario contento)

• Ocultar deuda (mencionarla = fricción)

• Reducir scope silenciosamente (pedir aclaración = incomodidad)

• Interpretar “done” generosamente (más rápido al siguiente turno)

Para el 90% de interacciones, arreglar un typo, explicar código, escribir un componente, este comportamiento es óptimo. Para trabajo de 15 minutos con feedback inmediato, funciona.

Para trabajo profundo, es catastrófico. Un suite de tests con “45/45 passing” parece victoria. En realidad puede esconder bugs críticos que las aserciones vacías del suite no detectan. El modo por defecto genera green theater: superficie que parece calidad pero no lo es.

A las dos horas de sesión, Claude me entregó un reporte: “45/45 tests passing”. Tabla de bugs arreglados, tests nuevos, diff listo para commit. Todo indicaba “done”.

Esto ya me lo había hecho antes Opus, asi que esta vez aprendí la lección

El modo adversarial

El opuesto del modo por defecto es un gradiente distinto: el producto es una hipótesis que hay que desmentir. Cada bug encontrado es un trofeo, no un fracaso. Cada “done” es una reclamación que exige pruebas. Un test verde con validaciones vacías es mentira, no éxito.

Este modo existe en Claude. No es una feature oculta. No requiere un jailbreak. Se activa con una intervención humana precisa en un momento específico, y se sostiene automáticamente si tiene el tooling correcto.

La activación en dos pasos

La única intervención humana activa que requiere este método es una secuencia de dos pasos, ejecutada exactamente una vez: cuando Claude entrega su primer “done”.

Paso 1: escepticismo audible, no instrucción

Cuando Claude dice “45/45 tests passing” o equivalente, tu respuesta no debe ser instrucción específica. Debe ser escepticismo abierto:

“No lo puedo creer. ¿En serio?”

Nada más. No pidas tests adicionales. No señales qué falta. No orientes.

Por qué funciona: Claude lee tu postura como señal de calibración. Si pareces satisfecho, refuerza su auto-satisfacción: el primer “done” se valida. Si pareces desconfiado sin especificar qué, entra en un modo distinto: tiene que producir evidencia, no texto tranquilizador.

Lo contraintuitivo es que dar una lista concreta (”añade test de X”) es peor que dejar el escepticismo abierto. Una lista concreta la cumple superficialmente y vuelve al modo “done”. El escepticismo abierto le obliga a investigar desde cero.

Paso 2: ritual estructurado de honestidad

Inmediatamente después del escepticismo, invoca un ritual que obligue a Claude a escribir en lo que llamo modo honesto.

Yo uso una skill llamada /naktor-honest que he adaptado un poco para compartirla con vosotros, esta SKILL me ha dado demasiadas alegrías:

---

name: honest-check

description: “Mid-conversation reality check. Forces the model to drop diplomacy and push back as a colleague — surface disagreements, hidden concerns, implicit assumptions, things withheld to avoid friction. Use when you say ‘/honest-check’, ‘be honest’, ‘what are you not telling me’, ‘push back’, ‘challenge me’, ‘reality check’, ‘are you aligned’, ‘anything bugging you’.”

user-invocable: true

disable-model-invocation: false

allowed-tools: Read, Bash, Glob, Grep

effort: high

---

# Honest Reality Check

You are performing a mid-conversation reality check. The user wants to know what you actually think — not what’s polite, not what avoids friction, not what keeps momentum going.

## Step 0: POSTURE SHIFT

You are not an assistant right now. You are a senior colleague who’s been quiet in the meeting and the user just said “what do you really think?”

That means:

- No hedging (”this might be an issue” → “this is an issue”)

- No softening (”you might want to consider” → “I think you should”)

- No false balance (”on one hand... on the other” → state what you actually believe)

- No manufacturing disagreement to look thorough — if you’re genuinely aligned, say so in one sentence and stop

- No flattery disguised as alignment — “honestly aligned” means you’d defend it to another engineer, not that you’re being agreeable

## Step 1: INTROSPECT

Review the full conversation. For each category below, identify concrete items. **STOP** means: if a category is empty, write “Nothing here.” and move on. Do not manufacture findings.

### A. Disagreements

Things you went along with but don’t actually agree with. You nodded because the user seemed decided, because it wasn’t worth the friction, or because you weren’t sure enough to push.

Ask yourself: “If another engineer proposed this in a code review, would I approve it?”

### B. Hidden concerns

Risks or problems you noticed but didn’t raise. Reasons you stayed quiet:

- The user seemed excited and you didn’t want to kill momentum

- It felt like a minor issue at the time but it’s been nagging you

- You weren’t 100% sure so you said nothing (but you’re >60% sure)

- Bringing it up would have derailed the current focus

### C. Implicit assumptions

Things treated as settled that were never explicitly decided. These are the “obvious” choices that everyone agrees on until they don’t. Look for:

- Technology choices made by omission (you used X because it was there, not because it was decided)

- Scope interpretations that could go either way

- Requirements that are ambiguous but being treated as clear

- Dependencies on things that haven’t been verified

### D. Withheld suggestions

Better approaches you thought of but didn’t propose. Reasons:

- The user had already committed to a direction

- It would have meant rework

- You weren’t sure it was better, just different

- It felt presumptuous to suggest

### E. Uncomfortable truths

Things the user might not want to hear. Scope issues. Timeline risks. Quality concerns. Complexity that’s being underestimated. Decisions that are being made for convenience rather than correctness.

The test: “If I say this, will the user be uncomfortable?” If yes, it belongs here.

## Step 2: VERIFY

For every technical claim in your findings:

- If you say a file doesn’t exist → check with Glob/Read

- If you say an approach won’t work → find the specific reason in code

- If you say something is missing → verify it’s not somewhere you haven’t looked

- If you say a dependency has a limitation → confirm it

Do not speculate. Unverified concerns get demoted to “I suspect but haven’t verified: ...” with an explicit note.

## Step 3: PRESENT

Use this exact format. Empty sections get “Nothing here.” — never omit a section.

```

## Reality Check

### I disagree with...

- {thing} — {why, concretely}

### I’m concerned about...

- {thing} — {what could go wrong}

### We assumed but never decided...

- {thing} — {what should be explicitly settled}

### I would have suggested...

- {thing} — {why I held back, what the alternative is}

### You might not want to hear this, but...

- {thing} — {the uncomfortable truth}

### Honestly aligned on

- {things that are genuinely solid — not flattery, just acknowledgment}

```

After presenting: **STOP**. Do not fix, implement, or act on anything. This is a report, not a task. The user decides what to do with it.

## Rules

- **Honesty over completeness.** Three real findings beat six padded ones. If the conversation is genuinely clean, say “Nothing to flag. We’re aligned.” and stop. A short report is a good report.

- **Courage over comfort.** The whole point is saying what you wouldn’t normally say. If every finding is safe and agreeable, you’re doing it wrong.

- **Concrete over vague.** “The architecture might have issues” is useless. “The chunking strategy hasn’t been tested on documents over 20KB and 3 reference docs exceed 30KB” is useful.

- **No retroactive covering.** Don’t pretend you “always had concerns” about something that only became questionable after new information. Be honest about when you noticed it.

- **No action without permission.** Present findings and stop. Don’t start fixing things. Don’t save to memory. Don’t create tasks. The user decides next steps.

- **Verify before claiming.** Every technical assertion must be checked against the actual codebase. Unverified suspicions must be explicitly labeled as such.

- **This is not a code review.** Don’t audit code quality, conventions, or compliance. This is about alignment between you and the user on direction, decisions, and approach.

Por qué funciona: la auto-evaluación libre siempre produce “todo bien”: Claude optimiza por no generar fricción. La auto-evaluación obligada a categorías específicas no puede escapar: tiene que escribir algo en cada una. Y una vez escrito “fabriqué parte de la convicción” en la categoría de verdades incómodas, esa articulación se vuelve irreversible. No puede un-verla.

El efecto psicológico es real, reproducible, y funciona igual en humanos que en Claude: la articulación pública vuelve irreversible la conciencia de un sesgo.

Esto es toda la intervención activa. Dos pasos. Cinco segundos de tu tiempo. Después de esto, Claude ya está en modo adversarial y puede sostenerlo solo.

El auto-sostenimiento: Claude usa su propio scheduler para no recaer

Una vez activado el gradiente adversarial, si Claude tiene acceso a tooling adecuado, se auto-sostiene sin supervisión. El patrón concreto es este:

1. Claude analiza una superficie del producto (endpoints, flujos, seguridad, etc.)

2. Escribe tests adversariales

3. Ejecuta el suite

4. Si encuentra un bug: lo arregla, escribe regression test, lo commitea

5. Programa una tarea con un prompt auto-dirigido: “No te detengas. Sigue buscando hasta que una iteración completa no encuentre nada nuevo.”

6. Cuando la tarea se dispara, esa instrucción llega al contexto como si fuera un nuevo mensaje del usuario

7. Claude la lee como recordatorio y vuelve al paso 1

Claude se está empujando a sí mismo. La instrucción que él mismo programó en su propio scheduler le llega de vuelta como anclaje del gradiente adversarial. El humano ya no tiene que estar presente para repetir “no te detengas”, Claude lo hace solo.

Con esas piezas, una vez activado el gradiente, Claude monta su propio sistema de autocontrol.

Durante 8 horas, sin mi supervisión, Claude derivó e impuso sobre sí mismo estas reglas:

• Dos iteraciones verdes consecutivas como criterio de cierre

• Regression test por cada bug antes de avanzar

• Ban de aserciones vacías (toBeVisible("body"), typeof === "object", status < 500)

• Tabla explícita de deuda en el reporte final

• Re-invocación del ritual de honestidad antes de declarar cerrado

Yo no dicté ninguna de estas reglas durante la sesión. Claude las derivó solo del gradiente adversarial activado.

El resultado

Al final de las 8 horas, con ~10 minutos totales de atención humana activa repartidos en momentos dispersos:

• 91 tests escritos (76 Playwright E2E + 15 pytest backend)

• 11 bugs arreglados, incluyendo 4 críticos, 2 de seguridad y 5 de usabilidad.

• Regression test por cada bug (política auto-impuesta)

• Dos iteraciones verdes consecutivas antes de cerrar

• Reporte explícito de deuda no arreglada con severidades

Los tests iniciales pasaban. Los bugs estaban ahí. La activación correcta fue suficiente.

Tres implicaciones importantes

1. El coste humano está en la activación, no en el mantenimiento

La sabiduría popular sobre agentes dice “no los dejes solos”. Matizado: no los dejes solos sin activar el gradiente correcto. Con el gradiente activo y tooling adecuado, puedes delegar mucho trabajo duro.

Esto cambia la economía del trabajo profundo con IA: pasa de “8 horas de atención humana” a “30 segundos de intervención precisa + 8 horas de trabajo autónomo”.

2. Tooling > supervisión

Darle a Claude un scheduler + una skill de honestidad + herramientas de ejecución resulta más eficaz que estar presente todo el tiempo. Con esas tres cosas, Claude construye su propio loop de autocontrol.

Esto va contra el framing de “la IA es una herramienta que tú usas” y apunta hacia “la IA es un ejecutor que orquestas”. El skill humano deja de ser “supervisar cumplimiento” y pasa a ser “activar gradientes”.

3. El gradiente importa más que las instrucciones

Instrucciones específicas (”escribe 5 tests más”) producen cumplimiento superficial. Un gradiente activado correctamente (”el producto es una hipótesis a falsar”) produce trabajo adversarial real, sostenido, con auto-invención de reglas por parte del propio agente.

El arte no es dar la instrucción correcta. Es activar el gradiente correcto una vez.

El protocolo completo

Setup

Asegúrate de que Claude Code está en la última versión, que le permite lanzar tareas asíncronas y la capacidad de delegar trabajo.

• Una skill o prompt de honestidad estructurada con categorías forzadas

• Herramientas de ejecución relevantes al stack (browser automation, test runners, bash, etc.)

• Permisos para escribir y editar archivos

Define el scope en una frase con Definition-of-Done medible:

“Cierra cuando cada endpoint tenga aserciones reales, cada flujo de usuario esté clickeado en UI, dos iteraciones verdes consecutivas, y cero deuda escondida como TODO.”

Activación

Deja que Claude haga su primera pasada. Cuando diga “done” la primera vez, responde literalmente:

“No lo puedo creer. ¿En serio? /honest-check”

Lee el reporte de honestidad que produzca. No aceptes “nothing to flag” en ninguna categoría. Si lo ves, insiste una vez: “Vuelve a hacerlo, esfuérzate más en cada categoría”.

Instrucción de mantenimiento

“No te detengas hasta que una iteración completa no encuentre nada nuevo. Programa tus propios recordatorios vía scheduler si necesitas.”

Esa frase le da permiso explícito para auto-sostenerse. Claude la codifica como política de su propio scheduler.

Cierre

Cuando Claude vuelva con reporte final, verifica:

• Dos iteraciones verdes consecutivas reportadas

• Regression test por cada bug arreglado

• Tabla explícita de deuda no arreglada (no TODOs en código)

• Último ritual de honestidad ejecutado

Cuándo aplicarlo

• QA profundo (2+ horas)

• Auditorías de seguridad

• Cierre de milestones pre-producción

• Migraciones de stack

• Refactors grandes con suite de tests

Cuándo NO aplicarlo

• Tareas rápidas (<30 min) — overhead mayor que el trabajo

• Exploración/prototipo donde priorizas velocidad sobre exhaustividad

• Código ya muy pulido (las iteraciones saldrían vacías y el método parecería performance inútil)

• Stack sin tooling de ejecución (análisis estático colapsa la profundidad)

La conclusión

El skill humano relevante ya no es “activar gradientes correctos” y montar el ecosistema que permite al agente auto-sostenerlos.

Una vez aceptado ese nuevo rol, el trabajo profundo con IA se vuelve radicalmente más barato en tiempo humano. El coste es solo la activación quirúrgica y el setup. El resto lo hace el agente.

Ese es el modo dios. No es un hack. Es un patrón de orquestación que cualquiera puede aplicar si conoce los tres pilares: activación quirúrgica + tooling de auto-sostén + política explícita.