Lo primero que abro al llegar al trabajo ya no es el editor de código. Es un bot de nuestro Slack interno llamado Anvil. La frase parece el inicio de una celebración de la automatización, así que conviene corregir esa impresión: añadir un bot no cambió mi día. El cambio útil llegó después, cuando construimos un harness que obligaba al trabajo iniciado por cualquier persona a alcanzar el mismo nivel de calidad.

Antes, QA preguntaba algo aparentemente pequeño: «Si cambiamos este texto, ¿qué más se ve afectado?». Yo detenía mi tarea, vaciaba el contexto mental, abría el repositorio, rastreaba el código, respondía y luego reconstruía lo que estaba haciendo. Una sola pregunta podía partir la jornada por la mitad. QA esperaba una respuesta y yo esperaba recuperar la concentración. Ninguno avanzaba con el trabajo previsto.

Ahora QA envía a Anvil el número del ticket y una petición corta. El bot lee el ticket y el código, clasifica el impacto y lleva un cambio de bajo riesgo hasta un merge request. Si el alcance es mayor, solicita aprobación antes de tocar la implementación. A mediodía reviso juntos los MRs acumulados. La diferencia importante no es la velocidad bruta. Es que una modificación iniciada en Slack pasa por las mismas reglas que otra iniciada desde mi terminal.

Las cifras de este artículo pertenecen a una única retrospectiva interna que aporté como material editorial. No son un benchmark de producto ni una promesa de resultados para otras organizaciones. Las afirmaciones técnicas verificables enlazan la documentación oficial de Claude Code, ESLint y TypeScript. El nombre Anvil, el flujo y los resultados son notas operativas de este caso.

Por qué escribí sobre esto

Enviar un mensaje a un bot no equivale a delegar. Si después debo leer todo el código desde cero, solo he cambiado la caja de entrada. La delegación empieza cuando existe un motivo serio para esperar la misma calidad después de soltar la tarea. Ese motivo no fue la inteligencia del modelo, sino las reglas del proyecto.

Al principio intenté resolverlo con prompts más largos. Pronto resultó absurdo. Reglas como «un mes de facturación tiene 28 días», «el pedido mínimo es de 50.000 KRW» o «no guardar si la divisa no es válida» no pueden pegarse en cada conversación. Parte de esa lógica ya estaba en el código, pero no de una forma que toda tarea nueva pudiera encontrar en el mismo orden.

Reunimos archivos de políticas, niveles de impacto, comandos de validación y condiciones de traspaso en una definición operativa. Slack y el terminal pasaron a ser dos entradas del mismo proceso. Anvil no es otra capa de inteligencia: es una interfaz fina que llama en modo no interactivo al agente de código que ya usamos. La documentación oficial del modo headless de Claude Code describe claude -p para ejecutar una consulta y salir.

La interfaz es la parte fácil de copiar. La definición operativa concentra el trabajo. Un bot atractivo que lanza un agente sin el mismo contexto del repositorio, permisos y comprobaciones finales solo ofrece a las personas no técnicas una ruta más rápida hacia resultados inconsistentes.

El caso de trabajo que tomé como base

La referencia fue un ticket de QA. Primero hay que identificar el repositorio y los archivos afectados. Después, el agente determina si el cambio toca una política o un módulo central. Una modificación menor avanza hacia la implementación y las comprobaciones. Una mayor espera al responsable antes de cambiar código. En todos los caminos, una persona conserva la decisión sobre intención del producto y publicación.

Un solo flujo desde una petición en Slack hasta el análisis de impacto, el cambio de código, las puertas de calidad, el merge request y el juicio humano final

El recorrido desde Slack es deliberadamente sencillo:

[Petición de QA en Slack]
→ Anvil
→ ejecución no interactiva del agente
→ reglas del proyecto y nivel de riesgo
→ cambio de código
→ lint · typecheck · test
→ merge request o solicitud de aprobación

Slack es solo la interfaz. La definición del proyecto, los comandos de validación y las reglas de bloqueo son el harness. La guía oficial para depurar la configuración de Claude Code también separa las instrucciones que aportan contexto de los permisos y hooks que imponen límites. Escribir «no ejecutes comandos peligrosos» no es lo mismo que impedir su ejecución.

