Поваренная книга вайбкодера: одна LLM в роли архитектора, ревьювера и тестировщика

Un desarrollador ruso publicó en agosto de 2026 en Habr una guía detallada sobre el desarrollo multi-agente con un único modelo de lenguaje — sin necesidad de adquirir infraestructura adicional ni de meses de configuración.

Qué es la «esquizofrenia del LLM»

El efecto básico sobre el que descansa todo el método: el mismo modelo que acaba de escribir una funcionalidad y quedó satisfecho con ella, en el rol de revisor, encuentra en ella tres bugs reales con escenarios de fallo. Un único conjunto de pesos — dos opiniones diametralmente opuestas sobre el mismo código.

Hechos clave del método:

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

La división no es un bug, sino un recurso arquitectónico: un revisor que no sabe que está mirando su propio código critica con más honestidad que cualquier compañero real.

Por qué el proceso debe vivir en un archivo

Las decisiones arquitectónicas tomadas por el modelo en el rol de arquitecto desaparecen del contexto en el momento en que el mismo modelo cambia al rol de desarrollador. Sin un plan registrado, el agente reinventa la rueda cada vez — gastando tokens en repetir lo ya hecho.

El autor insiste: cualquier decisión que deba sobrevivir a una sesión debe existir en un archivo, no en el diálogo ni en la memoria del modelo. Las skills — conjuntos de instrucciones de rol para cada uno de los cuatro roles — se almacenan allí y se cargan con cada cambio de rol.

«El proceso debe vivir en un archivo, no en la cabeza» — 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 multi-agente

La compañía sabe construirse a sí misma — esta es la principal conclusión práctica del artículo. Basta con darle al agente en el rol de arquitecto una descripción de la tarea: formará la estructura del proyecto, distribuirá las tareas entre los roles y creará los archivos de plan.

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 manualmente. El flujo de trabajo es el siguiente:

• Skills — instrucciones de rol que definen la «personalidad» del agente en cada rol
• Archivos de plan — decisiones registradas que sobreviven a cambios de sesión y contexto
• Ciclo de roles — arquitecto → desarrollador → revisor → tester, con repetición al detectar bugs
• Autoensamblaje — la estructura del proyecto la construye el propio agente-arquitecto, no el humano

«Accesible, sin enciclopedia — en un solo café» — así describe el autor el formato de su guía en

Habr.

Qué significa todo esto

El desarrollo multi-agente ha dejado de ser un experimento de laboratorio: una persona con un único modelo de lenguaje construye un equipo interno que se critica a sí mismo con más honestidad que la mayoría de los revisores reales. La principal barrera de entrada no es la infraestructura, sino la disposición a registrar el proceso en archivos.