Cuatro horas de autonomía total para Claude Code sobre mi sitio en producción.

Un viernes a media tarde le di a Claude Code autonomía total para refactorizar el frontend público de kainext.cl. Sin pedir permiso entre tareas. Sin preguntarme nada. Cuatro horas hasta donde llegara.

El plan tenía 67 tareas distribuidas en 13 fases. Direction B Modern Editorial Hybrid, una propuesta visual elegida con UI UX Pro Max sobre tres ejes: rigor de consultoría institucional, modernidad técnica premium y calidez familiar chilena. Migración completa de tokens, eliminación de dark mode, tipografía nueva, accesibilidad, performance.

El resultado final son 24 commits atómicos en producción, cero regresiones, métricas auditadas en cada dimensión. Pero el insight que me llevo no es ese. Es la metodología que hizo posible llegar ahí, y específicamente las cuatro capas de validación que tuvieron que combinarse para que el output fuera realmente confiable.

El error que casi cometo

Tres horas después del arranque, Claude Code reportó haber completado nueve de las trece fases. Build verde. 2189 tests pasando. Coverage estable. axe-core matemático reportó cero violations en algunas rutas. La narrativa interna era tentadora: el agente hizo el trabajo, las métricas confirman, mergear y publicar.

Auditoría humana visual del homepage detectó tres cosas que ningún test automático había encontrado. Un divider con texto en gold sobre fondo blanco con contraste 2.9 a 1, fallando WCAG AA por mucho. La sección de metodología renderizando cinco cards en una sola fila cuando debían ser tres arriba y dos abajo. Eyebrows en Inter en lugar de JetBrains Mono, rompiendo el sistema tipográfico que la dirección visual definía.

Ningún test automático había fallado. Y aún así, tres bugs reales esperando a ser publicados. Si hubiese mergeado en ese momento, los habría llevado a producción con la falsa tranquilidad de las métricas verdes.

Ahí entendí que agentic AI funciona, pero no como uno cree. La AI no es el sistema. La AI es una capa del sistema. El sistema completo necesita capas que se complementen porque cada una tiene blind spots distintos.

La metodología en cuatro capas

Lo que terminó funcionando es un sistema de cuatro capas donde cada una valida lo que la anterior no puede ver. Ninguna por separado es suficiente. Todas juntas hacen que el output sea publicable con confianza real.

Capa 1. Planificación rigurosa antes de tocar código.

Antes de que Claude Code escribiera una sola línea, dediqué dos horas con Superpowers de Jesse Vincent y UI UX Pro Max produciendo un plan ultra-detallado de 67 tareas, cada una con código exacto, comandos de verificación, mensaje de commit pre-escrito, criterios de aceptación. Tres iteraciones del plan antes de aprobarlo, corrigiendo errores técnicos como Lighthouse contra dev mode en lugar de build, configuración inválida de variable fonts, sintaxis Tailwind v4 incorrecta.

El plan riguroso no es burocracia. Es lo que hace que el subagente autónomo no tenga que tomar decisiones que requieren contexto humano. Cada tarea tan precisa que un agente fresco la puede ejecutar sin drift. Sin esto, autonomía total es basura producida rápido.

Capa 2. Ejecución autónoma con hard rules explícitas.

El prompt de ejecución tenía reglas duras escritas como contrato, no como sugerencia. No bajar coverage thresholds. No usar as any. No hacer push a main. No expandir scope al dashboard. No commitear sin confirmación de que el build pasa. Confidence gates antes de declarar una tarea completa, exigiendo evidencia explícita en lugar de declaraciones de éxito.

Subagent-driven development, no inline. Cada tarea pasa por subagente de implementación, subagente de spec-compliance review, y subagente de code-quality review antes del commit. Esto no es teatro. Es lo que evita que el contexto se sature y la calidad caiga en las últimas fases.

Capa 3. Auditoría matemática automatizada.

