~/compare / paelladoc-vs-aider.md · 7 min · 1345 palabras
[compare] · paelladoc vs · por

PaellaDoc vs Aider: un execution gate alrededor de tu pair programmer de terminal

Aider edita tu repo desde la línea de comandos. PaellaDoc puede correr un agente tipo Aider y decidir si está "hecho" ejecutando el código.

JL @jlcasesES Creador de PaellaDoc · València
Portada PaellaDoc vs Aider: un pair programmer, o un sistema que lo verifica.

Aider y PaellaDoc ponen una IA a trabajar sobre tu repo de verdad, pero van a por cosas distintas. Aider es un pair programmer en tu terminal: tú hablas, él edita, él commitea. PaellaDoc es la capa que rodea ese trabajo. Corre un agente de código en un worktree aislado y luego decide si el cambio está realmente hecho ejecutándolo. Así que esto no es tanto “Aider vs PaellaDoc” como “Aider a secas vs un agente tipo Aider corriendo dentro de PaellaDoc”.

Qué hace Aider

Aider es un pair programmer de IA open source para la línea de comandos. Vive en tu terminal, edita los archivos directamente en tu repo y hace sus propios commits sobre la marcha. Es model-agnostic, así que lo apuntas al modelo que quieras, y es lo bastante ligero y scriptable como para meterlo en un loop de shell o en un Makefile. La gente lo usa porque es pequeño, abierto, arranca rápido y no se mete en medio.

Nada de eso es un reproche. Aider es uno de los agentes CLI con más cariño de la comunidad, y con razón. Si quieres un loop apretado de editar y commitear en la terminal, sin app que instalar y sin opiniones impuestas, es una elección estupenda.

Qué hace PaellaDoc

PaellaDoc corre agentes de código, agentes CLI tipo Aider incluidos, en worktrees de git aislados en tu máquina. Es local-first, model-agnostic y con tu propia suscripción. Lo que importa es lo que pasa cuando el agente deja de teclear.

PaellaDoc tiene un execution gate. “Hecho” no es “el build está en verde”. “Hecho” es “el código corre y cumple los criterios de aceptación que escribiste antes”. El gate ejecuta el cambio contra esos criterios y se niega a darlo por terminado hasta que pasa de verdad. Un build en verde que hace lo que no debe no pasa.

Alrededor de ese gate está el resto: una metodología de producto que convierte una petición en artefactos .paella versionados (un PRD, épicas, historias de usuario, criterios de aceptación), un reverse intake que lee un repo existente y reconstruye su contexto de producto, un sala de control multi-repo para los cien repos que ahora tienes en disco, control remoto por Telegram para arrancar un trabajo o aprobar un paso desde el móvil, y un modo no-coder que construye un producto entero a partir de una descripción.

La diferencia clave

Diagrama: Aider solo se corrige cuando el build pasa, frente a Aider dentro de PaellaDoc, donde un gate ejecuta el código contra tus criterios de aceptación y “hecho” se vuelve un artefacto .paella versionado.

El loop de Aider termina en el commit. Edita, commitea y confía en que tú, el desarrollador que lee el diff, vas a pillar lo que esté mal. Es el diseño correcto para un pair programmer. Tú estás en la silla.

El loop de PaellaDoc termina en el gate. El commit del agente es el principio de la verificación, no el final de la tarea. La pregunta que hace PaellaDoc no es “¿el modelo produjo código plausible?” sino “¿esto pasa los criterios cuando lo ejecutamos?”. Mismo repo, mismos modelos, distinta condición de parada.

Por qué existe el gate

Corrimos un benchmark público de 210 ejecuciones para ver con qué frecuencia un agente seguro de sí mismo se equivoca sin más. La salida de un agente a pelo pasaba el build pero estaba genuinamente mal el 40% de las veces. Incluso el frontier model más fuerte al máximo esfuerzo falló una tarea difícil dos de cada tres veces, y falló en ejecuciones distintas cada vez, así que no puedes predecir cuál intento es el malo. Ese es todo el argumento del gate: un build en verde no es una feature correcta. Si dejas que un agente commitee y lo des por hecho, cuatro de cada diez de esas tarjetas en “hecho” te están mintiendo.

Código, o producto

Aider produce código. PaellaDoc intenta producir producto. La capa de metodología es un SDK abierto, y la comunidad construye y comparte cuatro tipos de packs: method packs para cómo trabajas, stack packs para tu stack técnico, design packs para theming y design tokens, y validator packs para los propios gates. El resultado no es solo un diff en tu historial, es un conjunto de artefactos .paella versionados y comparables que puedes leer, diffear y pasarle a otra persona. La idea es sencilla: haces producto, no solo código.

PaellaDoc no reemplaza a Aider

Esta es la parte importante. PaellaDoc no es una alternativa a Aider. Es algo dentro de lo que Aider puede correr.

Si te encanta el loop de terminal de Aider, quédatelo. PaellaDoc envuelve un agente CLI tipo Aider en un worktree, le deja hacer su edita-y-commitea, y luego corre el gate por encima. Te llevas el agente que ya te gusta más un control independiente de si su trabajo aguanta. Así que la respuesta a “¿PaellaDoc reemplaza a Aider?” es no. PaellaDoc lo corre y lo verifica.

Qué compartimos

Bastante, la verdad. Los dos son local-first y trabajan sobre tu repo de verdad. Los dos son model-agnostic y con tu propia suscripción, así que no te atan a un único proveedor. Los dos respetan la terminal y git como fuente de verdad.

Y Aider va por delante en lo que viene de ser abierto y maduro: es open source con una comunidad real, es más ligero de instalar y arrancar, está más rodado, y tiene años de uso scriptable detrás. PaellaDoc es temprano y lo construye un solo fundador. Si lo que necesitas hoy es acabado y una base de usuarios grande, Aider los tiene y PaellaDoc todavía no.

Capacidad Aider PaellaDoc
Trabaja sobre tu repo de git real
Model-agnostic, con tu propia suscripción
Local-first, nativo de terminal
Open source No
Madurez, comunidad, acabado Por delante Temprano, un solo fundador
Corre en worktrees de git aislados Manual Sí, integrado
Execution gate (hecho = corre contra criterios de aceptación) No
Artefactos de producto .paella versionados (PRD, épicas, historias) No
Packs por SDK abierto (method, stack, design, validator) No
Reverse intake de un repo existente No
Sala de control multi-repo No
Control remoto por Telegram No
Modo no-coder No

Para quién es cada uno

Tira de Aider si eres un desarrollador que vive en la terminal, lee cada diff y quiere un pair programmer rápido, abierto y scriptable, sin app y sin ceremonia. Es una de las mejores herramientas para eso, y tú eres la capa de verificación.

Tira de PaellaDoc si quieres que el trabajo se compruebe ejecutándolo, no solo leyéndolo. Si quieres que una petición se convierta en PRD, épicas, historias y criterios de aceptación, si manejas un montón de repos y quieres un único sitio desde donde llevarlos, si quieres aprobar un paso desde el móvil, o si no sabes leer un diff y aun así necesitas sacar un producto. PaellaDoc puede correr un agente tipo Aider por debajo de todo eso.

PaellaDoc no es mejor que Aider. Hace un trabajo distinto, y para la parte de terminal de ese trabajo, encantado de correr Aider. Mira el hub de comparativas completo para ver cómo encaja PaellaDoc frente a otras herramientas.