- Comparte una metodología concreta para desarrollo de software con LLM usando un flujo de trabajo multiagente de arquitecto-desarrollador-revisor para mantener proyectos de decenas de miles de líneas con una baja tasa de defectos
- Más que la programación en sí, le interesaba construir cosas, y ahora que los LLM programan bien puede enfocarse en crear
- Más que la capacidad de escribir código, ahora son mucho más importantes las habilidades de ingeniería para diseñar la arquitectura del sistema y tomar decisiones correctas
- Mezcla distintos modelos para mejorar la calidad de la revisión de código y aprovecha las fortalezas y debilidades de cada modelo separándolas por rol
- Publica una sesión completa real agregando una función de correo electrónico, y documenta en detalle el proceso de colaboración con LLM guiado por humanos, desde las decisiones de arquitectura hasta QA
Ventajas de construir con LLM
- Pensaba que le gustaba programar, pero en realidad lo que le gustaba era construir cosas; ahora que los LLM programan bien, está creando sin parar
- Alrededor del lanzamiento de Codex 5.2, y más recientemente con Opus 4.6, se volvió posible escribir software con una tasa de defectos muy baja. Puede incluso ser significativamente menor que al programar todo a mano
- Antes, tras 2 o 3 días de trabajo el código terminaba en un estado imposible de mantener, pero ahora puede trabajar durante semanas seguidas y hacer crecer con estabilidad decenas de miles de líneas de código útiles
- Las habilidades de ingeniería no dejaron de servir, sino que se desplazaron: en vez de la capacidad de escribir el código correctamente, lo central es el criterio para arquitectar bien el sistema y hacerlo utilizable
- En proyectos donde conoce bien la tecnología base (por ejemplo, backend), no hay problema incluso con decenas de miles de SLoC, pero en tecnologías que no domina (por ejemplo, apps móviles) el código aún termina desordenado por la acumulación de malas decisiones
- En la etapa inicial de los LLM (después de davinci) había que revisar cada línea de código; en generaciones posteriores, a nivel de función; ahora la tendencia es que solo haga falta verificar la arquitectura completa. El próximo año quizá ni eso sea necesario
Proyectos hechos de esta manera
- Stavrobot: asistente personal con LLM centrado en seguridad. Gestiona calendario, evalúa disponibilidad, investiga, se amplía a sí mismo escribiendo código, envía recordatorios y administra tareas domésticas de forma autónoma. Su valor principal no está en una sola función estrella, sino en resolver miles de pequeñas molestias
- Middle: un pequeño dispositivo colgante que graba notas de voz, las convierte en texto y las envía por webhook. Lo importante es poder llevarlo siempre encima y usarlo sin fricción
- Sleight of Hand: un proyecto artístico de reloj de pared que hace tic-tac de forma irregular a nivel de segundos, pero siempre es exacto a nivel de minutos. Ofrece varios modos: tics variables de 500ms a 1500ms, cambios de velocidad difíciles de percibir seguidos de pausas aleatorias, correr al doble de velocidad y luego esperar 30 segundos, etc.
- Pine Town: un lienzo multijugador infinito donde cada persona recibe un pequeño terreno para dibujar, un proyecto interactivo de pradera
- Todos estos proyectos fueron hechos con LLM, y aunque nunca ha leído la mayor parte del código directamente, sí conoce bien la arquitectura y el funcionamiento interno de cada proyecto
Herramienta de harness
- Está usando OpenCode como harness, y también tuvo una buena experiencia con Pi
- Dos requisitos esenciales del harness:
- Poder usar varios modelos de distintas empresas: la mayoría de los harness de primera parte (Claude Code, Codex CLI, Gemini CLI) solo soportan sus propios modelos, así que no cumplen este requisito
- Que agentes personalizados puedan invocarse entre sí de forma autónoma
Por qué hace falta usar múltiples modelos
- Puede pensarse en un modelo específico como si fuera una persona: incluso reiniciando el contexto, tiende a mantener las mismas opiniones, fortalezas y debilidades
- Pedirle a un modelo que revise el código que él mismo escribió es casi inútil por su tendencia a estar de acuerdo consigo mismo, pero asignar la revisión a otro modelo mejora mucho la calidad
- Actualmente, Codex 5.4 es ideal para revisión por ser minucioso y exigente; Opus 4.6 coincide bien con las decisiones que él mismo tomaría; y Gemini 3 Flash a veces propone soluciones que otros modelos pasan por alto
- Para obtener resultados óptimos, hace falta mezclar todos los modelos
Flujo de trabajo: arquitecto → desarrollador → revisor
- El flujo de trabajo se compone de arquitecto, desarrollador y 1 a 3 revisores. Están configurados como agentes de OpenCode (archivos de skills)
- Tres razones para usar múltiples agentes:
- Ahorrar tokens usando un modelo caro (Opus) para planificación y uno barato (Sonnet) para escritura de código
- Al revisar con distintos modelos, cada uno detecta problemas diferentes
- Permite separar permisos por rol (por ejemplo, solo lectura vs. escritura)
- Usar dos agentes con el mismo modelo y los mismos permisos no aporta mucho: es como una sola persona usando sombreros distintos
- Los archivos de skills los escribe manualmente. Si le pides a un LLM que escriba skills, es como pedirle a alguien que redacte “cómo ser un gran ingeniero” y luego devolverle esas instrucciones diciéndole “ahora conviértete en uno”
Rol del arquitecto
- El arquitecto (actualmente Claude Opus 4.6) es el único agente con el que conversa directamente, y debe ser el modelo más potente
- Presenta una meta muy específica de función o corrección de bug, y mantiene una conversación de hasta 30 minutos hasta fijar objetivos, restricciones y trade-offs
- El resultado es un plan bastante de bajo nivel, a nivel de archivos individuales y funciones
- No es simple prompting, sino un proceso de formación del plan con ayuda del LLM. Corrige mucho cuando el LLM se equivoca o propone algo distinto a su enfoque, y esa es su principal contribución para que el proyecto sea “suyo”
- Está configurado para no empezar a implementar hasta que él diga explícitamente la palabra “approved”. Algunos modelos tienden a lanzarse a implementar apenas creen haber entendido
- Tras la aprobación, el arquitecto divide el trabajo en tareas, lo documenta en detalle en un archivo de plan y llama al desarrollador
Rol del desarrollador
- El desarrollador puede usar un modelo más débil pero más eficiente en tokens (Sonnet 4.6)
- Como el plan deja poco margen de discreción, su rol es estrictamente implementar los cambios del plan
- Cuando termina la implementación, llama a los revisores
Rol de los revisores
- Cada revisor examina y critica de forma independiente el plan y el diff
- Siempre usa como mínimo Codex; a veces agrega Gemini, y en proyectos importantes también suma Opus
- El feedback vuelve al desarrollador, y si hay desacuerdo entre revisores, se escala al arquitecto
- Opus destaca para elegir el feedback correcto, y a veces ignora observaciones demasiado quisquillosas cuya probabilidad de causar un problema real no justifica el costo de implementación
Enfoque general y modos de fallo
- Con este método puede entender todas las decisiones por encima del nivel de función y usar ese conocimiento en trabajos posteriores
- Cuando el LLM tiene un punto ciego y omite un elemento específico del codebase, basta con indicarle “debes usar Y” para que reconozca la existencia de Y y cambie a un mejor enfoque
- Si no está familiarizado con la tecnología, no detecta las malas decisiones del LLM, y sobre ellas se acumulan decisiones equivocadas hasta llegar a un estado sin solución
- Un patrón típico de fracaso es repetir “el código no funciona”, y que el LLM responda “¡Entendido! Lo corregiré” para terminar rompiéndolo todavía más
- Por eso, incluso cuando no domina una tecnología, intenta entender lo más posible en la etapa de planificación
Sesión real: agregar soporte de email a Stavrobot
- Publica la transcripción completa de una sesión real anotada; omitió llamadas a herramientas y partes verbosas, pero mantuvo intactos el diálogo y el proceso de toma de decisiones
- Conversación inicial: presenta un objetivo de alto nivel (“quiero agregar soporte de email a este bot”) → el LLM lee el código, identifica el patrón actual (webhook entrante → enqueueMessage → procesamiento por LLM → respuesta) y plantea preguntas de diseño
- Método de entrada (polling IMAP, webhook, servidor SMTP), método de salida, si será bidireccional, arquitectura (contenedor separado vs. in-process), manejo de email HTML, seguimiento de hilos, adjuntos, etc.
- Decisiones de diseño: entrada con webhook de Cloudflare Email Worker, salida con cliente SMTP, conversación totalmente bidireccional, procesamiento in-process, conversión a Markdown, tratamiento de emails como independientes, soporte para adjuntos
- Propuesta de diseño detallado del LLM: presenta 7 preocupaciones y diseños concretos sobre parsing MIME (usando mailparser), autenticación del webhook (shared secret), necesidad de asunto saliente, manejo de emails solo HTML, identidad de la dirección From, emails reenviados y adjuntos salientes
- Propone simplificar el payload del Worker a
{ from, to, raw } y parsearlo del lado del servidor
- Organiza la estructura de config, el flujo de entrada/salida, la lista de archivos a modificar y los no-objetivos explícitos (YAGNI)
- Refinamiento del plan: el humano señala omisiones como actualizar README.md y config.example.toml, y quitar la validación E.164 en la página de allowlist de email → el LLM lo integra
- División en 6 tareas: config/dependencias, allowlist, validación UI/backend de allowlist, email entrante, email saliente, README/tests
- Mejora adicional: propone hacer que los campos SMTP sean opcionales para que el email entrante funcione incluso sin configuración SMTP → se implementa
- Bug encontrado en QA: se descartaban mensajes porque el email del propietario no estaba registrado → la causa era que
seedOwnerInterlocutor omitía el canal de email → se corrige
- Propuesta de mejora de código: refactorizar para recorrer una lista compartida de canales en vez de usar bloques
if hardcodeados por canal. Tras discutir el caso especial de conversión numérica de Telegram, deciden aplicar el loop solo en seedOwnerInterlocutor y mantener getOwnerIdentities porque la diferencia de tipos ahí es esencial
- Allowlist de email con wildcard: se agrega soporte para wildcards a nivel de dominio como
*@example.com. Era necesario para un caso real donde usa direcciones de email descartables
- Consideración de seguridad: para evitar ataques como
"me@mydomain.com"@evildomain.com, convierten * en [^@]* para impedir que cruce el límite de @
- También se soportan wildcards parciales como
myusername+*@gmail.com
- El humano señala que al usar regex hay que escapar todos los demás caracteres de la dirección de email
- Verifican que los wildcards funcionen tanto en el campo del propietario como en la allowlist, usando la misma función helper
matchesEmailEntry
- Toda la implementación tomó aproximadamente 1 hora
Epílogo
- No es una configuración extremadamente llamativa, pero funciona muy bien y está satisfecho con la confiabilidad del proceso
- Lleva casi un mes ejecutando Stavrobot 24/7 y ha sido muy estable
10 comentarios
Así como hace unos 20 años, con la moda de los editores web y los blogs hechos en serie, se produjeron en masa páginas personales o posts que nadie iba a ver, en la era de la inteligencia artificial está ocurriendo algo parecido; aun así, creo claramente que crear apps personalizadas y compartir ese proceso o esa rutina es un recurso excelente y muy valioso. Personalmente, pienso que en esta época no se trata de crear con IA una app o un servicio que genere dinero, sino de hacer fácilmente las herramientas personalizadas que uno necesita para aumentar la productividad.
La verdad, parece que con los humanos también pasa algo parecido. ¿No será por eso que los humanos también necesitamos buscar diversidad...?
Como es un modelo de lenguaje, tiene sentido que un modelo caro se encargue de la planificación.
> Usar el modelo caro (Opus) para la planificación y el modelo barato (Sonnet) para escribir código ahorra tokens
Mucha gente suele hacerlo al revés, usando Sonnet para planificar y Opus para implementar el código, pero aquí es al contrario.
Yo también pongo a
opusycodexa pelotear incluso desde la etapa de planificación.Le encargo la codificación a
opus, y la revisión de código a otroopusy acodex.Lo que siento al hacer esto es que, tanto la IA como las personas, parecen ser muy buenas para criticar a los demás...
https://code.claude.com/docs/ko/model-config#opusplan-model-config
Yo también lo tengo configurado con
opusplande Claude y lo estoy usando.En la configuración básica de Oh my opencode, la planificación la hace opus y la implementación la realiza un modelo más liviano.
A mi alrededor, suelen planificar/diseñar con Sonnet y luego escribir el código con GLM-5..
Yo también hago la planificación con Sonnet y la implementación del código con Opus, pero quizá el método del autor sea más eficiente.
Yo también planifico con Opus y hago la revisión con Codex high; la programación real la hago con sonet o codex medium.