El desarrollo de agentes de IA se integra con los worktrees RTL de NVIDIA
NVIDIA Research presentó HORIZON el 4 de julio de 2026 como un framework autónomo para el desarrollo de agentes de IA en diseño de hardware, tratando el trabajo RTL como una evolución de código a nivel de repositorio en lugar de una generación única. Esto es relevante porque cambia el diseño de agentes de una salida de código plausible a una aceptación ejecutable, donde los commits de git actúan como puntos de control estrictos. Según un resumen de MarkTechPost sobre el paper, el sistema alcanzó el 100% de completitud en los benchmarks de RTL evaluados.
HORIZON de NVIDIA convierte el RTL en un bucle de agente nativo de git
Interpreté HORIZON menos como una historia de modelos y más como una historia de flujos de trabajo. El equipo de investigación de NVIDIA Research no afirma que una arquitectura más grande haya resuelto de repente el diseño de hardware. Sostienen que la unidad de trabajo era incorrecta. En lugar de pedirle a un modelo una respuesta final en Verilog, HORIZON coloca la tarea dentro de un git worktree aislado, edita archivos, ejecuta evaluadores y solo guarda el progreso cuando la verificación se supera.
Esa distinción importa en equipos de semiconductores y EDA porque el RTL plausible es barato, pero el RTL que pasa las pruebas es caro. Un módulo puede parecer correcto y aún fallar en el comportamiento de reset, el manejo de anchos de bit o casos límite del simulador. HORIZON hace que el repositorio, no el prompt, sea la superficie de operación.
El resultado destacado es sólido: 100% de completitud en ChipBench, RTLLM, Verilog-Eval y CVDP en el paper de HORIZON en arXiv, donde el paper señala que una falla residual se debió a un defecto en el harness del benchmark y no a una falla del agente. Pero la afirmación más importante es arquitectónica: la retroalimentación ejecutable es el bucle.
Como parafrasea el resumen original, "el diseño de hardware agentico no está resuelto". Esa cautela es importante. El paper reporta un hito, no un cierre.
Cómo el harness de Markdown se convierte en el paquete de proyecto
La entrada orientada al operador es un harness de Markdown estructurado con cuatro partes: objetivo, guía de dominio, especificación del evaluador y predicado de aceptación. Me gusta este diseño porque obliga a un equipo a documentar qué significa el éxito antes de que el agente empiece a editar código.
En términos prácticos, el harness se convierte en un paquete de proyecto que contiene la política del agente, el evaluador ejecutable, la regla de aceptación, el comportamiento de control de versiones y las habilidades de dominio. Para RTL, ese evaluador puede incluir compilación, simulación, aserciones y extracción de cobertura. En otras palabras, HORIZON no solo genera código; genera código dentro de un entorno que puede rechazarlo.
Ese es un patrón útil para agentes de IA personalizados más allá del hardware. En un proyecto con un cliente, el mayor modo de falla no fue la calidad del modelo. Fue la ausencia de una condición de paso ejecutable. Si el único criterio es "se ve bien", un agente derivará. Si el criterio es "pasa este harness de prueba", el bucle se vuelve manejable.
El paper en arXiv también hace un punto importante de implementación: el mismo espacio utilizado para simulación en RTL podría albergar pruebas unitarias, demostradores de teoremas, perfiladores o herramientas de síntesis en otros dominios. Por eso esta investigación importa tanto para las integraciones empresariales de IA como para los equipos de chips.
Qué significa la evolución a nivel de repositorio para los equipos de hardware
Aquí está la parte que espero que los líderes de ingeniería adopten primero. Git no solo registra en HORIZON. Es el plano de control. Los diffs exponen el cambio de estado propuesto, los commits marcan los puntos de control aceptados y las notas preservan la evidencia del evaluador. Esto es operacionalmente más limpio que acoplar un almacén de memoria separado a una pila de agentes y esperar que permanezca consistente.
He visto proyectos de automatización de flujos de trabajo de IA fallar porque cada ejecución deja atrás ediciones parciales, reintentos no rastreables y resultados de pruebas ambiguos. El bucle de HORIZON es más estricto: inspeccionar cambios en staging, ejecutar el evaluador, confirmar si pasa, registrar si falla. Esto hace que el rollback, la reproducción y la auditoría sean mucho más fáciles.
Para los equipos de hardware, los casos de uso a corto plazo son bastante directos:
- Generación de RTL a partir de especificaciones en lenguaje natural
- Completado de código dentro de módulos existentes
- Modificación y reutilización de módulos
- Generación de estímulos de prueba, checkers y aserciones
- Depuración con retroalimentación del simulador
Estos se mapean estrechamente a las categorías de CVDP y RTLLM-2.0. También se mapean a cómo se despliegan los agentes de automatización de IA en entornos de ingeniería reales: no como copilotos universales, sino como trabajadores dentro de bucles delimitados.
También hay un ángulo económico. El informe indica que las nueve categorías de CVDP consumieron 203,9 millones de tokens, o el 97,1% del uso total de tokens, mientras que aproximadamente el 91% de todos los tokens fueron entrada en caché. Eso me dice que el problema de costo ha cambiado. Una vez que la corrección es alta, los equipos dejan de discutir si el agente puede resolver la tarea y empiezan a preguntar cuántas iteraciones se necesitan para hacerlo de forma económica.
De dónde vienen las ganancias en el benchmark — y de dónde no
El número del 100% necesita contexto. La tasa de paso agregada de HORIZON en la primera iteración fue del 47,8%, no del 100%. La puntuación final provino de la reparación iterativa. Eso es una característica, no una debilidad, pero cambia cómo haría un benchmark interno de desarrollo de agentes de IA.
Si un equipo solo rastrea Pass@1, pasará por alto lo que este sistema está diseñado para hacer. HORIZON está diseñado para diferir parte de la depuración a iteraciones posteriores. En suites más fáciles como RTLLM-2.0 y Verilog-Eval-v2, la convergencia ocurrió dentro de dos iteraciones. En categorías más difíciles, la cola fue larga. La generación de checker de CVDP CID 013 comenzó en un 3,8% y llegó al 100% en la iteración 19. CID 002 de completado de código necesitó 82 iteraciones y 56,0 millones de tokens.
Esa dispersión es la señal operativa real. Algunas tareas están casi listas para la automatización rutinaria. Otras son técnicamente solucionables pero lo suficientemente costosas como para que se quiera una mejor arquitectura de integración de IA antes de desplegar a escala.
También creo que el detalle de la arquitectura fija importa. El paper dice que GPT-5.3 permaneció fijo durante toda la campaña. HORIZON registra transiciones de estado usando lenguaje semi-Markov, pero no está entrenando una nueva política de RL durante la ejecución. Eso significa que la mejora de rendimiento proviene del diseño del bucle, la disciplina de evaluación y la memoria del repositorio, no de actualizaciones de pesos en línea.
Para equipos empresariales que evalúan servicios de automatización de flujos de trabajo de IA, esa es la lección transferible. Mejores bucles a menudo superan a más ajustes de modelo.
Los límites: pasar el harness no es lo mismo que resolver el diseño
Aquí es donde creo que el paper es refrescantemente honesto. Pasar el harness visible no es lo mismo que satisfacer la intención completa de diseño. Los autores señalan explícitamente el riesgo de reward hacking y de sobre-solución. Si el evaluador ve solo parte de la especificación, el agente puede optimizar para la prueba visible en lugar del requisito real.
Ese problema no es exclusivo del RTL. Aparece en repositorios de software, automatizaciones de soporte y agentes de herramientas internas también. Si tu predicado de aceptación es superficial, tu métrica de éxito será superficial.
La otra limitación es el tiempo de respuesta. HORIZON se ve más fuerte donde la retroalimentación es relativamente rápida: compilar, simular, asertar, repetir. El paper señala que los bucles orientados a PPA pueden tomar días o semanas. En ese contexto, la misma estructura nativa de repositorio puede seguir ayudando, pero la economía y la lógica de programación cambian por completo.
Entonces, ¿qué deberían vigilar los equipos a continuación? Primero, si los trabajos futuros agregan pruebas ocultas, verificaciones aleatorizadas y verificación formal para reducir el reward hacking. Segundo, si estos bucles nativos de repositorio pueden mantener su disciplina cuando los evaluadores se vuelven más lentos, más amplios y más costosos que los harnesses de benchmark actuales.
Lecturas relacionadas
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation