Funciones generadas por IA: revisa su encaje en el producto

Revisar una función generada por IA desde el punto de vista del producto consiste en comprobar si un cambio resuelve un problema real del cliente, tiene un alcance claro, funciona durante todo el recorrido del cliente y cuenta con alguien que se responsabilice de comprobar el resultado. La verificación técnica sigue siendo necesaria. Estas preguntas te ayudan a decidir si el cambio tiene cabida en tu producto antes de publicarlo.

Un agente puede preparar una demostración convincente antes de que hayas tomado esa decisión. Puedes pulsar el nuevo botón, examinar la implementación y dar por buenas las pruebas. Aun así, quizá estés añadiendo una segunda forma de realizar una tarea que ya se podía hacer, un ajuste que nadie entiende o un paso que carga de trabajo a otra persona.

En Someone behind the software, publicado el 15 de octubre, Karri Saarinen, cofundador de Linear, expresa su preocupación por los cambios que, aun teniendo sentido por separado, debilitan una visión compartida del producto. El ensayo suscitó una animada conversación en Hacker News. Es el argumento de alguien con experiencia en el oficio; no demuestra que los agentes empeoren los productos en general.

Conviene preguntarse qué revisar cuando la implementación llega antes de que se haya tomado una decisión firme sobre el producto. Proponemos un proceso de revisión con cuatro comprobaciones. Recoge consejos de YC para conocer los problemas de los clientes y prácticas de gestión de proyectos de Shape Up, de Basecamp. La combinación es una recomendación nuestra: no tiene una tasa de éxito medida ni pretende contar con validación científica.

¿Por qué una función que funciona puede debilitar un producto?

Una función puede cumplir su especificación y, a la vez, dificultar la tarea de la que forma parte. La coherencia del producto implica que sus piezas permitan hacer algo de una manera comprensible, incluido lo que ocurre antes y después de la nueva interacción.

Imagina que añades un acceso directo para cambiar la hora de una entrevista. El acceso funciona. Pero el candidato recibe un mensaje distinto del que ve el reclutador y un enlace antiguo sigue mostrando la hora anterior. Cada pantalla puede parecer razonable y, sin embargo, el conjunto deja a las personas sin saber qué hora es la válida.

Saarinen relaciona el criterio sobre el producto con la experiencia, las conversaciones con los clientes y la atención a cómo encajan las piezas. Eso permite debatir algo más concreto que si una función da buena impresión. Pregúntate qué expectativas previas modifica y si las personas afectadas pueden seguir completando su tarea.

Puedes aplicar esa pregunta al trabajo de una persona, un agente o ambos. Lo que justifica la revisión es la propuesta de cambiar el producto. Quién haya escrito el código no determina si el cambio tiene cabida.

Ajusta la revisión a la magnitud del cambio. Corregir una etiqueta puede requerir una breve explicación y una captura de pantalla. Una nueva vía para programar citas necesita pruebas de las interacciones a las que afecta. Las cuatro comprobaciones siguientes ayudan a tomar esa decisión; no exigen crear un nuevo comité de aprobación para cada retoque.

¿Qué problema del cliente resuelve este cambio?

Empieza por una situación real en la que un usuario haya tenido dificultades. Anota qué intentaba hacer, dónde se atascó y cómo se las arregló con el producto actual.

En el resumen y la transcripción de Startup School de YC, Eric Migicovsky recomienda preguntar por una ocasión anterior en la que la persona se encontró con un problema y por lo que ya ha intentado para resolverlo. Esas preguntas aportan material que examinar más allá de su reacción a la solución que propones.

Al revisar una función, adjunta una conversación con soporte, una sesión observada o un ejemplo de un cliente descrito con claridad. Distingue lo observado de tu interpretación. «El reclutador copió la nueva hora en dos mensajes» describe una conducta. «Necesitamos un asistente de IA para programar entrevistas» propone una solución de mucho mayor alcance.

Identifica a la persona afectada con la precisión que requiera la tarea. Un candidato que cambia su propia reserva tiene necesidades distintas de las de un reclutador que coordina a varios entrevistadores. Llamar a ambos «el usuario» puede ocultar el relevo entre personas que necesitas entender.

Las pruebas pueden justificar una mejora concreta y dejar dudas sobre la oportunidad más amplia. Una situación vivida por un cliente puede revelar una interacción confusa; no permite determinar lo habitual que es ese problema en el mercado. Explica qué sabes, qué deduces y qué sigue sin respuesta.

Si la función nació de una demostración, todavía puedes investigar el problema. Observa cómo alguien intenta realizar la tarea actual antes de enseñarle el cambio propuesto. Puede que descubras que basta con un texto más claro o con un enlace que ya existe. También puedes detectar una necesidad más profunda que la demostración pasó por alto.

La comprobación: ¿puedes describir la dificultad del cliente sin mencionar la función? Si para responder solo puedes describir lo que ha construido el agente, investiga el problema antes de ampliar la implementación.

