Lo que la IA no puede verificar: por qué todo va hacia el product engineer
Jorge Saavedra11 min de lectura
Le pides a tu agente el sistema de notificaciones push que el equipo tenía pendiente hace meses. Queda precioso, con reintentos, idempotencia, entrega en menos de un segundo, tests en verde y un reporte final que da gusto leer. Manda todo lo que el spec dice que mande, que sumado resultan ser seis notificaciones al día.
Al mes, la mitad de los usuarios las tiene desactivadas.
Lo curioso es que nadie se equivocó. El agente hizo lo que le pediste y lo hizo bien. Verificó todo lo que se podía verificar. Lo único que no tenía cómo saber era si alguien quería recibir seis notificaciones al día, y resulta que esa era toda la pregunta. El sistema funciona perfecto. Lo que no funcionaba era la idea, y eso ningún test lo iba a atrapar.
Esa distancia entre "está correcto" y "sirve" siempre existió, pero cuando escribir código costaba mucho pasaba desapercibida, porque casi todo el esfuerzo se iba en escribirlo. Ahora que escribirlo cuesta poco, la distancia sigue ahí y ya no hay nada que la tape.
Los dos tipos de "correcto"
Hay una diferencia que casi nunca decimos en voz alta y que explica bastante de lo que le está pasando al oficio. Algo puede estar bien de dos maneras, y solo una se puede comprobar sin que nadie mire.
La primera es el correcto verificable. Hay algo que toma tu resultado y te devuelve sí o no. 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 hay nada que discutir, lo corres y te enteras.
La segunda es el correcto de producto, y ahí no hay nada que correr. ¿Se entiende sin que nadie lo explique? ¿Alguien lo va a usar? ¿Resuelve el problema que la persona tenía, o el que nosotros creímos que tenía? ¿Valía más que las otras cinco cosas que estaban en la lista? Todavía no existe el comando que conteste eso, y créeme que lo he buscado.
Dónde está la señal y dónde no
La IA es buenísima en la columna de la izquierda, y no por magia. Ahí tiene cómo saber si va bien. Corre el test, lee el error, corrige y lo vuelve a correr, las veces que haga falta y sin aburrirse, que es más de lo que yo puedo decir de mí.
En la columna de la derecha no tiene nada que correr. Y no es que le falte contexto o que el próximo modelo lo vaya a resolver. La respuesta depende de para quién es el producto, de qué se está jugando la empresa este trimestre y de qué se decidió no hacer. Esa información vive en la cabeza de algunas personas y en decisiones que nadie se tomó la molestia de escribir. En el caso de las notificaciones, la respuesta estaba en la paciencia de cada usuario, y esa no viene documentada en ningún lado.
Por qué esto le mueve el piso al rol
Durante mucho tiempo escribir código fue caro y lento, así que escribirlo bien era la ventaja. Ser rápido, conocer el lenguaje a fondo, no dejar bugs. Todo eso se convertía directo en valor, porque el cuello de botella era producir.
Producir código se abarató. No es gratis ni pasa en todos los casos, pero bajó lo suficiente como para que ya no sea lo que te frena. Y cuando producir algo cuesta menos, el cuello de botella se muda más arriba, a decidir qué producir.
Ahí viene la parte incómoda. Si tu trabajo es recibir un ticket bien definido y convertirlo en un pull request correcto, estás haciendo con mucha precisión justo lo que la máquina hace bien y barato. Ese trabajo no desaparece mañana, así que no hace falta actualizar el CV esta noche. Pero ya no es donde se gana.
Esto no mata al staff engineer
La lectura fácil de todo esto es que el camino técnico se acabó y que ahora todos tenemos que volvernos medio product managers, con diapositivas y todo. No me la creo.
Lo que la IA abarata no es la ingeniería, es la implementación de decisiones ya tomadas. Y de eso el staff engineer nunca vivió. Lo suyo siempre fue el criterio, solo que aplicado a otras preguntas. Qué arquitectura aguanta los próximos tres años, qué complejidad no vale la pena pagar, qué migración es mejor no hacer, dónde cortar entre dos servicios. Ninguna de esas preguntas tiene un test que se ponga en verde.
Los dos roles hacen el mismo trabajo en ejes distintos, y en el fondo se preguntan lo mismo:
- Staff engineer: ¿vale la pena este sistema? Profundidad, escala, costo técnico, lo que vamos a tener que mantener dentro de tres años.
- Product engineer: ¿vale la pena este producto? Resultado, usuario, negocio, y qué pasa si nadie lo usa.
Lo que se achica no es ninguno de los dos extremos, es el medio. Esa franja donde el valor estaba en convertir especificaciones claras en código correcto. Ahí es donde aprieta de verdad, y ahí es donde yo no me quedaría a vivir.
Y los dos roles se cruzan cada vez más. El staff que no entiende el producto termina diseñando arquitecturas preciosas 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 mirar un solo eje.
Qué hace distinto a un product engineer
El título cambia según la empresa, así que no me voy a pelear por el nombre. Lo que sí veo son cinco cosas bastante concretas que hace la gente que trabaja así, y que el resto no.
1. Cuestiona el requerimiento antes de estimarlo
Ante un ticket, lo primero que pregunta no es cuánto toma sino qué problema resuelve y a quién le duele. Muchas veces el requerimiento es una solución que alguien ya eligió, disfrazada de necesidad. Te piden un botón para exportar a Excel cuando el problema real es que no confían en el número que ven en pantalla y lo quieren revisar a mano. Estimar el botón es fácil. Darse cuenta de que el botón no arregla nada es el trabajo.
2. Sabe qué número se movería
Si esto funciona, ¿qué cambia y dónde lo veríamos? Puede ser una métrica de negocio, lo que tarda soporte en cerrar un caso, una tasa de error. No hace falta un dashboard con veinte gráficos, basta con tener una respuesta antes de escribir la primera línea. Si nadie sabe qué debería moverse, tampoco vamos a saber si sirvió. Con las notificaciones se midió todo lo que era fácil de medir, cuántas salían y cuánto tardaban en llegar. Nadie miró cuánta gente las apagaba, que era el único número que decía si servían. De esto ya escribí en el post de experimentación.
3. Decide qué no construir
Es la más difícil de todas porque no deja rastro. Nadie te felicita por la feature que convenciste al equipo de no hacer, aunque haya sido lo más valioso que hiciste en el trimestre. No sale en la demo, no aparece en el changelog y en la evaluación de desempeño se ve igualito a no haber hecho nada. Pero cada cosa que no se construye es código que nadie tiene que mantener, un caso borde que nadie tiene que probar y una decisión que nadie tiene 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. Siempre fue importante, pero ahora lo es mucho más, porque la cantidad de código que se puede generar sin que un humano lo mire creció muchísimo. El PR de las notificaciones era de los que da gusto aprobar. Lo que nadie hizo fue instalar la app y recibirlas durante un día entero, como cualquier usuario.
5. Traduce sin perder precisión de ningún lado
Le puede explicar a negocio por qué esa fecha no es realista sin esconderse detrás de la jerga, y le puede explicar al equipo por qué negocio necesita eso sin repetir el pedido como loro. Cuando esa traducción falla, en cualquiera de las dos direcciones, tienes la receta 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 imaginarlo como el ingeniero que se fue ablandando. Menos código, más reuniones, más diapositivas, hasta que un día amanece hablando de sinergias. Es al revés.
Para decidir qué no construir tienes que saber con precisión cuánto cuesta construirlo, y esa es una pregunta técnica. Si alguien pregunta si se puede filtrar 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 lugar de doce.
Intuición de producto sin criterio técnico se queda en lista de deseos. Lo contrario ya lo vimos más arriba, con las arquitecturas preciosas para problemas que nadie tiene. El rol pide las dos cosas al mismo tiempo, y por eso es difícil de hacer bien.
Un buen spec no te salva
Podría parecer que la moraleja es escribir mejores especificaciones. De eso ya escribí en Spec-Driven Development y sigo pensando lo mismo, especificar bien es necesario. Pero no es lo que faltó en la historia del principio. El spec de las notificaciones era clarísimo, decía qué evento disparaba cuál, a qué hora y con qué texto. Y el agente lo cumplió al pie de la letra, seis veces al día.
Un spec quita la ambigüedad sobre qué construir, pero no te dice si ese qué era el correcto. Guarda la decisión, no su calidad. Si la decisión era mala, un buen spec la ejecuta más rápido y con más precisión, que es lo último que quieres cuando vas en la dirección equivocada.
Por eso la falla interesante no es el spec vago. Esa ya la conocemos y sabemos arreglarla. La interesante es el spec bien escrito de la cosa equivocada. Nadie la detecta leyendo el documento, porque el documento es coherente de principio a fin. Solo aparece cuando miras 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ó, pero solo lo que se podía revisar sin mirar. La sensación de control es real, la cobertura no. En la historia del principio, el reporte de entrega decía 99.9% todos los días, y todos los días era verdad.
El ciclo no se cierra en el documento ni en el reporte, se cierra mirando. Y mirar es barato. Es el paso que más nos saltamos, justamente porque cuando todo viene en verde parece que no aporta nada. Con las notificaciones bastaba que alguien del equipo las recibiera un día completo en su propio celular. Dudo que hubiera aguantado hasta la sexta.
Las dos preguntas
Todo esto cabe en dos preguntas que parecen la misma y no lo son:
- ¿Está bien hecho?
- ¿Valía la pena hacerlo?
La primera la contesta cada vez mejor una máquina, y va a seguir mejorando. La segunda todavía necesita 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 tener ningún título en particular. Lo que importa es que exista, y que se haga la segunda pregunta antes de que los usuarios la contesten por su cuenta, desde la configuración del celular.
