El recetario del vibe coder: una sola LLM como arquitecta, revisora y tester

Un desarrollador ruso publicó en agosto de 2026 en Habr una guía detallada sobre desarrollo multiagente con un único modelo de lenguaje, sin comprar infraestructura adicional y sin meses de configuración.

Qué es la «esquizofrenia de la LLM»

El efecto básico en el que se apoya todo el método es este: el mismo modelo que acaba de escribir una funcionalidad y se ha quedado satisfecho con ella, en el papel de revisor encuentra tres bugs reales, con escenarios concretos en los que el código falla. Un único conjunto de pesos produce dos opiniones diametralmente opuestas sobre el mismo código.

Hechos clave del método:

• La compañía consta de cuatro roles: arquitecto, desarrollador, revisor y tester
• El cambio entre roles se hace mediante prompts de rol («skills»)
• El autor mantiene con este principio un proyecto real en producción, escrito por agentes casi sin código manual
• El primer paso no requiere escribir ni una sola línea de código a mano: la compañía se construye a sí misma

La división no es un bug, sino una técnica de arquitectura: un revisor que no sabe que tiene delante su propio código lo critica con más honestidad que cualquier colega humano.

Por qué el proceso debe vivir en un archivo

Las decisiones de arquitectura que toma el modelo en el papel de arquitecto desaparecen del contexto cuando ese mismo modelo pasa al rol de desarrollador. Sin un plan documentado, el agente reinventa la rueda cada vez y gasta tokens en repetir lo que ya está hecho.

El autor insiste: cualquier decisión que deba sobrevivir a una sesión tiene que existir en un archivo, no en el diálogo ni en la memoria del modelo. Los skills, es decir, los conjuntos de instrucciones de rol para cada uno de los cuatro papeles, se guardan en el mismo lugar y se cargan en cada cambio de rol.

«El proceso debe vivir en un archivo, no en la cabeza», es la tesis central de la guía publicada en

Habr.

El cambio de contexto entre roles lleva segundos; los acuerdos y decisiones acumulados no se pierden entre sesiones.

Cómo lanzar el primer proyecto multiagente

La compañía sabe construirse a sí misma, y ahí está la principal conclusión práctica del artículo. Basta con darle al agente en el rol de arquitecto la descripción de la tarea: él define la estructura del proyecto, reparte las tareas entre los roles y crea los archivos con los planes.

Según la descripción del autor en Habr, todo el ciclo, desde un repositorio vacío hasta código funcional con revisión y pruebas, transcurre sin una sola línea escrita a mano. El flujo de trabajo es el siguiente:

• Skills: instrucciones de rol que definen la «personalidad» del agente en cada papel
• Archivos de plan: decisiones documentadas que sobreviven al cambio de sesión y de contexto
• Ciclo de roles: arquitecto → desarrollador → revisor → tester, con repetición cuando se detectan bugs
• Autoensamblaje: la estructura del proyecto la construye el propio agente arquitecto, no una persona

«Accesible, sin enciclopedia: en lo que dura un café», así describe el autor el formato de su guía en

Habr.

Qué significa

El desarrollo multiagente ha dejado de ser un experimento de laboratorio: una persona con un solo modelo de lenguaje monta un equipo interno que se critica a sí mismo con más honestidad que la mayoría de los revisores humanos. La principal barrera de entrada no es la infraestructura, sino la disposición a dejar el proceso fijado en archivos.