Mi techo no desapareció. Se movió.

La mayor ventaja de los agentes no ha sido escribir código más rápido. Ha sido cambiar mi relación con lo desconocido.

Durante años medí mi capacidad técnica de una forma bastante simple: por lo que ya sabía hacer.

Sabía programar. Podía construir aplicaciones, entender un backend, trabajar con APIs, moverme por TypeScript, React, servidores, automatizaciones y todo el ecosistema que había ido acumulando con los años. Si aparecía un problema dentro de ese radio, podía estimar más o menos cuánto me costaría resolverlo.

Pero fuera de ese radio había una frontera bastante clara.

Kernel. Ingeniería inversa. Exploitation. Consolas. Protocolos de transporte. SIMD. Zig. Sistemas distribuidos. Drivers. Firmware. Arquitecturas multimedia complejas.

No era que creyera que esas cosas fueran mágicas. Sabía que alguien las había construido y que, por tanto, podían entenderse. El problema era otro: cuando miraba uno de esos dominios desde fuera, no veía un primer paso. Veía un bloque enorme.

No pensaba exactamente «soy incapaz». Pensaba algo más razonable y, por eso mismo, más difícil de cuestionar:

Esto es muy complicado. No sé cómo se hace. No he estudiado nada de esto. Probablemente necesite años antes de poder aportar algo real.

Ese era mi techo.

No estaba hecho de falta de inteligencia ni de falta de curiosidad. Estaba hecho de coste de entrada.

Hoy ese techo ya no está en el mismo sitio.

No porque ahora sepa hacerlo todo. No porque un modelo de lenguaje me haya convertido en experto en seguridad, kernels o protocolos. Y tampoco porque los agentes puedan resolver automáticamente cualquier problema que les lance.

Ha cambiado porque ya no necesito comprender un dominio entero antes de entrar en él.

Ahora puedo construir un proceso que convierta lo desconocido en un mapa.

Y una vez existe el mapa, ya puedo empezar.

La primera grieta

Mi primera experiencia seria usando agentes para pentesting no fue una gran operación ni una investigación académica. Fue un servicio de IPTV.

Había utilizado modelos para programar, consultar documentación o generar ideas. Eso no era nuevo. Lo diferente fue emplearlos como parte de una investigación técnica real: reconocer superficie, entender comportamientos, formular hipótesis, contrastar respuestas y mantener una línea de trabajo que no consistía simplemente en «escribe este código por mí».

La diferencia parece pequeña, pero para mí no lo fue.

Hasta entonces, un agente era principalmente una herramienta de producción. Podía ayudarme a implementar algo que yo ya había definido.

En aquella investigación empezó a convertirse en otra cosa: una herramienta para navegar incertidumbre.

No tenía que conocer desde el principio todas las piezas del sistema. Podía empezar con observaciones incompletas, pedir análisis paralelos, identificar contradicciones y convertirlas en pruebas.

El ciclo dejó de ser:

sé lo que quiero construir
→ pido código
→ reviso el resultado

Y empezó a parecerse a esto:

observo algo extraño
→ genero varias explicaciones posibles
→ diseño pruebas para distinguirlas
→ recojo evidencia
→ descarto hipótesis
→ actualizo el modelo del sistema

Ahí apareció la primera grieta en el techo.

No había descubierto que la IA pudiera «hackear por mí». Había descubierto que podía ayudarme a entrar en una investigación sin tener resuelto de antemano cómo se investigaba.

El cambio no fue un modelo. Fue un sistema.

La narrativa habitual sobre agentic coding suele centrarse en el modelo: qué versión genera mejor código, cuál razona más, cuál tiene más contexto o cuál obtiene mejores resultados en un benchmark.

Todo eso importa. Pero mi cambio real no vino de usar un modelo concreto.

Vino de construir una forma de trabajar.

Poco a poco dejé de mantener una única conversación esperando que el modelo recordara todo y acertara a la primera. Empecé a separar funciones:

• agentes de reconocimiento;
• agentes de arquitectura;
• agentes de implementación;
• agentes adversariales;
• revisores;
• tareas de convergencia;
• checkpoints;
• handoffs;
• documentos canónicos;
• roadmaps ejecutables;
• evidencia reproducible.

