[nevrai]
· 8 min de lectura

Mi CEO de IA Trabaja Mientras Duermo

El martes pasado a las 2am, mientras dormia, mi factory de agentes de IA desplego una correccion de bug, corrio la suite de tests, comiteo los cambios con un mensaje descriptivo y me envio una notificacion por Telegram. Cuando desperte, la correccion estaba en produccion.

Esto no es hipotetico. Esto es Factory OS — mi sistema de orquestacion de agentes de IA personalizado construido sobre Claude Code. Asi es como funciona y lo que puede hacer realmente.

Que es Factory OS

Factory OS es un sistema de 15 roles de agentes de IA especializados, coordinados por un agente CEO/orchestrator. Cada rol tiene:

  • Un archivo de prompt con conocimiento de dominio, reglas y restricciones
  • Una asignacion de modelo (que LLM usar para este rol)
  • Limites de permisos (que puede y no puede hacer el agente)
  • Quality gates (verificaciones que deben pasar antes de que el trabajo sea aceptado)

Los agentes corren en sesiones de Claude Code. El agente CEO lee descripciones de tareas, las descompone en subtareas, genera agentes especialistas, revisa su output y gestiona el pipeline.

Los 15 Roles

RolQue HaceModelo
CEO/OrchestratorDelega tareas, revisa output, gestiona pipelineClaude Sonnet
BuilderEscribe codigo de aplicacion (Rails, Astro, Next.js)Claude Opus
QA TesterTesting a nivel de navegador via Chrome DevTools MCPClaude Sonnet
DevOpsDeployment, infraestructura, gestion de servidoresClaude Sonnet
Product ResearcherAnalisis de mercado, investigacion competitiva, analisis JTBDClaude Sonnet
SEO SpecialistOptimizacion de contenido, investigacion de keywords, SEO tecnicoClaude Sonnet
Landing BuilderLanding pages con copy enfocado en conversionClaude Sonnet
CTODecisiones de arquitectura, planificacion de tech stackClaude Opus
Senior RubyDesarrollo Rails con reglas de codificacion estrictasClaude Opus
Content WriterPosts de blog, documentacion, copy de marketingClaude Sonnet
Data AnalystInterpretacion de analitica, analisis de funnelClaude Sonnet
DesignerDecisiones de UI/UX, diseno de componentesClaude Sonnet
Security AuditorCode review para vulnerabilidadesClaude Sonnet
Performance EngineerOptimizacion, cache, load testingClaude Sonnet
TranscriberExtraccion de audio y speech-to-textClaude Sonnet

Las Reglas Que Lo Hacen Funcionar

Regla 1: El CEO Nunca Escribe Codigo

Esta es la regla mas importante. El agente CEO delega todo. Nunca abre un archivo y lo edita. Nunca corre tests directamente. Genera un agente Builder o QA para eso.

Por que? Porque cuando un solo agente hace todo, pierde contexto, comete errores descuidados y produce codigo inconsistente. La especializacion crea responsabilidad.

Regla 2: Cada Agente Lee las Reglas Primero

Antes de hacer cualquier trabajo, cada agente generado lee:

  1. El preambulo universal del agente (reglas compartidas)
  2. Su archivo de prompt especifico del rol
  3. El CLAUDE.md del proyecto (notas de arquitectura, convenciones, archivos clave)

Esto no es negociable. Incluso si el agente “ya conoce” el codebase, lee las reglas. Porque despues de la compactacion de contexto (cuando la conversacion se vuelve muy larga), el agente olvida todo. Las reglas son la memoria persistente.

Regla 3: Quality Gates Antes de Commit

Ningun codigo se comitea sin pasar:

  1. Smoke test (ruby bin/rails runner test/smoke_test.rb)
  2. Verificacion de consistencia (sin imports rotos, sin archivos huerfanos)
  3. Actualizacion de documentacion (CLAUDE.md se mantiene actualizado)
  4. Plan de rollback (podemos deshacer esto de forma segura?)

Si algun gate falla, el agente corrige el problema y re-ejecuta. No salta gates.

Regla 4: Limites de Permisos Estrictos

El Builder no puede desplegar a produccion. El DevOps no puede modificar logica de aplicacion. El QA Tester no puede cambiar codigo fuente. Cada agente opera dentro de su limite.

Esto previene el modo de falla mas peligroso: un agente “ayudando” haciendo algo fuera de su expertise.

CLAUDE.md: El Sistema Operativo

Cada proyecto tiene un archivo CLAUDE.md en su raiz. Esto no es documentacion — es el sistema operativo para los agentes que trabajan en ese proyecto.