¿Qué renuncias permiten acotar la función?

Define el resultado útil y la complejidad que estás dispuesto a aceptar. Indica expresamente qué queda fuera para delimitar la revisión.

El capítulo Set Boundaries de Shape Up explica cómo fijar cuánto se está dispuesto a dedicar a un proyecto y acotar el problema dentro de ese límite. Su ejemplo del calendario distingue entre la necesidad de ver huecos disponibles y la idea, mucho más amplia, de construir todo lo que podría hacer un calendario.

Aplica la misma distinción al revisar una función. «Ayudar a un candidato a encontrar el proceso existente para cambiar una cita» es un resultado acotado. «Programar entrevistas sin esfuerzo» deja espacio para nuevos calendarios, permisos, recordatorios, preferencias y excepciones, sin precisar qué parte importa ahora.

Anota la alternativa que has considerado. ¿Podrías mejorar el recorrido actual, eliminar un paso confuso o corregir el mensaje que lleva hasta él? Comparar una función nueva con el producto sin cambios se lo pone fácil a la nueva función. Compararla con una corrección útil y más pequeña permite ver qué ganas y a qué renuncias.

Después, indica qué descartas. En el ejemplo de las entrevistas, podrías excluir cambios en la asignación de entrevistadores o en la política de notificaciones. Esa exclusión resulta útil cuando aparece una idea relacionada y atractiva durante la implementación: permite decidir si las nuevas pruebas justifican revisar el alcance.

Ten en cuenta también el coste a largo plazo. Alguien tendrá que explicar la función, mantener sus estados, traducir sus mensajes y atender sus fallos. No necesitas un modelo financiero especulativo para cada botón. Sí necesitas advertir cuándo un acceso directo crea otra interacción que tu equipo debe mantener en consonancia con el resto.

La comprobación: ¿puedes explicar por qué merece la pena mantener esta versión frente a la alternativa más pequeña? Si sigue sin estar claro, reduce o replantea la propuesta. Aunque decidas no publicarla, la implementación que funciona sigue sirviendo para aprender.

¿Sigue teniendo sentido el proceso completo?

Prueba el cambio como parte de una tarea real, incluido el estado guardado y lo que experimenta la siguiente persona. Una pantalla cuidada o un componente aislado no muestran toda la interacción.

El capítulo Get One Piece Done de Shape Up propone integrar una parte utilizable para que las personas puedan probarla. Aplica esa idea a la revisión: sigue la tarea desde lo que la pone en marcha hasta el relevo a la siguiente persona.

Si el cambio afecta a la modificación de citas, empieza donde el candidato recibe realmente la invitación. Sigue el enlace, elige una hora, guárdala y vuelve a la reserva. Después, examina qué ve el reclutador y qué mensajes recibe cada participante. Comprueba que el resultado se conserva al salir de la página.

Elige los casos difíciles según el cambio. Un hueco puede dejar de estar disponible antes de la confirmación. Un candidato puede volver a abrir un enlace antiguo. Un entrevistador puede cancelar mientras otra persona tiene la página abierta. No puedes agotar todas las posibilidades en una prueba del recorrido, pero sí descubrir supuestos que merecen una verificación técnica.

Examina también el resto de la experiencia. ¿La nueva vía usa etiquetas conocidas? ¿Es posible recuperarse de un error? ¿Puede la persona correspondiente realizar la acción en una pantalla pequeña? ¿El acceso sigue dependiendo de la cuenta correcta o de la autorización para esa reserva?

Sé preciso al describir las pruebas. Una grabación permite establecer lo que ocurrió en el recorrido grabado. Las pruebas automatizadas comprueban el comportamiento dentro de los límites de sus aserciones y su configuración. Ninguna de las dos justifica afirmar de forma general que todo el producto funciona correctamente.

Esto guarda relación con la práctica de probar las instrucciones de un ejercicio de código con alguien que las lee por primera vez: observar a alguien seguir el recorrido real puede revelar carencias que el autor ya no percibe. En este caso, la decisión abarca también si la función encaja en el conjunto del producto.

La comprobación: ¿puede la persona a la que va dirigida completar la tarea prometida y puede la siguiente persona entender el resultado? Si falla el relevo, repáralo o reduce lo que prometes antes de publicar el cambio.

¿Quién se responsabiliza del resultado después del lanzamiento?

Asigna a una persona la responsabilidad del cambio y concreta qué se observará después. Esa responsabilidad debe mantenerse hasta averiguar si el cambio ha ayudado.

En Hand Over Responsibility, Shape Up describe cómo asignar un proyecto completo y acotado a un equipo que decide las tareas necesarias. Eso permite trabajar con autonomía dentro de unos límites claros. El fundador no necesita aprobar cada decisión de implementación para mantener la coherencia del producto.

