La mayoría de las herramientas de revisión con IA ven un diff. Hedy revisa los merge requests con contexto de proyecto — decisiones recientes, módulos relacionados, sus convenciones — y publica un comentario en borrador sobre el que un humano puede actuar. El merge sigue siendo humano; las escrituras se permiten por repositorio mediante lista de permitidos.
Hedy revisa merge requests y pull requests como un empleado de IA privado que se ejecuta en su propia infraestructura, no como un bot en la nube que vive en el chat de otra persona. Lee su repositorio para obtener contexto de proyecto real, publica comentarios de revisión en línea en GitLab y GitHub, y nunca hace merge. Cada escritura es primero borrador (draft-first) y está sujeta a lista de permitidos: se permiten las acciones de comentario y de nota en borrador, mientras que aprobar, hacer merge y push a ramas protegidas se deniegan por defecto. La gobernanza es el producto: auditoría append-only, niveles de aprobación L0/L1/L2 y hallazgos sujetos a puerta de evidencia.
Última actualización: 20 de julio de 2026
Hedy extrae el diff más el código circundante, los commits recientes en los archivos tocados y el contexto de proyecto desde su memoria.
Comenta sobre corrección, acoplamiento oculto y casos omitidos — haciendo referencia a su base de código, no a consejos genéricos de lint.
Solo puede comentar en repositorios incluidos en la lista de permitidos, nunca aprobar, nunca hacer merge. El botón de merge se queda con su equipo.
Cada revisión queda registrada en el libro de actividad con un enlace — resultados visibles, no impresiones.
Hedy revisa el código con contexto de proyecto, no solo el diff. Como se despliega dentro de su infraestructura mediante Docker o Kubernetes, y puede ejecutarse contra redes air-gapped (aisladas de red), lee el repositorio circundante —convenciones, módulos adyacentes, decisiones previas— de modo que los comentarios de revisión hacen referencia a cómo funciona realmente su base de código en lugar de a un lint genérico. Se adapta tanto a los merge requests de GitLab como a los pull requests de GitHub mediante un adaptador dual, usando el mismo comportamiento de revisión y los mismos controles de gobernanza en cualquiera de las dos plataformas.
La postura por defecto es primero borrador y solo comentarios. Hedy deja comentarios de revisión en línea y notas en borrador; no aprueba, no hace merge y no hace push a ramas protegidas. Esto no es una petición a nivel de prompt: se aplica en la configuración y el código, porque una limitación que vive solo en un system prompt no existe. El merge, la aprobación y el force-push quedan fuera de la lista de permitidos de escritura y se deniegan por defecto, de modo que una pasada de revisión nunca puede cambiar en silencio el estado de su repositorio.
Aquí es donde Hedy se diferencia de los empleados de IA en la nube que viven en Slack o Teams. Esas herramientas en su mayoría resumen y registran; Hedy asume el resultado del ingeniero que revisa manteniéndose gobernada. Las operaciones de escritura siguen una lista de permitidos con denegación por defecto, las acciones sensibles escalan a través de los niveles de aprobación L0/L1/L2 y cada hallazgo pasa por la puerta de evidencia: Hedy debe citar las líneas y fuentes exactas a las que reacciona, de modo que un humano pueda verificar un comentario en lugar de confiar en una afirmación sin fuente.
Todo se ejecuta bajo su stack de gobernanza. El log de auditoría es append-only, sin ruta de actualización ni de borrado, de modo que se conserva el historial completo de lo que Hedy revisó y publicó. Usted aporta su propia clave de modelo —incluidos vLLM u Ollama locales— de modo que el código y los diffs nunca salen de su perímetro, no hay subencargados (sub-processors) y el licenciamiento se verifica offline con Ed25519. La instalación es un despliegue con compose de unos 30 minutos, y Lark/Feishu y Slack son de primera clase para notificaciones y aprobaciones.