La separación mantiene útil el proceso fuera de Slack. Cuando comienzo una modificación desde el terminal, se aplican la misma definición y los mismos controles. Un subagente no necesita heredar toda la historia de un chat para conocer la regla de los 28 días o las pruebas obligatorias.

Lo que comparé en la práctica

La primera comparación no fue entre modelos. Comparé un prompt que pide revisar con un flujo que no puede terminar si las revisiones fallan. La puerta de calidad se ejecuta cuando el agente intenta detenerse. Los problemas de lint corregibles se resuelven con ESLint --fix; los errores restantes, tsc --noEmit y las pruebas relevantes deben pasar antes de entregar el resultado. La guía de hooks de Claude Code documenta eventos del ciclo de vida y hooks de Stop para ejecutar comandos deterministas en el límite de finalización.

Las acciones peligrosas se dividen en dos capas. rm -rf, DROP TABLE o la creación de un archivo .env quedan bloqueados porque su ejecución no es aceptable en este recorrido. git push --force o saltarse verificaciones con --no-verify pueden tener un uso excepcional, pero necesitan aprobación humana y registro. Una capa es la barandilla alrededor del horno; la otra es el aviso que llama a una persona cualificada.

Los cambios menores avanzan solos, los moderados se revisan después de implementar y las políticas o módulos centrales necesitan aprobación previa

Nivel de impacto Ejemplos Recorrido
MINOR Texto, mapeos simples Implementar → puertas de calidad → MR
MODERATE Estructura de componentes, estilos Implementar → puertas de calidad → revisión
MAJOR Constantes de política, validación, núcleo Aprobación previa → implementar → revisar MR

Colocar un cuello de botella en MAJOR permitió abrir MINOR y MODERATE. Hacer que todos los cambios avancen a la misma velocidad no es automatización, sino ausencia de control. Exigir aprobación previa para corregir una errata produce el problema contrario: el bot automatiza la espera.

El nivel se decide a partir de rutas y palabras de política específicas de cada proyecto. No es un clasificador universal de seguridad. Un archivo de texto puede ser inocuo en un repositorio y controlar precios en otro. Lo útil no son las etiquetas, sino conectar el impacto previsto con el momento en que entra una persona.

Dónde se rompe en la práctica

Escribo menos código, pero el trabajo no desapareció. Según mi estimación personal, la implementación pasó de cerca del 60% a casi cero, y escribir pruebas de alrededor del 20% a casi cero. En cambio, explicitar políticas y requisitos subió aproximadamente al 60%, la revisión al 30%, y el merge y despliegue al 10%. No son mediciones de una hoja de horas; por eso las columnas no pretenden sumar exactamente 100.

Estimación personal del tiempo que dejó la implementación y las pruebas para pasar a políticas, requisitos, revisión, merge y despliegue

Sigo usando el teclado. Ahora escribo recorridos de usuario, reglas de validación, mensajes de error y casos de fallo en vez de la mayor parte de la implementación. «Mejorar el login» se convierte en un documento que indica dónde empieza el recorrido, qué valores entran, qué ve el usuario si algo falla y cuál es el siguiente paso. Ese texto sirve como especificación para el agente y como superficie de revisión para quien acepta el resultado.

El nuevo proceso ha fallado en puntos muy ordinarios. En una pantalla con varios modales de error, el bot no pudo decidir con seguridad qué repositorio debía cambiar. La ejecución se detuvo en el primer paso. Añadimos una salida en la que el usuario elige entre repositorios candidatos y el flujo pudo continuar. Yo había tratado la recuperación como un problema de código; también era un problema de experiencia para la persona que había iniciado el trabajo.

Las políticas ambiguas causaron más fallos que un modelo débil. Si una regla del negocio solo vive en la cabeza de alguien como «siempre lo hacemos así», el agente no puede leerla. Cuando un fallo se repetía, aprendí a corregir antes los documentos de política y el harness. Que el modelo no pueda leer mi mente no es un defecto: marca el límite del sistema.

Pasar las pruebas no significó completar la función

