La pregunta equivocada
La pregunta más fácil es si un modelo puede escribir Liquid. Ya puede hacerlo. La pregunta difícil es si un sistema puede recibir una solicitud de un merchant, entender el contexto correcto de la tienda, limitar el alcance, modificar los archivos adecuados, comprobar el resultado, mostrar una vista previa y detenerse cuando la incertidumbre supera lo permitido. Esa diferencia separa una demostración llamativa de un producto de ingeniería.
Empezar por el límite de producción
Nuestro punto de partida es sencillo: la generación de código no concede autoridad de publicación. Conectar una tienda, leer un theme, preparar cambios en una copia no publicada y publicar el theme activo son capacidades distintas. El producto debe representarlas como permisos y estados diferentes. Cuando se mezclan, cualquier error del modelo se convierte inmediatamente en un incidente de producción. Cuando se separan, el error puede quedar contenido en un job revisable.
Una solicitud debe convertirse en un job
Una conversación abierta no es una unidad operativa suficiente. El sistema necesita un job con una tienda, un theme, un objetivo, un alcance, criterios de aceptación y un estado. El job puede pedir aclaraciones, pasar a planificación, preparar cambios, ejecutar validaciones, quedar bloqueado o llegar a staging. El estado no es decoración de interfaz: determina qué acciones son legales y qué evidencia debe existir.
El contexto no puede depender de copiar y pegar
Un merchant no debería identificar manualmente todos los snippets relevantes. El sistema conectado puede inspeccionar la arquitectura del theme, pero debe hacerlo con límites. Leer todo indiscriminadamente aumenta coste y ruido. Leer demasiado poco produce cambios que ignoran convenciones, settings o dependencias. Por eso el contexto se selecciona a partir del objetivo, las rutas afectadas y las relaciones entre templates, sections, snippets y assets.
El plan es un artefacto revisable
Antes de modificar archivos, el agente propone qué piensa cambiar, por qué esos archivos son relevantes, qué queda fuera y cómo comprobará el resultado. El plan permite detectar un alcance equivocado antes de que se convierta en código. También ofrece un punto de comparación: si la implementación toca archivos no previstos o cambia una conducta distinta, el sistema puede señalar la desviación.
Los changesets importan más que la respuesta del chat
La salida principal no debería ser un bloque de texto con código. Debe ser un changeset que identifique archivos, contenido anterior, contenido nuevo, motivo y relación con el job. Un changeset permite mostrar un diff, ejecutar validaciones selectivas, revertir y mantener un historial atribuible. También hace posible que una persona revise el trabajo sin reconstruir lo ocurrido a partir de mensajes.
QA no es una etiqueta verde
Una validación útil debe estar ligada al tipo de cambio. Sintaxis de Liquid, assets faltantes y enlaces internos son checks generales. Una sección nueva necesita además comprobar schema, render y responsive. Un cambio de metadata necesita revisar varias rutas y el HTML final. Una mejora de rendimiento requiere medición y cuidado con efectos secundarios. El sistema debe distinguir pasado, fallado e inconcluso; convertir todo en verde destruye confianza.
Staging responde una pregunta distinta
QA pregunta si el cambio cumple condiciones. Staging responde dónde puede inspeccionarse sin afectar producción. Un theme no publicado ofrece el contexto real del storefront, incluyendo datos, navegación y comportamiento responsive. La vista previa debe apuntar a la ruta relevante y conservar suficiente estabilidad para que el merchant pueda revisarla. Aprobar la preview no debe confundirse automáticamente con publicar.
La recuperación debe diseñarse antes del fallo
Los agentes fallan de formas menos predecibles que un script determinista. Pueden seleccionar un archivo incorrecto, ampliar el alcance, producir una implementación incompleta o interpretar mal una solicitud. La respuesta no puede ser esperar que el modelo no falle. Necesitamos límites de escritura, cambios pequeños, snapshots, historial de jobs, capacidad de reintento y un camino claro para cerrar sin implementar.
El producto debe saber cuándo no continuar
Una arquitectura responsable incluye condiciones de parada. Falta de permisos, datos contradictorios, validaciones que no pueden ejecutarse, reglas comerciales ambiguas o impacto en sistemas externos son razones para detenerse. El sistema puede pedir contexto o escalar, pero no debe improvisar una política de precios, un claim regulatorio o una migración completa y presentarla como una tarea rutinaria.
Qué estamos construyendo primero
El orden importa. Empezamos por conexión segura, auditoría, jobs delimitados, planificación, changesets, validaciones y staging. Después se puede ampliar capacidad, tipos de trabajo e integraciones. Construir primero una interfaz de chat y añadir controles al final crea una deuda difícil: la conversación se convierte en el sistema de registro y cada nueva función hereda permisos implícitos.
Cómo evaluaremos si funciona
No basta con medir cuántas líneas genera el modelo. Evaluaremos cuántos jobs llegan a un resultado revisable, cuántos se detienen correctamente, qué checks detectan problemas, cuánto contexto necesita una solicitud y cuántas veces el merchant puede entender el cambio sin ayuda adicional. La calidad del sistema está en terminar trabajo seguro y explicar claramente por qué no debe continuar cuando no puede.
Lo que sigue siendo humano
La IA puede acelerar inspección, implementación y comprobaciones. Las decisiones que combinan arquitectura, riesgo comercial, cumplimiento, identidad de marca o coordinación entre sistemas siguen necesitando responsables humanos. TaskerArmy no intenta ocultar esa frontera. La meta es reducir coordinación y tiempo perdido en el trabajo repetible, mientras hace más visible cuándo se requiere experiencia senior.
Conclusión
Estamos construyendo un ingeniero de IA para Shopify que no toca producción primero porque el orden de autoridad define la seguridad del producto. El modelo es una pieza. El sistema completo necesita contexto, jobs, plans, changesets, QA, staging, aprobación y recuperación. Cuando esos elementos existen, la IA puede convertirse en una herramienta de ejecución controlada. Sin ellos, solo genera código más rápido.