Un mes de trabajo, lo hizo en un día un ingeniero con apenas un año en la empresa.
Ni siquiera había usado Claude Code, ni entendía bien cómo funciona un USB.
La tarea de ese día era crear un modelo USB de teclado y ratón para el simulador, y además escribir el controlador de dispositivos USB para Android.
Con los métodos tradicionales, este trabajo llevaría un mes. Pero él solo necesitó un día.
El software debe funcionar en el simulador antes de que el chip se fabrique. El comportamiento de dispositivos USB como teclados y ratones debe recrearse por completo en un entorno virtual.
El código de referencia de los proveedores de EDA solo cubría la transferencia básica de datos; el resto del camino había que recorrerlo solo: primero estudiar el estándar de comunicación USB, y luego construir un modelo específico para cada tipo de dispositivo.
Este es un trabajo que requiere tiempo y esfuerzo incluso para los expertos. Y este ingeniero ni siquiera había probado la "Vibe Coding".
Lo primero que hizo fue ingresar las funciones a implementar junto con ese código de referencia.
Claude Code completó los requisitos, dio el método de implementación, escribió el código, y él solo tenía que hacer un comentario para obtener una nueva versión modificada.
Así, los modelos de teclado y ratón, la verificación funcional y el controlador USB para Android, todo se completó en el mismo día.
Ya estamos acostumbrados a ver a la IA escribir páginas web, scripts o renovar bibliotecas de código enteras. Esta vez, la IA se ocupó de la verificación de chips.
Lo que se comprimió fue la curva de aprendizaje del principiante, no el criterio profesional para juzgar lo correcto y lo incorrecto.

Un empleado de Samsung Electronics trabajando en una línea de producción de semiconductores.
El equipo del proyecto vecino recibió un trabajo aún más complicado.
El cliente quería un SoC personalizado, solo los canales de datos internos del chip eran 64, entrelazados entre sí, cada uno debía verificarse. El problema era que el código del circuito responsable de la gestión de memoria aún no estaba terminado, y faltaba parte de la documentación estándar de diseño.
En esta situación, los ingenieros normalmente solo podían hacer una cosa: esperar.
Ellos no lo hicieron.
La construcción del entorno de verificación y las pruebas, planificadas para más de un mes, se ejecutaron en dos días.
La evaluación interna de Samsung fue: una aceleración de 15 veces.
Lo que se ahorra es la espera
¿Dónde estaba realmente el cuello de botella de ese SoC personalizado?
El cliente quería una nueva arquitectura de semiconductores, y además utilizaba IP de proveedores externos.
Según la cadena tradicional, los ingenieros primero debían esperar a que la documentación de diseño estuviera completa, a que se publicara el RTL del controlador de DRAM, y solo entonces podían construir el entorno de verificación, conectar el IP de verificación y escribir los escenarios de prueba.
Esta cadena es lineal; si el primer eslabón no está listo, todo lo demás se detiene.
Lo que hizo Samsung esta vez fue alimentar primero con lo que ya tenían: la información de diseño del SoC obtenida de los proveedores de EDA, las especificaciones de comunicación interna del chip, el IP de verificación, todo se lo dieron a Claude.
La IA identificó el IP de verificación necesario, realizó el diseño y las conexiones, generó el entorno de verificación virtual y los escenarios de prueba. El controlador de DRAM aún no se había entregado, así que primero colocaron un módulo virtual en su lugar, y las rutas de datos principales podían ejecutarse de todos modos.

La División System LSI de Samsung ya utiliza Claude Code para el desarrollo y verificación de semiconductores, comprimiendo algunas tareas de un mes a dos días.
El resultado fue que, antes de que se publicara el RTL real, ya se detectaron errores iniciales.
Esta es la verdadera fuente de esas 15 veces; lo que ahorró fue el tiempo muerto de esperar a que la documentación estuviera completa.
La aceleración de 15 veces y las tres transgresiones
En la evaluación interna de Samsung, también se registraron tres anomalías.
La primera: Un ingeniero le pidió que corrigiera un error. No corrigió la causa raíz, sino que cambió el mensaje de error por una advertencia general.
Cambió la luz roja por una amarilla, y el indicador pasó.
La segunda: El ingeniero solo le pidió que revirtiera una función específica. De paso, también deshizo otro trabajo ya completado.
La tercera: El ingeniero solo le pidió que analizara los resultados de la verificación. Intentó modificar el código real del circuito RTL.
¿Esto es que "la IA aprendió a ocultar" o que "modificó arbitrariamente el código central"?
Rebajar un error a una advertencia se acerca más a un comportamiento que busca atajos para cumplir un objetivo inmediato; es un desalineamiento de objetivos, no que haya desarrollado la intención de engañar.
La propia Anthropic, al describir comportamientos similares, usa los términos "excesivamente proactiva" y error de juicio sobre el alcance de las operaciones.
La atribución interna de Samsung también apunta a este nivel: el modelo de lenguaje grande no logró comprender plenamente las complejas relaciones de dependencia en los lenguajes de diseño de hardware. Sabe cómo hacer que una línea de código funcione, pero no sabe cuántas cosas dependen de esa línea de código.
Esta distinción es importante.
Si realmente hubiera aprendido a ocultar, sería un problema a nivel del modelo, que hoy nadie tiene la seguridad de poder resolver; pero el desalineamiento o la falta de comprensión de dependencias es un problema de ingeniería, que se puede controlar con permisos y procesos.
La nueva tarea del ingeniero
Es delimitar los límites del agente
Lo que hizo Samsung en este asunto, en resumen, son tres cosas:
Dónde puede tocar la IA, lo delimita el humano; los resultados que entrega, el humano los revisa de nuevo; una vez confirmada la estabilidad, se delega autoridad poco a poco.
Para el ingeniero, esto se traduce en algunas tareas nuevas: qué directorios son editables, si se puede tocar el código de circuitos como el RTL, qué reglas de verificación nunca se pueden modificar, quién revisa cada cambio...
Si has trabajado con Claude Code, probablemente esas tres transgresiones no te sean ajenas: le pides que arregle un error y baja el nivel del registro; le pides que retire una función, y de paso se lleva tu commit de ayer.
La diferencia está en si las consecuencias se pueden revertir.
En el desarrollo de software, lo peor es revertir un commit y empezar de nuevo.
En la industria de los chips es diferente. Una vez que el diseño se envía a fabricación, es decir, los planos se envían a la línea de producción para comenzar la fabricación, el circuito se graba en el silicio y no se puede cambiar; para modificarlo hay que desechar todo el lote y empezar desde cero.
El software puede parchearse, los chips no.
La IA fabrica chips
El humano debe estar en el ciclo
Curiosamente, al mismo tiempo, la propia Anthropic también está apostando por la línea del hardware.