Después empecé a construir mi propio harness agéntico y, más tarde, Axon: una capa para coordinar, inspeccionar y convertir ese proceso en algo menos improvisado.

Ese fue el verdadero multiplicador.

Un agente aislado puede darte una respuesta brillante o inventarse una explicación muy convincente. Un sistema de trabajo puede obligarlo a mostrar evidencia, contrastar decisiones, limitar su alcance, registrar incertidumbre y entregar algo que otro agente pueda revisar.

El salto no fue pasar de «programo solo» a «la IA programa por mí».

Fue pasar de esto:

yo
→ problema

a esto:

yo
→ sistema de investigación
→ problema

Mi capacidad dejó de depender únicamente de lo que pudiera mantener dentro de mi cabeza durante una sesión.

Podía externalizar contexto, paralelizar reconocimiento, documentar decisiones, preservar estado y volver días después sin reconstruir toda la investigación desde cero.

No eliminaba la dificultad. Eliminaba una parte enorme de la fricción que antes impedía siquiera empezar.

Styx: la prueba de que no era solo velocidad

Styx fue donde esta forma de trabajar dejó de parecer una curiosidad.

Styx no es un proyecto que pueda explicarse como «un media player hecho con agentes». Tampoco es un prototipo de fin de semana que funciona en una demo y se desmorona cuando alguien pregunta por consistencia, observabilidad o transporte.

Es un sistema que cruza dominios distintos: reproducción multimedia, políticas de playback, protocolos, almacenamiento, sesiones, QUIC, WebTransport, Zig, servicios, contratos, instrumentación, seguridad, compatibilidad y experimentación.

La clase de proyecto que normalmente obliga a un equipo a distribuir conocimiento entre varias personas.

Durante mucho tiempo pensé que el gran valor de los agentes era que me permitían producir más. Styx me enseñó que el valor más profundo era otro: me permitían sostener complejidad.

Podía lanzar investigaciones sobre una parte del sistema mientras otra línea de trabajo validaba invariantes. Podía someter una decisión arquitectónica a revisión adversarial. Podía convertir hallazgos en ADRs, tickets y gates. Podía exigir que una afirmación quedara respaldada por una prueba y no simplemente por una intuición razonable.

Aun así, el proyecto seguía dependiendo de mí.

Los agentes podían explorar veinte caminos, pero alguien tenía que decidir cuáles importaban. Podían producir tres arquitecturas plausibles, pero alguien tenía que detectar que una de ellas violaba una premisa antigua. Podían resumir una prueba, pero alguien tenía que distinguir entre evidencia real y una narración demasiado optimista.

Ahí apareció una verdad incómoda y útil:

Los agentes reducen el coste de producir posibilidades. Eso aumenta el valor del criterio.

Cuanta más capacidad tienes para generar código, documentos e hipótesis, más importante se vuelve saber qué no hacer.

Styx no demostró que yo pudiera construir cualquier cosa. Demostró que podía coordinar un proceso suficientemente riguroso como para mantener vivo un proyecto mucho más grande que mi conocimiento inicial de cada una de sus partes.

Mi techo volvió a moverse.

Hyperdiff y el final de «este lenguaje no es para mí»

Con Hyperdiff ocurrió algo parecido en otro eje.

Zig, SIMD, hashing acelerado, algoritmos de diff, FFI, compatibilidad con Bun, Node y Deno, rutas optimizadas para distintos tamaños de entrada.

Hace unos años habría visto esa lista como una colección de especialidades que debía dominar antes de intentar unirlas.

Con agentes, la pregunta cambió.

Ya no era:

¿Sé suficiente Zig, SIMD y diseño de runtimes para construir esto?

Era:

¿Puedo dividir el problema en fronteras verificables y aprender lo necesario en cada una mientras avanzo?

Eso no convierte automáticamente una implementación en buena. De hecho, hace más fácil generar una implementación aparentemente sofisticada que no resiste una revisión seria.

Pero también permite aprender de una forma que se parece más a la ingeniería real: no estudiar durante meses esperando sentirte preparado, sino construir, medir, romper, comparar y corregir.

