Twill.ai y el sueño de 'delegá a un agente, recibí un PR': yo ya lo viví y fue más raro de lo que parece

Eran las 11:47pm y tenía un PR abierto de un agente esperando merge. El pipeline estaba verde. Los tests pasaban. El código se veía prolijo. Y yo no tenía la menor idea de por qué había elegido esa implementación específica.

No estaba nervioso por el código. Estaba nervioso porque en diez minutos iba a apretar el botón de merge y el responsable técnico de ese PR iba a ser yo — alguien que no había escrito ni una línea.

Ahí entendí el problema real de los agentes que generan PRs. Y no es el que aparece en los pitch decks.

AI agents PRs automation: la promesa y lo que no dicen

Twill.ai acaba de salir de YC S25. La promesa es limpia: le mandás un issue, el agente lo lee, investiga el codebase, escribe el código y te manda un Pull Request listo para revisar. Sin fricción. Sin delegación a un dev senior que tiene diez cosas más en el backlog.

En el demo, es mágico. El agente lee el issue, navega el repositorio, entiende el contexto, escribe código que compila y abre el PR con una descripción razonable. El pipeline pasa. Parece que el problema está resuelto.

Y a nivel técnico, muchas veces sí está resuelto. Ese no es el problema.

El problema es lo que pasa después.

Lo que el pitch deck no menciona: responsabilidad epistémica

Cuando un desarrollador humano abre un PR, hay algo implícito: esa persona sabe por qué hizo lo que hizo. Si le preguntás en la review "¿por qué elegiste un mutex acá en vez de un channel?", te puede responder. Si hay un bug en producción a las 3am, esa persona puede debuggear porque tiene el modelo mental de su propia decisión.

Con un agente, ese modelo mental no existe en ningún lugar accesible.

Yo lo viví trabajando con Research-Driven Agents — sistemas donde el agente investiga antes de codear, similar a lo que describe mi post sobre agentes que leen antes de escribir. El resultado del código era notablemente mejor que vibe-coding puro. Pero la comprensión del código seguía siendo mía, si la tenía, o de nadie, si yo hacía merge sin entenderlo.

A eso le llamo responsabilidad epistémica del código generado: quién tiene el conocimiento de por qué existe cada decisión técnica en el codebase.

El experimento que me cambió la perspectiva

Durante tres semanas, usé un agente de coding para un proyecto side de automatización sobre PostgreSQL. Le pasaba issues descritos con precisión quirúrgica. Recibía PRs. Hacía review. Mergeaba.

Al final del sprint, el codebase funcionaba. Los tests cubrían los happy paths. Y yo podía explicar quizás el 60% de las decisiones de implementación.

El otro 40% era código que yo había leído pero no había entendido en profundidad. Lo suficiente para aprobar la review. No lo suficiente para debuggearlo a las 3am.

