Transcripción del vídeo
Texto de los subtítulos disponibles; puede contener errores.
Entre el ticket que abro por la mañana y
el Short que sale por la tarde, trabajan para mí 13 agentes de IA, 55 skills
y 2 servidores que tengo en casa. Y lo tienen que hacer casi sin mí, trabajo
a jornada completa y tengo muy poco tiempo. Casi siempre sale
bien, el 7 de octubre no. Uno de sus agentes lanzó un rm -rf y se
llevó por delante una carpeta entera de un proyecto mío. Hoy te enseño cómo es
un día normal con todo esto, y ese susto también, porque me hizo
cambiar dos reglas. Bienvenido al Rincón de Isma. Llevo más de 15 años escribiendo
backend y hoy trabajo en un equipo de 6 desarrolladores en una EdTech que
programa con agentes todos los días. Te pongo en situación,
esto va de un día de verdad. Empieza con un ticket de la empresa a
primera hora y termina a las 8 de la tarde cuando se publica un short del canal. De cada pieza te cuento qué problema tenía
y qué decidí, y al final lo que pasó con ese rm -rf, que es lo que más
me ha enseñado de todo esto. En enero subí a este canal mi stack 2026 y
ahí te dije que hoy por hoy usaba Cursor, que iba a empezar a probar OpenCode y
que le pedía el backend a Sonnet 4.5 y el frontend a Gemini 3 Pro, porque en el
frontend ya lo sabes, soy un negado. Nueve meses después trabajo con
Claude Code y no soy un caso raro. La encuesta del Stack Overflow de este
mes, la de 2026, dice que entre los que usan agentes para programar,
el 66 % usa Claude Code. Pero el cambio grande de estos meses
está en cómo reparto el trabajo. En enero, la IA era un
chat dentro del editor. Hoy es un equipo y yo hago de jefe. Y otra cosa que he cambiado, ahora mido. En julio del año pasado, METR hizo
un estudio con 16 desarrolladores con experiencia en código abierto. Con IA tardaron un 19 % más y al acabar
creían que habían ido un 20 % más rápido. Ese estudio ya es viejo, y los propios
autores lo consideran histórico. Pero me quedo con lo que enseño. La sensación de ir rápido engaña. Por eso en este vídeo te doy
números y no sensaciones. Y el día arranca pronto,
con el primer café. 1. Café y el primer ticket
del día en la empresa. Lo abro en una sesión de Claude Code,
y en esa sesión, el que habla conmigo casi nunca escribe el código.
Tiene una regla escrita en mi CLAUDE.md. La sesión conversa y lo que no
es trivial lo hace el equipo. Para saber qué es trivial uso lo
que llamo la prueba de reanudación. Si el cambio se entiende en tres lecturas
o menos, no toca nada delicado y se podría terminar solo con la petición y
el git diff lo hace la sesión. Si no, se lo pasa a un
agente que se llama director. Lo delicado lo tengo apuntado
en seis puntos de riesgo. El esquema y las migraciones, la
autenticación y los permisos, el dinero o los datos de usuario, una API o un
formato que usan otros, borrar cosas y las dependencias o la infraestructura. Si un ticket roza uno solo, no hay atajo. Va al equipo. Y el director
no programa, reparte. Debajo tiene a 6, el arquitecto,
el database dev, el backend dev, frontend dev, el QA tester y devops. 7 agentes en total. Y cada uno es un
fichero markdown con una cabecera, cómo se llama, para qué sirve, qué herramientas
puede tocar y qué modelo usa. Los tengo en mi carpeta de usuario,
así que me sirven en todos mis proyectos. ¿Y por qué no uno solo que lo haga todo? Porque según la documentación de
Anthropic, cada subagente arranca con su propio contexto. No ve mi conversación
ni los ficheros que ya he abierto. Le llega su encargo,
lo hace y devuelve un resumen. Al principio parece una pega,
pues para mí es justo lo que buscaba. El que implementa no arrastra todo lo que
yo he hablado antes, solo lo que necesita. Y a cada uno le doy su modelo. Tres van con Opus, el director,
el arquitecto y el QA tester. Los otros cuatro, con Sonnet. Incluso la sesión con la
que hablo yo va con Sonnet. El criterio es muy sencillo. Opus, para los que planifican o juzgan. Sonnet, para los que ejecutan
un plan que ya está pensado. El caro, donde se piensa. El barato, donde se redacta. Tiene sentido, ¿no? En la misma encuesta
de Stack Overflow, solo un 27 % usa modelos distintos según la
tarea para controlar el coste. A mí me parece de lo más
rentable que he hecho. Cuando el QA tester da el visto bueno,
todavía falta alguien, yo. Reviso lo que devuelve como si lo hubiera
escrito alguien que acaba de llegar al equipo. Con cariño, pero sin fiarme. En el equipo de la empresa, con un flujo
así, un ticket mediano de backend pasó de un día de una persona a dos o tres horas,
y el agente ya es el autor principal de 7 de cada 10 pull requests. Esas cifras ya
te las conté en el vídeo anterior, con todo el detalle. Hay dos reglas más que el
equipo no se salta, push, merge y force, solo con mi permiso explícito, y cada
agente trabaja en su propio worktree y en su propia rama. Lo del worktree, por
cierto, no lo puse por elegancia, lo puse después del susto. Llegaremos a él. Hay un límite del CLAUDE.md que
no se ve hasta que te choca. La propia documentación de Anthropic
recomienda que no pase de 200 líneas, porque cuanto más largo es, más contexto
gasta, y menos caso le hace el modelo. Así que lo que no tiene que estar
siempre delante, lo saca una skill. Una skill es una carpeta con
sus instrucciones y sus scripts. Lo bueno es cómo carga. El modelo solo ve una línea que dice para
qué sirve y el resto entra cuando hace falta. Mientras no la usas,
casi no cuesta nada. Anthropic la presentó hace casi un año,
el 16 de octubre del 2025. Hoy tengo ya 55 instaladas. Las he contado esta semana, 55 carpetitas. Algunas son de programar, pero por la
tarde, cuando paso al canal, las que más uso hoy por hoy son otras. La investigación de este vídeo la ha
hecho un skill que se llama guion. Ha mirado qué vídeos míos retienen,
dónde se va la gente y qué ha publicado la competencia. Y me sacó
un dato que me dolió. En mi stack del 2026, a los 24 segundos
seguía viendo el vídeo el 86 % de la gente, a los 48 el 61. En 24 segundos se fue una
de cada cuatro personas. ¿Y qué estaba haciendo yo justo ahí? Enumerar herramientas, una detrás de otra. Y la primera era el lenguaje, PHP,
que ya sabes que es el que yo uso. Por eso este vídeo va de
un día y no de una lista. Los datos los baja otra skill,
estadísticas, que tira de YouTube Studio y me apunta en un fichero lo
que funciona y lo que no. Ese fichero lo leen después los agentes
del canal antes de proponer nada. Así no me sugieren el
mismo error dos veces. Hay otra skill que me hace gracia
tener en un vídeo como este. Se llama Redacción y repasa lo que
escribo buscando frases que suenan raras. Muletillas, frases de folleto, esas cosas. Para el canal tengo otros 6 agentes,
aparte de los 7 de programar. Uno investiga, otro me prepara un borrador
del guion, dos se encargan del B-roll que estás viendo, uno propone los
Shorts y otro la miniatura. Aquí los 6 van con Opus. A las 8 de la tarde sale un Short. El tramo lo propuso un agente,
la decisión de publicarlo fue mía. Todo esto funciona con
un problema de fondo. Cada sesión empieza de cero. Y la solución la tengo en casa. En junio, en el vídeo de
Hermes, te conté esto. Tenía un agente al que le había enseñado
mis flujos, mis manías, mi forma de trabajar y todo eso vivía en mi máquina. Si el portátil se suspendía, se acababa. Si se reiniciaba,
se olvidaba de medio contexto. Y así es como funciona. Según la
documentación de Claude Code, cada sesión empieza con el contexto vacío. Lo que pasa, de una sesión a otra,
es lo que tú le dejes apuntado. Yo tengo dos memorias,
y cada una con su sitio. Neurona es la de la empresa, la ve todo
el equipo, y así lo que aprendo en un repositorio de allí lo aprovecha
el siguiente que entre. Cerebro es la mía,
la de mis proyectos y el homelab. Y una regla, cada cosa se guarda
en una sola, nunca en las dos. Lo de la empresa no sale de la empresa. Cerebro me hace falta
por una razón muy simple. En el disco tengo casi
50 proyectos personales. Si cada vez que vuelvo a uno tengo que
explicarle a la IA en qué me quedé, se me va media tarde. Y la tarde
es justo lo que no me sobra. En el día a día se nota así. Por la tarde abro una sesión en un
proyecto mío y el contexto llega solo: qué decidí la última vez y en qué me quedé. Llega en titulares y si uno no basta,
el agente pide el detalle. Si me quedo sin red, siguen funcionando. Solo la búsqueda en documentación
necesita llegar a mi servidor. Ese servidor es mi homelab. Dos nodos con Proxmox, que ya sabes
que es mi virtualizador preferido. El pequeño tiene 4 hilos, 30 GB de RAM
y el grande tiene 12 y 64 GB de RAM. Encima corren unos 20 contenedores
y una sola máquina virtual. Casi todo va en los contenedores LXC
porque, según la documentación de Proxmox, usan el kernel del anfitrión y su coste
de ejecución suele ser despreciable. Ahí viven Cerebro, mi gestor de
contraseñas, el bloqueador de anuncios de la red y hasta Plex
para películas y series. En otro de esos contenedores vive Atelier,
el sistema del vídeo anterior, 8 agentes que llevan un ticket hasta
una pull request revisada. Lo que pasa entre un paso y el
siguiente lo decide el código. En producción hizo más de 40 tickets en
dos semanas, de una a dos horas por ticket y por menos de dos euros cada uno. Y tiene un freno que me gusta mucho,
el revisor solo señala, no arregla. Puede devolver el código
como mucho tres veces. A la tercera Atelier se
para y avisa a una persona. Eso tampoco está en un prompt,
está en el código. En la encuesta de Stack Overflow solo el
20 % usa la IA para desplegar u operar sistemas en producción. Yo la tengo
trabajando en un servidor que está a tres metros de mi sofá. Mi opinión, y es solo
la mía, la memoria de mis agentes no la quiero en un portátil que se duerme,
la quiero en una máquina que controlo. Y con todo esto montado, el 7 de octubre,
uno de mis agentes borró lo que no debía. Te lo cuento tal cual. Estaba trabajando
en Alfred, un proyecto personal. Tenía dos sesiones abiertas. En una, un subagente estaba haciendo una
función nueva en su rama y en un momento dado, lanza un rm -rf y borra
la carpeta de test entera. Como ese agente trabajaba en su propio
worktree, la otra sesión no se enteró, siguió con lo suyo,
con sus tests en su sitio, etc. Si los dos hubieran estado en la misma
carpeta, el rm -rf se lo habría llevado todo por delante.
Y ahí me di cuenta de una cosa. Borrar era uno de mis 6 puntos de riesgo. Estaba escrito en el CLAUDE.md
y dio exactamente igual. La documentación de Anthropic
lo dice con todas las letras. Claude trata el CLAUDE.md como contexto,
no como una configuración que se cumple. Si quieres bloquear algo, decida lo que
decida el modelo, tienes que usar un hook, un comando que se ejecuta antes de
cada herramienta y que la puede parar. En el vídeo anterior te dije que las
reglas que importan tienen que estar escritas en el código. Lo decía
por lo que vimos en la empresa. Una semana después me pasó en casa y con
la documentación oficial dándome la razón. Y en el worktree tampoco es una jaula. La misma documentación avisa de que no
vigila lo que escribe un comando del shell. Un cp o una redirección que apunta
a la carpeta principal no lo hace nadie, y el worktree evita que dos
agentes se pisen, nada más. Así que hice dos cambios. El primero,
cada agente siempre en su worktree y en su rama. Lo que fue suerte
ese día ahora es una norma. El segundo, lo destructivo se bloquea en
código antes de que el comando llegue a ejecutarse. Ya no depende de que el
agente se acuerde de leer una línea. Me fastidió, no te voy a engañar, pero
prefiero que me pase con los test de un proyecto mío que algo de la empresa. Con todo esto te digo por dónde
empezaría yo según donde estés. Si estás empezando con agentes,
no copies mis números. Copia lo que me salvó el 7 de octubre,
cada agente en su worktree y en su rama y el borrado bloqueado en código. Eso funciona igual con
un agente que con 13. Si ya usas agentes a diario y
te sientes más rápido, mide. Coge los tickets de un mes y mira
cuánto tardabas antes y cuánto ahora. Después de lo que te decía del METR,
yo no me fío de mi sensación y tú tampoco deberías de fiarte de la tuya. Si trabajas en un equipo, lo que más me
ha cambiado el día es dar a cada agente su modelo y separar la memoria. La del equipo compartida,
la tuya, totalmente aparte. Y nunca la misma cosa en las dos. Y si tienes un homelab o te tienta
montarlo, saca de ahí la memoria de tus agentes. Con un mini PC y Proxmox
tienes de sobra para empezar. Si me quedo con una sola idea
de estos 9 meses es esta. La regla que no puedes permitir que un
agente se salte, escríbela en código. El CLAUDE.md, para el contexto. Lo que sí va en mi CLAUDE.md lo he juntado
en un PDF, las 12 reglas de mi CLAUDE.md en empresa. Te lo mando si te
apuntas a la newsletter, en mi web. Tienes el enlace justo debajo. Y una pregunta que me interesa de verdad,
¿qué es lo peor que te ha borrado o roto un agente de IA? Cuéntamelo
en los comentarios que te leo. Soy Isma y nos vemos
en el siguiente vídeo.
Assuntos: Agentes de IA, ASI. Publicado no YouTube em 2026-10-15.