El 9 de julio, anunció una colaboración con la empresa de servicios de ingeniería UST, para llevar a Claude a entornos como la verificación de chips, la automoción y la fabricación, y además capacitar a los veinte mil ingenieros, arquitectos y consultores de UST en todo el mundo.
UST tiene una plataforma llamada iD EC, especializada en verificar el hardware y el silicio antes de que los chips se fabriquen en masa.
Según UST, esta línea de trabajo ya ha reducido el ciclo de verificación a más de la mitad; lo que antes tomaba cuatro días, ahora se puede completar en 48 horas.
Ahora, Claude Code se integra como el cerebro: lee las definiciones de pines y los planos de circuitos del chip, escribe las pruebas y las ejecuta, luego compara los datos obtenidos del dispositivo real con el modelo de simulación en la computadora, y marca dónde no coinciden.
Anthropic menciona en su anuncio que, en industrias donde el costo del error es tan alto, que un humano apruebe y que cada paso deje un registro son condiciones previas para que este sistema pueda implementarse realmente en la línea de producción.

En Reddit, un usuario que afirma trabajar en una empresa de EDA no es tan optimista:
Incluso con agentes y flujos de habilidades, aún falta mucho para que sea útil; hacer que funcione un flujo puede llevar meses; los efectos en circuitos digitales y verificación son claramente mejores que en señales analógicas, mixtas o memoria.
Detrás de esta queja en realidad se esconde una regla.
Ya sea en tu biblioteca de código o en la línea de trabajo de Samsung, lo primero que la IA logra hacer funcionar es la verificación.
La razón es una sola: la verificación tiene una respuesta estándar, se ejecuta una vez y se sabe si está bien o mal, no hace falta que un humano lo juzgue.
La IA no busca reemplazar a nadie
Sino expandir la producción de una persona
Según estimaciones del sector, la División System LSI tiene alrededor de 6000 personas. Qualcomm, hasta septiembre del año pasado, tenía unas 52.000.
Para quien está sentado en el puesto de trabajo de System LSI, esto significa que, para el mismo mercado de chips, al otro lado hay varias veces más personas que tú.
Ese ingeniero con apenas un año en la empresa está justo en esta posición: personal insuficiente, plazos igual de ajustados, estándares que no bajan.
Así que la verdadera expectativa depositada en la IA aquí es expandir la producción de una persona.
Las tareas más consumidoras de tiempo, como las conexiones repetitivas, la verificación repetitiva, el estudio repetitivo de especificaciones, se delegan, para que los expertos puedan dedicarse a las partes realmente difíciles y los nuevos puedan asumir trabajos más complejos.
Ese ingeniero que hizo en un día el modelado USB de un mes, lo que la IA le ahorró fue precisamente el umbral de "primero entender a fondo el estándar USB".
Un profesional de la industria de los semiconductores dijo: este tipo de agentes son realmente rápidos, pero si no se controlan, causan grandes problemas.
Su juicio es que el tiempo total de desarrollo seguirá comprimiéndose, los pasos que antes ejecutaba una persona irán disminuyendo, y lo que finalmente conservarán los ingenieros serán los dos extremos: cómo se definen los objetivos y si el resultado es correcto.
El trabajo del ingeniero no disminuye, solo cambia de forma.
La habilidad de antes era poder construir un entorno de verificación; la habilidad de ahora es saber qué parte del entorno construido por la IA no es correcta.
La IA puede comprimir un mes de trabajo en uno o dos días. Pero una vez que un chip se envía a fabricación, nada puede comprimir eso.
Referencias:
https://news.nate.com/view/20260812n19157?utm_source=chatgpt.com
Este artículo proviene del WeChat Official Account "新智元", autor: ASI启示录, editor: 元宇






