Cómo llevo solo un negocio de módulos PrestaShop con una flota de agentes de IA

Hace unos meses descubrí que mis agentes de IA habían dejado 154 repositorios Git dirty - y la solución no fue un prompt mejor, sino un organigrama.

No 154 archivos. 154 repositorios. Decenas de bases de código de módulos, cada una con cambios sin commit apilados unos sobre otros - algunos experimentos a medio terminar, algunos trabajos realmente buenos que simplemente nunca se publicaron. Distintos agentes, en distintos momentos, habían hecho cada uno un trozo y siguieron adelante. Nadie hizo commit. Nadie limpió. El trabajo no estaba exactamente perdido. Era peor que perdido. Estaba enredado, y yo no podía saber qué manos habían tocado qué.

El instinto, cuando un agente de IA hace algo tonto, es arreglar el prompt. Añadir una línea. "Haz commit siempre que termines tu trabajo." "No dejes nunca repositorios dirty." Lo intenté. No aguanta - y cuando entiendes por qué, cambia por completo la manera de trabajar con estas herramientas.

Este es un relato de cómo llevo realmente la tienda: una persona, un catálogo de bastante más de cien extensiones PrestaShop publicadas en seis idiomas, más un puñado de tiendas online reales que yo mismo opero con esos mismos módulos. Mucho del trabajo repetitivo de desarrollo y soporte pasa por una flota de agentes de IA - siempre bajo mi revisión; la arquitectura, las decisiones de release y la aprobación final siguen siendo mías. Lo que viene es la parte que nadie pone en la página de ventas - los errores concretos que cometieron esos agentes, y la maquinaria que construí para que no puedan cometerlos dos veces.

El agente es un empleado brillante con amnesia total

Este es el modelo mental que realmente funciona. Tu agente de IA es un contratista genuinamente excelente - rápido, leído, incansable - que tiene cero memoria de haber trabajado antes para ti. En cada sesión entra por la puerta un desconocido brillante. Nunca ha visto tu base de código. No conoce tus convenciones. No sabe que lo que está a punto de hacer rompió producción el mes pasado, porque no estaba allí. Para su memoria, nadie estaba allí.

No puedes arreglar a esa persona con un conjunto de instrucciones más listo al entrar. Un prompt es una conversación. Se evapora cuando termina la sesión. Lo que necesitas es lo que toda organización real construye para no depender de la memoria de una sola persona: conocimiento institucional duradero, escrito y aplicado. Documentos de onboarding. Runbooks. Una checklist de pre-commit clavada en la pared. Guardarraíles que hacen físicamente difícil el movimiento equivocado.

No escribo prompts mejores. Escribo mejor memoria. La amnesia solo es cara si haces que el agente reaprenda todo cada vez que entra.

Así que el oficio no es prompt engineering. El oficio es construir la organización alrededor del amnésico. Y la idea más útil que tuve fue esta: cada guardarraíl de mi sistema es una cicatriz. Apunta a un momento específico, con fecha, en el que un agente hizo algo mal, yo sentí el dolor, y convertí ese dolor en una regla que el entorno aplica para siempre. Mi configuración no es una lista de deseos. Es una historia clínica.

Estas son las cicatrices.

Cicatriz #1: el agente que borró la carpeta vendor y tumbó la tienda

Algunos de mis módulos dependen de bibliotecas internas compartidas - código que reutilizo en todo el catálogo. Por razones de despliegue, esas bibliotecas viven dentro de la carpeta vendor/ de cada módulo, pero las copia allí un script de sincronización, no las gestiona el package manager normal. Es una configuración poco habitual, y un agente amnésico no tiene forma de saberlo.

Así que una tarde del otoño pasado un agente necesitaba añadir una dependencia, e hizo lo correcto según el manual: ejecutó composer install. El package manager miró el manifest, vio un montón de archivos en vendor/ que él no había puesto ahí, y los borró amablemente. Las clases desaparecieron. La tienda en producción empezó a devolver 500 en cuanto un cliente entraba en una página que autoloadaba uno de los traits que faltaban.

