[{"content":"Tus agentes escriben código, abren PRs y quizás entran por SSH a tus máquinas. Párate a comprobar con qué permisos lo hacen de verdad, y no te fíes de ficheros de policy y similares.\nDescubrirás los problemas de control de acceso de toda la vida, los que aparecen en cuanto alguien que no eres tú empieza a entrar en tus servidores. ¿Por qué pasa? Porque tratas a los agentes como herramientas y no como usuarios.\nUna cuenta por agente El agente no debe entrar en producción como ubuntu, con la misma clave que usas tú.\nDe lo contrario podrá hacer todo lo que puedas hacer tú mismo, y el log de autenticación no distinguirá sus sesiones de las tuyas. Si el «sólo lectura» de su acceso es una frase en un fichero de policy que el modelo lee al empezar la sesión, ojo, la máquina le dará root cuando lo pida con un sudo, si tu cuenta lo tiene.\nEl arreglo es una cuenta por agente y por host, con su propia clave. Cuesta un script de aprovisionamiento y hace que «quién hizo esto» lo conteste el log y no tu memoria, y ya se sabe que más vale un lápiz corto que una memoria larga.\nEl sudoers no debe dar root El siguiente paso es un sudoers con verbos de diagnóstico y nada más: leer el journal, mirar el estado de una unidad. Ningún restart, ningún stop, ningún dato. No debe dar uid 0 así gratuitamente, sin necesitarlo.\nEn sudoers, un comando declarado sin argumentos permite todos los argumentos. journalctl y systemctl status entrarán desnudos, y los dos paginan con less por defecto. Desde less, !sh abre una shell, que bajo sudo es una shell de root.\nOtro camino puede ser openssl x509, que puedes tener clasificado como comando de inspección. Acepta -out, así que escribe un fichero: cualquiera, incluido el sudoers que acaba de conceder el permiso.\nEl «sólo lectura» resultará ser una propiedad de la invocación, no del binario. Cualquier cosa que pagine, que abra una shell o que escriba un fichero es una primitiva de escritura con nombre de verbo de lectura. Las especificaciones deben fijar el paginador, y ninguna debe quedarse sin argumentos declarados.\nSi montas una allowlist de SSH, permitirá saltar a cualquier host Otro control puede ser una allowlist de hosts a los que el agente pueda entrar por SSH. Conviertes cada host de la lista en un punto de salto hacia cualquier otro sitio.\nÉl puede encontrar formas de saltárselo. Las claves de las opciones de ssh no distinguen mayúsculas, así que una comprobación de ProxyCommand no ve proxycommand. Las comillas rompen la comparación. Y ni Hostname ni -F contienen la cadena «proxy», mientras que Hostname manda la conexión a otra máquina y -F apunta a un fichero de configuración que puede definir cualquier cosa.\nPara invertirlo: una opción pasa sólo si su clave está en la lista de las que no pueden mover la conexión, y se rechaza -F.\nOtro posible fallo: buscar -F en toda la línea, así que un ssh host 'awk -F: ...' queda bloqueado. Debe leer sólo los tokens que son de ssh, desde el ssh inicial hasta el host, saltándose el valor de las opciones que llevan uno, porque el clave de -i clave no es el host. Si va pegada no necesita caso especial: -iclave es un solo token que empieza por guion. Pasado el host es la línea de comandos de otro programa, salvo un ssh anidado, que abre su propia conexión y por eso también se le leen las opciones.\nLos tests podrían estar en verde todo el tiempo Los controles anteriores pueden tener tests. Pero si comparas subcadenas del fichero de configuración renderizado, estarán en verde mientras el sudoers da root.\nComparar texto no prueba un control. El test del sudoers haría mejor en parsear las especificaciones de verdad, y comprobar que falla al reintroducir la forma peligrosa. El del dry-run de SSH puede tener un ssh de pega en el path que revienta si alguien lo llama.\nMutar el código para ver los dos tests en rojo serían unos minutos muy bien invertidos.\nEl veredicto del halcón era texto en el transcript Tengo un segundo modelo que revisa los turnos del agente principal, lo que Alejandro Vidal llama un halcón. Cuando ve algo serio escala, y el escalado es texto inyectado en el transcript: para y consúltalo con el humano.\nO sea que el veredicto sobre el agente se le entrega al agente, que decide luego si hacerle caso (y eso que Alejandro lo explica bastante bien 😅). A mí en una sesión el halcón escaló seis veces, el agente descartó las seis como falsos positivos y siguió. Una de las seis era un git push --force, que no debe decidir el agente por mucho que después resulte que tenía razón.\nAhora un escalado me escribe un fichero de bloqueo y un hook deniega cualquier herramienta mientras exista. Sin herramientas, la única acción posible es escribir texto, así que la única salida es preguntarle al humano. El agente tampoco puede quitar el bloqueo, porque la escritura y el comando que necesitaría se los deniega ese mismo hook. Me lo dice a mí, me explica lo que sucede, y si todo está bien, borro el fichero que lo bloquea.\nLa otra mitad del cambio: sólo escala lo que el código puede corroborar. Tres intentos idénticos, contados. Un comando de la lista de irreversibles, reconocido. Todo lo demás avisa sin paralizar nada, porque si una opinión de un modelo corta la sesión, lo único que has hecho es mover la no determinación del agente a su halcón.\nLos hooks no deben colgar de Write/Edit, sino de Bash Los hooks de contenido no deben estar enganchados a las herramientas de edición de ficheros, sino a la shell.\nDe lo contrario, un heredoc a python3, un cat \u0026gt;, un sed -i o un tee podría escribir el fichero pasando por delante de ellos. No sería una regla la que se saltarían: serían todas, pasarían como Pedro por su casa sin que nadie los moleste. Los hooks no juzgarían mal ese código, simplemente no lo recibirían.\nMerece la pena contar los caminos de entrada a lo que estás protegiendo, no sólo las reglas. Un agente usa más caminos que una persona, se saben todas las triquiñuelas.\nPor dónde empezaría Si tienes agentes actuando sobre tu infraestructura, la primera comprobación podría ser el log de autenticación: mira si sabes distinguir sus sesiones de las tuyas. Todo lo demás de este post salió de ahí.\nEl resto es trabajo normal: identidad antes que permisos, listas blancas en lugar de listas negras, un test que hayas visto fallar, un control en cada camino de entrada. Lo único nuevo es que el usuario del otro lado trabaja a las tres de la mañana y lee tu fichero de policy como un consejo, no le da miedo que lo despidas ;-). Y cuanto más ocurre dentro de un bucle que corre sin ti, más tardas en enterarte.\n","permalink":"https://jupaygon.dev/es/posts/2026-09-04/agent-as-a-user/","summary":"\u003cp\u003eTus agentes escriben código, abren PRs y quizás entran por SSH a tus máquinas. Párate a comprobar con qué permisos lo hacen de verdad, y no te fíes de ficheros de policy y similares.\u003c/p\u003e\n\u003cp\u003eDescubrirás los problemas de control de acceso de toda la vida, los que aparecen en cuanto alguien que no eres tú empieza a entrar en tus servidores. ¿Por qué pasa? Porque tratas a los agentes como herramientas y no como usuarios.\u003c/p\u003e","title":"Los agentes como usuarios de la infraestructura"},{"content":"En junio de 2026, Addy Osmani y Boris Cherny le han puesto nombre a algo que no es nuevo (considerando las velocidades actuales de novedades): loop engineering. Osmani es ingeniero en Google Chrome y escribe mucho sobre desarrollo; Cherny es uno de los creadores de Claude Code. Le dieron forma en un hilo en X y un par de ensayos.\nLa frase que lo resume es de Cherny: \u0026ldquo;Ya no prompteo a Claude. Tengo bucles corriendo que promptean a Claude.\u0026rdquo; El cambio se dice en una línea y se vive en grande. Dejas de ser quien sostiene la herramienta turno a turno y empiezas a diseñar el sistema que encuentra el trabajo, lo reparte, lo revisa, anota lo que está hecho y decide lo siguiente.\nEllos hicieron esa parte difícil: ver la forma con claridad suficiente para nombrarla. Llevo meses probando esas seis piezas en mi propio setup. Así que este post es dos cosas a la vez: un mapa de las piezas que describen, cada una conectada a mi setup real, y una nota honesta sobre la factura.\nUn piso por encima del harness Ya escribí antes sobre sacar decisiones del modelo de lenguaje y cristalizarlas en hooks, scripts y tablas de routing. Eso es el harness: el perímetro determinista dentro del que corre un agente.\nLoop engineering vive un piso por encima. El harness responde a \u0026ldquo;cómo se comporta un agente de forma segura\u0026rdquo;. El bucle responde a \u0026ldquo;quién arranca al agente, cuántos corren a la vez, qué pasa cuando uno termina y cómo se elige el siguiente trabajo\u0026rdquo;. El harness son las barreras de seguridad. El bucle es lo que conduce por la carretera.\nOsmani parte el bucle en seis piezas. Veámoslas una por una.\n1. Automatizaciones: el latido Un bucle necesita algo que dispare sin ti. Tareas programadas y vigilantes que descubren trabajo y lo sacan a la superficie en vez de esperar a que tú escribas.\nEn mi caso son dos capas. Los hooks reaccionan a eventos (una PR abierta lanza un watcher que sondea hasta que CI está en verde o llega una review). Las ejecuciones programadas van a buscar trabajo con una cadencia: coger la siguiente fila sin marcar del roadmap, abrir la tarea trackeada, arrancar la rama. La clave es que el primer prompt de una sesión no siempre es mío. Muchas veces lo escribió el sistema.\nEsta es la pieza que parece magia la primera semana y un pasivo la tercera, por razones a las que llego enseguida.\n2. Worktrees: paralelo sin colisiones En cuanto hay más de un agente vivo, se pelean por los ficheros. Los worktrees de Git lo resuelven limpio: cada agente tiene su propio checkout en su propia rama, compartiendo historia, sin pisarse el árbol de trabajo.\nDebe ser regla dura en el setup: nada se toca en master, toda tarea arranca con rama y worktree, y el bootstrap que lo prepara es una receta fija que ejecuta un subagente barato. El paralelismo deja de dar miedo cuando el aislamiento es el valor por defecto y no una ocurrencia posterior.\n3. Skills: la intención que sobrevive al reset Una skill es una carpeta con un SKILL.md que captura una convención, un paso de build, una pieza de conocimiento de dominio que el agente, si no, vuelve a deducir (mal) en cada ciclo. Osmani llama a lo que evitan \u0026ldquo;intent debt\u0026rdquo;: el coste de que el modelo redescubra, una y otra vez, lo que tú ya decidiste.\nTengo un conjunto versionado de ellas. Una fija la superficie de API de un framework de administración que rompió la mitad de sus métodos entre versiones mayores, para que el agente deje de adivinar. Otra codifica un checklist de SEO técnico. Viven en el repo del agente, revisadas como código, porque eso es lo que son: intención ejecutable, no documentación que se pudre en una wiki.\n4. Conectores: el agente actúa, no sugiere Sin conectores, un bucle es un becario muy elocuente que sólo sabe hablar. Con ellos lee una PR, la comenta, transiciona un ticket, resuelve una alerta, abre una incidencia. Los servidores MCP son el cableado: GitHub, el gestor de tareas, el monitor de errores, el tablero de proyecto.\nEs la diferencia entre \u0026ldquo;esto es lo que haría\u0026rdquo; y \u0026ldquo;hecho, aquí tienes el enlace\u0026rdquo;. Y es donde una tabla de routing aporta más valor: el bucle tiene que llegar a una PR privada por el conector de GitHub, nunca por curl, o pierde identidad, logging y manejo de auth en un solo atajo.\n5. Sub-agentes: separación de responsabilidades Un agente explora, otro implementa, otro verifica. Corren con instrucciones distintas y, a menudo, con niveles de modelo distintos. El modelo barato ejecuta las recetas deterministas; el caro se reserva para el diseño y para la review antes de un push.\nLa razón más afilada para separarlos es de Osmani, y merece citarla literal: \u0026ldquo;el modelo que escribió el código es demasiado blando corrigiendo sus propios deberes.\u0026rdquo; Un agente nuevo, sin nada invertido en la respuesta anterior, es mucho mejor crítico que el que la defiende. Por eso el auditor no es el autor. El verificador lee el diff en frío.\n6. Estado externo: memoria en disco El modelo olvida todo entre ejecuciones. Así que la memoria no puede vivir en la ventana de contexto: tiene que vivir en disco. Ficheros markdown, un tablero de tareas, un tracker. El bucle lee su estado al empezar una ejecución y lo vuelve a escribir al terminar.\nEsta es la columna vertebral silenciosa. El roadmap que dice qué está hecho y qué viene, la tarea trackeada que sobrevive a un crash, la auto-memoria que recuerda un quirk que expliqué hace tres semanas. Me importa mucho qué entra en la ventana de contexto; el corolario es que me importa igual qué vive a salvo fuera de ella.\nLa factura Aquí está la parte que no cabe en un hilo de lanzamiento.\nUn bucle es un amplificador, y a los amplificadores les da igual el signo de la señal. Apúntalo a una buena práctica y compone buena práctica. Apúntalo a una suposición endeble y compone el error, en paralelo, mientras duermes. La misma maquinaria que entrega diez PRs correctas por la noche entregará diez equivocadas con la misma confianza y los mismos checks en verde.\nEl coste más sutil es lo que Osmani llama comprehension debt. Un bucle te deja correr en trabajo que entiendes a fondo, y te deja correr exactamente igual en trabajo que has dejado de entender por completo. Desde fuera los dos casos son idénticos: los tickets se cierran, el tablero se pone verde. La diferencia sólo aparece el día que algo se rompe y descubres que no sabes razonar sobre un sistema que tus bucles construyeron sin ti.\nPor eso el humano no sale del bucle. El humano se mueve a sus dos extremos. Al principio, decidiendo lo que no se mueve: la arquitectura, el perímetro, qué problema merece siquiera un bucle. Al final, la verificación: no \u0026ldquo;¿pasó CI?\u0026rdquo; sino \u0026ldquo;¿entiendo lo que cambió y estoy dispuesto a ponerle mi nombre?\u0026rdquo;. Ese segundo punto de control es el cuello de botella real de todo esto, y la única pieza que no debes automatizar, porque en el momento en que lo haces, el bucle ya no te hace más rápido. Te convierte en espectador de tu propio código.\nCierre Loop engineering es real, y es un salto genuino respecto a promptear turno a turno. Lo tengo corriendo desde hace meses y no volvería atrás.\nPero la palanca corta por los dos lados. Un bucle bien diseñado multiplica a un programador cuidadoso. También multiplica a uno descuidado, más rápido. El trabajo de diseño, la parte que de verdad es ingeniería, no es cablear las seis piezas. Es decidir qué se le permite hacer al bucle por su cuenta, y conservar el único punto de control que sigue siendo tuyo: entregar código que verificaste que funciona, y que entiendes.\n","permalink":"https://jupaygon.dev/es/posts/2026-06-17/loop-engineering/","summary":"\u003cp\u003eEn junio de 2026, Addy Osmani y Boris Cherny le han puesto nombre a algo que no es nuevo (considerando las velocidades actuales de novedades): \u003cstrong\u003eloop engineering\u003c/strong\u003e. Osmani es ingeniero en Google Chrome y escribe mucho sobre desarrollo; Cherny es uno de los creadores de Claude Code. Le dieron forma en \u003ca href=\"https://x.com/addyosmani/status/2064127981161959567\"\u003eun hilo en X\u003c/a\u003e y un par de ensayos.\u003c/p\u003e\n\u003cp\u003eLa frase que lo resume es de Cherny: \u0026ldquo;Ya no prompteo a Claude. Tengo bucles corriendo que promptean a Claude.\u0026rdquo; El cambio se dice en una línea y se vive en grande. Dejas de ser quien sostiene la herramienta turno a turno y empiezas a diseñar el sistema que encuentra el trabajo, lo reparte, lo revisa, anota lo que está hecho y decide lo siguiente.\u003c/p\u003e","title":"Loop engineering: diseñar el sistema que promptea al agente"},{"content":"Un agente IA es no-determinista por construcción.\nLe pides lo mismo dos veces y te da dos respuestas distintas. La mayoría del tiempo eso no importa: son dos formas igualmente válidas de redactar un commit, dos maneras razonables de explicar un bug. A veces incluso es deseable, porque lo creativo se mueve precisamente en ese margen.\nHasta que llegas a las decisiones que no admiten margen.\n\u0026ldquo;Nunca pushees a master.\u0026rdquo; \u0026ldquo;Antes de tocar nada, crea un branch + worktree.\u0026rdquo; \u0026ldquo;Para hablar con GitHub usa el MCP, nunca curl.\u0026rdquo; Estas decisiones ya están tomadas (por mí, por el equipo, por alguna herida operacional anterior). No quiero que el agente las reabra en cada sesión.\nY aquí es donde el diseño se vuelve interesante. Porque el instinto, cuando trabajas con un modelo de lenguaje, es escribir la regla con palabras y meterla en el system prompt. \u0026ldquo;Nunca pushees a master.\u0026rdquo; Listo. Funciona el 95% de las veces.\nEl 5% restante es un push a master.\nLa tentación del prompt Mientras la regla viva sólo como texto en una policy, sigue siendo una sugerencia. Una sugerencia muy bien argumentada, escrita en mayúsculas, repetida tres veces, con ejemplos. Pero en última instancia, una sugerencia que el modelo evalúa contra todo lo demás que tiene en context.\nUn día arrastra demasiados tokens, otro día el ticket dice \u0026ldquo;urgente\u0026rdquo; tres veces, otro día sólo hubo una ambigüedad pequeña en la instrucción inicial, y la regla se diluye. No falla en plan dramático, falla en silencio: el agente toma la decisión \u0026ldquo;rápida\u0026rdquo; porque, dentro de su lectura del contexto, parecía la más razonable.\nLas policies sirven para muchas cosas. Para protecciones absolutas no son suficientes.\nSacar la decisión del LLM Lo que sí funciona es mover la decisión fuera del runtime del modelo. Cristalizarla en código que no se ejecuta dentro del LLM, sino antes o después. Tres capas, con ejemplos concretos de mi setup:\n1. Hooks: bloqueo absoluto Un hook es un script shell que el harness ejecuta antes (o después) de cada tool call. Si devuelve exit 2, la llamada se bloquea. El modelo ni siquiera ve la herramienta como ejecutable: el harness le devuelve un error.\n# .claude/hooks/block-push-master.sh if [ \u0026#34;$BRANCH\u0026#34; = \u0026#34;master\u0026#34; ] || [ \u0026#34;$BRANCH\u0026#34; = \u0026#34;main\u0026#34; ]; then echo \u0026#34;BLOCKED: direct push to master/main not allowed.\u0026#34; exit 2 fi Da igual lo que el modelo crea que es \u0026ldquo;la mejor solución\u0026rdquo;: la herramienta no se ejecuta. La decisión \u0026ldquo;nunca master\u0026rdquo; ha salido del LLM y ahora vive en bash, que es determinista por aburrido. Ya hablé de cómo funcionan los hooks en Claude Code por dentro, así que no me repito; lo que importa aquí es dónde vive la regla.\nY este caso lleva además doble candado: el usuario de GitHub del agente no tiene permiso de push directo a master en los repos protegidos. Si el hook local fallara, el remoto rechaza. Doble capa de defensa (ambas capas en dos sitios diferentes y fuera del LLM).\n2. Scripts: receta fija No todo es prohibir. Mucho del trabajo de un agente es ejecutar una secuencia que ya está decidida.\nCuando se mergea una PR, hay que: tirar de master, borrar el worktree, borrar la branch local y remota, marcar la PR como mergeada en el tracker, cerrar la tarea, marcar resueltos los issues de Sentry referenciados. Siete pasos. Siempre los mismos.\nEso no es trabajo de LLM. Eso es trabajo de scripts/post-merge-cleanup.sh. El agente invoca el script; el script hace los siete pasos sin re-decidir nada. Si en lugar de eso le dejas al modelo \u0026ldquo;hacer la limpieza\u0026rdquo;, lo que vas a obtener es una variante distinta cada vez, alguna de ellas incompleta.\nLo mismo con el bootstrap de un worktree: siete pasos fijados en un protocolo. Existe un subagente con un único trabajo: leer el protocolo, ejecutar los siete pasos, devolver el control. No piensa en alternativas. No las necesita.\n3. Tablas de routing: qué herramienta para qué Esta es la capa menos vistosa, y la que más bugs evita.\nEn el CLAUDE.md que carga mi agente al arrancar hay una tabla de seis filas que dice cosas como:\nAcción Usar No usar Leer una PR privada mcp__github__github_pr_read curl, gh, WebFetch Crear un Jira mcp__jira__jira_create curl, CLI Eso parece documentación. En realidad es una decisión sacada del runtime del modelo. Si dejas al agente elegir herramienta caso por caso, antes o después va a meter curl en algún momento porque \u0026ldquo;es más simple\u0026rdquo;. Y curl no propaga el error de auth, no graba la operación en logs, no respeta la identidad del agente. La tabla cierra esa decisión de antemano.\nQuién decide qué Llegados aquí conviene aclarar el reparto, porque es fácil resbalar.\nEl humano decide. La arquitectura, el enfoque ante un trade-off ambiguo, qué problema se ataca primero, cuándo descartar un planteamiento y empezar de nuevo. Eso no se delega a un modelo de lenguaje. No por desconfianza, sino por diseño: el criterio es justamente lo que un agente no debe improvisar en mi nombre.\nEl humano cristaliza esas decisiones en hooks, scripts, tablas, policies y protocolos. Cada vez que una decisión se ha tomado ya, baja del prompt al código.\nEl agente ejecuta, dentro de un perímetro estrechado por todas esas capas. Interpreta el ticket (con margen acotado), escribe el código (con políticas de estilo y tests obligatorios), redacta el commit (con plantilla), abre la PR (con cuerpo estructurado). Lo que queda no es \u0026ldquo;criterio creativo\u0026rdquo; del agente; es ejecución dentro de los huecos que el humano deliberadamente ha dejado abiertos.\nEs human-in-the-loop, pero con un matiz importante: el humano no está sólo al final, revisando lo que el agente produjo. Está al principio, decidiendo qué cosas no se pueden mover. El loop empieza con el humano definiendo el perímetro determinista, sigue con el agente trabajando dentro, y se cierra con el humano revisando lo que salió.\nBonus: el determinismo es barato Hay un efecto colateral agradable de mover las decisiones fuera del LLM: el modelo barato puede hacer lo determinista.\nLos siete pasos del bootstrap de worktree no necesitan a un modelo frontier. Son siete comandos. Un subagente con un modelo más pequeño los ejecuta perfectamente, porque no hay nada que razonar; sólo hay que correr la receta. Lo mismo con el cleanup post-merge, con un smoke test cuyos pasos están escritos, con una traducción de UI.\nEl modelo caro queda libre para lo que sí lo necesita: el diseño con el humano, el debug con causa desconocida, el self-review antes de pushear.\nEsto sólo es posible si las tareas deterministas están de verdad cristalizadas. Si la \u0026ldquo;receta\u0026rdquo; en realidad es \u0026ldquo;más o menos esto, ya verás\u0026rdquo;, ningún modelo, ni grande ni pequeño, te va a dar el mismo resultado dos veces.\nConclusión Un agente IA no se vuelve fiable dándole más libertad ni mejores prompts. Se vuelve fiable achicando el espacio donde tiene que decidir.\nCada hook que añades es una pregunta que el modelo ya no se hace. Cada script al que invoca es una secuencia que no se reinventa. Cada tabla de routing es una elección de herramienta que sale del razonamiento del momento y entra en el contrato.\nLo que queda dentro del LLM es ejecución acotada. Lo que decide lo decido yo, antes. Y lo cristalizo en cuanto la decisión está tomada, para no tener que volver a tomarla.\nEso es lo que diferencia un agente que \u0026ldquo;funciona casi siempre\u0026rdquo; de uno con el que puedes dormir tranquilo.\n","permalink":"https://jupaygon.dev/es/posts/2026-05-13/determinism-in-ai-workflows/","summary":"\u003cp\u003eUn agente IA es no-determinista por construcción.\u003c/p\u003e\n\u003cp\u003eLe pides lo mismo dos veces y te da dos respuestas distintas. La mayoría del tiempo eso no importa: son dos formas igualmente válidas de redactar un commit, dos maneras razonables de explicar un bug. A veces incluso es deseable, porque lo creativo se mueve precisamente en ese margen.\u003c/p\u003e\n\u003cp\u003eHasta que llegas a las decisiones que no admiten margen.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Nunca pushees a master.\u0026rdquo; \u0026ldquo;Antes de tocar nada, crea un branch + worktree.\u0026rdquo; \u0026ldquo;Para hablar con GitHub usa el MCP, nunca \u003ccode\u003ecurl\u003c/code\u003e.\u0026rdquo; Estas decisiones ya están tomadas (por mí, por el equipo, por alguna herida operacional anterior). No quiero que el agente las reabra en cada sesión.\u003c/p\u003e","title":"Lo que ya está decidido no se pregunta: determinismo en flujos de trabajo con IA"},{"content":"Todo empieza bien.\nLe das instrucciones a tu agente IA, las sigue al pie de la letra. Le defines políticas, las cumple. Le pasas protocolos de trabajo, los ejecuta. Es rápido, preciso y no se queja.\nHasta que un día deja de hacerlo.\nNo da error. No avisa. Simplemente ignora reglas que antes seguía. Comete errores estúpidos. Repite preguntas que ya habías respondido. ¿Qué ha cambiado?\nLa respuesta es el context window, nos metemos en faena y no le prestamos suficiente atención.\nQué es el context window y por qué es importante El context window es la cantidad de texto que un modelo de IA puede \u0026ldquo;tener en mente\u0026rdquo; en un momento dado. Es su memoria de trabajo. Todo lo que le inyectas — instrucciones del sistema, políticas, ficheros de código, historial de la conversación — compite por el mismo espacio.\nEl modelo que uso últimamente tiene un context window de un millón de tokens. Suena enorme. Pero cuando trabajas en serio con un agente de IA, descubres que un millón de tokens se llena más rápido de lo que crees.\n¿Por qué? Porque no se trata solo de lo que tú escribes. En una sesión real de desarrollo, el agente:\nLee ficheros de código completos para entender el contexto. Ejecuta comandos y recibe su output. Lee documentación, tests, configuraciones. Acumula todo el historial de la conversación. Cada una de estas acciones consume tokens. Y cuando se acerca al límite, el sistema empieza a comprimir mensajes anteriores. Es decir: el agente empieza a olvidar.\nLo que inyectamos antes de que el agente diga una sola palabra En mi setup, el agente arranca cada sesión con un conjunto de ficheros inyectados en el system prompt — las instrucciones fundamentales que debe seguir siempre:\nFichero Función IDENTITY.md Quién es el agente: nombre, email, GitHub user CONTACTS.md Su agenda: el Owner, otros agentes, personas relevantes MAIN_RULES.md Las reglas duras: nunca pushear a master, siempre usar worktrees, estados de ejecución BASE_POLICY.md Política operacional: verdad verificable, seguridad, autonomía, credenciales DEVELOPER_POLICY.md Política de rol: calidad de código, tracking de tareas, permisos Además, hay protocolos que se cargan bajo demanda: flujo de desarrollo con Git, workflow de Jira, reglas de CSS, verificación visual\u0026hellip;\nTodo esto existe porque sin instrucciones explícitas, el agente toma decisiones propias — y no siempre buenas. Las políticas son lo que convierte una IA genérica en un colaborador fiable.\nEl problema es que cada línea de política consume tokens del context window. Y esos tokens compiten con el código que el agente necesita leer, las herramientas que necesita usar, y la conversación que necesita recordar.\nCuando las políticas dejaron de funcionar Hace unos días me encontré con un problema serio: el agente había dejado de seguir reglas fundamentales. Reglas que estaban escritas en su política. Reglas que antes cumplía.\nLa causa: los ficheros de política habían crecido demasiado. Lo que empezó como documentos concisos se había ido inflando con explicaciones, ejemplos, secciones de contexto histórico, y duplicaciones entre ficheros. El system prompt se había convertido en un muro de texto que, combinado con una sesión larga de trabajo, empujaba el contenido importante fuera de la zona de atención del modelo.\nEl agente no \u0026ldquo;decidía\u0026rdquo; ignorar las reglas. Simplemente no las veía — estaban enterradas bajo tanto texto que el modelo las descartaba al priorizar.\nEl síntoma más traidor: no hay error. El agente sigue respondiendo, sigue trabajando, sigue pareciendo competente. Pero sus decisiones ya no respetan las restricciones que le definiste. Y no te das cuenta hasta que empiezas a desesperarte con los errores.\nLa gran reducción La solución fue drástica pero necesaria: reescribir todas las políticas desde cero con un criterio claro — cada token debe ganarse su sitio en el context window.\nEl resultado en los ficheros que se inyectan en cada sesión:\nFichero Antes Después Reducción IDENTITY.md 18 líneas 6 líneas 67% CONTACTS.md ~27 líneas 19 líneas 30% MAIN_RULES.md — 41 líneas nuevo BASE_POLICY.md 353 líneas 50 líneas 86% DEVELOPER_POLICY.md 391 líneas 47 líneas 88% Total ~789 líneas 163 líneas 79% A esto hay que sumar los protocolos que se cargan bajo demanda durante las sesiones de trabajo (Jira, Symfony, verificación visual, etc.), que pasaron de 651 líneas a 302.\nEn total, el contexto inyectable pasó de ~1.440 líneas a ~465. Ojo, luego he tenido que hacer reajustes, porque en algunas cosas había recortado demasiado.\nEjemplo concreto: IDENTITY.md Antes:\n## Agent - Display name: Jarvis - Role: developer - Execution environment: Claude Code on macOS - Timezone: Europe/Madrid - Operational email: jarvis@example.com - GitHub user: jarvis-aidev - Code language: English ## Jira Instances - zeronet - URL: xxxxxxxxxxxxxxxxx - Key: ZN - Credentials: credentials/jira-zeronet.conf Después:\n# Identity - Display name: Jarvis - Role: developer - Email: jarvis@example.com - GitHub user: jarvis-aidev - Code language: English El execution environment, el timezone, las instancias de Jira — nada de eso necesitaba estar en el prompt permanente. El agente ya sabe que corre en macOS. El timezone no afecta sus decisiones. Y las credenciales de Jira se resuelven por otro mecanismo.\nEjemplo concreto: BASE_POLICY.md Antes — la sección de control de cambios en políticas:\n## HARD RULE — Policy file change control - No automated agent may edit policy files directly on `master`. - Exception: direct updates to `master` are allowed only when explicitly instructed by the Owner. Default rule for any policy change (unless the exception above is explicitly invoked): - Any change to a policy must be made only: 1) by the Owner manually, OR 2) via a dedicated branch + Pull Request explicitly requested by the Owner. - Agents must never push policy changes to `master` (no direct commits, no force-push) unless the Owner explicitly invokes the exception above. - If the Owner requests a policy change via PR, the agent must: - propose the diff, - create a PR, - and wait for the Owner to review/merge. - If in doubt, do not modify. Ask. Después — la misma regla en MAIN_RULES.md:\n## Hard Rules 1. ALL code changes → branch + worktree. No exceptions. 2. Never push master/main. 3. Never merge PRs. Tres líneas. La misma protección. Cero ambigüedad.\nEl estilo telegráfico: menos prosa, más instrucción La clave de la reducción no fue eliminar reglas, sino cambiar el formato. Pasamos de prosa explicativa a estilo telegráfico: frases cortas, sin artículos innecesarios, sin justificaciones largas.\nUna política no es un documento para humanos. Es una instrucción para una máquina. No necesita convencer; necesita ser clara y breve.\nEsto es contraintuitivo. Cuando escribes políticas para un agente IA, el instinto natural es ser exhaustivo — explicar el por qué, dar ejemplos, cubrir todos los edge cases. Pero cuanto más texto añades, más diluyes las instrucciones importantes entre ruido.\nHay una variante de esto que se está poniendo de moda, que es el estilo \u0026ldquo;cavernícola\u0026rdquo; - sí sí, en serio - que parece que también funciona muy bien, y con una reducción tremenda de tokens. No he tenido tiempo ni ganas de probarlo aún, pero seguro que lo hago.\nMenos texto, más cumplimiento.\nSesiones largas: el otro enemigo Las políticas optimizadas resuelven la mitad del problema. La otra mitad son las sesiones largas.\nEn una sesión de trabajo intensa, el agente puede leer decenas de ficheros, ejecutar comandos, recibir outputs largos, y acumular cientos de intercambios de mensajes. Todo eso se apila en el context window. Y cuando se acerca al límite, el sistema comprime automáticamente los mensajes más antiguos.\nEsa compresión es necesaria, pero tiene un coste: el agente pierde matices. Decisiones que tomasteis juntos al principio de la sesión, acuerdos sobre cómo abordar un problema, contexto específico del task — todo eso se difumina.\nLos síntomas:\nRepite preguntas que ya habías respondido. Vuelve a leer ficheros que ya había leído. Contradice decisiones tomadas antes en la misma sesión. Pierde el tono — se vuelve más genérico, menos preciso. La solución no es técnica — es operativa: aprende a cortar sesiones a tiempo. Una sesión fresca con contexto limpio rinde más que una sesión larga donde el agente arrastra tokens comprimidos de hace una hora. Pídele que haga un resumen con lo imprescindible para continuar el trabajo sin terminar en una próxima sesión, y que lo deje en un sitio donde pueda recuperarlo.\nLecciones aprendidas Después de semanas optimizando el context window de mi agente, estas son las lecciones que me llevo:\n1. El context window es un presupuesto, no un espacio ilimitado. Cada token que gastas en políticas es un token menos para código, herramientas y conversación. Gestiona ese presupuesto con la misma disciplina que hace muuuuchos años se gestionaba la memoria RAM al programar.\n2. Si el agente no sigue una regla, el problema puede no ser el agente. Antes de culpar al modelo, revisa cuánto texto le estás inyectando. A veces la solución no es repetir la instrucción — es quitar todo lo demás.\n3. Escribe políticas como código, no como documentación. Concisas, sin ambigüedad, sin prosa innecesaria. Si una regla necesita un párrafo de explicación, probablemente no es una buena regla.\n4. Las sesiones tienen vida útil. No intentes hacer todo en una sola sesión. Corta cuando notes degradación. Una sesión nueva con instrucciones claras es más productiva que una sesión vieja con contexto comprimido.\n5. Mide antes de optimizar. Pídele al propio agente que mida el coste en tokens de todos los ficheros inyectados y te liste los mayores consumidores. Es algo que puede hacer él mismo en segundos.\nEl context window como restricción de diseño Trabajar con un agente IA no es solo escribir buenos prompts. Es diseñar un sistema donde la información correcta llega al modelo en el momento correcto, sin saturar el espacio disponible.\nEl context window no es un detalle técnico que puedas ignorar. Es la restricción fundamental que determina si tu agente es un colaborador fiable o una máquina de generar respuestas genéricas.\nCuanto antes lo optimices, antes dejarás de preguntarte por qué tu agente \u0026ldquo;ha dejado de funcionar.\u0026rdquo; No ha dejado de funcionar. Ha perdido información relevante que no le das (sin saberlo).\n","permalink":"https://jupaygon.dev/es/posts/2026-04-14/context-window/","summary":"\u003cp\u003eTodo empieza bien.\u003c/p\u003e\n\u003cp\u003eLe das instrucciones a tu agente IA, las sigue al pie de la letra. Le defines políticas, las cumple. Le pasas protocolos de trabajo, los ejecuta. Es rápido, preciso y no se queja.\u003c/p\u003e\n\u003cp\u003eHasta que un día deja de hacerlo.\u003c/p\u003e\n\u003cp\u003eNo da error. No avisa. Simplemente ignora reglas que antes seguía. Comete errores estúpidos. Repite preguntas que ya habías respondido. ¿Qué ha cambiado?\u003c/p\u003e\n\u003cp\u003eLa respuesta es el \u003cstrong\u003econtext window\u003c/strong\u003e, nos metemos en faena y no le prestamos suficiente atención.\u003c/p\u003e","title":"Context window: cuando tu agente IA empieza a olvidar"},{"content":"Hay mucho miedo alrededor de la IA ahora mismo.\nCada semana un nuevo titular dice que los developers se han acabado. Que la IA escribe código mejor y más rápido que cualquier humano. Que los juniors ya no van a ser contratados. Que toda la profesión tiene fecha de caducidad.\nEntiendo la ansiedad. Si has pasado años aprendiendo tu oficio, ver cómo una máquina genera en segundos lo que a ti te costaba horas resulta amenazante. Pero llevo meses trabajando con un agente de IA como colaborador diario — y lo que veo es lo contrario de una sustitución. Veo amplificación.\nEl miedo es real. Pero la premisa detrás de él está equivocada.\nDe qué tiene miedo la gente realmente Seamos concretos. Cuando los developers dicen que temen la IA, normalmente se refieren a una de estas cosas:\n\u0026ldquo;Mi trabajo va a desaparecer.\u0026rdquo; Las empresas reemplazarán equipos con herramientas de IA y dejarán una persona supervisando el output. \u0026ldquo;Los juniors ya no hacen falta.\u0026rdquo; Si la IA puede escribir código básico, no hay punto de entrada para nuevos developers. \u0026ldquo;Entender el código ya no importa.\u0026rdquo; Si puedes generarlo, ¿para qué aprenderlo? Estos miedos comparten una premisa común: que programar consiste en escribir código. Que el valor de un developer está en el acto de escribir sintaxis.\nEsa premisa está equivocada — y siempre lo ha estado.\nProgramar nunca ha sido escribir código Piensa en cómo ha sido la programación a lo largo del tiempo.\nAl principio, la gente programaba en binario. Unos y ceros literales, introducidos a mano. Luego llegó el lenguaje ensamblador — todavía bajo nivel, pero al menos legible por humanos. Luego los lenguajes de alto nivel como C, que abstrajeron la máquina. Luego la programación orientada a objetos, que abstrajo la estructura. Luego los frameworks — Rails, Django, Symfony, Spring — que abstrajeron patrones e infraestructura enteros.\nEn cada paso, la gente dijo lo mismo: \u0026ldquo;Si la máquina hace esto por nosotros, ¿para qué nos necesitan?\u0026rdquo;\nY en cada paso, la respuesta fue la misma: para más. Se necesitaron más developers, no menos. Porque cada capa de abstracción hizo posible construir cosas que antes eran imposibles — lo que creó más demanda, más complejidad, y más necesidad de personas que entienden lo que están construyendo.\nUn developer usando un framework moderno es órdenes de magnitud más productivo que alguien escribiendo ensamblador. Pero el programador de ensamblador no se volvió obsoleto porque existan los frameworks. El rol evolucionó. El nivel de abstracción subió. El pensamiento se quedó.\nLa IA es la siguiente capa de abstracción.\nNo reemplaza la programación. Cambia cómo se ve programar. En lugar de escribir cada línea a mano, describes intención, revisas output, tomas decisiones de arquitectura y validas resultados. La habilidad ya no es solo \u0026ldquo;sabes escribir un for loop.\u0026rdquo; Es \u0026ldquo;sabes qué hay que construir y por qué.\u0026rdquo;\nQué hace la IA realmente (y qué no) Llevo meses trabajando con un agente de IA integrado en mi flujo de desarrollo diario. No como juguete. No para demos. Para trabajo real de producción.\nEsto es lo que hace bien:\nGenera boilerplate rápido. Operaciones CRUD, migraciones, patrones repetitivos — cosas mecánicas y bien definidas. Explora codebases eficientemente. Puede leer, buscar y cruzar referencias en miles de líneas más rápido que yo. Aplica patrones conocidos. Si la solución sigue un patrón documentado o común, lo ejecuta de forma fiable. Itera sobre feedback. Revisas, corriges, y se ajusta. El ciclo es rápido. Esto es lo que no hace:\nNo entiende tu negocio. No sabe por qué tu cliente necesita esta funcionalidad, cuáles son los trade-offs, o qué les importa realmente a los usuarios. No toma decisiones de arquitectura. Puede sugerir patrones, pero decidir cómo deben interactuar los sistemas, qué desacoplar, cuándo optimizar — eso requiere juicio y contexto que ningún modelo tiene. No negocia. Requisitos, plazos, prioridades — son conversaciones humanas. No asume responsabilidad. Cuando algo se rompe en producción, alguien tiene que diagnosticar, decidir y arreglar. Ese alguien entiende el sistema, no solo el código. La IA es una herramienta potente. Pero una herramienta sin un operador cualificado es solo ruido.\nLa comparación real está mal planteada La mayor parte del miedo viene de una comparación equivocada.\nLa gente compara \u0026ldquo;un developer hoy\u0026rdquo; contra \u0026ldquo;la IA sola.\u0026rdquo; Y en esa comparación, la IA parece amenazante — escribe código más rápido que cualquier humano.\nPero esa no es la comparación real. La real es:\nUn developer sin IA contra un developer con IA.\nY en esa comparación, el developer con IA gana siempre. No porque la IA reemplace su habilidad, sino porque la multiplica.\nSi sabes qué construir, la IA te ayuda a construirlo más rápido. Si entiendes arquitectura, la IA implementa tus diseños en minutos. Si puedes evaluar la calidad del código, la IA te da más código que evaluar — y el cuello de botella pasa de la producción al criterio.\nEl developer que abraza la IA se vuelve dramáticamente más productivo. El que la ignora se queda donde está.\nPero cuidado: la IA multiplica — y puedes multiplicarte por cero Aquí está el matiz crítico que la mayoría de narrativas \u0026ldquo;la IA nos salvará a todos\u0026rdquo; se saltan.\nLa IA es un multiplicador. Pero multiplicar por cero sigue siendo cero.\nSi se lo dejas todo a la IA — el diseño, las decisiones, la validación, la comprensión — te conviertes en cero. Ya no eres un developer. Eres un relay de prompts. Y un relay de prompts sí que es reemplazable.\nLos developers que deberían preocuparse no son los que compiten contra la IA. Son los que dejan de pensar porque la IA piensa por ellos. Los que aceptan código generado sin entenderlo. Los que pierden la capacidad de evaluar si el output es correcto, seguro, mantenible, o está alineado con la necesidad del negocio.\nLa IA amplifica lo que tú aportas. Si aportas comprensión profunda, pensamiento crítico y conocimiento de dominio — te hace extraordinario. Si no aportas nada y solo le das a \u0026ldquo;aceptar\u0026rdquo; — te hace prescindible.\nEl umbral mínimo no ha bajado. Se ha desplazado. Se necesita menos gente que sepa escribir sintaxis. Se necesita más gente que sepa pensar.\nQué habilidades ganan valor ahora Si la IA se encarga de más parte del \u0026ldquo;escribir código\u0026rdquo;, ¿qué se vuelve más valioso?\nPensamiento de sistemas. Entender cómo interactúan los componentes, dónde aparecerán los cuellos de botella, qué pasa a escala. Conocimiento de dominio. Conocer el negocio, los usuarios, la regulación, el contexto al que ningún modelo tiene acceso. Evaluación crítica. Ser capaz de mirar código generado y decir \u0026ldquo;esto va a fallar bajo carga\u0026rdquo; o \u0026ldquo;esto viola nuestra política de seguridad\u0026rdquo; — rápido y con confianza. Comunicación. Traducir entre necesidades de negocio y soluciones técnicas. Esto siempre fue importante; ahora es esencial. Arquitectura y diseño. Decidir qué construir y cómo estructurarlo. La IA puede implementar un diseño. No puede decidir el diseño correcto. Ninguna de estas es una habilidad nueva. Son las habilidades que los developers senior siempre han tenido. La diferencia es que ahora no son opcionales — ni siquiera en etapas tempranas de carrera.\nLa oportunidad es ahora Esto no es un escenario futuro. Está pasando hoy.\nLos developers que aprenden a trabajar con IA de forma efectiva tienen una ventaja inmediata. Entregan más rápido, manejan más complejidad, y se liberan de las partes tediosas del trabajo para centrarse en las interesantes.\nLa oportunidad no es \u0026ldquo;aprender IA\u0026rdquo; en abstracto. Es concreta:\nIntegra la IA en tu flujo de trabajo real. No un chatbot al lado. Un colaborador real en tu entorno de desarrollo. Desarrolla tu capacidad de evaluar y dirigir. Cuanto mejor seas revisando output, más valor extraes de la herramienta. Invierte en lo que la IA no puede hacer. Arquitectura, comprensión del negocio, comunicación, liderazgo. Eso es lo que te diferencia. Mantente curioso. Las herramientas evolucionan rápido. Lo que es limitado hoy no lo será el año que viene. Adapta continuamente. Y si no eres developer pero estás construyendo con IA Esto va para ti — el diseñador, el emprendedor, la persona de producto, la mente curiosa que descubrió que la IA puede escribir código y empezó a construir cosas que nunca pensó que podría.\nPrimero: sigue adelante. En serio. El hecho de que estés construyendo, experimentando y sacando cosas adelante es fantástico. La IA ha bajado la barrera de entrada a la creación de software de una forma que era impensable hace cinco años. Eso es genuinamente emocionante.\nAhora bien, tienes dos caminos — y ambos son válidos.\nOpción 1: Aprende los fundamentos Cuanto más entiendas lo que pasa por debajo, mejor podrás dirigir a la IA, evaluar su output, y construir cosas que realmente funcionen a escala. No necesitas convertirte en ingeniero de software a tiempo completo, pero los conceptos básicos marcan la diferencia:\nQué es SOLID y por qué hace que el código sea mantenible. Qué son los patrones de diseño — soluciones recurrentes a problemas comunes que los developers han refinado durante décadas. Qué es la programación orientada a objetos — cómo modelar conceptos del mundo real en código. Qué es la arquitectura por capas (arquitectura hexagonal) — cómo separar responsabilidades para que tu aplicación no se convierta en un caos inmantenible. Qué son los tests de código — cómo verificar que tu software realmente hace lo que crees que hace. Qué es DDD (Domain-Driven Design) — cómo modelar software alrededor del problema real del negocio, no de la tecnología. Qué es TDD (Test-Driven Development) — escribir los tests antes que el código, para que el diseño emerja de las necesidades reales. Y aquí viene lo mejor: ya tienes la herramienta de aprendizaje perfecta. La misma IA que te escribe código puede explicarte estos conceptos, generarte resúmenes, guiarte con ejemplos y responder tus preguntas a cualquier nivel de profundidad. Pídele que te explique SOLID con ejemplos de tu propio proyecto. Pídele que refactorice tu código siguiendo un patrón de diseño y que te explique por qué. Úsala como profesora, no solo como generadora de código.\nOpción 2: Crea prototipos y colabora con los desarrolladores Si aprender a programar no es tu foco — perfecto. Pero lo que puedes hacer con IA sigue siendo enormemente valioso: crear prototipos, ideas, MVPs funcionales. Y luego pasárselos a un equipo de desarrollo.\nPiénsalo. Antes, para transmitir una idea a un developer necesitabas mockups, wireframes, documentos de especificación. Ahora puedes entregarles algo que funciona. Un prototipo vivo. Ya casi no tienes que explicarles lo que quieres — ellos simplemente van a verlo.\nTu MVP se convierte en lo que antes era el mockup de producto o de diseño, pero mucho más real, más vivo. Y el equipo de desarrollo puede basarse en él para construir algo sólido — con la arquitectura, los tests y la calidad que un producto necesita para escalar.\nNo necesitas hacerlo todo tú. Necesitas saber lo suficiente para empezar — y tener a alguien que sepa lo suficiente para terminarlo bien.\nY si eres junior developer: esto es para ti también Hay un discurso que dice que los juniors ya no hacen falta. Que si la IA escribe código básico, no tiene sentido contratar a alguien que está aprendiendo.\nEse discurso está equivocado.\nLa IA no elimina la necesidad de juniors — cambia lo que un junior necesita aprender primero. Antes, lo primero era dominar la sintaxis. Ahora la sintaxis es lo que menos importa. Lo primero es entender por qué se construye algo de cierta forma, no cómo se escribe.\nSi eres junior, tienes una ventaja que ninguna generación anterior tuvo: puedes aprender con un tutor infinitamente paciente que sabe de todo. Pregunta sin miedo. Pide que te explique cada línea. Pide que te muestre alternativas y te diga cuál es mejor y por qué. No te limites a copiar lo que genera — entiéndelo.\nLos juniors que crezcan con IA como herramienta de aprendizaje van a ser los seniors más completos que la industria haya visto. Pero solo si usan la IA para aprender, no para evitar aprender.\nEl miedo es natural. El estancamiento es el riesgo real Cada generación de developers se enfrentó a un momento en que las herramientas cambiaron drásticamente. Cada vez, los que se adaptaron prosperaron. Los que se negaron a aprender las nuevas herramientas se quedaron atrás — no por las herramientas, sino por las personas que las usaron.\nLa IA no es el fin del desarrollo de software. Es el principio de una nueva capa. Como cada capa anterior, nos permitirá construir cosas que hoy ni siquiera podemos imaginar.\nEl riesgo no es la IA. El riesgo es quedarse quieto.\nLa pregunta no es si la IA va a cambiar tu trabajo. Lo hará. La pregunta es si serás tú quien la use — o si te quedarás quieto viendo cómo se escapan las oportunidades.\n","permalink":"https://jupaygon.dev/es/posts/2026-04-07/ai-fear-vs-opportunity/","summary":"\u003cp\u003eHay mucho miedo alrededor de la IA ahora mismo.\u003c/p\u003e\n\u003cp\u003eCada semana un nuevo titular dice que los developers se han acabado. Que la IA escribe código mejor y más rápido que cualquier humano. Que los juniors ya no van a ser contratados. Que toda la profesión tiene fecha de caducidad.\u003c/p\u003e\n\u003cp\u003eEntiendo la ansiedad. Si has pasado años aprendiendo tu oficio, ver cómo una máquina genera en segundos lo que a ti te costaba horas resulta amenazante. Pero llevo meses trabajando con un agente de IA como colaborador diario — y lo que veo es lo contrario de una sustitución. Veo amplificación.\u003c/p\u003e","title":"La IA no te va a reemplazar. Pero te multiplica — cuidado con multiplicarte por cero"},{"content":"El 31 de marzo de 2026, el código fuente de Claude Code quedó expuesto brevemente. Un developer coreano llamado Sigrid Jin hizo un port clean-room a Python y Rust antes de que Anthropic lo retirara. El repositorio claw-code no contiene el código original, pero sí snapshots, metadatos de subsistemas, y un port parcial del runtime que revela cómo funciona Claude Code por dentro.\nEntender cómo funciona tu herramienta te permite usarla mejor, así que interesaba revisarlo a fondo. Por razones obvias yo tardaría varios años en revisar todas las líneas de código, pero para eso tenemos a Jarvis, que se puso manos a la obra y me abstrajo de las primeras 50K horas de trabajo ;-)\nAlgunas de las cosas que hemos encontrado ya eran más o menos obvias, depende de cada uno hasta dónde haya leído o investigado, así que espero comprensión de los lectores más avanzados. Para el resto, creo que va bien incluirlas en este resumen.\n1. CLAUDE.md es recursivo: usa una jerarquía de instrucciones Esto es lo que más me ha cambiado el flujo de trabajo.\nClaude Code no busca un único CLAUDE.md en la raíz de tu proyecto. Busca archivos de instrucciones en toda la cadena de directorios ancestros, desde tu directorio de trabajo actual hasta la raíz del filesystem. En cada directorio busca:\nCLAUDE.md CLAUDE.local.md .claude/CLAUDE.md .claude/instructions.md Todos se cargan y se concatenan (con deduplicación automática si dos archivos tienen el mismo contenido). El budget total es de 12.000 caracteres, con un máximo de 4.000 por archivo.\nCómo aprovecharlo: pon reglas globales en ~/CLAUDE.md (estilo de código, convenciones de commits, reglas de seguridad), reglas de equipo o empresa en ~/Work/CLAUDE.md, y reglas específicas en cada repo. Se aplican todas, en cascada.\nY un detalle: CLAUDE.local.md está pensado para instrucciones que no quieres commitear. Ponlo en .gitignore y úsalo para inyectar contexto personal: paths locales, variables de entorno, preferencias individuales.\nEso sí: no todo tiene que vivir en el CLAUDE.md. En mi caso, el CLAUDE.md apenas tiene unas líneas \u0026mdash; apunta a un repositorio dedicado con policies, protocols y skills organizados en carpetas. Si tu CLAUDE.md empieza a crecer demasiado, plantéatelo. Pero eso da para otro post.\n2. Los hooks son guardias de seguridad reales, no sugerencias El system prompt de Claude Code le dice cosas como \u0026ldquo;no ejecutes comandos destructivos\u0026rdquo;. Pero eso es una instrucción al modelo \u0026mdash; una sugerencia que puede ignorar.\nLos hooks son otra cosa. Son comandos shell reales que se ejecutan antes y después de cada uso de herramienta. Si un hook devuelve exit code 2, la herramienta se bloquea. No hay forma de saltárselo.\nEl sistema pasa al hook toda la información necesaria como variables de entorno:\nHOOK_EVENT \u0026mdash; PreToolUse o PostToolUse HOOK_TOOL_NAME \u0026mdash; nombre de la herramienta (ej: Bash) HOOK_TOOL_INPUT \u0026mdash; el input JSON completo HOOK_TOOL_OUTPUT \u0026mdash; el output (solo en PostToolUse) Ejemplo práctico: un hook que bloquea comandos peligrosos:\n#!/bin/bash # PreToolUse hook: bloquear comandos destructivos if echo \u0026#34;$HOOK_TOOL_INPUT\u0026#34; | jq -r \u0026#39;.command // empty\u0026#39; | grep -qE \u0026#39;rm -rf /|DROP TABLE|format \u0026#39;; then echo \u0026#34;Comando peligroso bloqueado por hook\u0026#34; exit 2 fi Esto es infinitamente más fiable que confiar en que el modelo \u0026ldquo;obedezca\u0026rdquo; las instrucciones del prompt.\n3. La auto-compactación tiene un umbral configurable Cuando una sesión se hace larga, Claude Code compacta automáticamente los mensajes antiguos en un resumen estructurado. El resumen preserva: herramientas usadas, archivos clave, trabajo pendiente, y un timeline de la conversación. Los últimos mensajes recientes se mantienen intactos.\nLo que no es obvio es que el umbral se puede ajustar. Por defecto se activa al ~95% de la capacidad del contexto, pero puedes forzar una compactación más agresiva o más conservadora.\nTip: para sesiones largas donde el agente \u0026ldquo;pierde el hilo\u0026rdquo;, compacta manualmente con /compact. El resumen que genera es sorprendentemente bueno \u0026mdash; captura el trabajo pendiente, los archivos tocados, y lo que estabas haciendo. Es como un checkpoint de tu sesión.\n4. El system prompt se construye dinámicamente El system prompt no es un texto fijo. Se ensambla pieza a pieza por un builder con secciones modulares:\nIntro \u0026mdash; define el rol del agente Output Style \u0026mdash; instrucciones de formato (opcional, solo si lo configuras) System \u0026mdash; reglas base (permisos, hooks, compresión) Doing Tasks \u0026mdash; guía de comportamiento (\u0026ldquo;no agregues abstracciones especulativas\u0026rdquo;) Actions \u0026mdash; principio de precaución para operaciones destructivas __SYSTEM_PROMPT_DYNAMIC_BOUNDARY__ \u0026mdash; marca que separa la parte estática de la contextual Environment \u0026mdash; modelo, directorio, fecha, SO Project Context \u0026mdash; git status + git diff al inicio de sesión CLAUDE.md \u0026mdash; tus instrucciones, recursivamente Runtime Config \u0026mdash; settings cargados Ese DYNAMIC_BOUNDARY es clave: todo lo que está antes es cacheable por la API de Anthropic. Todo lo que está después cambia en cada sesión.\nImplicación práctica: mantener tu CLAUDE.md estable (sin cambios frecuentes) maximiza el cache hit de prompts, lo que reduce latencia y coste. Si cambias tu CLAUDE.md constantemente, invalidas la cache.\n5. Cada herramienta tiene un nivel de permiso requerido El sistema de permisos no es un simple on/off. Cada herramienta tiene un required_permission asignado:\nHerramienta Permiso requerido read_file, glob_search, grep_search ReadOnly write_file, edit_file, TodoWrite WorkspaceWrite bash, Agent, REPL DangerFullAccess Si tu modo de permisos es menor que el requerido, Claude Code te pregunta antes de ejecutar. Si es igual o mayor, ejecuta directamente.\nTip: para tareas de solo lectura (auditorías, exploración de código, documentación), usa el modo ReadOnly. El agente no podrá modificar nada aunque quiera. Para automatización CI/CD sin intervención, usa Allow.\n6. Los subagentes admiten override de modelo Cuando Claude Code lanza un subagente (con la herramienta Agent), acepta un parámetro model que permite usar un modelo diferente al principal.\nEsto ya está integrado en el flujo normal: cuando pides algo que requiere búsqueda, Claude Code puede lanzar un agente Haiku (más rápido y barato) para la búsqueda, y reservar el modelo principal para el razonamiento complejo.\nCómo aprovecharlo: si estás en una sesión con Opus y necesitas buscar algo simple, el sistema ya optimiza esto automáticamente. Pero si defines tus propios agentes (agentes custom en .claude/agents/), puedes especificar qué modelo usar para cada uno.\n7. Claude Code captura git status y diff al arrancar Al inicio de cada sesión, el runtime captura un snapshot de git status --short --branch y git diff (tanto staged como unstaged). Esto se inyecta en el system prompt como contexto.\nImplicación: Claude Code sabe desde el primer mensaje qué archivos has cambiado, qué tienes staged, y en qué branch estás. No necesitas explicarle \u0026ldquo;estoy en la branch feature/X y he modificado estos archivos\u0026rdquo; \u0026mdash; ya lo sabe.\nTip: si quieres que Claude Code parta de un estado limpio, haz commit o stash antes de iniciar la sesión. Si quieres que sepa exactamente qué has tocado, deja los cambios sin commitear.\n8. Las herramientas \u0026ldquo;deferred\u0026rdquo; se cargan bajo demanda No todas las herramientas están disponibles desde el inicio. Algunas son \u0026ldquo;deferred\u0026rdquo; \u0026mdash; aparecen listadas en los \u0026lt;system-reminder\u0026gt; pero no tienen schema hasta que se cargan con ToolSearch.\nEsto es una optimización: cargar todas las herramientas desde el principio consumiría mucho contexto. En su lugar, el modelo ve los nombres disponibles y carga la definición completa solo cuando la necesita.\nTip: si necesitas una herramienta específica y Claude Code no parece encontrarla, menciónala por nombre. El sistema usará ToolSearch para cargar su schema y hacerla disponible.\n9. Hay un sistema de skills empaquetados más allá de los visibles El source revela 20 módulos de skills, varios no evidentes desde la interfaz:\n/loop \u0026mdash; ejecuta un comando o prompt de forma cíclica con intervalo configurable. Perfecto para polling (ej: vigilar una PR abierta cada 5 minutos por si recibe comentarios o cambia de estado). /simplify \u0026mdash; revisa código cambiado buscando oportunidades de reutilización, calidad y eficiencia. Auto-corrige lo que encuentra. /schedule \u0026mdash; programa agentes remotos con cron. La base para tareas automatizadas recurrentes. skillify \u0026mdash; meta-skill que convierte un patrón de uso frecuente en un nuevo skill reutilizable. Estos skills no siempre aparecen en la ayuda básica, pero están ahí. Prueba /loop 5m /status para monitorizar algo, o /simplify después de un refactor grande.\n10. El sandbox es mucho más que limitar rutas En Linux, Claude Code usa bubblewrap (que internamente crea namespaces de usuario, mount, IPC, PID y UTS con unshare). En macOS usa Seatbelt. Puede aislar la red completamente.\nAdemás, detecta automáticamente si está corriendo dentro de Docker, Podman o Kubernetes \u0026mdash; revisando /.dockerenv, /run/.containerenv, /proc/1/cgroup y variables de entorno como KUBERNETES_SERVICE_HOST.\nPor qué importa: si trabajas con datos sensibles o en entornos regulados, el sandbox de Claude Code no es un juguete. Es aislamiento real a nivel de kernel. Y si estás dentro de un container, lo detecta y ajusta su comportamiento en consecuencia.\nBonus: la magnitud real de Claude Code Los números del source original dan perspectiva:\n1.902 archivos TypeScript 207 comandos slash 184 módulos de herramientas 33 subsistemas independientes 130 módulos solo en el directorio de servicios Esto no es una CLI que llama a una API. Es un runtime de agente completo, con sistema de plugins, coordinación multi-agente, modo vim, modo voz, un companion animado (sí, hay un buddy con sprites), y subsistemas que aún no se han activado públicamente.\nConclusiones Entender cómo funciona tu herramienta te da ventaja. Las tres cosas que más impacto práctico tienen:\nCLAUDE.md jerárquico \u0026mdash; usa la cascada de archivos para tener reglas globales, de equipo y de proyecto. Es la forma más efectiva de controlar el comportamiento del agente. Hooks como guardias reales \u0026mdash; si necesitas seguridad real (no sugerencias), los hooks con exit code 2 son la única barrera que el modelo no puede saltar. Estabilidad del CLAUDE.md \u0026mdash; mantenerlo estable maximiza la cache de prompts. No lo cambies constantemente. El source de Claude Code confirma algo que por otra parte ya era obvio: si quieres marcar la diferencia, donde tienes margen de maniobra y mucho que mejorar en tu productividad y en resultados, es en la orquestación. Cómo configuras el entorno, cómo estructuras las instrucciones, cómo conectas las herramientas. Ahí es donde está la ventaja real.\n","permalink":"https://jupaygon.dev/es/posts/2026-04-01/claude-code-internals/","summary":"\u003cp\u003eEl 31 de marzo de 2026, el código fuente de Claude Code quedó expuesto brevemente. Un developer coreano llamado \u003ca href=\"https://github.com/instructkr\" target=\"_blank\"\u003eSigrid Jin\u003c/a\u003e hizo un port clean-room a Python y Rust antes de que Anthropic lo retirara. El repositorio \u003ca href=\"https://github.com/instructkr/claw-code\" target=\"_blank\"\u003eclaw-code\u003c/a\u003e no contiene el código original, pero sí snapshots, metadatos de subsistemas, y un port parcial del runtime que revela cómo funciona Claude Code por dentro.\u003c/p\u003e\n\u003cp\u003eEntender cómo funciona tu herramienta te permite usarla mejor, así que interesaba revisarlo a fondo. Por razones obvias yo tardaría varios años en revisar todas las líneas de código, pero para eso tenemos a \u003ca href=\"https://github.com/jarvis-aidev\" target=\"_blank\"\u003eJarvis\u003c/a\u003e, que se puso manos a la obra y me abstrajo de las primeras 50K horas de trabajo ;-)\u003c/p\u003e","title":"Dentro de Claude Code: 10 cosas interesantes analizando su código fuente"},{"content":"Tu agente IA tiene un problema que no te cuenta: no sabe lo que no sabe. Cuando le pides que trabaje con una librería o herramienta que ha cambiado desde su fecha de entrenamiento, genera código con total confianza\u0026hellip; usando métodos que ya no existen. No está mintiendo. Simplemente no tiene la información.\nEste es el problema del knowledge cutoff, y afecta a todos los modelos. Para tecnologías estables y maduras, el impacto es menor. Pero para librerías, bundles y herramientas que evolucionan rápido, es un problema real que produce errores silenciosos: código que parece correcto pero falla en runtime.\nLa solución no es mejor prompting ni modelos más grandes. Es darle al agente información actualizada y verificada en un formato que pueda consumir. Eso es exactamente lo que hace un AI Skill.\nQué es un AI Skill Un skill es un documento Markdown estructurado que contiene conocimiento verificado sobre una tecnología concreta. No es un tutorial. No es documentación genérica. Es una referencia optimizada para agentes IA: firmas de API exactas, cambios entre versiones, patrones correctos, ejemplos mínimos y copiables.\nPiénsalo como la diferencia entre darle a un developer nuevo un libro de 500 páginas y darle la cheat sheet verificada contra la versión exacta que estás usando. El agente no necesita entender toda la historia de una librería \u0026mdash; necesita saber qué métodos existen ahora, cuáles desaparecieron, y cómo se usan.\nUn skill típico incluye:\nTabla de breaking changes entre versiones \u0026mdash; lo primero que el agente consulta Firmas de API verificadas contra el código fuente, no contra documentación que puede estar desactualizada Ejemplos de código mínimos y funcionales, no tutoriales Notas sobre trampas comunes \u0026mdash; cosas que parecen correctas pero no lo son Cómo lo consume un agente La integración es simple porque un skill es solo un fichero .md. No hay instalación, no hay dependencias, no hay build.\nEn Claude Code, lo colocas en .claude/skills/ dentro de tu proyecto, o lo referencias desde tu CLAUDE.md:\n# CLAUDE.md When working with EasyAdmin, read the skill at /path/to/skills/easyadmin5/SKILL.md before writing any code. En Cursor, va en .cursor/rules/. En otros agentes, donde sea que coloques el contexto del proyecto.\nCuando el agente va a generar código con esa tecnología, lee el skill primero. Es como consultar la documentación antes de escribir \u0026mdash; pero automatizado y con información que sabemos que es correcta.\nPor qué no basta con la documentación oficial La documentación oficial está pensada para humanos. Tiene contexto narrativo, explicaciones progresivas, ejemplos didácticos. Todo eso está bien para aprender, pero un agente IA necesita otra cosa:\nFirmas exactas, no párrafos explicativos Cambios entre versiones explícitos y en tabla, no enterrados en un UPGRADE.md Datos verificados contra el código fuente real, no contra documentación que a veces se desfasa del código Formato consumible: tablas, listas, bloques de código \u0026mdash; no prosa Además, la documentación oficial cubre todo. Un skill cubre lo que el agente necesita saber para escribir código correcto: la API pública, los cambios que rompen, los patrones que funcionan.\nCómo se crea un skill fiable Aquí es donde se pone interesante. Crear un skill no es copiar la documentación y reformatearla. Es un proceso de verificación iterativo donde intervienen humanos y múltiples agentes IA, cada uno con un rol diferente.\nEl proceso que hemos seguido:\n1. Extracción inicial \u0026mdash; Un agente investiga la documentación oficial, el código fuente del paquete, el UPGRADE.md, y produce un primer borrador con la API completa: métodos, firmas, parámetros, breaking changes.\n2. Primera revisión \u0026mdash; Otro agente, diferente al que escribió el borrador, verifica cada afirmación contra el código fuente real. No contra la documentación \u0026mdash; contra el código. ¿Este método existe? ¿Esta firma es correcta? ¿Este parámetro es object o mixed?\n3. Corrección y segunda revisión \u0026mdash; Se corrigen los errores encontrados y un tercer agente vuelve a revisar. El principio es el mismo que en code review: ojos frescos encuentran cosas que el autor no ve.\n4. Verificación humana \u0026mdash; El humano revisa el resultado, aporta criterio sobre qué incluir y qué no, valida las correcciones, y a veces descubre que un revisor estaba equivocado y otro tenía razón.\n5. Iteración \u0026mdash; Se repite hasta que la tasa de errores converge a cero.\n¿Por qué múltiples agentes y no uno solo? Por la misma razón que no haces code review de tu propio código: el sesgo de confirmación. Un agente que escribió algo tenderá a validarlo. Un agente diferente lo cuestiona.\nEjemplo real: EasyAdmin 5 Todo esto suena abstracto, así que voy con un caso concreto.\nEasyAdmin es uno de los bundles más populares de Symfony. La versión 5 se publicó como nueva versión estable, eliminando todo lo deprecado de la serie 4.x. Funcionalmente es similar, pero la API cambió en sitios críticos:\nlinkToCrud() → linkTo() displayAsLink() → renderAsLink() addPanel() → addFieldset() {{ ea.property }} en Twig → {{ ea().property }} Pretty URLs ahora obligatorias PHP 8.2+ y Symfony 6.4+ requeridos Son cambios que parecen menores, pero producen errores en runtime que no son obvios. Y lo peor: tu agente está convencido de que su código es correcto, porque lo era\u0026hellip; en la versión 4.\nEl detonante fue práctico: estaba migrando uno de mis proyectos de EA4 a EA5 con Jarvis, y el resultado era frustrante. Usaba métodos de la versión 4 con total confianza, daba por hecho que cosas de EA4 seguían funcionando en EA5, y generaba código que fallaba en runtime una y otra vez. No era un problema de capacidad del agente \u0026mdash; era un problema de información.\nJavier Eguíluz (creador de EasyAdmin) ha escrito sobre cómo usar Claude Code con Symfony, pero no existe un skill oficial de EasyAdmin 5 para agentes de IA, una referencia verificada y estructurada específica para EA5 que los agentes puedan consumir directamente.\nAsí que decidí crearla y compartirla con la comunidad Symfony, esperando que más programadores le vean la utilidad que yo le veo y la puedan aprovechar.\nLo que encontraron los revisores En la primera revisión, un agente verificó el borrador contra el código fuente de EasyAdmin 5 y encontró 8 errores factuales.\nEn la segunda revisión, otro agente encontró 5 errores más: un atributo con parámetros incorrectos (routePath en lugar de path), un formato de número engañoso, tokens de ImageField incompletos.\nEn la tercera revisión: 2 errores más. Y en la cuarta: 1 error y 1 imprecisión.\nCada ronda convergía: 8 → 5 → 2 → 1. Hasta llegar a un documento con más de 900 líneas verificadas donde cada firma, cada parámetro y cada ejemplo está contrastado contra el código fuente real del bundle.\nEl resultado Antes del skill, pedirle a un agente que creara un menú en EasyAdmin 5 producía código con linkToCrud() (EA4). Después del skill, genera linkTo() (EA5) a la primera. Lo mismo con campos, actions, filtros, eventos, templates Twig.\nEl skill cubre la API pública completa: dashboard, menús, CRUD controllers, 30 tipos de campo con documentación detallada, actions y action groups, batch actions, filtros, seguridad por niveles, eventos de ciclo de vida, pretty URLs, personalización de diseño, y generación de URLs.\nSkills como inversión Crear un skill lleva tiempo. Pero es una inversión que se amortiza cada vez que tú \u0026mdash; o cualquier otro developer \u0026mdash; le pide a un agente que trabaje con esa tecnología.\nEs open source. Verificado. Mantenido. Un fichero Markdown que cualquiera puede copiar a su proyecto y empezar a usar.\nSi trabajas con EasyAdmin y un agente IA, pruébalo. Y si trabajas con otra tecnología que cambia entre versiones, considera crear tu propio skill. El proceso que he descrito funciona, y el resultado marca la diferencia entre un agente que alucina y uno que escribe código correcto a la primera.\nEl skill de EasyAdmin 5 está disponible en jupaygon/ai-skills. Si te resulta útil, una estrella en el repo ayuda a que otros developers lo encuentren.\n","permalink":"https://jupaygon.dev/es/posts/2026-03-29/ai-skills/","summary":"\u003cp\u003eTu agente IA tiene un problema que no te cuenta: no sabe lo que no sabe. Cuando le pides que trabaje con una librería o herramienta que ha cambiado desde su fecha de entrenamiento, genera código con total confianza\u0026hellip; usando métodos que ya no existen. No está mintiendo. Simplemente no tiene la información.\u003c/p\u003e\n\u003cp\u003eEste es el problema del \u003cstrong\u003eknowledge cutoff\u003c/strong\u003e, y afecta a todos los modelos. Para tecnologías estables y maduras, el impacto es menor. Pero para librerías, bundles y herramientas que evolucionan rápido, es un problema real que produce errores silenciosos: código que parece correcto pero falla en runtime.\u003c/p\u003e","title":"AI Skills: cómo darle a tu agente IA conocimiento verificado que no tiene"},{"content":"Hay mucho ruido sobre IA y programación. Copilots, autocompletados, generadores de código\u0026hellip; La mayoría de herramientas se quedan en sugerir la siguiente línea. Pero se puede hacer algo diferente, algo más: trabajar con un agente IA que opera como otro developer en el equipo.\nMi compañero digital se llama Jarvis. Tiene su propia cuenta de GitHub, su propio acceso a Jira, y un flujo de trabajo idéntico al de cualquier desarrollador humano: branch, implementación, commit, pull request, code review. Llevo meses con este sistema en producción, y esto es lo que he aprendido.\nQué es AI-Augmented Development (y qué no es) No es pedirle a una IA que te escriba una función. No es autocompletado inteligente. No es copiar y pegar de ChatGPT.\nAI-Augmented Development es integrar un agente IA en tu flujo de trabajo real, con las mismas herramientas, las mismas restricciones y el mismo proceso que un developer humano:\nBranch aislado — cada tarea en su propio branch, nunca en master. Pull request — todo el trabajo pasa por PR. Yo reviso, comento, pido cambios. Permisos limitados — el agente no puede mergear ni pushear a master. Las branch protection rules lo impiden. Trazabilidad — cada commit está asociado a su autor. El git log muestra quién hizo qué. La diferencia con un copilot es que Jarvis entiende el contexto completo del proyecto, no solo el archivo que tienes abierto. Aporta velocidad y menores curvas de aprendizaje, siempre como un complemento que te hace mejor programador, no como un sustituto.\nY un matiz importante: Jarvis no es simplemente abrir una sesión de Claude Code o Codex y pedirle que haga cosas. Lleva meses de iteración. Políticas que definen qué puede y qué no puede hacer, procedimientos para cada tipo de tarea, herramientas conectadas (GitHub, Jira, MCP servers), reglas de seguridad, convenciones de código. Todo eso es prompt engineering estructurado, y es lo que convierte una sesión de chat en algo viable para trabajo real.\nLa ventaja: pídele a tu propio agente que te ayude a perfeccionarlo. Cuando algo no funcione, pregúntale: ¿cómo podemos solucionar esto? ¿Cómo podemos evitar que cometas este error de nuevo? Revisa tus políticas y dime dónde y cómo propones la modificación. O para un nuevo procedimiento: hazme una propuesta de procedimiento para próximas ocasiones, y cómo forzaremos a que lo sigas a rajatabla en tareas similares. El agente mejora su propia configuración. Es un ciclo de mejora continua que se retroalimenta.\nProductividad: lo que realmente cambia El aumento de productividad es real, pero no viene de donde la gente piensa.\nNo es que escriba código más rápido. Es que yo dedico más tiempo a lo que importa: diseñar la arquitectura, pensar los edge cases, revisar con criterio. Las tareas mecánicas \u0026mdash; el boilerplate, los CRUDs, las migraciones, los tests unitarios repetitivos \u0026mdash; las hace Jarvis. Y las hace bien, porque tiene el contexto del proyecto.\nTareas que antes llevaban horas se resuelven en minutos. Las que llevaban días, en horas. Y no hablo de código chapucero que luego hay que rehacer. El código pasa review, pasa tests, y sigue los estándares del proyecto.\nEjemplo concreto: el symfony-dashboard-skeleton \u0026mdash; un dashboard completo con EasyAdmin 5, multi-tenant, 4 temas, jerarquía de roles, i18n \u0026mdash; lo montamos en horas. No semanas. Horas. Con tests, documentación, y README completo.\nDocumentación: el cambio que menos esperaba Si hay algo que ha mejorado drásticamente y no esperaba, es la documentación.\nLa mayoría de developers odian documentar. Otros lo disfrutan pero no tienen tiempo. Yo estaba en el segundo grupo. Ahora, la documentación se genera como parte natural del flujo de trabajo. Jarvis documenta lo que implementa: README, comentarios en PR, descripciones de tickets Jira. Y yo reviso y ajusto el tono.\nEl resultado es que mis proyectos tienen mejor documentación que nunca. No como un extra que haces al final cuando te acuerdas, sino como parte del proceso. Cada PR lleva su descripción, cada ticket su resumen, cada repo su README actualizado.\nPor ejemplo, he incorporado los Project Books: documentos HTML vivos con gráficos, colores y enlaces que reflejan la vida completa del proyecto \u0026mdash; desde el brainstorm inicial hasta producción y más allá. Incluyen roadmap, decisiones arquitectónicas, enlaces a los tickets de Jira, estado actual de cada pieza. Es como un dashboard del proyecto, pero narrativo. Y mantenerlos actualizados ya no es un esfuerzo extra, es parte del flujo.\nStack: el abanico se abre Este es quizás el cambio más inesperado.\nPuedes llevar toda tu carrera en un lenguaje y frameworks concretos, en tu zona de confort. Pero programar es programar \u0026mdash; las buenas prácticas, SOLID, la separación de responsabilidades, la programación por capas\u0026hellip; son universales e independientes del lenguaje.\nCon este flujo de trabajo, yo aporto la experiencia en esos principios y Jarvis domina los detalles sintácticos de cada lenguaje. ¿Necesito un script en Python? ¿Un componente en Go? ¿Configuración de infraestructura? Puedo trabajar con confianza en stacks que antes me habrían exigido semanas de curva de aprendizaje.\nNo es que me haya convertido en experto en Python de la noche a la mañana. Es que puedo aplicar más de dos décadas de criterio de ingeniería en cualquier lenguaje, porque la parte sintáctica ya no es un cuello de botella.\nSeguridad: esto no es un juguete Cuando le cuento a otros developers que tengo un agente IA con su propia cuenta de GitHub, algunos levantan una ceja. Suena arriesgado. Pero es exactamente lo contrario: es el enfoque más seguro.\nCredenciales separadas — Jarvis no tiene mis tokens ni mis contraseñas. Tiene los suyos, con permisos limitados. Branch protection — No puede pushear a master ni mergear PRs. Las reglas de protección de rama se lo impiden. Permisos acotados — En Jira puede crear y mover tickets, pero no puede borrar ni modificar configuraciones. Trazabilidad total — Cada acción queda registrada bajo su identidad. Si algo sale mal, sé exactamente qué hizo y cuándo. La alternativa \u0026mdash; darle tu token personal con todos tus permisos \u0026mdash; es mucho más peligrosa. Y es lo que hace la mayoría de gente sin pensarlo.\nLo que he aprendido Después de meses con este sistema, estas son mis conclusiones:\nLa IA no reemplaza al developer, lo amplifica. El criterio de ingeniería sigue siendo humano. La IA ejecuta, el humano diseña y revisa. El flujo de trabajo importa más que el modelo. Da igual que uses Claude, GPT o Gemini. Lo que marca la diferencia es cómo integras la IA en tu proceso. La documentación se soluciona sola cuando es parte del flujo, no un extra. El stack ya no es una barrera. Los principios de ingeniería son universales. La sintaxis es un detalle. La seguridad no es opcional. Identidad separada, permisos limitados, branch protection. No hay atajos. Si eres developer y aún piensas en la IA como \u0026ldquo;el autocompletado que a veces acierta\u0026rdquo;, te animo a explorar esta otra forma de trabajar. No es perfecta, pero ha cambiado radicalmente cómo desarrollo software.\nEste blog \u0026mdash; incluyendo este post \u0026mdash; se ha construido siguiendo exactamente el flujo que describo. Puedes verlo en el repositorio.\n","permalink":"https://jupaygon.dev/es/posts/2026-03-26/ai-augmented-development/","summary":"\u003cp\u003eHay mucho ruido sobre IA y programación. Copilots, autocompletados, generadores de código\u0026hellip; La mayoría de herramientas se quedan en sugerir la siguiente línea. Pero se puede hacer algo diferente, algo más: trabajar con un agente IA que opera como \u003cstrong\u003eotro developer en el equipo\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eMi compañero digital se llama Jarvis. Tiene su propia cuenta de GitHub, su propio acceso a Jira, y un flujo de trabajo idéntico al de cualquier desarrollador humano: branch, implementación, commit, pull request, code review. Llevo meses con este sistema en producción, y esto es lo que he aprendido.\u003c/p\u003e","title":"AI-Augmented Development: mi experiencia real trabajando con un agente IA"},{"content":"Quién soy Desarrollo software desde 2003. He sido CTO y Co-Fundador durante la mayor parte de mi carrera, liderando equipos técnicos y diseñando sistemas de alta concurrencia y rendimiento exigente.\nActualmente soy Co-Fundador y CTO en Zeronet IT, donde trabajamos en mejorar la eficiencia energética de las redes IT, y donde hemos incorporado la IA como parte central de nuestro flujo de trabajo, y también del producto final.\nQué hago ZeroNet ayuda a reducir el consumo energético de las redes IT. Es un problema real: las infraestructuras de red consumen mucho más de lo necesario, y la mayoría ni siquiera lo sabe. Combinamos monitorización inteligente para mejorar la eficiencia de las redes. Incluimos data centers, dispositivos finales, detección de shadow AI agents y alerta de ciberamenazas (basados especialmente en patrones de consumo energético). Más información: zeronetit.com.\nHe incorporado la IA como parte central de mi flujo de trabajo. No como autocompletado de código, sino como AI-Augmented Development \u0026mdash; agentes IA que operan como colaboradores reales: crean branches, escriben código, abren pull requests y responden a code review.\nHe decidido compartir este nuevo enfoque y colaborar con la comunidad con este blog, y con herramientas open source que iré añadiendo a mi cuenta de GitHub, algunas relacionadas directamente con la IA, otras simplemente desarrolladas con su ayuda. No tengo grandes aspiranciones, si solo un developer se aprovecha de estas experiencias, me daré por muy satisfecho :-).\nJarvis: mi colaborador IA Jarvis es un agente IA developer con su propia identidad en GitHub. Crea branches, escribe código, abre pull requests, gestiona tickets Jira y responde a code review \u0026mdash; todo bajo supervisión humana.\n¿Por qué una identidad separada y no simplemente usar mi cuenta? Por seguridad y separación real de responsabilidades. Jarvis tiene sus propias credenciales en GitHub y Jira, con permisos limitados: puede crear branches, hacer commits y abrir pull requests, pero no puede commitear a master ni mergear PRs \u0026mdash; las reglas de protección de rama se lo impiden. No tiene acceso a mis contraseñas ni a mis tokens. Si algo sale mal, el daño está acotado. Puede parecer un juguete, pero es un criterio de ingeniería y seguridad.\nJarvis no es fine-tuning ni un modelo custom. Es prompt engineering con contexto estructurado: políticas, skills, protocolos y herramientas (MCP servers) que definen su comportamiento. El resultado es un agente que trabaja como un developer más en el equipo \u0026mdash; autónomo dentro de su branch, pero siempre esperando revisión de otros antes de mergear.\nCada trabajo mío muestra la colaboración (visible si es un repositorio público): Jarvis implementa, yo diseño y reviso. El git log cuenta la historia real.\nEl resultado El impacto en productividad es enorme. Tareas que antes llevaban horas se resuelven en minutos, las que llevaban días se resuelven en horas, manteniendo la misma calidad y rigor. No se trata de escribir código más rápido, sino de poder dedicar más tiempo a lo que realmente importa: diseñar bien, pensar la arquitectura y revisar con criterio.\nAdemás, este flujo de trabajo me ha abierto el abanico en cuanto a stack. Programar es programar \u0026mdash; las buenas prácticas, SOLID, la separación de responsabilidades, la programación por capas\u0026hellip; son universales e independientes del lenguaje de programación elegido. Yo aporto mi experiencia en esos principios, y Jarvis domina los detalles sintácticos de cada lenguaje. El resultado es que puedo trabajar con confianza en stacks que antes me habrían exigido semanas o meses de curva de aprendizaje.\nContacto GitHub: jupaygon LinkedIn: jupaygon X: jupaygon Tarjeta digital ","permalink":"https://jupaygon.dev/es/about/","summary":"Sobre Juanjo Payá","title":"Sobre mí"},{"content":"","permalink":"https://jupaygon.dev/es/card/","summary":"Juanjo Payá — Tarjeta Digital","title":"Tarjeta"}]