El péndulo del alcance: ¿Cuánto podemos delegar realmente en la IA?

La pregunta aparece en toda charla de pasillo, en todo hilo de LinkedIn, en toda reunión con un cliente que leyó un titular: ¿la IA va a reemplazar al desarrollo como profesión? No tengo la respuesta y desconfío de quienes dicen tenerla. Lo que sí tengo, después de meses de trabajar así todos los días, es algo probablemente más útil que un pronóstico: un patrón. Un ciclo que repito, que veo repetir a colegas, y que todavía no aprendí a romper.

El comienzo: cuando la confianza se construye de a poco

Al principio uno desconfía, y hace bien. Las primeras delegaciones son mínimas: una expresión regular, una función de parseo, el esqueleto de un test unitario, la conversión de un JSON a un tipo. Cosas que se verifican de un vistazo. Leía cada línea generada con la atención de quien revisa el código de un junior talentoso pero desconocido. Y funcionaba. Casi siempre funcionaba. Cada acierto erosionaba un poco la desconfianza inicial. No fue una decisión consciente confiar más: fue el resultado acumulado de decenas de pequeñas verificaciones exitosas.

Cuando el alcance crece más rápido que la revisión

El paso siguiente es inevitable. De la función al módulo. Del módulo al endpoint completo, con su validación, su manejo de errores y sus tests. De ahí a "implementá el CRUD entero siguiendo el patrón de esta otra carpeta". Lo interesante no es cuánto crece el tamaño de la tarea delegada, sino cómo se degrada silenciosamente la revisión. Primero leo cada línea. Después leo en diagonal buscando cosas raras. Después miro solo la firma de los métodos. Después corro los tests, veo verde y sigo. El salto de "leer" a "probar que ande" parece un detalle de proceso, pero es un cambio profundo: dejé de evaluar el código y pasé a evaluar su comportamiento observable, que es una fracción mucho más chica de lo que importa.

El verdadero problema no es que funcione

En algún momento del ciclo aparece una sensación incómoda que tardé en poder nombrar. No es que el código esté mal. Anda. Los tests pasan. El feature se demuestra. El problema es otro: acumulé una cantidad de trabajo hecho cuyo valor no sé estimar. El código no se escribe para defenderlo, se escribe para que funcione y para que aporte algún valor; el punto es que dejé de poder juzgar cuánto aporta. No sé si esa clase resuelve una necesidad real o una que el modelo infirió por analogía. No sé si las tres capas de abstracción que aparecieron responden a una complejidad que existe de verdad o a un patrón que se coló porque estaba en el promedio de lo que el modelo dedujo.

Y hay un corolario más incómodo. Cuando llegue el cambio que el negocio inevitablemente va a pedir, no tengo cómo anticipar qué cuesta: qué se rompe, qué depende de qué, dónde está el riesgo. Puedo volver a delegar la modificación, claro, pero eso es repetir la apuesta, no controlarla. La pregunta deja de ser "¿el código anda?" y pasa a ser "¿esto vale algo?".

El péndulo de delegar en la IA vuelve a empezar

La corrección es siempre la misma: vuelvo a achicar. Recorto el alcance de lo que delego hasta un tamaño que puedo volver a revisar de verdad. Recupero el control sobre el avance, aunque avance más lento. Y por un tiempo el trabajo se siente sólido otra vez. Acá está la parte que me parece más honesta de contar: no es una curva de aprendizaje. Es un péndulo.

Sale un modelo nuevo. Aparece una herramienta con mejor contexto, mejor integración con el repositorio, mejor manejo de tareas largas. Me envalentono. Pruebo algo un poco más grande, sale bien, pruebo algo más grande todavía. Y en algún punto —siempre— vuelvo al mismo lugar: produzco más de lo que puedo revisar. El alcance de lo que delego es elástico y se estira cada vez que la herramienta mejora. El techo no lo pone el modelo. Lo pone mi capacidad de revisión, que es constante.

Lo que realmente pasó a ser indispensable

Si el cuello de botella es la revisión, y la revisión no escala, entonces lo único que escala es el arnés. Esta es, para mí, la revalorización más importante que trajo todo esto. El testing automatizado dejó de ser una buena práctica que se negocia con el cronograma y pasó a ser el sensor que me avisa cuando algo que no leí rompió algo que no miré. La arquitectura dejó de ser una discusión estética y pasó a ser el mecanismo que limita el radio de daño de un cambio que no entiendo del todo. Los atributos de calidad —observabilidad, trazabilidad, acoplamiento, testabilidad— dejaron de ser un capítulo del documento de diseño y pasaron a ser la infraestructura que me permite trabajar rápido sin trabajar a ciegas.

Es una resignación productiva: acepto que no voy a revisar todo, y a cambio invierto en que el sistema me proteja de mí mismo. Curiosamente, todo lo que la industria pasó veinte años tratando de justificar ante clientes impacientes se volvió condición de posibilidad.

Del experimento a la responsabilidad

No sé cómo salir del ciclo. Sigo estirando y achicando el alcance, y sospecho que voy a seguir haciéndolo cada tanto. Pero hay una distinción que sí aprendí a sostener. Cuando exploro, cuando juego, cuando pruebo una idea un sábado a la noche, el ciclo es gratis: el costo del exceso lo pago yo, en tiempo propio, y el aprendizaje justifica el desperdicio. Cuando el trabajo es profesional y para un cliente, el costo del exceso lo paga otro, muchas veces en un plazo que ninguno de los dos va a ver hasta que sea caro.

En el primer caso, el péndulo es un experimento. En el segundo, es una responsabilidad. Todavía no puedo evitar oscilar, pero al menos ya sé de quién es la cuerda.