Identifica a la persona que pueda responder a las preguntas sobre la decisión, reunir a quienes corresponda y actuar según lo que ocurra después. Puede ser alguien de producto, diseño o ingeniería, o el fundador. El equipo puede compartir el trabajo y mantener a la vez un punto de contacto claro.

Elige qué observar en relación con el problema original. Si los candidatos no encontraban cómo cambiar una reserva, comprueba si ahora pueden completar esa tarea y si cambian las conversaciones con soporte sobre ella. Contar únicamente los clics en el nuevo botón deja sin respuesta la pregunta original.

En productos con poco uso, volver a hablar directamente con los clientes afectados puede aportar más que un panel de métricas. En procesos con más actividad, también puedes examinar los registros de tareas completadas y de fallos. En ambos casos, evita tratar un cambio posterior al lanzamiento como prueba de una relación causal si también han cambiado otras condiciones.

Decide qué justificaría volver a modificar o retirar la función. Quizá el acceso directo genere confusión, duplique una vía existente o traslade el trabajo de coordinación a los reclutadores. Son motivos para reconsiderar la decisión sobre el producto, aunque la implementación siga siendo técnicamente correcta.

Si también evalúas la rentabilidad de los agentes, hazlo de forma explícita. El coste por resultado aceptado aborda la rentabilidad de la prueba piloto. La revisión que proponemos aquí pregunta si este resultado concreto merece aceptarse.

La comprobación: ¿quién volverá al problema original del cliente y qué examinará? Asigna esa responsabilidad antes de publicar el cambio para que la pregunta no se olvide tras el lanzamiento.

Aplica las cuatro comprobaciones a un cambio de cita

Considera esta propuesta hipotética: un agente añade un botón destacado para cambiar la cita en la página de confirmación de una entrevista. Es un ejemplo desarrollado; no describe un incidente de Kit ni anuncia una función.

El punto de partida es una conversación con un cliente que describe la dificultad para encontrar la vía existente. La propuesta podría resolver ese problema. Todavía no demuestra que haga falta un nuevo mecanismo para programar entrevistas.

Al comprobar el alcance, compara el botón destacado con una versión más clara del enlace existente. Supongamos que ambos llevan al mismo proceso actual para cambiar una cita. Así puedes evaluar lo fácil que resulta encontrarlo sin rediseñar también la selección de horarios disponibles o de participantes. Deja constancia de esa decisión en la descripción de la revisión.

Al comprobar el proceso, sigue el recorrido tanto cuando el cambio se completa como cuando falla un intento. Examina la reserva guardada, lo que ocurre cuando vuelve el candidato, la vista del reclutador y las notificaciones. Comprueba qué muestra una invitación antigua después de cambiar la hora. Un botón que lleva a la página correcta solo ha superado la primera parte de esta revisión.

Estas dependencias son concretas en el código actual de programación de citas de Kit. Para cambiar una cita, se comprueban los plazos, el estado de la reserva y la disponibilidad del organizador y de los participantes, se actualizan la reserva guardada y la secuencia del calendario, y se ponen las notificaciones en cola. Esto describe las responsabilidades de la implementación; no garantiza que se entregue cada mensaje externo. Explica por qué un cambio aparentemente pequeño en el producto exige examinar la tarea de la que forma parte.

Al comprobar la responsabilidad, identifica quién examinará los intentos posteriores y los comentarios relacionados. Esa persona debe saber si se resolvió la dificultad original del candidato y si dar más visibilidad a la opción crea otro problema. Por ejemplo, que alguien espere poder cambiar una reserva que ya no admite modificaciones.

El documento de revisión puede ser breve:

Usa decisiones como aceptar, reducir el alcance, investigar o descartar. Una puntuación numérica daría a estas preguntas una precisión que no tienen. Cuando dejes un cambio pendiente, indica qué pruebas faltan y cuál es la siguiente acción para que el equipo pueda tomar una decisión.

Aplica el mismo criterio a tu proceso de selección

La selección de personal hace tangible la coherencia del producto porque la acción de un candidato cambia lo que el equipo debe hacer a continuación. Las horas de las entrevistas, el avance por las etapas, las expectativas de los participantes y los mensajes deben concordar para que el proceso tenga sentido.

Kit ofrece procesos de contratación y programación de citas en los que esas conexiones importan. No incorpora las comprobaciones de revisión de producto aquí propuestas, ni valida la investigación con clientes, ni certifica funciones creadas por agentes. Tu equipo sigue siendo responsable de decidir qué cambios tienen cabida y comprobar sus efectos.

Antes de aceptar tu próxima función, anota el problema del cliente, las renuncias que delimitan el alcance, el recorrido completo y la persona responsable. Aporta pruebas proporcionales al cambio y toma la decisión. Si estás valorando un proceso de selección para tu startup, puedes probar Kit y examinar cómo encajan sus interacciones entre candidatos y equipo en tu proceso.