Volví sobre un cambio terminado y separé dos resultados. La completitud técnica fue del 85%; la cobertura de la especificación, del 62,5%. Pasaron las 151 pruebas Jest y estaban presentes los seis estados del modal. Sin embargo, al comparar 40 puntos de la especificación, solo 25 aparecían en el producto. Los 15 ausentes incluían políticas de categoría, alcance de responsables y filtros de búsqueda: reglas de negocio que lint, tipos y pruebas existentes no podían deducir.

Retrospectiva interna con 85 por ciento de completitud técnica, 62,5 por ciento de cobertura de requisitos, 151 pruebas superadas, seis estados y 25 de 40 requisitos reflejados

Lo más extraño es que el agente no ignoró por completo los huecos. Su informe indicaba que categoría, responsable y confirmación de guardado estaban incompletos. Encontró y anotó los puntos, pero no los conectó con la definición de terminado. La puerta técnica no podía detectar ese fallo porque el código era válido y las pruebas conocidas estaban verdes.

Empezamos a añadir una segunda capa para comportamiento y especificación. Busca las políticas que toca un cambio, ejecuta sus criterios de aceptación y avisa cuando documento y resultado divergen. Todavía no funciona en todos los proyectos ni descubre todas las reglas no escritas. El objetivo actual es más modesto: conectar «qué debe cumplirse antes de terminar» con comprobaciones ejecutables, para que un punto pendiente no sobreviva únicamente en un informe.

Qué haría la próxima vez

No empezaría construyendo el bot. Primero comprobaría si dos personas que reciben la misma tarea encuentran las mismas reglas y pruebas. Si no ocurre, el bot de Slack será una entrada más rápida a la confusión existente.

Conservaría tres límites. Los comandos peligrosos se bloquean en la ejecución, no solo en el prompt. La aprobación humana se adelanta a medida que aumenta el impacto. Y el estado de las pruebas se separa del estado de los requisitos. Las puertas técnicas responden si el código está roto. Los criterios de aceptación responden si construimos lo que pretendíamos.

Las personas siguen dentro del flujo. Un cambio relacionado con dinero, datos de clientes o políticas centrales recibe la aprobación de alguien con experiencia relevante. La recuperación tras una automatización fallida y la publicación final también tienen un responsable. El objetivo no es eliminar a la persona: es dejar a la máquina las verificaciones repetibles y reservar el juicio humano para los puntos donde cambia el resultado.

Checklist antes de copiarlo

  • Escribe tres políticas que el equipo repita de memoria con frecuencia.
  • Separa, a nivel de comando, los cambios autónomos, las acciones que requieren revisión y las acciones bloqueadas.
  • Conecta lint, tipos y pruebas como puertas obligatorias de finalización.
  • Da rutas distintas a texto y mapeos, componentes, políticas, validación y módulos centrales.
  • Cuenta la cobertura de especificación por separado del número de pruebas superadas.
  • Ofrece una salida para elegir repositorio o siguiente acción cuando falle la clasificación.
  • Nombra a una sola persona responsable del merge final y cualquier despliegue externo.

No hace falta empezar con un bot interno de Slack. Usar una definición de proyecto y los mismos hooks desde el terminal ya aporta buena parte del valor. Elegiría una pregunta que se repite varias veces al día, permitiría que solo un cambio de bajo riesgo llegase al MR y observaría primero los MRs reabiertos y los requisitos ausentes, no las horas supuestamente ahorradas.

Deja por escrito el límite operativo

La retrospectiva interna de este artículo es un caso operativo, no una prueba de que los mismos controles se hayan probado o funcionen igual en otro repositorio. Usa la hoja de trabajo para anotar las rutas afectadas, el nivel de riesgo, el punto de aprobación y las comprobaciones necesarias antes de que un agente inicie un cambio. Descargar la hoja de trabajo de riesgo de cambios para agentes de IA.

Fuentes que revisé

Mi jornada cambió no porque dejara de escribir código, sino porque empecé a precisar mejor qué debía construirse. Dentro de un límite claro, el modelo puede actuar; fuera de él, decide una persona. Para mí, la ingeniería de harness consiste menos en hacer más fuerte al modelo y más en volver visible hasta dónde merece la pena delegar.

Fuentes y referencias

Páginas públicas usadas para contrastar hechos reportados, documentación oficial, contexto de política, información de producto y afirmaciones que pueden cambiar.