Ask HN: ¿Cómo lidiar con desplegar código escrito por IA que no entiendes?
A medida que los modelos de lenguaje grandes aceleran rápidamente el desarrollo de software, muchos ingenieros ya están desplegando código que no escribieron —y a menudo no entienden del todo—. Los comentarios abarcan desde “si pasan las pruebas, despliega” hasta sostener que liberar código opaco generado por IA es negligente, con mitigaciones propuestas que incluyen pruebas automatizadas más intensas, verificación formal, control arquitectónico estricto y revisión multiagente. Debajo del debate sobre herramientas hay una preocupación más profunda: si este cambio está erosionando la artesanía y la responsabilidad en el software, o simplemente está elevando a los ingenieros a otro nivel de abstracción hacia el diseño y la especificación.
Pruebas, verificación y “si funciona”
- Muchos sostienen que la única forma sensata de desplegar código escrito por IA es con pruebas automatizadas intensivas: grandes suites de pruebas unitarias e de integración, granjas de pruebas entre arquitecturas, fuzzing, chaos testing, mutation testing y pruebas e2e.
- Algunos adoptan TDD de forma estricta, incluso para agentes: el agente escribe primero pruebas fallidas y luego código hasta que pasan.
- Otros se preocupan de que dejar que el mismo LLM escriba tanto el código como las pruebas es peligroso, ya que pueden compartir puntos ciegos; entre las mitigaciones se incluyen:
- Agentes separados de “código” y de “pruebas”.
- Varios LLM distintos en bucles de revisión adversarial.
- Inyectar fallos intencionalmente y verificar que las pruebas los detecten.
- Varios insisten en que las pruebas por sí solas no bastan: no verifican el diseño, no pueden probar la ausencia de vulnerabilidades y las pruebas escritas por IA suelen ser débiles o justificarse a sí mismas.
Arquitectura, diseño y el papel humano
- Un patrón común: los humanos diseñan la arquitectura y las abstracciones (“esqueleto”), y los LLM rellenan las implementaciones (“carne”).
- La gente enfatiza la planificación previa: documentos de diseño de funcionalidades, planes de implementación, diagramas de arquitectura, invariantes y contratos; luego los LLM implementan dentro de esas restricciones.
- Algunos lo comparan con el trabajo de un principal engineer: entiendes la intención y la estructura, no cada línea.
- Otros dicen que si no entiendes el código, en la práctica eres un gestor/escritor de especificaciones, no un ingeniero.
Calidad, deuda técnica y seguridad
- Los entusiastas informan de grandes aceleraciones y afirman que la calidad puede ser alta con buena planificación y guardarraíles.
- Los escépticos ven “slop” y temen una explosión de deuda técnica, arquitecturas frágiles y un enorme coste futuro de mantenimiento.
- Hay debate sobre la seguridad: algunos predicen CVE “épicos” por código de IA no revisado; otros señalan que el código escrito por humanos ya es inseguro y argumentan que el problema de fondo es la falta de estándares profesionales, no la IA en sí.
Herramientas, guardarraíles y flujos de trabajo
- La gente construye marcos de guardarraíles: análisis estático, linters, umbrales de cobertura, escáneres de CVE, comprobaciones de rendimiento, paneles de observabilidad, staging/feature flags, copias de seguridad y rollback automatizado.
- Algunos usan “equipos” de agentes: constructor, revisor, QA y un agente de nivel superior tipo “CTO”/manager coordinando tareas.
- Surgen nuevas herramientas para:
- Resumen y categorización de PR.
- Visualización de arquitectura y del grafo de llamadas.
- Exploración interactiva de código y “explicadores” para subsistemas complejos.
- Varios ahora dedican menos tiempo a teclear código y más a pruebas, revisión de diseño y monitorización.
Normas profesionales y ansiedades laborales
- Un bando: “nunca despliegues código que no entiendes”; hacerlo es negligente y degrada la profesión.
- El otro: en sistemas grandes nunca has entendido por completo todo el código desplegado (dependencias, trabajo de colegas), así que esto es una extensión de la práctica existente.
- Hay una fuerte corriente subyacente de ansiedad: miedo a convertirse en “proxies de carne” para agentes, a una cultura de ingeniería degradada y a un futuro descenso de los roles de SWE frente a PM/“maintenance engineer”.
- Otros abrazan el cambio, argumentando que negarse a usar IA limita la carrera y que el verdadero apalancamiento ahora está en el diseño, la especificación y en construir procesos robustos alrededor de agentes.
Nivel de abstracción y diferencias de dominio
- Muchos comparan la programación con LLM a saltos de abstracción anteriores (compiladores, ORM, frameworks), pero los críticos responden que los LLM son cajas negras no deterministas, a diferencia de los compiladores.
- La tolerancia al código escrito por IA y mal entendido depende mucho del radio de explosión:
- Más relajada para UI, herramientas internas, dashboards y funciones sociales.
- Mucho más estricta para sistemas de pago, libros contables, infraestructura y dominios tipo aeroespacial/médico.