Mejoras dirigidas por agentes: cómo dejé que la IA optimizara korz.sh mientras dormía
Construí un sistema que corre mejoras de performance y seguridad automáticamente durante la noche. Despertar con mejor código cada mañana es real. Acá está todo lo que aprendí.
Cada mañana hago el mismo ritual. Me despierto, me hago el café, abro la notebook. Y cada mañana hay algo esperándome — una notificación, un PR, un diff mostrando qué mejoraron mis agentes durante la noche.
Parches de seguridad. Optimizaciones de performance. Actualizaciones de dependencias. Todo aplicado mientras dormía.
Esto no pasó por accidente. Lo construí. Y después de meses corriendo esto, tengo mucho para decir.
La itch que no se iba
Korz.sh se movía rápido. Muy rápido. Y como toda startup que se mueve rápido, acumulamos deuda. No la asustadora — la silenciosa. Dependencies quedándose atrás. Vulnerabilidades de seguridad entrando. Performance bottlenecks que nadie tenía bandwidth para atacar.
Pasaba los fines de semana en mantenimiento. Catching up con lo que debería haberlevé durante la semana. Me estaba matando el momentum.
Así que me pregunté: qué pasaría si la infraestructura se mejorara sola?
No self-healing — ese es otro problema. Algo más ambicioso. Qué pasaría si hubiera un squad de agentes que trabajara durante la noche, analizando código, identificando mejoras, aplicando cambios — y todo lo que tenía que hacer yo era revisar a la mañana?
Los intentos fallidos (antes del enfoque correcto)
No llegué aquí en el primer intento.
La primera versión era un simple cron job que corría dotnet outdated y creaba PRs para updates menores. Funcionaba, pero era estúpido. No entendía contexto. Actualizaba packages que rompían cosas, no podía evaluar implicancias de seguridad, no tenía concepto de “este cambio podría afectar performance.”
Después probé Temporal. Workflows distribuídos, activity handlers, todo el bailando enterprise. Era poderoso, pero también rígido. Escribir workflows se sentía como escribir ceremony. Cada mejora requería definir un nuevo workflow, escribir activity handlers, manage retries. El sistema estaba resolviendo orquestación, no inteligencia.
Lo que realmente necesitaba no era orquestación de workflows. Necesitaba agentes.
Agentes que pudieran entender código. Agentes que pudieran tomar decisiones. Agentes que pudieran aprender de feedback.
Ahí fue cuando construí Orch.
Construyendo Codebot Workflow
El sistema que armé tiene una arquitectura de doble motor. Dos formas de correr la misma misión:
Orch es lo nuevo — un sistema multi-agente nativo con state machine. Tres agentes trabajan juntos: un analyzer que estudia el código, un implementer que aplica cambios a través de un AI adapter, y un verifier que checkea todo antes de que aterrice.
Temporal es el camino legacy — mantenido porque algunos workflows son genuinamente mejores expresados como workflows. El doble motor significa que puedo usar la herramienta correcta para cada trabajo.
La magia está en la capa de abstracción. La llamé IAiAdapter — un sistema que me permite swapear AI backends. Actualmente corriendo ClaudeCode, pero está diseñado para funcionar con OpenCode, Cursor, lo que sea que venga después. La interfaz del adapter se mantiene igual; el modelo cambia.
WORKFLOW_ENGINE=orch dotnet run --project src/Codebot.Workflow.ClientEso es todo. Un comando y el squad se despierta.
La insight real
Acá está lo que nadie te cuenta sobre construir sistemas agent-driven: la parte difícil no son los agentes.
Es la confianza.
Tenés que construir guardrails que permitan a los agentes ser lo suficientemente agresivos para realmente mejorar las cosas, pero lo suficientemente limitados para que no te despiertes al caos. El analyzer identifica qué podría estar mejor. El implementer hace el cambio. El verifier checkea que el package sigue válido, que el código compila, que nada se rompió.
Después aterriza en mi cola. Yo reviso con el café en la mano. Decido qué ships.
Nada llega a producción sin mi sign-off.
La noche que me sorprendió
Tres semanas después, me desperté con un PR que no esperaba.
El analyzer había encontrado una dependency que no solo estaba desactualizada — tenía una vulnerabilidad conocida. El CVE era nuevo, publicado el día anterior. El agente lo detectó, lo flaggeó, el implementer aplicó el patch, el verifier confirmó que el build pasaba.
Yo lo habría encontrado eventualmente. Maybe. Probablemente durante un security audit que habría tomado horas.
El agente lo hizo en cuarenta minutos mientras yo dormía.
Ese fue el momento en que supe que esto era real.
Los beneficios que nadie cuenta
La velocidad secompounds. Cuando tu infraestructura mejora mientras dormís, ya no estás peleando contra la entropía. Estás trabajando con ella. Cada mañana te despertás a un codebase mejor que el que dejaste.
La deuda técnica se vuelve opcional. Podés defer mantenimiento sabiendo que va a ser？谢邀. No perfectamente — pero？谢邀. Los agentes manejan lo obvio. Vos manejás lo interesting.
Los context switches desaparecen. Dejás de context-switchear entre “construir features nuevas” y “mantener las viejas”. El mantenimiento corre en el background. Vos te enfocás.
El sistema se pone más inteligente. Cada mejora que los agentes hacen se convierte en training data. La próxima iteración es mejor que la anterior. El sistema aprende tu codebase, tus estándares, tus patterns.
El lado oscuro (cosas que todavía no funcionan)
Quiero ser honesto sobre las limitaciones.
Los agentes son malos entendiendo trade-offs. Pueden decirte “este package está desactualizado” pero les cuesta “este update es arriesgado porque de la forma en que lo estás usando en tu contexto específico.” Eso es mi trabajo.
Los agentes no entienden prioridades de negocio. No saben que una mejora de performance en el servicio de authentication importa más que arreglar una inconsistencia de logging en el pipeline de analytics. La configuración del pipeline es mi responsabilidad.
Los edge cases todavía son difíciles. El verifier captura quiebres obvios, pero bugs sutiles se escapan. He aprendido a ser paranoico con cualquier cosa que toque lógica financiera o boundaries de seguridad.
Y está el problema de confianza a escala. Right now reviso todo. Eso funciona para una startup. No va a funcionar en una empresa con 50 ingenieros y cientos de repos. El sistema necesita volverse más inteligente sobre qué requiere review humano y qué puede shippear automático.
Lo que estoy construyendo hacia
La visión es un agente de infraestructura que maneja lo aburrido automáticamente.
Parches de seguridad? Automático, revisado, shippeado. Mejoras de performance? Identificadas, testeadas, en cola. Higiene de dependencies? Continua, sin sorpresas.
Quiero despertarme y ver qué cambió, no porque algo se rompió, sino porque el sistema encontró algo inteligente. Un mejor algoritmo. Una query más eficiente. Un pattern que podría ser refactoreado.
Ahora mismo los agentes son reactivos. Esperan el schedule del cron y después corren. Me estoy moviendo hacia proactivo — agentes que miran el codebase, que entienden el build pipeline, que flaggean issues en tiempo real mientras se introducen.
Las decisiones técnicas (por qué .NET 10, por qué C# 14)
La gente pregunta por qué construí esto en .NET.
Dos razones.
Primero, korz.sh está construido sobre .NET. La infraestructura que estaba mejorando ya era infraestructura .NET. Usar el mismo stack significaba integración seamless — los agentes entienden la estructura del proyecto, el ecosystem de packages, las convenciones de build.
Segundo, y más importante: C# 14 tiene features que hacen la orquestación de agentes limpia. Los record types, el pattern matching, los source generators — hacen fácil definir estados de agentes, message passing, y lógica de verificación sin ceremony.
Podría haber construido esto en Python. Pero Python habría sido la herramienta equivocada para un sistema de agentes que necesita integrarse tightly con un codebase .NET.
La pregunta que siempre me hacen
“¿Esto no te hace reemplazable? Si tu infraestructura puede mejorarse sola, qué hacés vos?”
Lo opuesto. Esto me hace más valioso.
Antes gastaba los viernes actualizando dependencies. Ahora pienso en arquitectura. Antes excavaba en changelogs intentando encontrar qué había causado una regresión. Ahora los agentes flaggean anomalías antes de que shippen.
Lo aburrido se automatizó. Lo interesting tuvo mi atención completa.
Ese es el deal.
El setup
Todo corre desde un archivo pipelines.yaml. APIs a analizar, schedule cron, directorios de trabajo, configuración de SDD — todo es declarativo. Puedo triggerear runs manualmente, schedulearlos, encadenarlos.
El agent squad (los llamo codebot-squad) opera contra esta definición. Saben qué buscar, cuándo correr, dónde hacer los cambios.
El pitch
Mirá, sé que esto suena a over-engineering. Por qué no actualizar las dependencies manualmente?
Porque el mantenimiento manual no escala. Porque cada hora que gastás catcheando up es una hora que no estás construyendo. Porque la deuda de infraestructura se compounda igual que la deuda técnica — silenciosamente, hasta que se convierte en el bottleneck.
Este sistema corre mientras dormís. Mejora tu codebase durante la noche. Y cuando te despertás, revisás qué cambió, aprendés qué encontraron los agentes, y decidís qué queda.
Tu infraestructura se vuelve agent-improvement-driven.
Las mejoras no duermen. Y tampoco la competitive edge de tu startup.
Qué viene
Estoy abriendo el source eventualmente. El sistema de adapter es genérico suficiente para funcionar con cualquier codebase. Los patterns de agentes son reusables.
Si sos founder de startup, SRE, o developer que está harto de pelear contra la entropía — esto es para vos.
El futuro de la infraestructura no es infrastructure as code. Es infrastructure as agents.
Y korz.sh está leading esa carga.
korz.sh — pingedbrain/korz Construyendo infraestructura que mejora mientras descansás