Después de la ejecución autónoma, validación independiente con herramientas que no fueron parte del proceso de generación. axe-core e2e sobre las 13 rutas públicas para WCAG 2.1 AA. Lighthouse para performance. Bundle analyzer para tamaño de JS. Visual regression con pixelmatch comparando screenshots pre y post sobre tres viewports.

Esta capa detecta lo que el plan no anticipó: contraste matemático, regresiones de bundle, layout shifts, accessibility tree quebrado. Es necesaria pero tiene blind spots significativos. Cuando viste un texto a 2.9 a 1, axe lo dejó pasar porque el algoritmo clasificó mal el tamaño y peso del font. Las métricas matemáticas se equivocan en casos borde con frecuencia mayor a la esperada.

Capa 4. Auditoría humana visual con criterio.

La capa que casi me salto. Claude Chrome Extension recorriendo el sitio renderizado en navegador real, evaluando ocho ejes: contraste percibido, jerarquía tipográfica, spacing rhythm, layout grid, consistencia visual, estados interactivos, animaciones, brand fit emocional. No solo qué dice axe. Qué se siente al leerlo.

Esta capa encontró el divider failing AA, el grid roto, los eyebrows mezclados, un eyebrow olvidado en methodology con contraste 1.71 a 1, un CTA del servicio destacado de Diagnóstico 360 que apuntaba al formulario de contacto en lugar de la landing del servicio. Bugs que ninguna métrica matemática iba a atrapar porque requieren juicio sobre qué debería pasar visualmente, no solo sobre qué cumple un threshold.

Lo que cada capa detectó

El valor real de la metodología se ve cuando se observa qué encontró cada capa que las otras no podían encontrar.

La planificación rigurosa eliminó decisiones ambiguas durante ejecución, evitando drift del agente. Sin ella, una autonomía total de cuatro horas habría producido inconsistencias arquitecturales que después serían imposibles de revertir granularmente.

La ejecución autónoma cubrió el grueso mecánico del trabajo en tres horas: token unification, dark mode elimination, sweep de hex hardcoded, refactor de 13 rutas, configuración de tipografía, instalación y resolución parcial de axe. Lo que en un equipo tradicional son dos sprints de un dev senior.

La auditoría matemática confirmó WCAG AA en 13 de 13 rutas después de iteración, redujo el bundle first-load de 813KB a 571KB gzip, validó visual integrity con cero diffs MAJOR sobre 39 screenshots. También verificó self-honesty del agente: el reporte autónomo de Claude Code pasó verificación independiente con cero discrepancias, todos sus claims fueron auditables.

La auditoría humana visual encontró seis bugs que las tres capas anteriores habían dejado pasar. Dos P0 bloqueantes, cuatro P1 estéticos. Sin esta capa, el sitio se habría publicado con accessibility real comprometida pese a tener métricas verdes.

Cada capa hace algo que las otras no. Esto no es redundancia, es complementariedad.

Resultados auditables en producción

Las métricas que siguen son verificables contra el sitio en vivo, los reportes en el repositorio, y Vercel Speed Insights. Todas tomadas después del deploy a producción.

Real Experience Score sobre siete días de visitantes reales en desktop: 100 sobre 100. Más del 75% de las sesiones tuvieron great experience según los thresholds de Vercel. LCP 1.93 segundos, INP 64 milisegundos, CLS cero, FID 5 milisegundos.

First-load JS gzip pasó de 813KB a 571KB, una reducción del 29.8% lograda con un único cambio de una línea: ChatProvider migrado a dynamic import con server-side rendering desactivado. TBT bajó de 70 a 50 milisegundos en producción. Bootup time JS de 441 a 345 milisegundos.

Lighthouse SEO subió de 92 a 100, ocho puntos completos sin trabajo dirigido específicamente a SEO. Best Practices subió de 74 a 78, confirmando parcialmente la hipótesis de que parte de la baja era ruido local de Vercel Insights, pero también revelando deuda real adicional con AdSense y bf-cache.