El agente no estaba equivocado según su propia lógica. Estaba equivocado porque no tenía mi memoria. No puedes salir de esto de forma fiable con un prompt - "ten cuidado con composer" es exactamente el tipo de instrucción blanda que un agente olvida bajo presión. Así que la solución no es una frase. Es un muro:

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Ahora el error está no disponible. Un agente nuevo sin memoria de la caída sigue sin poder reproducirlo, porque el entorno dice que no antes de que ocurra el daño. Esa es la diferencia entre un prompt y una cicatriz: el prompt espera; la cicatriz impone. Ahora tengo una pequeña biblioteca de estos hooks, y cada uno de ellos es una tarde que no voy a recuperar.

Cicatriz #2: los 154 repositorios dirty

Volvamos al arranque. El enredo ocurrió porque había resuelto otro problema - ejecutar muchos agentes en paralelo - sin construir la capa de coordinación que el paralelismo realmente necesita.

Ejecutar un agente es una conversación. Ejecutar una flota es logística, y la logística es un conjunto de problemas que ningún prompt resuelve:

• Se throttlean y se cuelgan. Lanza cinco trabajos pesados a la vez y se amontonan, se atascan y expiran. La solución fue infraestructura: un runner que pone trabajos en cola, los balancea entre workers paralelos y pone un watchdog en cada run, para que el uso concurrente pesado no se acumule ni se congele. Los agentes no gestionan su propia capacidad. Lo hace la organización.
• Colisionan. Dos agentes editando el mismo módulo al mismo tiempo corrompen el trabajo del otro. La solución es un bloqueo de archivo por módulo - un agente toma el módulo, trabaja, lo libera. Con un giro que aprendí por las malas: un bloqueo cuyo proceso dueño está muerto no es trabajo activo, es basura. Así que el bloqueo comprueba si su dueño aún existe y limpia automáticamente los bloqueos obsoletos. Un sistema de coordinación que hace deadlock con fantasmas es peor que no tener sistema.
• Committean la ropa sucia de otros. Esta fue la verdadera raíz de los 154. Un agente que terminaba su propia tarea ejecutaba el equivalente de "commit everything" - y barría el trabajo sin terminar de otros tres agentes en el mismo commit. Así que la ruta de commit recibió una puerta: un agente solo puede stagear sus propios archivos, nunca un "add everything" general. Literalmente no puede commitear trabajo que no hizo.

Ninguna de esas tres cosas es ingeniosa. Son la maquinaria aburrida de un lugar de trabajo que funciona: fichar, no tocar el escritorio donde alguien está a mitad de proyecto, no firmar por un paquete que no es tuyo. Tuve que construir cada una porque un agente concreto, un día concreto, hizo lo contrario.

La coordinación tiene que permitir terminar, no congelar. Los bloqueos existen para impedir que dos agentes editen un archivo a la vez - no para convertir "trabajo terminado" en "trabajo congelado". Committear es un punto de control, no una jaula.

Esa última línea importa más de lo que parece. La primera versión de mi locking era demasiado estricta, y los agentes empezaron a quedarse de brazos cruzados esperando bloqueos que ya no pertenecían a nadie. Un sistema de seguridad que impide que el trabajo se termine no es seguridad - es simplemente otro fallo. La regla ahora es que la coordinación debe hacer que terminar sea más fácil que no terminar, o se rediseña.

Cicatriz #3: nunca dejes que un agente aprenda en la tienda del cliente

Esta es la única regla que no esperé a ganarme por las malas. Al principio, un agente "solo comprobó una cosa" contra una tienda en vivo - y los diez segundos antes de confirmar que en realidad nada había cambiado fueron suficientes para hacer el principio no negociable: los agentes construyen y prueban primero en una copia desechable, y solo tocan algo visible para clientes después de que el cambio esté probado.

Un agente nuevo no tiene instinto para saber en qué entorno está. Para él, una shell es una shell. Así que el entorno hace la distinción por él: las operaciones arriesgadas se enrutan por defecto a clones desechables, producción se trata como un lugar separado y protegido, y los comandos destructivos por hábito que la gente ejecuta en una máquina de dev (vaciar un directorio de cache, resetear estado) se bloquean o redirigen en cualquier cosa que esté frente a un cliente real. El agente no tiene que recordar la diferencia entre "mi sandbox" y "la tienda de alguien". La organización la recuerda por él.

Este es el único guardarraíl que querría que conociera un cliente, porque es el que lo protege a él. La razón por la que una actualización de módulo rara vez llega con una sorpresa es que los cambios visibles para clientes pasan por un ensayo general completo - en una tienda desechable, donde un error no cuesta nada - antes de la release.

