3 puntos por groro 5 시간 전 | Aún no hay comentarios. | Compartir por WhatsApp

Título: ¿Es posible un escenario en el que la IA desarrolle al 100% el firmware MCU de electrodomésticos?

Original: Samsung Tech Blog - https://techblog.samsung.com/blog/article/90

  • Samsung Electronics aplicó "Harness Engineering" al desarrollo del firmware MCU de un electrodoméstico (una campana extractora) para verificar si un agente de IA puede crear el firmware al 100% sin intervención humana en la codificación, repitiendo de forma autónoma el ciclo de planificación-implementación-verificación

  • Aquí, "harness" no significa hacer más inteligente al modelo, sino diseñar el entorno de trabajo para que la IA produzca el resultado esperado: información necesaria, restricciones, bucles de autoverificación, estructura de carpetas, especificaciones, estándares de codificación y build/linter. El rol del desarrollador pasa de "escritor de código" a "diseñador de especificaciones y harness"

  • El principio clave es: "una especificación que la IA no puede verificar es una especificación que no existe". Los requisitos no documentados no pueden servir ni como criterio de implementación ni de validación, por lo que equivalen a "requisitos inexistentes" (por ejemplo, si no se indica si el flujo de aire debe ser Low-Mid-High o On-Off, la IA decidirá por su cuenta). El punto de partida es el "diseño de especificaciones", que sistematiza las especificaciones heredadas y el conocimiento tácito de los desarrolladores en una forma utilizable por la IA

  • Las especificaciones dispersas se reorganizaron alrededor de la carpeta docs/. El comportamiento del producto se coloca en behavior/, la justificación de diseño en design/, y la configuración de hardware y la información de inicialización en hardware/; además, las especificaciones de comunicación, la máquina de estados y el protocolo de comunicación se ordenan en carpetas separadas. A esto se suman AGENTS.md, que contiene las reglas de trabajo de la IA, y ARCHITECTURE.md, que define la estructura por capas y las reglas de dependencias, completando así la base del harness. Como resultado, la documentación cumple el rol de "Single Source of Truth"

  • Además de los tres tipos de harness para especificación/implementación/validación, se proporcionaron como "skills" la especificación del MCU propietario de Samsung, la forma de usar el depurador del MCU y un USB Switch que apaga y enciende físicamente la alimentación de 220V. El alcance de la implementación se controla con SDD/TDD/BDD, y solo se avanza a la siguiente etapa tras pasar las compuertas de calidad de Build/Test/Lint

  • El bucle AUTOPILOT parte de código Zero-Base y repite de forma autónoma planificación-implementación-validación. En este proceso se separa al "agente que genera" del "agente que evalúa/verifica" para evitar que la IA califique con demasiada benevolencia sus propios resultados

  • El reto más difícil fue construir un entorno en el que la IA pudiera verificar directamente los resultados en un "MCU real". El entorno de validación está compuesto por Codex AI en una PC + un depurador de MCU basado en JTAG + un USB Switch para controlar la energía, y Codex AI controla tanto el depurador como el switch. El depurador lee y escribe directamente el estado del MCU, y el USB Switch enciende y apaga la alimentación de 220V para que la IA pueda reiniciar por sí misma el equipo incluso en estados irrecuperables

  • A la IA se le proporcionan las especificaciones del producto, información de protocolos y paquetes, el datasheet del MCU, el modo de uso del depurador, la estructura del código fuente y de las variables, y el método para encender/apagar la alimentación. La IA analiza la especificación y deriva por "voluntad autónoma" escenarios de prueba; luego inyecta entradas de teclas al equipo real mediante el depurador (memory Write) y lee los valores de estado como variables (memory Read) para determinar por sí misma Pass/Fail en cada escenario. Es decir, la validación automática autónoma se establece cuando se conectan estos tres elementos: "escenario de funcionamiento + memory Write + memory Read"

  • Resultado: en las 5 pruebas se logró una finalización autónoma completa sin intervención humana (aprox. 4.5 a 5.5 horas por intento), con cerca de 95% de completitud en el funcionamiento básico. El ~5% faltante se produjo principalmente en HAL (UART, Timer, WatchDog, Clock y otras áreas de validación de hardware real), y puede complementarse con 1 a 4 horas de depuración humana

  • Se confirmó la posibilidad de reducir en promedio entre 50% y 70% el tiempo de desarrollo. Sin embargo, se trata de una estimación de IA basada en tiempo puro de desarrollo, excluyendo aprobación/revisión/release, y la expansión del enfoque requiere tanto inversión inicial como el establecimiento de criterios de validación lo suficientemente perfectos como para que las personas no necesiten revisar el código

Aún no hay comentarios.

Aún no hay comentarios.