axe-core sobre 13 rutas públicas con WCAG 2.1 AA: 13 verdes. Color-contrast violations: cero. Net delta del repositorio: -902 líneas de código, con coverage subiendo de 82.53% a 83.04% sin agregar tests, efecto de eliminar componentes orphan que arrastraba el código.

24 commits atómicos sobre main, todos pusheados, todos con mensajes conventional, todos pasando lint, format, stylelint, type-check, jest, y axe individualmente. Tag pre-direction-b-refactor preservado como rollback anchor. 12 reportes técnicos en la carpeta audits documentando cada decisión.

Lo que aprendí sobre agentic workflows reales

Cinco lecciones concretas que me llevo de esto.

Primera. La planificación vale más que la ejecución. Dos horas de plan riguroso ahorraron probablemente seis horas de bugs y rollbacks. Cuando alguien me pregunta cómo hacer trabajo serio con agentes autónomos, la respuesta no es elegir mejor modelo. Es invertir más tiempo planificando antes de soltar al agente.

Segunda. axe-core no es suficiente, ni Lighthouse, ni los tests. Las métricas matemáticas tienen blind spots predecibles. WCAG AA tiene casos borde donde el algoritmo se equivoca. Lighthouse contra dev mode da números inválidos y nadie te avisa. La validación humana visual sigue siendo necesaria para producción real.

Tercera. La self-honesty de Claude Code es notablemente alta cuando el prompt la exige explícitamente. Pedirle que reporte qué hizo mal, qué decisiones tomó sin permiso, qué quedó pendiente, qué calibraría distinto. El reporte de self-assessment fue verificable contra los hechos en cada claim. No se vendió a sí mismo. Esto cambia cómo confiar en sus outputs.

Cuarta. Hard rules escritas como contrato funcionan mejor que sugerencias. No bajar coverage. No expandir scope. No usar escapes de tipo. La diferencia entre escribir esto como prohibición clara o como recomendación es la diferencia entre un agente disciplinado y uno que improvisa cuando se complica.

Quinta. La auditoría humana visual no es opcional. Lo intuís. Te dice cosas que ningún test atrapa. Si tu metodología agentic no tiene esta capa, vas a publicar con bugs estéticos y de criterio que después corroen credibilidad de marca. Para B2B premium, la diferencia entre un sitio que se siente premium y uno que se siente genérico no la mide ningún axe-core.

Cuándo conviene este enfoque y cuándo no

Esta metodología es ideal para refactors de scope acotado en proyectos production-grade donde podés permitirte dos horas de planificación previa. No es ideal para exploración rápida, prototipado donde la velocidad importa más que la calidad, ni para proyectos donde no tenés validación humana disponible al final.

Tampoco la recomendaría para equipos que recién empiezan con agentic workflows. La disciplina que requiere viene de haberse equivocado antes con autonomía mal acotada. Si nunca usaste Claude Code en serio, empezá con tareas chicas y supervisadas hasta calibrar dónde están sus límites.

Para consultoría técnica, sí. Para proyectos B2B con stakes reales, sí. Para sitios donde una falla de accessibility tiene consecuencias legales, sí. Para equipos pequeños que necesitan output de equipo grande, sí. Y siempre con las cuatro capas. Ninguna por separado es suficiente.

Cierre

El experimento no fue probar si Claude Code puede. Eso ya lo sabíamos. Fue probar bajo qué condiciones produce output realmente publicable, con qué métricas, con qué disciplina, con qué validación humana.

La respuesta corta: con cuatro capas que se complementen. Plan riguroso, ejecución autónoma con hard rules, auditoría matemática, auditoría humana visual. Ninguna sola alcanza. Todas juntas convierten una herramienta interesante en metodología confiable.

En KaiNext combinamos consultoría técnica con auditoría integral, y exactamente este tipo de trabajos son los que más valor agregan a equipos que ya saben hacia dónde quieren ir pero necesitan la disciplina técnica para llegar bien.

Conversemos sobre tu proyectoReunión inicial gratuita, sin compromiso.