El conocimiento dejó de ser un requisito previo absoluto.

Se convirtió en algo que podía adquirirse dentro del bucle experimental.

Xiaomi: entrar en el kernel

Después llegó la Xiaomi Pad con HyperOS.

El objetivo no era escribir una review de la tablet ni montar un entorno cómodo para consumir contenido. Era investigar la posibilidad de conseguir root, entender la superficie disponible y entrar en áreas mucho más cercanas al kernel, firmware, componentes privilegiados y particularidades del fabricante.

Ese proyecto todavía representa bien la clase de barrera que antes me habría detenido.

«Nunca he encontrado una vulnerabilidad de kernel.»

«No tengo experiencia profesional en Android exploitation.»

«No he trabajado desarrollando drivers.»

Todas esas frases pueden ser ciertas y, sin embargo, ya no funcionan como conclusión.

Son datos de partida.

Puedo empezar por recopilar versiones, binarios, kernels, configuraciones y diferencias. Puedo construir un inventario de superficies. Puedo comparar CVEs, parches y backports. Puedo pedir a varios agentes que investiguen familias distintas de vulnerabilidades. Puedo instrumentar pruebas. Puedo descartar caminos. Puedo aprender por qué una hipótesis no funciona.

Puede que no encuentre nada.

Ese punto es importante.

La transformación no consiste en creer que cualquier investigación terminará en un zero-day. Consiste en dejar de pensar que no encontrarlo demostraría que nunca debí entrar.

Investigar seriamente un dominio ya es una capacidad distinta de observarlo desde fuera y considerarlo reservado para «otra clase de ingeniero».

PS5 13.40: la frontera

La PS5 representa el extremo de esta evolución.

Una plataforma cerrada. Una scene fragmentada. Conocimiento público incompleto. Investigación privada que sabemos que existe, pero que no podemos consultar. Versiones específicas. Cadenas de explotación. WebKit, userland, kernel, superficies extrañas, harnesses, crashes, hangs y señales ambiguas.

Y una posibilidad: ser el primero en hacer público un jailbreak funcional para una versión concreta.

No sé si lo conseguiré.

Esa incertidumbre no debilita la historia. Es la historia.

Hace años, la frase «intentar encontrar una cadena nueva para una PS5» habría activado inmediatamente mi antiguo techo:

Esto ya no es saber programar. Esto es otra liga.

Ahora activa otra cosa:

Vale. ¿Qué sabemos? ¿Qué podemos observar? ¿Qué primitivas tenemos? ¿Qué candidato probamos primero? ¿Qué resultado distinguiría una hipótesis buena de una mala?

Ya tengo userland y un remote debugger. Tengo un harness. Tengo agentes haciendo reconocimiento, revisando documentación, conectando piezas y preparando experimentos. Tengo una metodología para no confundir una coincidencia con una señal.

Eso no significa que esté cerca de conseguirlo.

Significa que la investigación ha dejado de ser una fantasía abstracta y se ha convertido en una secuencia de pruebas.

Ese cambio me afecta de una forma difícil de describir sin sonar exagerado.

La frase «eso no se puede hacer» me activa.

No porque crea que todas las limitaciones sean falsas, sino porque empiezo a preguntarme de qué supuestos depende esa imposibilidad.

dicen que no se puede
→ ¿qué parte exactamente?
→ ¿por ausencia de primitivas, de acceso o de conocimiento público?
→ ¿qué tendría que ser cierto para que sí pudiera?
→ ¿podemos probar alguna de esas condiciones?

El muro se convierte en variables.

Y las variables pueden investigarse.

No tengo techo, pero sí límites

Decir «siento que no tengo techo» puede sonar a grandiosidad, especialmente en un momento en el que la industria está llena de promesas sobre agentes autónomos que supuestamente construirán empresas enteras mientras dormimos.

No es eso lo que quiero decir.

Tengo límites evidentes:

• tiempo;
• energía;
• dinero;
• hardware;
• acceso;
• conocimiento;
• capacidad de concentración;
• experiencia;
• suerte;
• número de proyectos que puedo sostener;
• tendencia a dispersarme.

