Lo que la IA no puede verificar: por qué todo va hacia el product engineer
Jorge Saavedra11 min de lectura
Una IA recibe una tarea grande y la ejecuta completa. Al terminar, el reporte es impecable: el build pasa, los tests están en verde, midió el contraste de cada par de colores y ninguno baja del mínimo de accesibilidad, no hay una sola regresión medible. Cada afirmación del reporte es verdadera y comprobable.
Alguien abre la pantalla y dice que no sirve.
No hubo un error. Todo lo verificable estaba verificado y el resultado seguía estando mal. La decisión que faltaba no era técnica: era si eso valía la pena, y esa no aparece en ningún reporte.
Esa distancia entre "está correcto" y "sirve" es de lo que va este post. Es pequeña cuando el código es caro de escribir, porque casi todo el esfuerzo se va en producirlo. Y se vuelve enorme cuando producirlo deja de ser el problema.
Los dos tipos de "correcto"
Hay una diferencia que casi nunca hacemos explícita, y que explica bastante de lo que está pasando con el oficio. Existen dos formas de que algo esté bien, y solo una de ellas se puede comprobar sola.
La primera es el correcto verificable. Existe una función que toma tu resultado y devuelve verdadero o falso. Compila o no compila. El test pasa o falla. El contraste da 4.7:1 o da 2.5:1. El p99 está bajo 200ms o no lo está. No hace falta discutirlo: se ejecuta y se sabe.
La segunda es el correcto de producto, y ahí esa función no existe. ¿Esto se entiende sin explicarlo? ¿Alguien lo va a usar? ¿Resuelve el problema que la persona tenía, o el que nosotros creímos que tenía? ¿Valía la pena construirlo en vez de las otras cinco cosas que estaban en la lista? No hay comando que responda eso.
Dónde está la señal y dónde no
La IA es extraordinaria en la columna izquierda, y no por una razón mística. Es que ahí hay una señal de retorno: puede correr el test, leer el resultado, corregir y volver a correrlo. Tiene con qué saber si va bien.
En la columna derecha no hay nada que ejecutar. Y esto no es falta de contexto ni un problema que se arregle con un modelo más grande: la respuesta depende de para quién es el producto, qué se está jugando la empresa este trimestre y qué se decidió deliberadamente no hacer. Es información que vive en las cabezas de las personas y en decisiones que nadie escribió.
Por qué esto mueve el rol
Durante mucho tiempo escribir código fue caro y lento, así que escribirlo bien era la ventaja competitiva. Ser rápido, ser preciso, conocer el lenguaje a fondo, no dejar bugs: todo eso se traducía directamente en valor, porque la producción era el cuello de botella.
Producir código bajó de precio. No a cero, y no en todos los casos, pero bajó lo suficiente como para que deje de ser lo que limita. Y cuando el costo de producir algo baja, el cuello de botella se mueve hacia arriba: hacia decidir qué producir.
Ahí está la incomodidad. Un ingeniero que recibe un ticket bien definido y lo convierte en un pull request correcto está haciendo, con enorme precisión, exactamente aquello en lo que la máquina es buena y barata. No es que ese trabajo desaparezca mañana. Es que dejó de ser donde se gana.
Esto no mata al staff engineer
La lectura fácil de todo lo anterior es que el track técnico se acabó y que ahora todos tenemos que volvernos medio product managers. Me parece falsa, y vale la pena desarmarla.
La IA no devalúa la ingeniería. Devalúa la implementación de decisiones ya tomadas. Y el staff engineer nunca vivió de eso. Su valor siempre estuvo en el juicio, solo que en otro eje: qué arquitectura sostiene los próximos tres años, qué complejidad no vale la pena pagar, qué migración no hacer, dónde poner el límite entre dos servicios. Nada de eso tiene una función que devuelva verdadero o falso.
Los dos roles hacen el mismo trabajo en ejes distintos, y la pregunta de fondo es la misma:
- Staff engineer: ¿vale la pena este sistema? Profundidad, escala, costo técnico, lo que vamos a estar manteniendo en tres años.
- Product engineer: ¿vale la pena este producto? Resultado, usuario, negocio, lo que pasa si nadie lo usa.
Lo que se achica no es ninguno de los dos extremos: es el medio. La franja donde el valor era convertir especificaciones claras en código correcto. Ahí es donde hay presión real, y ahí es donde conviene no quedarse.
Y hay un solapamiento que crece entre los dos. El staff que no entiende el producto propone arquitecturas elegantes para problemas que nadie tiene. El product engineer sin criterio técnico pide cosas que cuestan diez veces lo que valen. Los dos fallan por lo mismo: por juzgar en un solo eje.
Qué hace distinto a un product engineer
Dejando de lado el título del puesto, que cambia según la empresa, hay cinco comportamientos bastante concretos que separan a alguien que trabaja así de alguien que no.
1. Cuestiona el requerimiento antes de estimarlo
Ante un ticket, la primera pregunta no es cuánto toma sino qué problema resuelve y de quién es ese problema. Muchas veces el requerimiento es una solución ya elegida disfrazada de necesidad: alguien pide un botón de exportar cuando el problema real era que no confía en el dato que ve en pantalla. Estimar el botón es fácil. Notar que el botón no arregla nada es el trabajo.
2. Sabe qué número se movería
Si esto funciona, ¿qué cambia y cómo lo veríamos? Puede ser una métrica de negocio, un tiempo de soporte, una tasa de error. Lo importante no es tener un dashboard: es que exista una respuesta antes de escribir la primera línea. Si nadie sabe qué debería moverse, tampoco vamos a saber si sirvió. De eso ya escribí en el post de experimentación.
3. Decide qué no construir
Esta es la más difícil de todas, porque no deja evidencia. Nadie te felicita por la feature que convenciste al equipo de no hacer, aunque probablemente sea lo más valioso que hiciste ese trimestre. Cada cosa que no se construye es código que no hay que mantener, un caso borde que no hay que probar y una decisión que no hay que revertir después.
4. Mira el resultado, no el diff
Revisar el pull request no es lo mismo que abrir la pantalla y usar la cosa. El diff te dice que el cambio hace lo que dice hacer. Solo el resultado te dice si eso era lo que hacía falta. Esta distinción era importante antes y se volvió crítica ahora, porque el volumen de código que se puede generar sin que nadie lo mire creció muchísimo.
5. Traduce sin perder precisión de ningún lado
Puede explicarle a negocio por qué esa fecha no es realista sin esconderse detrás de jerga, y puede explicarle al equipo por qué el negocio necesita eso sin repetir el pedido como loro. Traducir mal en cualquiera de las dos direcciones es la fuente de la mitad de los proyectos que salen tarde y sirven poco.
No es "ser menos técnico"
El malentendido más común con este rol es leerlo como el ingeniero que se fue ablandando: menos código, más reuniones, más diapositivas. Es exactamente al revés.
Para decidir qué no construir hay que saber con precisión qué cuesta construirlo, y eso es una pregunta técnica. Cuando alguien pregunta si se puede agregar filtrado por doce campos en esa pantalla, la respuesta útil no es sí ni no: es entender la cardinalidad de esos campos, qué índices existen, qué le pasa a esa query cuando la tabla tenga cien veces más filas, y si el problema real se resolvía con dos filtros en vez de doce.
Intuición de producto sin criterio técnico es una lista de deseos. Criterio técnico sin producto es una arquitectura impecable para un problema que nadie tenía. El rol vive justo en la intersección, y por eso es difícil.
Un buen spec no te salva
Podría parecer que la conclusión de todo esto es escribir mejores especificaciones. Sobre eso ya escribí en Spec-Driven Development, y sigo pensando lo mismo: especificar bien es necesario. Pero no es lo que faltaba en la historia del principio.
Un spec elimina la ambigüedad sobre qué construir. No te dice si ese qué era el correcto. El spec captura la decisión, no su calidad: si la decisión era mala, un buen spec la ejecuta con más precisión y más rápido, que es exactamente lo contrario de lo que uno quiere cuando va en la dirección equivocada.
Por eso el modo de falla interesante no es el spec vago. Ese ya lo conocemos y sabemos arreglarlo. El interesante es el spec bien escrito de la cosa equivocada: nadie puede detectarlo leyendo el documento, porque el documento es coherente. Solo aparece al mirar el resultado.
El reporte en verde es el punto ciego
Un reporte que dice que todo pasó se siente como si alguien hubiera revisado. Y alguien revisó: revisó todo lo que se podía revisar solo. La sensación de control es real, la cobertura no. En la historia del principio nadie abrió la pantalla mientras se acumulaba el trabajo, y cada reporte intermedio decía que iba bien.
El lazo no se cierra en el documento ni en el reporte. Se cierra mirando. Y mirar es barato: es la parte del proceso que más se salta justamente porque parece que no aporta nada cuando todo viene en verde.
Las dos preguntas
Todo esto se puede resumir en dos preguntas que parecen la misma y no lo son:
- ¿Está bien hecho?
- ¿Valía la pena hacerlo?
La primera cada vez la contesta mejor una máquina, y va a seguir mejorando. La segunda sigue necesitando a alguien que sepa para quién es esto, qué se está jugando y qué se decidió no hacer. Esa persona puede llamarse product engineer, staff engineer o no llamarse de ninguna forma en particular. Lo que importa es que exista, y que abra la pantalla antes de que sea tarde.
