Imagina dos personas frente a una fecha de entrega.
Una estudia en el MIT y tiene que entregar un problema que le van a calificar. La otra acaba de empezar como ingeniera de software: tiene un ticket, un equipo esperando y un período de prueba encima.
Las dos tienen una IA a mano. Las dos podrían detenerse a entender cada paso. Pero el plazo sigue corriendo.
Para una, lo que está en juego es una nota. Para la otra, quizás el trabajo. Aprender sigue importando, pero entregar tiene consecuencias más inmediatas.
Ya habrá tiempo para entenderlo después.
Tal vez.
En los últimos meses he visto, más de una vez, conversaciones de trabajo en las que ya no hay ni un minuto de análisis humano.
A simple vista parece eficiencia. Pero en realidad nos hace buscar el valor en el lugar equivocado.
Como ingenieros, nuestro valor no está solo en hacer que algo funcione. Está también en entender por qué funciona.
Yo escribo poco código estos días. Y aun así entrego casi igual de rápido que siempre. No porque antes entregara a la velocidad de la luz, sino porque mantuve los mismos criterios de ingeniería.
Si me pides escribir un reduce de memoria, quizás ya ni me acuerde de la sintaxis. Pero sé cuándo tiene sentido usarlo, y por qué cambiar una búsqueda en un arreglo por un Map o un Set puede volver mucho más eficiente el código que la IA acaba de escribir.
Eso no lo aprendí copiando y pegando de Stack Overflow (que en paz descanse… casi). Lo aprendí leyendo, estudiando, experimentando y cuestionando.
#.Lo que vio el MIT
En agosto de este año, un comité del MIT publicó un informe sobre la IA en la enseñanza y el aprendizaje. Recoge algo que dijeron los propios estudiantes: la tentación de delegar el pensamiento era mayor cuando temían no llegar a la fecha de entrega.
También advierte que sacar la respuesta correcta puede dar una ilusión de aprendizaje. Y que con tanto énfasis en notas y credenciales, quien quiera maximizar su promedio tiene un fuerte incentivo para usar lo que le parezca más eficaz.
Ojo: es un informe hecho con consultas y encuestas, no un experimento.
Pero me hizo pensar en cómo organizamos el trabajo. Si evaluamos sobre todo el resultado visible, ¿de qué nos sorprendemos cuando alguien prioriza obtenerlo?
Una universidad no es una empresa, y nada de esto prueba que el miedo al despido haga que alguien dependa de la IA. Esa es mi hipótesis, no un dato.
#.Delegar no es rendirse
El informe usa una expresión que me quedó dando vueltas: cognitive surrender, rendición cognitiva. Cita una investigación de Steven Shaw y Gideon Nave, de Wharton.
Para ellos, es aceptar la respuesta de la IA casi sin revisarla, y dejar que su razonamiento reemplace el tuyo.
Pedir ayuda no es eso. Puedo delegar una tarea y seguir siendo yo quien decide si tiene sentido. Rendirse es adoptar una conclusión porque viene explicada con seguridad. Y recuerda: la IA casi nunca te va a llevar la contraria.
En sus experimentos, la gente consultaba a la IA en más de la mitad de los problemas, y cuando la IA se equivocaba, acertaban bastante menos que sin IA. Es un preprint con problemas de razonamiento, no un estudio de equipos de software. Pero deja una pregunta incómoda para ingeniería:
¿De qué sirve poner a una persona a revisar, si no tiene cómo revisar?
¿Puede explicar lo que pasa? ¿Reconoce una suposición peligrosa? ¿Tiene permiso para frenar la entrega si todavía no entiende algo?
#.El ticket cerrado no lo dice todo
En un experimento de Anthropic, 52 desarrolladores, en su mayoría junior, aprendieron una librería de Python nueva, con y sin ayuda de IA. Después, el grupo con IA sacó en promedio 50% en una evaluación; el grupo sin IA, 67%. La mayor diferencia estuvo en las preguntas de debugging. Y terminar con IA no fue significativamente más rápido.
En la Universidad Técnica de Múnich, un ensayo con 275 estudiantes lo vio desde otro ángulo: con IA sacaron mejores resultados en un ejercicio de 90 minutos, pero no aprendieron más.
Son estudios cortos y no predicen una carrera entera. Pero separan dos preguntas que un ticket cerrado mezcla: ¿qué pudo entregar la persona, y qué aprendió en el camino?
#.¿Qué le estamos pidiendo al junior?
Una empresa puede pedirle a alguien que desarrolle criterio y, al mismo tiempo, dejar muy claro lo caro que es demorarse. Puede pedirle que pregunte, sin reservar tiempo para responder.
En un ambiente así, la IA ofrece algo muy atractivo: avanzar sin mostrar lo que todavía no sabes.
Eso no es mala fe. Es intentar cumplir con lo que uno entiende que se espera. El problema es cuando se vuelve costumbre, y practicar el diagnóstico queda siempre para después.
#.Hacer espacio para entender
Aprendemos de los errores, sí. Pero solo si existe la segunda mitad: alguien que te ayude a ver qué falló y por qué.
Yo empezaría por algo concreto:
- Antes de buscar la solución, la persona escribe qué cree que pasa y cómo lo comprobaría.
- Si usa IA, compara la propuesta con esa hipótesis.
- En la revisión, alguien le ayuda a entender por qué funcionó, o qué supuesto falló.
No es una receta validada. Toma tiempo y depende del riesgo de la tarea. Equivocarse en un entorno local está bien; perder datos de clientes no debería ser el ejercicio pedagógico de nadie.
Si queremos ingenieros capaces de supervisar sistemas cada vez más automatizados, vamos a tener que formar esa capacidad. Decir “no entiendo esto” tiene que abrir una conversación, no cerrar una evaluación.
La estudiante necesita entregar. La ingeniera junior también. No podemos pedirles que ignoren las consecuencias de fallar y después juzgarlas como si esas consecuencias no existieran.