Cicatriz #4: haz que falle en voz alta, no con educación

Dejado solo, un agente servicial tapará un problema. Algo que esperaba no estaba ahí, así que sustituye silenciosamente un valor por defecto, envuelve la llamada en un fallback "por si acaso" y sigue adelante. La tarea parece haber salido bien. En la tienda de un cliente, un workaround silencioso es peor que un error visible - porque el error visible se arregla hoy, y el silencioso se publica y espera.

Así que la instrucción permanente es lo contrario del reflejo: cuando algo esté mal, crash loudly. No inventes un fallback para ocultar una pieza que falta. No añadas acolchado defensivo que convierta un bug en una respuesta sutilmente equivocada. Muéstralo, párate y deja que un humano decida. Combinado con la regla dev-first, esto significa que los fallos feos ocurren en la sala de ensayo, donde feo es exactamente lo que quieres, y el objetivo es que los clientes vean la toma que funcionó, no las tomas que no.

La parte que lo hace todo barato: memoria, hecha a propósito

Las cicatrices impiden que los agentes rompan cosas. Pero el hábito que hace económica toda la operación es el que convierte la amnesia de un impuesto en un error de redondeo.

La forma ingenua de usar un agente en una tarea recurrente es explicársela de nuevo cada vez. Volver a adjuntar los archivos de ejemplo. Volver a describir los pasos. Volver a deducir qué rutas importan y qué trampas muerden. Pagas precio completo, en tokens y en tiempo real, por conocimiento que ya descubriste la semana pasada. Es el amnésico reaprendiendo cada mañana las salidas de emergencia del edificio.

Así que hice una regla para los propios agentes: al final de una tarea, escribe la nota. No una entrada de diario - un memo operativo. Dónde viven los archivos relevantes. La secuencia exacta que funcionó. La única cosa no obvia que hará tropezar el próximo run. Estas notas viven en un árbol organizado, y - esta es la parte que la gente se pierde - hay un índice de una línea de cada nota que se carga al principio de cada sesión. El amnésico entra, lee la tabla de contenidos y sabe al instante lo que el negocio ya sabe y dónde buscarlo.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

Esta es toda la tesis en un hábito. Un prompt inteligente mejora este run. Una nota escrita abarata cada run futuro, sea cual sea el agente que lo recoja. La memoria institucional se compone; los prompts no. La primera vez que hago algo aquí es cara. La décima cuesta casi nada, y es barata precisamente porque las primeras nueve escribieron lo que aprendieron.

Cómo se ve realmente una tarea al pasar por esto

Juntándolo todo, un trabajo rutinario se ejecuta como un equipo pequeño y bien entrenado, no como una sesión de chatbot:

1. Un agente lee el índice, toma la nota para este tipo de tarea y empieza con gran parte del camino ya hecho en vez de desde cero.
2. Toma el bloqueo del módulo que está a punto de tocar, para que nada más pueda colisionar con él.
3. Trabaja en una copia desechable. Si algo va mal, falla en voz alta allí - no en una tienda en vivo.
4. Cuando intenta terminar, los guardarraíles aguantan: no puede ejecutar el comando que una vez borró una carpeta vendor, y solo puede commitear sus propios archivos, no el trabajo a medio hacer que está en el repo de al lado.
5. Escribe de vuelta lo que aprendió, para que la nota quede un poco más afinada para el próximo agente - quizá uno completamente distinto.

Fíjate en lo poco que hay ahí de "prompting". El prompt es una línea: haz la tarea. Todo lo que la hace segura, rápida y repetible vive en el entorno, no en el mensaje. Ese es todo el truco.

El registro de lo bueno y lo malo, y por qué cada "bueno" solo significa "tiene memoria"

La gente me pide consejos para usar IA eficientemente esperando trucos de prompt. La lista real es más aburrida y mucho más útil, y cada punto es la misma idea con ropa distinta - dale al amnésico una memoria y un taller preparado:

