Cómo uso agentes de código con IA en Adobe Commerce
Claude Code, hooks, skills y MCP en proyectos reales de Adobe Commerce. Qué delego en el agente, qué hago yo y qué cambia para el comercio que paga las horas.
En esta página
- Qué entiendo por «asistido por IA»
- Memoria del proyecto: un fichero de instrucciones por tienda
- Skills y slash commands para el trabajo repetido
- Hooks: barreras que no dependen de que el modelo se porte bien
- MCP: el ticket, el código y la revisión en una sola sesión
- Análisis de logs
- Revisión de código y refactorización
- Dónde lo limito
- Qué significa para tu tienda
Llevo 17 años trabajando con Magento y Adobe Commerce. Desde hace tiempo, Claude Code y Codex están abiertos en una terminal junto a mi editor cada día de trabajo. Este artículo explica cómo funciona ese entorno, dónde ahorra tiempo real en un código Adobe Commerce y dónde sigo haciendo el trabajo a mano.
Está escrito para dos lectores: el responsable de la tienda que paga las horas de ingeniería y quiere saber qué cambia, y el líder técnico que decide hasta dónde dejar entrar a los agentes en el repositorio.
Qué entiendo por «asistido por IA»
En mis proyectos, un agente no decide nada por su cuenta. Lee código, ejecuta comandos, propone cambios y escribe borradores. Reviso cada diff antes del commit, y nada llega a producción sin pasar los mismos controles que un cambio hecho por una persona.
El cambio útil no es que «la IA escribe el código». Es que las partes lentas y mecánicas del trabajo se reducen: encontrar qué plugin intercepta un método, leer una semana de exception.log, comprobar un módulo contra el estándar de código, escribir el quinto test casi idéntico. Así queda más tiempo pagado para las decisiones que necesitan 17 años de contexto.
Memoria del proyecto: un fichero de instrucciones por tienda
Cada tienda en la que trabajo tiene un CLAUDE.md en la raíz del repositorio. Claude Code lo carga en cada sesión, así que el agente empieza con lo que un ingeniero nuevo necesitaría en su primera semana:
- Edición de Adobe Commerce y versión de PHP, hosting (Adobe Commerce Cloud, Upsun o propio) y cómo acceder a cada entorno.
- Qué módulos de terceros están parcheados y dónde están los parches.
- Los comandos que importan:
bin/magento setup:di:compile, las suites de tests, los análisis estáticos, cómo limpiar solo las cachés necesarias. - Las normas de la casa: plugins antes que preferences, nada de SQL directo en controladores, solo esquema declarativo, dónde van los módulos propios.
Este fichero es la mejora más barata de todo el entorno. Sin él, el agente adivina las convenciones y produce código que funciona pero no encaja. Con él, el primer borrador suele parecerse a lo que habría escrito el equipo.
Skills y slash commands para el trabajo repetido
El trabajo en Adobe Commerce se repite. Un módulo nuevo necesita el mismo esqueleto. Un resolver GraphQL nuevo necesita una entrada en el esquema, una clase resolver, el cableado de DI y un test. Una actualización necesita la misma checklist cada vez.
Claude Code me permite empaquetar cada una de estas tareas como una skill: una carpeta con un SKILL.md que describe la tarea y los scripts o ficheros de referencia que necesita. Las skills se pueden versionar en el repositorio bajo .claude/skills/, así todo el equipo las tiene, y cada una está disponible también como slash command. Las que más uso en proyectos Commerce:
- Esqueleto de módulo. Crea
registration.php,module.xml,di.xmly la estructura de carpetas según las convenciones del proyecto. - Comprobación previa a la actualización. Lista cada plugin, preference y parche que toca clases del core modificadas entre dos versiones, para que la estimación parta de hechos.
- Pasada de revisión. Ejecuta PHP_CodeSniffer con el estándar de código de Magento y PHPStan, y resume los hallazgos por riesgo en lugar de por fichero.
Para tareas grandes uso subagentes. Cada uno trabaja en su propia ventana de contexto con su propia lista de herramientas, así que un «explorador» de solo lectura puede mapear cómo está personalizado el checkout en decenas de módulos sin llenar la sesión principal de contenido de ficheros. Solo vuelve su resumen.
Hooks: barreras que no dependen de que el modelo se porte bien
Las instrucciones de CLAUDE.md son consejos. Los hooks son obligatorios. Un hook PreToolUse ejecuta un script antes de que el agente use una herramienta, y si el script termina con código 2, la llamada se bloquea y el agente ve el motivo.
En proyectos Commerce bloqueo la edición de ficheros que nadie debería tocar en una rama de funcionalidad:
#!/usr/bin/env bash
# .claude/hooks/protect-paths.sh, registrado como hook PreToolUse para Edit y Write
file=$(jq -r '.tool_input.file_path // empty')
case "$file" in
*/vendor/*|*/app/etc/env.php|*/generated/*|*/pub/static/*)
echo "Blocked: $file is generated, vendored or environment-specific." >&2
exit 2 ;;
esac
exit 0
Lo combino con hooks de pre-commit de git normales que ejecutan el estándar de código y un escaneo de secretos. El agente pasa por los mismos controles que cualquier ingeniero, y un error se detecta antes de convertirse en commit.
MCP: el ticket, el código y la revisión en una sola sesión
El Model Context Protocol (MCP) conecta el agente con sistemas externos mediante pequeños servidores. Uso integraciones MCP con Atlassian (Jira y Confluence) y Bitbucket. En la práctica, puedo empezar una sesión con la clave de un ticket y el agente lee el ticket, la página de Confluence enlazada y el pull request abierto antes de mirar el código.
Mantengo dos reglas. Primera, los permisos son estrechos: el agente actúa con el acceso de mi cuenta y nada más, y todo lo que escribe en un sistema del cliente lo apruebo yo cada vez. Segunda, la configuración MCP del proyecto vive en .mcp.json dentro del repositorio, para que sea visible y revisable, no algo escondido en el portátil de una persona.
Análisis de logs
Aquí el ahorro de tiempo es mayor y menos discutible. Una incidencia en producción en Adobe Commerce suele implicar var/log/exception.log, system.log, los logs del servidor web y, si el cliente lo tiene, New Relic o Datadog. En Adobe Commerce Cloud Pro los logs son por nodo, así que la misma incidencia está repartida en varios ficheros.
Le doy al agente los ficheros y una ventana de tiempo. Agrupa trazas repetidas, separa el ruido (un bot que pide una URL eliminada) de la señal (un módulo de pago que agota el tiempo bajo carga) y señala las líneas de código implicadas. Después verifico las dos o tres hipótesis que importan. Lo que antes era una tarde de grep y scroll ahora lleva una fracción de ese tiempo, y el resumen escrito va directo al ticket de la incidencia.
Revisión de código y refactorización
Uso agentes para una primera pasada en cada pull request que me piden revisar: controladores de admin sin comprobación de ACL, plugins en métodos críticos como el renderizado de precios, observers que hacen trabajo que corresponde a un consumidor de cola, cargas N+1 en colecciones. El agente marca candidatos; yo decido cuáles son reales.
La refactorización es la otra área fuerte. Dividir un helper sobredimensionado en servicios, sustituir llamadas a ObjectManager por inyección en el constructor o mover un cron antiguo a un consumidor de RabbitMQ son tareas mecánicas una vez decidido el diseño objetivo. Yo decido el diseño, el agente hace la edición masiva, y la suite de tests y una revisión lo confirman.
Dónde lo limito
| Tarea | Papel del agente |
|---|---|
| Diseño de arquitectura e integraciones | Solo investigación; la decisión es mía |
| Estimaciones y hoja de ruta | Reúne datos; yo estimo |
| Lógica de pago, impuestos y checkout | Solo borradores, revisados línea a línea |
| Despliegues y cambios de datos en producción | Ninguno |
| Comunicación con el cliente | Ninguno |
Los agentes hablan con seguridad incluso cuando se equivocan. En una plataforma tan grande como Adobe Commerce, una respuesta plausible sobre cómo se comporta una clase del core a menudo está desactualizada o es inventada. Todo lo que toca dinero, datos personales o el estado de producción lo verifico leyendo el código o ejecutándolo.
Qué significa para tu tienda
Pagas menos horas de búsqueda, lectura de logs y código repetitivo, y más horas de decisiones. Las estimaciones de actualización parten de una lista de conflictos reales. Los informes de incidencias llegan antes y con pruebas. La revisión de código cubre más de cada cambio.
Lo que no cambia: un ingeniero sénior responde de cada línea que se publica, y el agente trabaja dentro del mismo proceso de ramas, tests y revisión que todos los demás.
Si quieres este flujo de trabajo en tu proyecto Adobe Commerce, o que tu propio equipo lo adopte con seguridad, escríbeme.
Artículos relacionados
Mi checklist de rendimiento para Adobe Commerce
Doce comprobaciones, en orden, que explican la mayor parte del tiempo de carga de una tienda Adobe Commerce típica antes de escribir una línea de código.
RendimientoCuándo pasar a headless en Adobe Commerce
Headless es una decisión de equipo y presupuesto antes que de tecnología. Así decido entre Hyvä y un storefront separado en Adobe Commerce.
Headless