Los agentes tampoco eliminan esos límites. En algunos casos los amplifican. Hacen tan barato empezar una nueva línea de trabajo que el riesgo deja de ser no poder comenzar y pasa a ser no terminar nada.

Mi nuevo techo no está en el mismo lugar, pero sigue existiendo.

Antes estaba principalmente en el conocimiento previo:

no conozco este dominio
→ no puedo entrar

Ahora está en otras capacidades:

puedo entrar
→ ¿sé formular el problema?
→ ¿sé distinguir evidencia de ruido?
→ ¿sé mantener coherencia?
→ ¿sé abandonar hipótesis muertas?
→ ¿sé concentrarme durante suficiente tiempo?
→ ¿sé terminar y publicar?

El cuello de botella se ha desplazado desde la ejecución hacia el criterio, la integración y la persistencia.

Y, honestamente, prefiero ese techo.

Es un techo más duro, pero también más interesante.

La IA no me hizo experto

No soy experto en todos los dominios que he tocado.

Los agentes tampoco lo son, aunque escriban con el tono de alguien que lleva quince años trabajando en ellos.

Esa es otra razón por la que esta forma de trabajo puede ser peligrosa. Es muy fácil confundir velocidad de producción con profundidad. Un sistema puede generar cientos de páginas de arquitectura y seguir sin haber entendido la premisa principal. Puede escribir una prueba que solo verifica su propia implementación defectuosa. Puede encontrar una explicación compatible con los datos y presentarla como si fuera la única posible.

Por eso el objetivo no puede ser delegar el pensamiento.

El objetivo es aumentar la superficie sobre la que puedo pensar.

Uso agentes para:

• explorar más caminos;
• leer más material;
• mantener más contexto;
• producir más hipótesis;
• automatizar trabajo mecánico;
• preparar experimentos;
• atacar mis propias conclusiones.

Pero la responsabilidad sobre lo que considero cierto sigue siendo mía.

En seguridad esto es especialmente evidente. Un agente puede afirmar que una primitiva permite escalar privilegios. La consola, el kernel o el dispositivo tienen la última palabra.

La realidad sigue siendo el reviewer final.

Lo que realmente cambió

Antes medía mi capacidad por la respuesta a esta pregunta:

¿Sé hacer esto?

Ahora la mido con otra:

¿Puedo construir un proceso que reduzca sistemáticamente lo que no sé?

La segunda pregunta abre muchas más puertas.

No exige confianza ciega. No exige creer que voy a resolverlo. Solo exige encontrar el siguiente experimento útil.

Eso ha cambiado mi relación con la programación y con mi propia identidad técnica.

Ya no veo los dominios desconocidos como clubes privados a los que solo se entra después de una década de preparación formal.

Los veo como sistemas.

Tienen componentes, interfaces, estados, supuestos, fallos, evidencia y límites.

Puedo entrar sin entenderlos por completo.

Puedo construir un mapa parcial.

Puedo equivocarme.

Puedo corregir el mapa.

Puedo avanzar.

El nuevo significado de «no sé hacerlo»

«No sé hacerlo» antes significaba casi siempre «todavía no estoy preparado para empezar».

Ahora significa algo más literal y menos definitivo:

No sé hacerlo todavía. Vamos a averiguar cuál es la primera cosa que necesito saber.

Esa es, para mí, la transformación real del agentic coding.

No escribir más código por hora.

No sustituir equipos.

No hacer desaparecer el conocimiento especializado.

No convertir cualquier idea en un producto con un prompt.

Sino reducir la distancia entre la curiosidad y el primer experimento serio.

IPTV, Hyperdiff, Styx, mi harness, Axon, Xiaomi y PS5 no son historias separadas. Son iteraciones de la misma historia.

La historia de alguien que dejó de medir su capacidad por los territorios que ya dominaba.

Mi techo no desapareció.

Se movió desde el conocimiento previo hacia el criterio, el foco, la disciplina y la capacidad de terminar.

Y por primera vez, cuando miro un problema y alguien dice «eso no se puede hacer», no pienso que tenga razón ni que esté equivocado.

Pienso:

¿Cómo podríamos comprobarlo?