Aceptás una sugerencia que parece perfecta, los tests pasan, hacés el commit. Tres semanas después alguien descubre que la función trata mal las fechas con zona horaria, y nadie recuerda haberla escrito porque, en rigor, nadie la escribió. Los asistentes de código ahorran tiempo de verdad, pero cambian el trabajo: menos tipear, más leer.
Dónde ayudan sin mucho riesgo
Hay tareas donde el resultado es fácil de comprobar o el costo de un error es bajo:
- Boilerplate. Estructuras repetitivas, configuraciones iniciales, esqueletos de clases o de endpoints. Escribirlo a mano es aburrido y rara vez interesante.
- Conversiones. Pasar un objeto a otro formato, migrar una función de una versión de un lenguaje a otra, traducir una consulta entre dialectos. Son mecánicas, y comparar entrada y salida es directo.
- Explicar código ajeno. Pegar una función heredada y pedir que te cuente qué hace es una forma rápida de orientarte. Tomalo como una hipótesis para verificar leyendo, no como una verdad.
- Primeros borradores. Una versión inicial de una función, una expresión regular, un script de un solo uso. Sirve para arrancar, y vos lo corregís.
Dónde hay que leer con lupa
Código que parece correcto y no lo es. El problema de fondo de estos modelos es que producen código verosímil. Compila, tiene buenos nombres, sigue las convenciones, y falla en un borde: un índice desplazado en uno, una comparación de strings donde debía ser numérica, un caso vacío que no contempló. Cuanto más limpio se ve, más tentador es no revisarlo.
Dependencias inventadas. Un asistente puede sugerir importar un paquete que no existe o llamar a una función que la librería nunca tuvo. Si el paquete tiene un nombre plausible, alguien podría haberlo publicado con intenciones dudosas. Antes de instalar algo que no conocés, buscalo vos en el repositorio oficial de paquetes y fijate quién lo mantiene y desde cuándo.
Estilo inconsistente. Cada sugerencia puede traer sus propias costumbres: otra forma de manejar errores, otra convención de nombres, otra manera de acceder a los datos. Con el tiempo, el proyecto queda como escrito por muchas manos que no se hablaron. Pedile que siga el estilo del archivo vecino, y si tenés un linter y un formateador, usalos siempre.
Seguridad. El código generado puede armar consultas concatenando strings, desactivar verificaciones de certificados "para que ande" o guardar secretos en el código. No hay razón para pensar que estas cosas sean menos frecuentes que en el código escrito por apuro.
Hábitos que ayudan
- Leé todo lo que aceptás. Si no podés explicar cada línea, todavía no está listo para entrar. Aceptar sin leer es pedirle prestado tiempo al futuro.
- Pedí cambios chicos. Una función por vez rinde más que "armame el módulo de pagos". Los diffs pequeños se revisan bien; los grandes se aprueban de cansancio.
- Corré los tests, y escribí uno nuevo si falta. Si el cambio toca comportamiento, que haya una prueba que lo cubra. Si el asistente la escribió, aplicá lo que ves en la nota sobre tests con IA.
- Dale contexto concreto. Versión del lenguaje, librerías que ya usás, restricciones del proyecto, un ejemplo de cómo se resuelve algo parecido en otro archivo. Los resultados mejoran bastante cuando no tiene que adivinar.
- No pegues secretos. Credenciales, certificados privados, datos personales de clientes, contenido de un entorno de producción. Lo que enviás a un servicio externo sale de tu máquina. Revisá la política del proveedor sobre qué hace con ese contenido y, si trabajás con código de un cliente, consultá antes si tenés permiso para compartirlo.
- Desconfiá de tus propios atajos. Si notás que dejaste de leer porque "casi siempre está bien", es la señal de volver a hacerlo.
Qué conservar
Entender el problema, elegir el diseño y asumir la responsabilidad por lo que se despliega siguen siendo tuyos. El asistente es un colega rápido que a veces se equivoca sin darse cuenta; tratalo como tratarías un pull request de alguien nuevo en el equipo: con buena voluntad, y con revisión.