El CLAUDE.md de AICPO tiene mas de 500 lineas. Contiene:

  • Vista general de arquitectura (framework, base de datos, hosting)
  • Modelo de datos con todas las tablas y columnas
  • Endpoints de API con formatos de request/response
  • Mapa de service objects (que hace cada servicio)
  • Diagramas de pipeline (flujo de datos a traves del sistema)
  • Lista de archivos clave (para que los agentes sepan donde buscar)
  • Comandos de desarrollo (como correr el servidor, tests, migraciones)
  • Release gate (checklist obligatorio antes de cada commit)

Cuando un nuevo agente se genera y lee CLAUDE.md, entiende todo el proyecto en segundos. Sin onboarding. Sin “me puedes explicar el codebase?” Solo lee el archivo y comienza a trabajar.

Un Ejemplo Real

Esto es lo que paso ayer. Queria agregar exportacion PDF al sistema de artefactos de AICPO.

  1. Le dije al CEO: “Agrega exportacion PDF para artefactos. Link publico, sin login requerido, listo para imprimir.”
  2. El CEO creo un desglose de tareas:
    • Base de datos: tabla artifact_pdf_links con token, document_id, snapshot de contenido
    • Modelo: ArtifactPdfLink con token auto-generado
    • Controller: Ruta publica GET /pdf/:token, sin autenticacion
    • Layout: HTML minimo listo para imprimir (oscuro en pantalla, B&W limpio en impresion)
    • API: Endpoints CRUD para crear y gestionar links
  3. El CEO genero un agente Builder con la tabla de tareas, criterios de aceptacion y referencias de archivos clave.
  4. El Builder escribio la migracion, modelo, controller, vistas y endpoints de API. Luego corrio el smoke test.
  5. Los tests pasaron. El Builder comiteo con un mensaje descriptivo.
  6. Revise el diff, aprobe y desplege.

Tiempo total: 25 minutos. Esfuerzo manual total: leer el diff y aprobar.

Lo Que los Agentes de IA No Pueden Hacer

No voy a pretender que esto es magia. Esto es con lo que los agentes todavia luchan:

Decisiones de producto. Los agentes pueden investigar, analizar y presentar opciones. Pero “deberiamos construir esta feature?” es un juicio humano. El agente CEO delega, no estrategiza.

Diseno visual. Los agentes pueden implementar un design system y seguir patrones. Pero crear una identidad visual original requiere gusto humano. Yo especifico la estetica, los agentes la implementan.

Arquitectura novedosa. Para patrones bien entendidos (CRUD, API, auth), los agentes son excelentes. Para arquitectura genuinamente novedosa, necesitan guia significativa. Son mejores ejecutando patrones conocidos que inventando nuevos.

Debuggear problemas de produccion. Los agentes pueden leer logs y sugerir correcciones. Pero el debugging real de produccion requiere entender comportamiento del usuario, estado de infraestructura y contexto de negocio que los agentes no tienen.

Saber cuando parar. Los agentes seguiran “mejorando” codigo eternamente si los dejas. El gold-plating es su modo por defecto. Necesitas criterios de aceptacion explicitos y condiciones de parada.

La Economia

Claude Code cuesta aproximadamente $75/M de tokens de output para Opus. Una feature tipica que le tomaria a un desarrollador humano 4-8 horas cuesta alrededor de $5-15 en tokens.

Compara eso con el tiempo de un desarrollador a $50-150/hora. Incluso en el extremo alto de los costos de tokens, los agentes de IA son 10-30x mas baratos que los desarrolladores humanos para trabajo de implementacion.

El detalle: todavia necesitas un humano para la direccion de producto, decisiones de diseno y revision de calidad. Los agentes de IA son amplificadores, no reemplazos.

Lo Que Estoy Construyendo Despues

Factory OS mismo esta evolucionando. Prioridades actuales:

  1. Mejor gestion de contexto. Las sesiones largas degradan la calidad. Estoy experimentando con archivos de memoria estructurados que sobreviven la compactacion de contexto.
  2. Ejecucion paralela de agentes. Actualmente los agentes corren secuencialmente. Correr Builder + QA en paralelo podria reducir el tiempo de ciclo a la mitad.
  3. Prompts que se auto-mejoran. Agentes que analizan sus propias fallas y mejoran sus archivos de prompt automaticamente.

El futuro no son equipos de ingenieria de 100 personas. Son makers solitarios con factories de agentes de IA, lanzando productos que antes requerian companias enteras.

Si quieres seguir el progreso, suscribete al newsletter. Comparto lo que funciona, lo que se rompe y lo que aprendo.