Por qué freno los contratos externos cuando implementar se vuelve rápido
Construir sobre una interfaz mal diseñada era lento, y esa lentitud avisaba a tiempo. Ese aviso desapareció y nada lo reemplazó.
Generar una implementación se volvió barato. Deshacer una interfaz sobre la que ya construyeron otras empresas, no. Casi toda mi cautela está en esa diferencia.
Trabajo detrás de contratos que consumen otras compañías. Cuando uno cambia mal, los primeros en darse cuenta son sus clientes y no los nuestros, y la cuenta llega después, a quien esté manteniendo eso para entonces.
La fricción era el aviso
Una decisión mal tomada en el modelo de datos, en la forma de un endpoint, en cuánto revela un error sobre lo que pasó de verdad, o en dónde va el límite entre identidad y permisos. Antes se notaba rápido. Construir encima de una decisión mala costaba trabajo, así que la incomodidad llegaba cuando todavía estaba fresca y rehacerla salía barato. He visto versiones de esto varias veces: alguien se topa temprano con la parte fea y lo dice.
Ese aviso ya no llega. Hoy se puede generar muchísimo código correcto sobre una base equivocada antes de que alguien tenga razones para mirar la base, y cada línea nueva la vuelve más difícil de mover. Para cuando el diseño se ve mal, ya hay cosas construidas encima, y la pregunta cambió sin que nadie lo dijera: dejó de ser si está bien y pasó a ser cuánto costaría cambiarlo.
El código suele estar bien, y eso es justamente lo que lo vuelve difícil de ver. Lo que desapareció fue la fricción que hacía de alarma. La velocidad no saca el error a la superficie. Lo entierra debajo de software que funciona.
Entonces el contrato va al ritmo de antes
La regla a la que llegué: la implementación puede ir tan rápido como quiera, y lo que un tercero va a tomar como fijo se mueve al ritmo de antes.
En la práctica es discutir la forma de una interfaz mientras todavía no hay nada construido encima, y no generar el cliente hasta que esa forma haya aguantado la discusión: desde que el cliente existe, empieza a funcionar como argumento a favor de la interfaz, la merezca o no. Es calcular cuánto le costaría el cambio a quien la consume y no cuánto nos cuesta a nosotros, que es el número más chico y el que uno mira por reflejo. Y es leer la falta de reclamos como lo que es, cero información: un socio que se armó una capa de traducción encima nuestro le dio la vuelta al problema en vez de contarlo.
Las superficies que reciben ese trato son pocas: modelos de datos, forma de los endpoints, semántica de errores, identidad, permisos, cualquier cosa con un número de versión que un socio vaya a fijar. El resto puede ir rápido, y casi todo es el resto.
Nada de esto vale como afirmación general sobre construir con IA. Es propio de un tipo de negocio, ese en el que el producto de otro depende de algo que decidiste una sola vez, y lo propio de ese tipo es que la cuenta llega tarde. Implementar barato la corrió más todavía.
De lo que menos seguro estoy es de cuánto va a durar. Si los modelos llegan a sostener de forma confiable todas las restricciones de un sistema a la vez, parte de esa fricción vuelve sola y la disciplina que describo pasa a ser sobrecarga.