IA con responsabilidad

Hace no mucho, resolver un problema de código implicaba abrir diez pestañas, releer la documentación tres veces, buscar en Stack Overflow alguna pregunta de 2014 que se pareciera un poco a lo tuyo, y rezar para que la respuesta aceptada no estuviera desactualizada. Era lento, frustrante, y a veces productivo de una manera que hoy cuesta explicar.

Hoy le escribes a un modelo, te da la solución en segundos, y sigues. O al menos, eso parece.

Llevo un tiempo pensando en lo que perdemos cuando hacemos eso sin parar a pensar. No me refiero al romanticismo de “aprender sufriendo”, que tampoco es el punto. Me refiero a algo más concreto: el criterio. Ese juicio que se forma cuando entiendes de verdad por qué algo funciona de cierta manera, y no solo que funciona.

Lo que me genera ruido —y no escucho mucho debate al respecto en la industria— es que estas herramientas no hacen distinción entre quién las usa. Las usa alguien que recién arranca y todavía está armando su modelo mental de cómo funciona todo. Las usa alguien con diez años de experiencia que, justamente por eso, a veces baja la guardia. Y en ninguno de los dos casos hay garantía de que el output sea correcto, seguro u óptimo. Simplemente parece correcto, que es distinto.

He visto código generado por IA que funciona perfecto en desarrollo y silenciosamente filtra datos en producción. He visto lógica que es ineficiente a una escala que no se nota hasta que escala de verdad. Y lo peor no es que eso pase, sino que nadie lo revisó porque “lo generó la IA y andaba”.

Entonces, algunas cosas que aprendí a hacer o a evitar:

No pegues contexto sensible en un prompt. Credenciales, tokens, datos reales de usuarios, esquemas de base de datos, lógica de negocio que no debería salir de tu empresa. Todo eso puede terminar en lugares que no controlas. Entiende el problema antes de mandarlo.

Revisa el código generado como si lo hubiera escrito alguien más. Porque básicamente lo hizo alguien más. Línea por línea. Si hay algo que no entiendes, no lo copies hasta entenderlo. Si no podés explicar lo que hace, no debería ir a producción.

Usa la IA para entender, no para saltarte el entendimiento. Hay una diferencia entre pedirle que te explique por qué un patrón es preferible en cierto contexto, y pedirle que lo implemente sin preguntarte nada. El primero te aporta algo. El segundo, no.

Si trabajas en equipo, hagan explícito qué está permitido. No para complicarla, sino porque sin esa conversación cada persona interpreta a su manera y el riesgo se distribuye de forma despareja. ¿Se puede usar para escribir tests? ¿Para revisar PRs? ¿Para consultar sobre arquitectura? Depende del proyecto, pero la pregunta tiene que hacerse.

No perdas el ownership del código que firmás. Si te preguntan por qué tomaste cierta decisión y la respuesta es “porque la IA lo puso así”… hay un problema. Lo que entra al repositorio es tu responsabilidad, sin importar quién lo escribió.

No tengo ningún problema con usar estas herramientas. Las uso todos los días. Pero hay una diferencia entre usarlas como palanca y usarlas como reemplazo del juicio. Lo segundo, por ahora, todavía no funciona solo.

---