Ask HN: ¿Cómo lidiar con enviar código escrito por AI que no entiendes?
Ask HN: How to deal with shipping AI-written code you don't understand?
Soy un desarrollador retirado y me tomo muy en serio la calidad del código. He estado trabajando en un compilador 'C' que usa clang para compilar a LLVM IR y luego traduce a nuestra IR para autovectorizar, logrando grandes aceleraciones en benchmarks como Mandelbrot y nbody. Sin embargo, me pregunto cómo debería manejar la situación de enviar código generado por AI que no comprendo completamente, especialmente cuando los resultados son correctos pero el proceso interno no es claro.
La clave es tratar el código generado por AI como código de terceros: debes revisarlo, probarlo y entenderlo antes de enviarlo. No importa si lo escribió una AI o un humano, la responsabilidad final es tuya.
He aprendido que si no puedes explicar el código línea por línea, no deberías enviarlo. La AI puede generar código que funciona, pero si no lo entiendes, no podrás mantenerlo ni depurarlo cuando falle.
En mi experiencia, el código generado por AI es como un borrador: útil para empezar, pero necesitas reescribirlo y adaptarlo a tus estándares. No lo envíes tal cual; úsalo como inspiración.
La mejor práctica es usar AI para generar pruebas y documentación, no para el código de producción directamente. Así puedes verificar que el comportamiento es el esperado sin depender de la comprensión completa del código generado.
- ChrisMarshallNY
Probando.
Muchísimas pruebas. Normalmente hago pruebas interactivas con el LLM. Ahora que paso menos tiempo programando, puedo dedicar más tiempo a probar.
En mi experiencia, pruebo más con un LLM de lo que probaba con mi propio código. No encuentro errores de programación, pero sí encuentro errores de implementación.
Por otro lado: pasé un LLM por un montón de código realmente maduro que yo había escrito, y que podría jurar que era "perfecto", y encontró varios problemas.
Nadie es perfecto. Confía; pero verifica.
- skeledrew
Técnicamente es solo un cambio de rol. Ahora eres el jefe de proyecto o algo así, no el desarrollador. No es trabajo de un jefe de proyecto entender el código, solo asegurarse de que hace lo que debe y no hace lo que no debe. Y de asegurarse de que los desarrolladores, etc., estén desbloqueados y rindiendo bien. Abraza el nuevo rol.
- trezm
He estado jugueteando con esto https://getchronosphere.com. Intentará reconstruir un PR en un recorrido coherente en lugar de un bloque masivo. Hasta ahora ha sido algo útil, y sigue mejorando.
- 4ndrewl
Así se siente todo jefe de producto todos los días.
Si eres un prompter de LLM que entrega productos, tus resultados se parecen más a los de un jefe de producto que a los de un ingeniero de software.
- spacedcowboy
Poco a poco me estoy convenciendo de que si funciona, me vale. Tampoco solía revisar personalmente el trabajo de todos mis colegas; simplemente confiaba en que habían hecho un buen trabajo.
Eso no quiere decir que confíe ciegamente en un LLM: mi proyecto es un compilador autovectorizador. Le hago escribir un montón de tests, y tengo programas reales y no triviales que ha compilado. Le hago ejecutar una 'puerta' antes de las versiones que tarda literalmente horas en 5 arquitecturas distintas. Decir que este código está probado es... quedarse muy corto.
Creo que lo que ayuda es una larga sesión de planificación, entrar en detalles, resolver casos límite, diseñar casos de prueba, ya sabes, trabajo y esfuerzo. Una vez hecho eso, es más fácil dejarlo trabajar toda la noche y hacer una funcionalidad importante de producción.
Sigo revisando el código, pero con la mano en el corazón no podría decir que lo he revisado todo; a veces se me escapa algo en un check-in complicado. Intento mantener los check-ins pequeños y acotados, pero a veces no es fácil gestionarlo junto con la regla de "no rompas cosas".
Así que se reduce a esto: llevo unos 6 meses trabajando en esto, y hasta ahora me ha funcionado. Ya sabes, algo así como acostumbrarte a las idiosincrasias de un colega con el tiempo.
Diré que en mi experiencia la calidad del código es bastante alta. Quizá se deba al esfuerzo puesto de antemano en las fases de planificación, no lo sé, pero no parece que sufra de la 'porquería' de la que se queja la gente. Tu experiencia puede variar.
- solatic
No es muy distinto de la vida como ingeniero de nivel Principal antes de la IA. Técnicamente supervisas el trabajo de muchos ingenieros en sus propios sistemas, pero no podrías revisar todo el código tú mismo. Valoras que la revisión de código humana reduce, pero no elimina, el número y la gravedad de los bugs que llegan a producción. No tienes los detalles de bajo nivel en la cabeza, solo los de alto nivel. Diseñas cómo interactúan todos esos ingenieros entre sí, sin pisarse los pies.
El tiempo dirá si acertamos al pasar de un sistema en el que confiábamos en que los humanos entendieran el sistema de bajo nivel, a uno en el que confiamos en calculadoras sofisticadas. Pero hasta ahora, está funcionando.
- cadamsdotcom
Desarrollo guiado por pruebas y la pirámide de pruebas.
Si el agente ha escrito tests y, crucialmente, los ha visto fallar antes de empezar el trabajo para hacerlos pasar, tienes mucha confianza.
Revisar tu propio trabajo también es más fácil: el código de test y el de producción tienden a reflejarse mutuamente, dándote una imagen mucho más completa. ¿Te confunde el código de producción? Ve a leer sus tests un rato, y luego vuelve.
También es más fácil entender el cambio si estuviste ahí durante la construcción, viendo la transcripción, revisando de vez en cuando. No tiene que ser tu tarea principal: déjalo en un segundo monitor, te llamará la atención de forma natural.
Y por último, además del desarrollo guiado por pruebas, haz que el agente primero (antes del primer ciclo de desarrollo guiado por pruebas) construya un test de extremo a extremo que cubra el trabajo que va a hacer. Una vez que ese test esté en verde (palabra del desarrollo guiado por pruebas para "está pasando"), has terminado tu trabajo y puedes limpiar a voluntad.
Juega con ello antes de lanzarlo, déjalo bien bonito. Nunca ha sido tan fácil limpiar la deuda técnica y dejar la interfaz perfecta.
¡Con el tiempo estarás listo para empaquetarlo en un PR!
Ahora puedes aprovechar los agentes y ser creativo. Haz que tus colegas se mueran por revisar tu trabajo. Considera hacer un vídeo de Loom para guiarlos. Considera reestructurarlo en una serie de commits; solo le toma unos segundos a tu agente y puedes contar una historia para humanos. Quizá quieras secuenciarlo según tus dificultades; quizá sea mejor mostrar las distintas capas emergiendo con cada commit - [...]
- vjerancrnjak
Verificación formal: elige un lenguaje que la tenga integrada y demuestra las postcondiciones relevantes.
La IA todavía no sabe ni siquiera escribir código que haga que los estados imposibles sean irrepresentables, así que las pruebas no ayudarán.