Hay una asimetría que ya nadie discute pero que casi nadie explica bien: los modelos escriben código como si les fuera la vida en ello y son mediocres decidiendo cosas de negocio. La explicación habitual es que programar es un problema cerrado y el negocio es ambiguo. Es una respuesta bonita y no es la buena.
La buena tiene que ver con quién corrige los deberes.
La frontera es irregular, no una línea
Solemos imaginar el avance de la IA como una línea que sube: cada año un poco más lista en todo. Se parece más a una costa recortada. Hay dominios donde ya está por encima del nivel humano y otros al lado, aparentemente más fáciles, donde va francamente peor.
Matemáticas, programación y lenguaje están cruzados. Biología experimental, no. Y lo interesante es que la diferencia no está en la arquitectura del modelo ni en que le falten capacidades: está en la naturaleza del dominio.
Lo que tienen en común los dominios que ha cruzado
Uno: verificación barata e inmediata. Un programa compila o no. Las pruebas pasan o fallan. Una demostración matemática se comprueba. En estos terrenos, un sistema puede generar un millón de intentos, quedarse con los que funcionan y aprender de eso sin que ningún humano etiquete nada.
Dos: datos en abundancia. Décadas de código público, de textos, de demostraciones.
Junta las dos y tienes un bucle que se alimenta solo. Ahí es donde la curva se dispara.
Ahora mira los dominios que no ha cruzado. Para saber si una molécula funciona hay que sintetizarla y probarla, y eso lleva meses. Para saber si una campaña funcionó hay que esperar el trimestre. La naturaleza y el mercado contestan cuando les da la gana, y no se les puede pedir un millón de intentos.
Qué significa esto para el trabajo de cada día
Tres consecuencias bastante prácticas.
La primera: si una tarea tuya se puede comprobar sola, prepárate, porque va a caer. No por difícil o fácil, sino por comprobable. Escribir una expresión regular, transformar un formato, generar un esquema de datos estructurados, migrar una plantilla: todo eso tiene verificador.
La segunda: si tu trabajo consiste en decidir con información incompleta y esperar meses a saber si acertaste, tienes bastante margen. No porque seas irremplazable, sino porque no hay forma de entrenar a nadie —máquina o persona— en un bucle tan lento.
Y la tercera, que es la aprovechable: puedes fabricar verificadores. Buena parte del trabajo de meter IA en un proceso no consiste en elegir modelo, consiste en construir la manera de saber rápido si lo que produjo está bien. Si eres capaz de convertir «esta ficha de producto está bien redactada» en una comprobación automática —tiene los campos, respeta el largo, menciona el material, no inventa medidas—, acabas de mover esa tarea al lado bueno de la frontera.
Y una guinda incómoda
Hay una observación que se repite entre quien trabaja con estos sistemas a diario: con el contexto adecuado, son bastante más capaces de lo que aparentan.
Es decir, que una parte de lo que llamamos «el modelo no llega» es en realidad «no le hemos dado lo que necesita para llegar». La documentación, los ejemplos, las restricciones reales, lo que ya se intentó y falló. Eso es trabajo humano y no lo hace nadie por ti.
Lo cual deja un reparto de tareas bastante claro para los próximos años: la máquina resuelve donde hay verificador, y el trabajo humano consiste cada vez más en dos cosas, construir el verificador y preparar el contexto. Ninguna de las dos aparece en las listas de profesiones del futuro, y las dos se están pagando ya.
