Hay un momento en el que todos los equipos de ingeniería llegan en los que la IA deja de ser un experimento interesante y pasa a ser una infraestructura de carga. No lo planeas. Un día te das cuenta de que tus suposiciones sobre la velocidad han cambiado, tu postura de revisión del código ha cambiado y los miembros de tu equipo están tomando decisiones diferentes a las de hace dieciocho meses.
Hemos llegado a ese momento en Rokt. Aún no hemos terminado de hacerlo. Pero ya hemos recorrido lo suficiente como para poder describir cómo son realmente las etapas desde dentro. Eso es diferente de lo que parecen en las publicaciones de blog y en las conferencias.
Etapa 1: Autocompletar
Aquí es donde casi todo el mundo comienza y donde un sorprendente número de organizaciones se detienen silenciosamente.
En esta etapa, la IA es un truco de productividad para las personas. Finalización de pestañas que comprende el contexto. Generación estándar. La función ocasional del cuerpo que sale casi exactamente bien. Los ingenieros que invierten tiempo en aprender a avisar con precisión son más rápidos. Los ingenieros que no lo hacen, no lo hacen.
La estructura organizacional no cambia. Los procesos de revisión no cambian. La arquitectura no cambia. Obtiene beneficios individuales con una herramienta, de la misma manera que un portátil más rápido le brinda beneficios individuales.
El error que cometen los equipos aquí es llamar a esto transformación. No lo es, es eficiencia. No son lo mismo.
Etapa 2: copiloto
El cambio al copiloto tiene menos que ver con las herramientas y más con la conversación.
En esta etapa, la IA participa en las discusiones de diseño. No solo le estás pidiendo que complete el cuerpo de una función. Le está pidiendo que revise su enfoque antes de crearlo, que identifique los casos extremos en sus especificaciones y que retrase sus decisiones de arquitectura. Los ingenieros que son buenos en esto se mueven notablemente más rápido que los que no lo hacen.
La señal visible es una brecha cada vez mayor entre los miembros del equipo que tratan a la IA como un compañero de pensamiento y los que la tratan como un generador de código. Ambos campamentos utilizan las mismas herramientas. La diferencia es lo que piden.
La habilidad rápida se convierte aquí en una verdadera división de habilidades. «Escríbeme una función que haga X» es un mensaje generador de código. «Este es mi enfoque actual, esta es la restricción con la que estoy trabajando, esto es lo que no estoy seguro: ¿qué es lo que me falta?» es un mensaje de copiloto. Las salidas están en diferentes ligas.
La calidad de tus especificaciones también empieza a importar más. La basura que entra y la basura que sale se aplica en ambas direcciones. Los ingenieros que escriben el contexto más claro obtienen el resultado más útil. Aquellos que quieren que la IA averigüe los requisitos a partir de entradas vagas obtienen un código vago.
Etapa 3: Coautor
Esta es la etapa en la que ocurre el cambio de identidad y es la más incómoda.
En la fase de coautoría, los agentes de IA participan en todo el ciclo de vida del desarrollo: sugieren, implementan, ejecutan conjuntos de pruebas, repiten los errores y generan relaciones públicas. El rol humano comienza a pasar de la construcción a la crítica, de la escritura a la dirección.
La mayoría de las organizaciones de ingeniería se estancan aquí, no porque las herramientas no funcionen, sino porque la cultura no se ha puesto al día. Los ingenieros que han dedicado su carrera a valorar la artesanía (la función elegante, la abstracción limpia, el ciclo bien invertido) de repente descubren que lo que están evaluando no es su código. Es su opinión sobre el código que escribió otra persona. Algo más. De repente, comienzan a parecerse mucho más a los clientes potenciales y mucho menos a su modelo mental de un colaborador individual.
Las organizaciones que superan esta etapa más rápido son las que otorgan un permiso cultural explícito para el cambio de roles. En Rokt, eso significaba ser directo con nuestros equipos: tu trabajo ya no es escribir código. Se trata de expresar la intención con claridad, verificar rigurosamente la producción y ser dueño de los resultados de lo que se envía. El código va más allá de eso. El código se convierte en una herramienta entre muchas otras para generar resultados para los clientes.
Los requisitos arquitectónicos también resultaron ser muy importantes en este caso. Los servicios que se implementan de forma independiente, son propietarios de sus datos y exponen los contratos en lugar de los internos son seguros desde el punto de vista de la arquitectura para el desarrollo de las agencias. Los sistemas estrechamente acoplados no lo son. No puedes dejar que los agentes operen de forma segura en una base de código en la que un cambio en un lugar puede derivar de forma impredecible en otros diez. Ya habíamos optado por la encapsulación, y esa inversión dio sus frutos de maneras que no anticipamos del todo cuando la hicimos.
Etapa 4: Supervisor
Aquí es donde el rol de desarrollador converge con el rol de gerente de ingeniería, y cambia el aspecto real del talento sénior de ingeniería.
En la etapa de supervisor, no estás revisando líneas de código. Usted gobierna una flota de agentes: establece la intención, revisa la dirección, hace cumplir las normas, está atento a la deriva. Las habilidades que importan son las que siempre han sido importantes para una buena gestión de ingeniería. Comunicación clara de lo que es bueno. Juicio sobre qué aceptar y qué devolver. Conciencia del riesgo sistémico.
Los ingenieros que sobresalen aquí no son necesariamente los que escribieron el mejor código. Son los que se comunican con mayor precisión. Quién puede observar 400 líneas de resultados generados e identificar rápidamente las tres cosas que están mal. Que entiendan el sistema de manera integral lo suficientemente bien como para encontrar una solución técnicamente correcta que es arquitectónicamente incorrecta. Los que pueden enfrentar a dos agentes entre sí y juzgar rápidamente el resultado ganador.
Claire Southey, nuestra directora de IA, lo expresó bien recientemente:
La habilidad que definirá a los futuros equipos de software no será la cantidad de código que escriban, sino la claridad con la que expresen su intención, pasen de la ambigüedad a la claridad y controlen el impacto de lo que crean.
Esa es la descripción del trabajo de un supervisor. Describe los circuitos integrados sénior y los líderes de nuestros equipos más rápidos en este momento. Nuestro camino en esta transición es hacer que se aplique a todos, desde el graduado universitario más rudo hasta nuestros ejecutivos.
Qué hace que las transiciones se mantengan
Algunas cosas han importado más de lo que esperábamos.
Un camino pavimentado. Las herramientas aprobadas con buenos valores predeterminados eliminan la fricción y eliminan la decisión de cada equipo de «qué herramienta debo usar». No queríamos quince configuraciones de codificación de IA diferentes en ingeniería. Hicimos del buen camino el camino fácil.
Aprendizajes compartidos. Los ingenieros que avanzaron en cada etapa aprendieron primero las cosas que el resto de la organización necesitaba. Creamos mecanismos para sacar a la luz esos aprendizajes rápidamente, a través de canales asincrónicos en lugar de hacerlo trimestralmente fuera de las instalaciones, de modo que las personas pudieran ver lo que funcionaba en tiempo real.
Medición. Aplicamos el mismo rigor a la adopción interna de la IA que aplicamos a las decisiones sobre los productos: instrumentación, grupos de control, criterios claros de éxito. «Parece más rápido» no es una métrica. Medimos la producción asistida por la IA (duración de los ciclos, ciclos de revisión, tasas de defectos) para poder ver si realmente estábamos mejorando o simplemente nos sentíamos como si lo estábamos haciendo.
Las transiciones entre etapas no son automáticas. Requieren decisiones deliberadas sobre cómo se estructura el trabajo, para qué habilidades se contrata y en qué se pide a los ingenieros que se conviertan. Las organizaciones que consideran la transición como algo pasivo (compran las herramientas, esperan a que la cultura siga su ejemplo) se quedan estancadas entre etapas y se preguntan por qué no se materializa el ROI.
Las herramientas están bien y siguen mejorando. El cuello de botella son casi siempre las decisiones organizacionales que los rodean. En esta etapa, la tecnología avanza más rápido que la cultura. Mi trabajo como líder de ingeniería es garantizar que la cultura pueda mantenerse al día.
En Rokt, tomar esas decisiones correctamente se ha agravado. La misma cultura de ingeniería que hizo viable el desarrollo de agencias es lo que nos permite avanzar tan rápido como lo hacemos en lo que respecta al producto: modelos de envío que se vuelven más inteligentes con cada transacción, creación de una infraestructura de personalización que funcione en milisegundos e iterar las cosas que son importantes para nuestros clientes sin el lastre de la inercia organizacional. Las etapas anteriores no son abstractas. Nos basamos en ellos.
Melissa Benua es vicepresidente de experiencias de desarrolladores en Rokt.
.jpg)
.jpg)
