Ángulo

Un Product Manager equipado con un asistente de código produce en cuatro días lo que le habría llevado un mes, y esa velocidad no dice nada de lo que tiene derecho a construir. Lo que sí lo dice es el estado del terreno sobre el que apoya su trabajo: un catálogo de API internas al día le ahorra los rodeos que fabrican la incoherencia; unos tests que llevan la intención de negocio le devuelven un agarre sobre un código que no ha leído; una codebase cuyo lenguaje de negocio es legible decide por sí sola si compone con bloques existentes o apaña algo al margen del producto; y unos controles de seguridad automáticos sostienen la única exigencia que no se negocia ni con lo que está en juego ni con el plazo. Allí donde faltan esas cuatro piezas, la misma persona, con la misma competencia y la misma herramienta, solo produce objetos que no sabrá ni explicar ni reparar; y su competencia técnica, cuando la tiene, solo retrasa el momento en que eso se ve. El terreno fija por tanto a la vez el perímetro autorizado y la velocidad alcanzable, lo que coloca la apertura del código a los perfiles de producto entre las decisiones de arquitectura antes de convertirla en una cuestión de habilitación.

Síntesis

Las notas tomadas por separado describen cada una una pieza del problema: la velocidad, los defectos que el asistente crea solo, la autorización, la revisión, los tests, los raíles, el papel de los desarrolladores. Lo que hacen aparecer juntas es un desplazamiento del parámetro de decisión. La discusión corriente gira en torno a la persona: ¿tiene bastante bagaje técnico?, ¿hace falta un nivel mínimo?, ¿hay que prohibirlo a los perfiles no técnicos? Cada nota, tomada por su extremo, remite a otro sitio: a lo que se preparó antes que ella.

El mecanismo es el mismo cada vez, y depende de una propiedad del asistente: no adivina lo que no está escrito en ninguna parte. Desconoce las volumetrías reales, así que diseña para el juego de pruebas. No conoce los puntos de entrada legítimos, así que se los inventa. No retiene lo que se le corrigió ayer, así que vuelve a empezar. Ninguna de esas carencias se cubre con la competencia de quien pilota; todas se cubren con una información colocada en el entorno, y eso es lo que traslada la responsabilidad al lado de quienes sostienen ese entorno.

Se sigue de ahí una consecuencia menos esperada. La competencia técnica de quien pilota sigue siendo útil, pero su empleo cambia: ya no sirve para producir, sirve para detectar — ver un archivo que engorda demasiado, notar una capa que se mezcla con otra, reconocer una respuesta de API que no aguantará la carga. Esa capacidad de detección no tiene ningún sustituto automático, y es lo único que el terreno no proporciona. Explica por qué la cuestión del perímetro no desaparece: un terreno excelente amplía lo que es factible sin volver al operador capaz de evaluar lo que produce.

Queda lo que este ángulo le cuesta a la organización. Desplazar la decisión hacia el terreno equivale a decir que la apertura del código a otras funciones se paga primero en trabajo de arquitectura —API limpias, convenciones sostenidas, entornos seguros, controles automáticos—, es decir, en gastos sin entregable visible para el cliente. Es la línea más fácil de recortar, y es sin embargo la que decide si la apertura produce alivio o chapuza. La pregunta "¿pueden desarrollar los Product Managers?" no tiene por tanto respuesta general: tiene una por empresa, y esa respuesta se escribió antes de que se planteara, en el estado de su codebase.

Tensiones / contradicciones

Estas notas no se ponen de acuerdo sobre el peso real de la competencia individual. Las que desplazan la decisión hacia el terreno suponen que las carencias del asistente se cubren con el entorno; la que describe la explotación de una herramienta recuerda que saber diagnosticar una avería no se escribe en ningún catálogo de API. Si esa parte es grande, el terreno no es más que una condición necesaria y la competencia sigue siendo el factor limitante.

Un desacuerdo más nítido enfrenta dos lecturas de la aceleración. El ángulo defendido aquí trata la velocidad como un beneficio que hay que encuadrar, y considera que los mecanismos perdidos se reinstalan mediante el terreno. La lectura desarrollada en otro sitio sobre la fabricación de la competencia sostiene que algunos de esos mecanismos —el error analizable, el primer escalón, el precio del gesto— no se reinstalan con un utillaje, porque exigían haber sido responsable del resultado. Nada zanja aquí: un terreno que suprime los rodeos suprime también las ocasiones de aprender a reconocerlos.

Por último, la exigencia de seguridad no graduada y el aligeramiento de la revisión sobre los objetos desechables conviven mal en la práctica: piden a la misma organización que afloje un control humano y sostenga un control automático, lo que supone un utillaje que las organizaciones que aflojan la revisión a menudo no tienen.

Preguntas

• ¿Qué parte del terreno debe construirse antes de abrir, y qué parte se construye en respuesta a los primeros usos, a riesgo de dejar pasar los objetos fabricados entretanto?
• ¿Divergen un terreno pensado para los asistentes y un terreno pensado para los desarrolladores humanos, y en qué momento hay que mantener dos?
• ¿Cómo evalúa una organización el estado de su propio terreno antes de abrir, de otro modo que constatando a posteriori lo que se ha producido?
• ¿En qué se funda la decisión de invertir en ese trabajo de arquitectura, cuando su beneficio se mide en incoherencias que no han llegado a producirse?