La IA ejecuta. El humano diseña, prueba y asegura.
Lucid coding es vibe coding con el humano despierto: la misma velocidad, pero sabiendo en todo momento qué está haciendo el agente y dirigiéndolo. Es para programadores que ya trabajan con agentes de código y quieren hacerlo con método. Nace de un año de práctica diaria, medido sobre más de 21.000 prompts reales. Su palabra ritual es la que más se tecleó en ellos: «proceda».
Lo de la derecha tiene valor y se usa: la IA genera código y escribe tests. Pero cuando hay conflicto, gana lo de la izquierda.
Son la columna del método. Todo lo que viene después existe para sostenerlos. Se recuerdan con las cinco letras de LUCID, que valen igual en inglés y en español.
Se parte de código y arquitecturas que existen y que el programador ya conoce. Al agente se le entregan repos listos y herramientas ya programadas, para que use plantillas de código que ya funcionan en vez de hacer todo desde cero.
Es el alma del código. Aquí el programador pone la visión: qué hay que hacer y cómo hacerlo. Es donde vive su creatividad, y no se delega.
Siempre hacia adelante con la IA. En la ejecución, la IA manda: hace todo lo que puede, terminal y navegador incluidos, y no devuelve trabajo que podría hacer ella.
Plantillas de método ya hechas, una por tipo de construcción, como guía para la IA. Se traducen en reglas concretas y lineales que forman el harness duro del sistema. Cada error que se repite se convierte en una regla más.
QA de producto intensivo, sobre todo humano: cada elemento se prueba por separado y a mano. La IA automatiza solo los unit tests y las automatizaciones controladas. Las técnicas principales son manejar el navegador, depurar de forma controlada y usar la CLI para simular al usuario.
Aquí se sigue programando «a mano» y aquí va todo el tiempo de revisión disponible. Sobre una base sólida de estudio en seguridad informática, el humano elige los componentes y parámetros según la arquitectura, los costos y el negocio. La IA los implementa primero, junto con los unit tests y las simulaciones. Al final, el programador revisa el código a mano.
Nunca se delega al 100 % en la IA.
En desarrollo colaborativo, el equipo tiene que poder ver qué hace cada dev con la IA. Se conservan los logs de las sesiones y el registro de los prompts que se entregan a los agentes, junto con el commit que produjo cada uno.
Una política escrita define cómo se usa la IA en el proyecto: qué herramientas y modelos se permiten, qué datos y credenciales puede ver el agente y qué queda registrado. Así hay trazabilidad para auditar, sobre todo la seguridad del código y el uso de credenciales.
Sin registro no hay auditoría.
No por malicia: así funciona. Se equivoca con total confianza, toma atajos y declara terminado lo que no comprobó. Por eso el método parte de la sospecha, no de la fe.
Todo lo que el agente hace o dice se trata como hipótesis hasta ver la prueba. Hay que exigirle que compruebe, verifique y chequee, sobre todo en lo importante. «Listo» sin evidencia (salida del test, URL, versión desplegada) no cuenta.
Se le pide que haga las pruebas e2e y que revise producción. Así trabaja con el contexto que importa, lo que está corriendo de verdad, y no con lo que cree recordar.
Una vez que hay una base de código sólida, otro agente la ataca: rebate, busca bugs y fallas. Parte de un contexto limpio, sin la conversación ni las justificaciones del que construyó, y evalúa solo contra reglas de evaluación definidas de antemano.
El mismo agente que escribió el código defiende su trabajo. Uno nuevo no tiene nada que defender.
La unidad mínima es el Cambio: un prompt que termina en un commit. Los cambios forman sesiones, las sesiones forman hitos y los hitos hacen avanzar el producto.
Semilla → Propuesta → MVP → Producción → Pulido → Operación → Retiro. La Propuesta y el paso a Producción siempre los decide el humano.
Un resultado visible: un MVP, una feature en producción, un endurecimiento de seguridad.
Abre con Arranque y termina con Cierre.
Generación, Integración, Evaluación y Depuración, completas. Auditable por otra IA.
El agente parte de lo que está desplegado, no de su memoria.
Revisión del agente adversario, prueba manual de cada elemento, revisión de seguridad línea por línea si se tocó código sensible, y decisión: seguir, corregir o detener.
Los errores repetidos del hito se vuelven reglas o plantillas.
Entre Arranque y Cierre, el bucle es simple: el agente propone opciones numeradas, el humano responde por número y dice «proceda».
En un equipo de una persona, los tres sombreros humanos los lleva el mismo programador. Lo que nunca se hace es pasarle uno a la IA.
Elige bases y arquitectura, escribe las invariantes, prioriza y decide en cada compuerta.
Prueba a mano cada elemento: navegador, CLI simulando al usuario, debug controlado.
Elige componentes y parámetros de seguridad y revisa a mano todo código sensible.
Mantiene BACKLOG y ESTADO, propone opciones, reparte e integra ramas.
Hacen los cambios dentro de una plantilla, uno por rama, y cierran cada uno con commit.
Ataca el código desde un contexto limpio y con reglas de evaluación fijas: busca bugs, fallas y lo que el Guardián debe leer. Señala; no reemplaza.
| Archivo | Qué contiene | Regla |
|---|---|---|
CONTEXTO | Índice para el agente: stack, cómo deployar, reglas, links. En Claude Code es CLAUDE.md; en otros agentes, AGENTS.md | Corto. Si crece, se divide |
INVARIANTES.md | Arquitectura, marca, idioma, i18n, estilo, componentes de seguridad | Se escribe antes del primer cambio |
BACKLOG.md | Cambios pendientes, hechos y bloqueados, numerados | Se actualiza en cada Cierre |
ESTADO.md | Infraestructura, versiones, versión desplegada, ramas activas | Fuera del archivo de contexto |
BITACORA.md | Incidentes y lecciones fechadas | Lo que se repite sube a regla |
El agente trabaja siempre con un tope de contexto, y cada cambio tiene que completar su ciclo GIED dentro de él:
La regla estable: cada cambio cabe entero antes de la primera compactación. Con los modelos de hoy, unos 200k tokens suelen bastar. Si un cambio no cabe, se parte en dos; si la sesión se acerca al tope, se hace Cierre y se abre otra.
Gestión de tokens, medida: en el último mes el contexto por turno fue de 25k tokens (mediana) y 50k (p90); solo 10 sesiones pasaron de 200k. Aun así hubo 840 compactaciones, en el 52 % de las sesiones: no las causan cambios grandes sino sesiones largas que acumulan. Gestionar tokens es cerrar y abrir sesión a tiempo, no pedir más ventana.
Sin relleno. Lo permanente va al archivo de contexto o a una plantilla, no a cada mensaje.
Con la estructura del proyecto ya montada, cada prompt pide un solo cambio, lo más acotado posible. Otra IA tiene que poder auditarlo leyendo el prompt y el diff.
Una URL, un repo propio, el nombre técnico exacto y un caso de prueba. «Hazlo más moderno» no es un pedido.
Ante una decisión, el agente propone 2 o 3 caminos numerados y el humano responde por número. «Proceda» siempre con objeto: proceda con qué.
Pocas ramas activas, cada una con un propósito claro (una rutina, un autopilot, un ambiente) y la menor divergencia posible.
Con demasiadas ramas el agente se confunde: se guía por la descripción de la rama más que por los commits, y se le suman merges y divergencias que pasa por alto.
Si hay más de un agente en el repo, cada uno trabaja en su rama y su copia aislada (worktree), sin excepción. Se coordinan por archivos, no por memoria, y el merge lo decide el líder o el humano. Solo se paraleliza trabajo independiente.
Orquestación: el líder reparte encargos acotados; cada subagente parte con contexto limpio y devuelve un resumen, no el volcado de archivos. Las tareas laterales van a un fork para no bloquear el hilo principal, y el líder integra y verifica lo que vuelve.
Último mes: 1.022 subagentes lanzados (512 de propósito general, 339 forks, 69 de exploración), 204 mensajes entre agentes y ~2.490 operaciones con worktrees.
Antes de empezar se define qué credenciales usará el agente y cómo le llegan.
Algunos agentes tienen límites que ninguna instrucción levanta, como escribir contraseñas reales o pagar. Para eso, el agente deja todo listo hasta ese paso y el humano lo completa.
Procedimientos repetidos con éxito se guardan como plantillas o skills precargadas que el agente carga (arranque, cierre, deploy, QA en navegador, publicación). Al segundo uso exitoso, se guarda. El agente no reinventa; carga.
Último mes: ~9.000 acciones de navegador, pero solo ~30 invocaciones de skills y una sola skill de proyecto en disco. El procedimiento se reescribía en cada sesión; ese es el gap que cierra esta regla.
El hilo principal usa siempre el modelo más capaz. Los rápidos solo en subagentes de búsqueda, exploración o tareas masivas cuyo resultado se verifica después. Arquitectura, seguridad, depuración difícil y auditoría nunca bajan de modelo.
Último mes: ~99 % de 94.606 respuestas vinieron del modelo tope y ~0,5 % de uno rápido, siempre en subagentes.
Casi todas las correcciones observadas tienen la misma raíz.
| Antipatrón | Síntoma | Lo corrige |
|---|---|---|
| Backlog en la cabeza del agente | «¿qué queda?» todos los días | BACKLOG.md y Cierre |
| Sesiones gigantes y multi-tema | El agente compacta y olvida el plan | Regla 0 |
| «proceda» sin objeto | El agente adivina qué aprobaste | Regla 4 |
| Estética sin referencia | Correcciones de diseño en cada hito | INVARIANTES y regla 3 |
| Pedido vago que deriva | Se pide una tecnología y se construye otra | Regla 3 |
| Agente que devuelve trabajo | «hazlo tú» desde el humano | Pilar Proceda |
| Credenciales sin inventario | Llaves de dev que llegan a prod sin rotar | Regla 7 |
| Agente que no se loguea en dev | Bloqueos y trabajo devuelto al humano | Regla 7: decirle la etapa |
| Varios agentes en una misma copia, o demasiadas ramas | Colisiones y contexto confuso | Reglas 5 y 6 |
| Creerle al agente | «Listo» sin prueba; el bug aparece en producción | El agente: reglas 0 y 1 |
| El que construye se revisa a sí mismo | El agente defiende su propio código | Adversario con contexto limpio |
| Seguridad delegada a la IA | Nadie leyó el código de auth | Pilar Seguridad |
Crear los cinco archivos, escribir las INVARIANTES, definir variables de entorno, vault e inventario de credenciales y guardar las plantillas de arranque y cierre.
Cada prompt termina en commit, cada sesión cierra antes de compactar y cada hito pasa por la compuerta. Las fricciones van a la BITÁCORA.
Contar en tus transcripts: compactaciones por sesión, «¿qué queda?», correcciones de diseño y prompts que terminan en commit. Compararlo con antes y ajustar.
| Señal de que funciona | Meta |
|---|---|
| Compactaciones por sesión | 0 |
| Prompts que terminan en commit | ≥ 80 % |
| «¿Qué queda?» por semana | 0 |
| Ramas activas por repo | ≤ 3 |
| Código sensible con revisión humana | 100 % |
| Credenciales de dev fuera del inventario | 0 |
| Commits de IA sin prompt ni log trazable | 0 |
Lucid coding sale del trabajo de un solo programador durante un año, con todo el historial medido: 21.310 prompts tecleados entre noviembre de 2025 y octubre de 2026, en 1.548 sesiones y 195 proyectos, más los 135 archivos de contexto. Las compactaciones salen de los transcripts que la herramienta conserva, el último mes. Los conteos se hicieron por expresiones regulares y son aproximados. Cada regla de esta guía sale de estos datos. Mide los tuyos y compara.
| Señal | Medida | Qué reveló |
|---|---|---|
| Mensajes de 3 palabras o menos | 27 % | El humano dirige; no especifica |
| «proceda» y variantes | ~1.230 | Aprobar es el acto principal |
| «¿qué queda?» / «¿cerramos?» | ~410 | El backlog vivía en el agente |
| Compactaciones en el último mes | 840 | Una cada ~6 prompts; el 52 % de las sesiones compactó: sesiones demasiado largas |
| Quejas de diseño, logo, i18n | ~360 | Requisitos que nunca se escribieron |
| «Hazlo tú» | ~22 | La frontera de autonomía no estaba explícita |
| Archivo de contexto más grande | 226 KB | La memoria del agente crecía sin techo |
Lo que mejor funcionó, con casi cero correcciones después: responder por número a opciones numeradas, pedir 3 propuestas y elegir una, dar una URL o un repo propio como referencia, nombrar la técnica exacta con un caso de prueba y convertir cada sesión exitosa en un procedimiento escrito. Con ese bucle, un producto SaaS completo pasó de idea a producción en 17 horas y un bot de despliegue en un día.