• Malo: pegar código en un chatbot gratuito y copiar la respuesta a mano. Bueno: ejecutar agentes donde vive el trabajo - en la máquina, con acceso real a los archivos y herramientas - para que no haya que describir nada que simplemente pueda ser leído.
• Malo: un disco desordenado donde cada tarea empieza con el agente buscando dónde están las cosas. Bueno: un árbol de materiales organizado, para que "encontrar la cosa" sea una consulta, no una expedición.
• Malo: el agente hace grep de todo el disco y lee veinte archivos para encontrar una función. Bueno: preparar el taller - búsqueda rápida y conectores que le permiten consultar directamente la base de datos, el navegador y los contenedores en ejecución en vez de adivinar.
• Malo: reconstruir desde cero la misma tarea de varios pasos cada vez. Bueno: la nota reutilizable y el índice que la saca a la superficie.
• Malo: un agente generalista para todo. Bueno: enrutar el trabajo - el modelo mejor en razonamiento backend cuidadoso recibe el backend; el que tiene mejor criterio para interfaz y palabras recibe eso. Igual que formar un equipo según fortalezas.

Un desconocido con amnesia en un edificio bien gestionado - estanterías etiquetadas, un manual claro, herramientas afiladas preparadas y guardarraíles en la maquinaria peligrosa - es asombrosamente productivo. El mismo desconocido soltado en una sala desordenada con un briefing verbal vago es un riesgo. Mismo trabajador. La diferencia es completamente la organización.

Dónde ayuda la IA, y dónde la revisión humana sigue ganando

Después de todo esto, tengo una sensación bastante clara de la frontera.

La IA gana en lo mecánico, lo paralelo y lo bien acotado. Llevar un cambio a decenas de módulos. Redactar la primera versión de cualquier cosa. Extraer y transformar datos estructurados. Ejecutar de nuevo desde una nota un workflow preparado. Investigar un bug complicado con más paciencia de la que tengo a las 6pm. Cuando la tarea tiene una respuesta correcta conocible y un camino hacia ella, un agente bien equipado es más rápido que yo y no se aburre en la tercera repetición.

La revisión humana gana en juicio, gusto y consecuencia. Cualquier cosa por la que paga un cliente. Cualquier cosa con peso legal o financiero - que es exactamente por lo que las correcciones de facturas de arriba llevan firma humana, no envío automático. Las decisiones de arquitectura donde la respuesta "correcta" depende de dónde quiero que esté el negocio dentro de un año, no de lo que diga el código hoy. Y el gusto del último metro en escritura y diseño, donde "técnicamente correcto" y "realmente bueno" son cosas distintas, y solo una conserva a un cliente.

La línea tampoco es fija. Cada cicatriz de este texto es un lugar donde una vez confié a un agente algo para lo que no estaba preparado, me mordió y moví la línea. Esa es la habilidad real - no decidir una vez dónde se detiene la IA, sino prestar atención a dónde falla y ajustar la frontera más rápido de lo que los fallos pueden acumularse.

Por qué debería importarte esto si me compras

Esta es la versión honesta, porque el encuadre de una pieza como esta puede deslizarse a un sitio al que no quiero ir. Los agentes no hacen mis módulos por mí, y nunca te diría que lo hacen. Construyen andamios, ejecutan herramientas que no me apetece ejecutar a mano, redactan primeras versiones y detectan errores unos de otros - todo dentro de un conjunto de guardarraíles que me gané caída tras caída. El juicio, la arquitectura y la firma final siguen siendo míos.

Lo que esa disciplina te compra a ti, al otro lado de un módulo o de un ticket de soporte, es aburrido en el mejor sentido. La misma regla que evita que 154 repositorios se enreden es la regla que evita que una release salga a medias. El mismo muro que impide a un agente borrar una carpeta vendor es la razón por la que una mala actualización tiene muchas menos probabilidades de salir de mi taller. El mismo hábito dev-first que protege mis propias tiendas de prueba protege las tuyas. Un proceso cuidadoso upstream es lo que downstream se siente como fiabilidad tranquila.

Si hay una sola idea que llevarse, es esta: deja de ajustar el prompt y construye la memoria. El agente olvidará todo en cuanto se cierre la sesión - así que pon todo lo que valga la pena recordar en algún lugar donde no pueda olvidarlo, y haz que los errores que no quieres volver a ver sean imposibles, no solo desaconsejados. Hazlo, y una flota de amnésicos brillantes deja de ser un riesgo y empieza a parecerse mucho a un equipo.