// Esto lo generó el agente. Yo lo aprobé.
// Tres semanas después no recordaba por qué usaba
// esta estrategia de retry específica y no exponential backoff
const retryWithJitter = async <T>(
  fn: () => Promise<T>,
  maxAttempts: number = 3,
  baseDelayMs: number = 100
): Promise<T> => {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (error) {
      if (attempt === maxAttempts) throw error;
      // Jitter decorrelacionado — el agente eligió esto
      // yo no cuestioné si era la decisión correcta para este caso
      const delay = Math.min(
        baseDelayMs * Math.random() * Math.pow(2, attempt),
        2000
      );
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
  throw new Error('Unreachable');
};

¿Era correcta la implementación? Sí. ¿Sabía yo por qué era correcta para ese contexto específico versus las tres alternativas que el agente podría haber elegido? No del todo.

Cuando el proyecto creció y tuve que modificar ese módulo, tardé el doble de lo que hubiera tardado si lo hubiese escrito yo desde cero.

Los gotchas reales de los agentes que generan PRs

1. El problema de la descripción del PR

Los agentes generan descripciones de PR razonables. Pero "razonable" no es lo mismo que "útil para entender las decisiones de diseño". Una descripción que dice "implementa retry logic para el cliente de base de datos" no te dice por qué eligió jitter decorrelacionado y no exponential backoff simple.

Esto se vuelve crítico en codebases donde la arquitectura tiene decisiones históricas con contexto. El agente no tiene acceso a la conversación de Slack de hace seis meses donde decidieron no usar una solución obvia por una razón específica.

2. El problema de la review superficial

Cuando revisás código que vos escribiste, hay un nivel de atención diferente. Sabés lo que querías hacer, entonces notás la diferencia entre lo que intentaste y lo que efectivamente lograste.

Cuando revisás código de un agente, el riesgo es reviewear sintaxis en vez de semántica. "¿Compila? ¿Pasan los tests? Merge." Eso no es code review, es validación superficial.

3. El problema del contexto distribuido

Cada PR de un agente es una decisión tomada en aislamiento. El agente no recuerda que en el PR de la semana pasada eligió una estrategia diferente para un problema similar. La coherencia arquitectural del codebase se convierte en tu responsabilidad exclusiva — con la carga adicional de que tampoco sos vos quien escribió el código anterior.

Esto se relaciona con algo que discutí cuando exploré si Git está preparado para un mundo de agentes: los sistemas de control de versiones están diseñados para rastrear quién escribió qué, no por qué el agente tomó esa decisión en ese momento con ese contexto.

4. El problema de la superficie de ataque invisible

Un agente que lee tu codebase para escribir código también está leyendo tus patrones de seguridad — los buenos y los malos. Si tu codebase tiene un patrón inseguro que "funciona", el agente va a replicarlo porque es consistente con el contexto.

Tuve un caso donde un agente replicó un patrón de manejo de errores que silenciaba excepciones específicas — algo que en el codebase original tenía una razón de ser bien documentada, pero que en el nuevo contexto era directamente peligroso. El código compilaba. Los tests pasaban. El bug estaba ahí, esperando.

Esto se vuelve especialmente relevante cuando pensás en verificación de código generado por IA — ni siquiera tenemos herramientas maduras para auditar qué fue generado por agentes y qué fue escrito por humanos en un codebase mixto.

5. El efecto acumulativo en el conocimiento del equipo

Este es el más silencioso y el más peligroso.

Si tu equipo empieza a mergear PRs de agentes de forma sistemática, el conocimiento profundo del codebase empieza a erosionarse. No de golpe — gradualmente. Cada PR que mergeás sin entenderlo al 100% es un pequeño déficit epistémico. Seis meses después tenés un codebase que "funciona" pero que nadie en el equipo puede explicar con confianza.

Es el opuesto del problema del conocimiento tribal: no es que el conocimiento esté en la cabeza de una sola persona. Es que no está en la cabeza de nadie.

Lo que Twill.ai promete vs. lo que el problema requiere

Soy directo: la tecnología detrás de estos agentes es genuinamente impresionante. Lo que describe Twill.ai — leer un issue, navegar el codebase, generar código contextualmente apropiado — es difícil de hacer bien y claramente hay trabajo serio atrás.

Pero el pitch de "delegá a un agente, recibí un PR" resuelve el problema de generación de código sin tocar el problema de responsabilidad sobre ese código.

Y en producción, la responsabilidad es el problema más caro.

Es similar a lo que pasó con los ORMs que "abstraían" la base de datos: funcionaban perfectamente hasta que necesitabas debuggear una query lenta a las 3am y el developer que había usado el ORM no sabía SQL. El agente es el ORM del código — una abstracción útil que crea dependencia de comprensión.

Interesante comparación con algo que exploré antes: cuando metí el historial de git de Linux en Postgres para análisis, lo que más me llamó la atención no fue el volumen de commits sino la densidad de contexto en los mensajes — cada commit humano explicaba por qué, no solo qué. Los PRs de agentes todavía no tienen esa densidad.

Lo que haría diferente

No digo "no uses agentes que generan PRs". Digo que hay condiciones bajo las cuales tiene sentido y condiciones bajo las cuales es deuda técnica disfrazada de productividad.

Tiene sentido cuando:

• El issue está completamente especificado y no deja espacio para decisiones de diseño
• El scope es pequeño y aislado (un test, un endpoint CRUD, un bugfix con causa identificada)
• El reviewer tiene contexto suficiente para entender por qué el agente eligió cada cosa
• Existe un proceso de documentación que captura las decisiones, no solo el código

Es deuda técnica cuando:

• El issue requiere decisiones de arquitectura
• El reviewer está bajo presión de tiempo y va a hacer merge sin entender el 100%
• Es el tercer PR del agente esta semana y el equipo perdió el hilo de qué escribió quién
• No hay proceso para capturar el contexto de las decisiones del agente

Lo que haría: exigirle al agente no solo el PR sino un documento de decisiones — Architecture Decision Record automatizado. No el código. Las alternativas que evaluó. Por qué eligió esta. Qué sacrificó. Qué asume del contexto.

Eso convierte el PR de un agente en algo revieweable de verdad. Y convierte la responsabilidad epistémica en algo transferible.

Sin eso, estás mergeando código de alguien que no podés llamar a las 3am.

FAQ: AI agents PRs automation

¿Qué es un agente de IA que genera PRs automáticamente? Es un sistema de IA que lee un issue o tarea en tu repositorio, analiza el codebase existente, escribe el código necesario para resolver el problema y abre un Pull Request listo para revisar — sin intervención humana en la fase de escritura. Herramientas como Twill.ai (YC S25), Devin, y varios agentes basados en Claude o GPT-4 hacen esto con distintos niveles de sofisticación.

¿Los PRs generados por agentes son confiables para producción? Depende del scope y del proceso de review. Para tareas acotadas y bien especificadas — bugfixes puntuales, tests adicionales, endpoints CRUD simples — la calidad técnica suele ser aceptable. El problema no es la confiabilidad del código sino la capacidad del equipo de entender las decisiones de implementación lo suficiente como para mantener ese código a futuro.

¿Cómo hago una code review efectiva de un PR generado por un agente? No reviewees solo sintaxis. Preguntate: ¿puedo explicar por qué el agente eligió esta implementación específica? ¿Qué alternativas existían? ¿Esta decisión es consistente con las decisiones previas del codebase? Si no podés responder esas preguntas, el PR no está listo para merge — necesitás más contexto, no más tests verdes.

¿Los agentes que generan PRs van a reemplazar a los desarrolladores? No en el horizonte visible, y específicamente por el problema de responsabilidad epistémica. Alguien tiene que entender el codebase en profundidad para tomar decisiones de arquitectura, debuggear problemas complejos y evaluar si las decisiones del agente son apropiadas para el contexto específico. Los agentes reducen el costo de generación de código, no el costo de comprensión de software.

¿Qué riesgos de seguridad introduce el uso de agentes que leen mi codebase? Dos riesgos principales: primero, el agente puede replicar patrones inseguros existentes en el codebase porque los percibe como "el estilo del proyecto". Segundo, si el agente tiene acceso a secretos o configuraciones durante su análisis, hay superficie de ataque en el pipeline de integración. Siempre revisá los permisos que le das al agente y qué partes del repositorio puede leer.

¿Tiene sentido para equipos pequeños o solo para empresas grandes? Para equipos pequeños el riesgo es mayor, no menor. En un equipo de 2-3 personas, cada developer tiene que poder mantener cualquier parte del codebase. Si mergeás PRs que no entendés completamente, el bus factor del proyecto sube a proporciones peligrosas — y el agente no va a estar disponible cuando necesites entender su propio código a las 3am antes de un deploy crítico.

La conclusión incómoda

Twill.ai va a conseguir tracción. El problema que resuelve — la fricción de convertir issues en código — es real y el mercado lo va a adoptar.

Pero hay algo que los sistemas de seguridad críticos aprendieron hace décadas y el mundo del software todavía está procesando: la responsabilidad no se puede delegar completamente a una herramienta. La herramienta ejecuta. La responsabilidad permanece humana.

El agente te manda el PR. La firma en el merge es tuya.

Asegurate de que lo que mergeás lo podés explicar. No porque el agente haya fallado — sino porque el codebase es tuyo, la arquitectura es tuya, y la llamada de las 3am también va a ser tuya.

Y eso, por ahora, ningún pitch deck lo está incluyendo en el slide de beneficios.

¿Estás usando agentes que generan PRs en producción? Me interesa saber qué proceso de review armaron. Escribime.