Lo mejor de ambos mundos desarrolladores humanos y colaboradores de IA

Lo mejor de desarrolladores humanos y colaboradores de IA

Cómo la IA generativa afectará a los equipos de ingeniería de producto – Parte 6 | Postscript

Esta es la parte final de una serie de seis partes que investiga cómo las herramientas de productividad de IA generativa dirigidas a desarrolladores, como Github Copilot, ChatGPT y Amazon CodeWhisperer, podrían afectar la estructura de equipos completos de ingeniería de productos.

En esta última parte, consideramos muchas de las complejidades que hemos dejado de lado en los artículos anteriores, el valor insustituible de los ingenieros humanos en la era de la IA y te dejamos con un llamado a la acción para que los líderes reflexionen, se adapten e innoven.

“Anteriormente en…”

Hemos recorrido un largo camino en esta serie y creo que vale la pena hacer un resumen rápido de lo que hemos cubierto en los cinco artículos anteriores, para poder presentar todo lo que no hemos cubierto hasta ahora:

En la Parte 1 vimos evidencia de que las herramientas de codificación de IA generativa como Copilot y ChatGPT tienen el potencial de mejorar significativamente la productividad de las personas en roles técnicos, como ingenieros y científicos de datos. Estas herramientas cambian el trabajo que se les pide a los desarrolladores al automatizar tareas tediosas, repetitivas y que consumen mucho tiempo. En teoría, elimina aspectos del trabajo del desarrollador que no disfrutan y hace que su trabajo valioso sea más rápido y fácil.

• ¡Atención Industria del Gaming! No más espejos extraños con Mirror-NeRF
• Optimización del tamaño del archivo de salida en Apache Spark
• GANs (Redes Generativas Adversarias)

En la Parte 2 consideramos que la mayor automatización de las tareas de los desarrolladores y una mayor productividad de los mismos podrían llevar a un cambio importante en la proporción de ingenieros a gerentes de productos en los equipos de productos. Históricamente, los equipos han tenido alrededor de cinco ingenieros por cada gerente de productos, pero con herramientas de IA generativa, esta proporción podría acercarse a 1:1.

En la Parte 3 vimos cómo los asistentes de codificación de IA generativa no solo tienen la capacidad de ayudar con aspectos básicos como refactorizar código o escribir pruebas. Exploramos cómo su impacto a largo plazo podría llevar a que las herramientas de IA refactoricen código heredado, incluyendo la creación de pruebas y documentación, y también simplificar algunas estructuras de equipos, como el desarrollo de aplicaciones móviles, que a menudo se creaban no por diferenciación de flujo de valor, sino simplemente porque las habilidades técnicas eran diferentes. También consideramos el posible impacto en los ingenieros junior y su desarrollo profesional.

En la Parte 4 consideramos cómo este cambio podría permitir a las empresas reducir drásticamente la cantidad de ingenieros sin reducir la producción, aumentar rápidamente la producción con el mismo presupuesto o alguna combinación de ambos. Comenzamos a modelar cómo la elección entre invertir en crecimiento, mantener el presupuesto o reducir costos podría afectar la cantidad de ingenieros y gerentes de productos.

En la Parte 5 investigamos cómo estos beneficios pueden afectar de diferentes maneras a diferentes tipos de empresas. Las nuevas startups deberían adoptar rápidamente las nuevas herramientas. Las empresas más grandes, que potencialmente tienen el mayor imperativo financiero para transformar las estructuras de sus equipos, tendrán dificultades para adaptarse debido a la inercia cultural, pero se les debe animar a comenzar a experimentar con herramientas y tomar sus propias decisiones estratégicas sobre cómo adoptarlas. También vimos cómo las empresas de externalización “bodyshopping” serían las más propensas a ser afectadas negativamente, ya que los clientes buscarían preservar a los empleados internos y ahorrar costos en otros lugares.

Todo lo que hemos discutido hasta ahora se ha centrado en la discusión de la hipótesis, “El equipo de ingeniería de productos de próxima generación probablemente tendrá muchos menos ingenieros”, pero creo que es justo decir que nos hemos quedado bastante lejos de demostrar o refutar esa hipótesis.

“Sí, pero…”

Ahora, me gustaría abordar muchos de los desafíos que me han planteado en conversaciones sobre este tema en los últimos meses, así como abordar el hecho de que he hecho muchas suposiciones en el servicio de mi hipótesis original.

He dejado sin abordar muchas posibles objeciones, no porque no me hayan preocupado, sino porque hay demasiada incertidumbre y mucho trabajo por hacer aún para experimentar con estas herramientas y ver cómo realmente ayudan a los equipos.

Aquí tienes una gran lista de muchas críticas y preguntas sin respuesta:

Estás confiando mucho en las herramientas de IA para escribir código de calidad. No pueden ser tan buenas como los humanos.

Lo admito, estoy impresionado con la calidad de las herramientas, pero tampoco estoy tratando de argumentar que necesitan ser tan buenas como los desarrolladores excelentes. He evitado deliberadamente modelar un escenario sin experiencia técnica, porque en mi experiencia al usar las herramientas, todavía necesitan una gran supervisión y orientación. Supervisión para asegurarse de que no estén haciendo algo estúpido o peligroso (como escribir claves de API en el código fuente) y orientación para asegurarse de que estén haciendo lo correcto (usando el lenguaje, marco o patrón de diseño correcto).

Tengo la sensación de que estas herramientas de IA deben ser el McDonalds de la ingeniería de software; mientras ir a un gran restaurante no franquiciado con un personal excepcional puede ser una experiencia trascendental, no siempre es posible. McDonalds es universalmente limpio, barato, saludable (quiero decir, no infestado de bacterias) y, sobre todo, consistente. Como dijo una vez uno de mis queridos amigos italianos cuando se enfrentó a una gran cadena de pizzas a domicilio, “No te mata”. Hasta cierto punto, este es el nivel al que apuntamos con las herramientas de IA.

Pero también creo que esto no es el final de la historia. Las herramientas que vemos hoy en día están lejos de la calidad que tendrán dentro de un año. Incluso mientras editaba el artículo original en esta serie, hubo noticias todos los días sobre más mejoras; UC Berkeley presenta un modelo que escribe mejores llamadas de API que GPT4. Microsoft anuncia ‘atención dilatada’, que permite que los modelos escalen a miles de millones de tokens con LongNet. StackOverflow anuncia OverflowAI con promesas de respuestas aún más ingeniosas a preguntas tontas (perdón, quiero decir, una búsqueda mejor y más útil).

Incluso si eres escéptico acerca de la capacidad de las herramientas actuales, temo que sería miope ignorar el potencial de las capacidades que es probable que desarrollen.

[Editar: Incluso en la semana o así desde que redacté este artículo por primera vez, Stack Overflow ha anunciado OverflowAI, Github ha anunciado herramientas adicionales para evitar problemas de propiedad intelectual y StabilityAI ha anunciado un LLM enfocado en la codificación. El mercado se mueve a un ritmo asombroso]

Las herramientas de IA tendrán problemas de propiedad intelectual. Y problemas de seguridad. Y si dejan de funcionar, no podremos trabajar más

Sí, todas estas cosas son posibles.

Pero no es la primera vez que trabajamos en torno a problemas como estos, y ya tenemos formas de mitigarlos. Muchas de las empresas con las que hablo están paralizadas por el temor a que se filtren secretos de la empresa que se utilizarán para entrenar aún más el LLM. Si bien esto puede ser cierto para suscripciones gratuitas e individuales, le recomendaría encarecidamente que, estimado lector, investigue por su cuenta a los proveedores más grandes para comprender exactamente cuál es el riesgo de eso y qué están haciendo los vendedores para abordar esta preocupación muy razonable. Eche un vistazo a algunas de las preguntas frecuentes de los grandes actores para ver si hay una respuesta lo suficientemente buena para su caso de uso y perfil de riesgo: OpenAI, Github Copilot, AWS CodeWhisperer (Google Duet todavía está en beta cerrada y no había documentación de seguridad de datos disponible).

Es un caso similar con la seguridad y la protección de datos. La mayoría de ustedes que leen hoy ya dependen de la seguridad de Github, Microsoft o AWS. Probablemente almacene su código en Github o sus aplicaciones o datos en Azure, GCP o Amazon. Pregúntese por qué está dispuesto a aceptar el riesgo de un proveedor de hipernube, pero no de una herramienta de codificación. El riesgo de usar ChatGPT no es despreciable, con una filtración de datos informada en mayo, noticias de posibles vulnerabilidades informadas esta semana y filtraciones persistentes de datos de usuarios internos informadas por el proveedor de seguridad en la nube, Netskope. Como con cualquier otra tecnología, puede optar por simplemente prohibirla en su organización, pero las personas, como la naturaleza, siempre encuentran una manera. Para abordar adecuadamente los problemas de seguridad, debe educar a los usuarios y proporcionar alternativas seguras y fáciles de usar. Si OpenAI no está a la altura de la tarea, tal vez alguno de los otros proveedores lo esté.

Otra preocupación es la exposición involuntaria al riesgo de propiedad intelectual; por ejemplo, cuando el modelo ha sido entrenado (¿”accidentalmente”?) en material que es de código cerrado, y la herramienta expone a su organización al riesgo de violar la ley (y llevar riesgos para remediar su infracción) simplemente al usar la herramienta. Aquí está la mala noticia: si cree que este es un nuevo riesgo, probablemente debería examinar más de cerca su uso de Open Source en su organización. Muchas empresas están muy lejos de administrar y comprender adecuadamente los riesgos de su “Lista de materiales de software” (SBOM), la lista de dependencias de código cerrado y de código abierto que tiene su software. Sin duda, debería preocuparse por el riesgo de que una de estas herramientas pueda ponerlo accidentalmente en incumplimiento de los derechos de propiedad intelectual de otra persona, pero debería extender los controles que ya utiliza para el software de código abierto y el gran botón rojo de copiar y pegar de sus desarrolladores.

Estos riesgos son suyos, y si está interesado en investigar las oportunidades que estas herramientas pueden brindar, también debe leer la documentación y hablar con los proveedores sobre las medidas que están tomando para protegerlo de este riesgo. Asegúrese de hacer su tarea. El informe de privacidad de sentido común para Copilot lo calificó con un 63%, lo suficientemente bajo como para recibir una advertencia “ámbar” (obtuvo una calificación especialmente baja en “Escuela” y “Consentimiento de los padres” que lo arrastraron hacia abajo).

Esto siempre debe ser parte de su proceso de adquisición de todos modos. Siempre debe considerar cualquier herramienta que vaya a utilizar cerca del código de producción o de los datos desde una perspectiva de riesgo, y le corresponde a usted decidir su apetito por el riesgo y cómo mitigarlo.

Como una nota más positiva, creo que los anuncios recientes de Salesforce son una buena indicación de la dirección que tomarán estas herramientas. Gran parte del impulso de marketing de Salesforce para el Día de la IA se centró en lo que llaman “Capa de confianza de Einstein”, que parece ser un envoltorio realmente impresionante para diferentes modelos de LLM que ayuda mucho a asegurar el acceso y proteger tanto la información del cliente como la de la empresa (en serio, vean este video, aunque no se trate de código).

Acabamos de ver a siete importantes empresas tecnológicas (Amazon, Anthropic, Google, Inflection, Meta, Microsoft y OpenAI) comprometerse voluntariamente con “AI Responsable”, lo que incluye marcar con marcas de agua la salida. Es razonable suponer que los principales actores de este mercado, la mayoría de ellos empresas a las que ya confiamos grandes cantidades de nuestros datos e infraestructura, lanzarán envoltorios de confianza y seguridad similares que responderán a muchas preguntas pendientes sobre propiedad intelectual, seguridad, privacidad y la tendencia de los LLM a ser un poco tóxicos y tener una relación cuestionable con la verdad.

Alguien todavía necesitará diseñar la solución general.

Ver también:

• Alguien tendrá que gestionar todos los datos y las canalizaciones de datos
• Alguien tendrá que gestionar las superposiciones entre aplicaciones
• Alguien tendrá que asegurar los productos
• Alguien tendrá que supervisar y responder a problemas
• Alguien tendrá que gestionar las dependencias e interacciones entre equipos y productos

Sí, tienes razón. Todavía hay muchos trabajos por hacer que no se limitan solo a escribir código.

¡Esto es genial!

Significa que todavía necesitamos personas por un tiempo más y comienza a mostrarnos dónde debemos proporcionar capacitación para nuestros ingenieros. Pero también debemos esperar que las herramientas, la automatización y el código de mejor calidad y más probado comiencen a impactar positivamente esta lista de problemas. Con más documentación, menos código “inteligente”, interfaces más limpias, mejor explicabilidad y mejor cobertura de pruebas, es posible que veamos menos de estos tipos de desafíos de todos modos.

Pero la mayor parte del tiempo de un ingeniero no se dedica realmente a programar porque nos siguen diciendo que vayamos a reuniones estúpidas

Sí, es cierto. La IA no va a resolver todos los problemas, pero si eres un ingeniero que pasa más tiempo en reuniones que programando, el problema no está en tu productividad, sino en cómo se gestiona tu organización.

Tal vez la IA resuelva eso algún día, pero a corto plazo es posible que las organizaciones más pequeñas, ágiles y automatizadas no necesiten tantas reuniones.

Si soy sincero, para la mayoría de las organizaciones, la mejor manera de mejorar la productividad de los desarrolladores es hacer un mejor trabajo en la priorización del trabajo, decir no a resultados de bajo valor y devolver más tiempo a los equipos para que se centren en entregar productos de alta calidad. Pero, si no podemos lograr eso, tal vez podamos tener asistentes de programación de IA en su lugar.

¿No podríamos reemplazar a los gerentes de producto con IA en su lugar?

Ah, esto es interesante.

Uno de los comentarios sorprendentes que ya he recibido sobre estos artículos ha sido: “eso es muy interesante, pero en mi negocio no tenemos ni cerca del suficiente soporte de producto”. Resulta que estaba mostrando un sesgo inconsciente con mi proporción de 5:1 de ingenieros, y muchos equipos de tecnología ya estaban luchando enormemente porque sus proporciones no solo eran mucho más altas que eso (digamos 10:1 o más), sino que también la habilidad en productos no era valorada lo suficiente dentro de la organización. Algunas empresas todavía parecen pensar que los ingenieros escriben código y los gerentes de producto son un lujo costoso.

Creo que obtener requisitos de los clientes es algo realmente importante. También creo que llevar a cabo un proceso de priorización comercial efectivo y fácil de entender es muy difícil. Pasará un tiempo antes de que podamos hacer que los interesados diseñen sus propias soluciones de software.

Los gerentes de producto son fundamentales para la ingeniería de productos excelentes. Los gerentes de producto enfocan los recursos de ingeniería y ayudan al negocio a identificar los resultados más valiosos. Creo que lo último que necesitamos en este momento es una reducción en el soporte de producto, aunque podamos ayudar en algunas de sus tareas diarias con la automatización.

Mi sospecha es que los roles de gerente de producto y líder técnico serán los más críticos en estos nuevos equipos.

No has pensado en X o Y o Z

Probablemente tengas razón. ¡Pero si lo has hecho, genial! Déjame un comentario, inicia una discusión o, lo mejor de todo, escribe un nuevo artículo explicando tus pensamientos sobre Y o Z. (Pero no sobre X. Ya no hablamos de X)

Resumamos todo eso

El objetivo de toda esta serie de artículos ha sido con una preocupación en mente: hoy en día, no siento que suficientes líderes de producto y tecnología se involucren activamente en la discusión de lo que podría suceder con sus equipos si se cumple la promesa de las herramientas de codificación de IA generativa. No estamos simplemente hablando de un pequeño impulso a la productividad del desarrollador. Es posible que estemos hablando de un cambio en la forma en que se crean los productos.

Si incluso parte de lo que hemos discutido es cierto, es probable que los equipos que construyen software sean asignados de manera bastante diferente a hoy, con un impacto significativo en los presupuestos de personal de productos y tecnología. Hay riesgos de interrupción en toda la industria, especialmente en una reducción en los roles de desarrollador.

Aunque esto puede ser mitigado por empresas que buscan invertir en cada vez más resultados, hay un límite en cuántos flujos de valor puede soportar un negocio. Las empresas que se tomen el tiempo para comprender y abrazar los cambios que se avecinan de manera cuidadosa y decidida podrían obtener una gran ventaja competitiva.

También hay un aspecto filosófico en este argumento. Creo que puede haber un valor inefable e irremplazable de los ingenieros humanos, pero ya no creo que pueda decirte con confianza qué es.

Sabemos que los desarrolladores escriben código, y podemos asignarles un valor en función de qué tan rápido escriben el código y con qué frecuencia funciona. Pero esta afirmación simplemente no comprende cuál es el verdadero trabajo de un ingeniero. Durante años fue fácil demostrar que los ingenieros humanos capacitados podían hacer cosas que los algoritmos no podían, pero eso ya no es cierto. Si la línea entre humano y máquina es simplemente el nivel de complejidad de la solución que se puede crear, estamos en arenas movedizas peligrosas. Como escribí antes:

Los ingenieros no solo aprenden a programar. Aprenden a pensar.

Nosotros, como industria, debemos apreciar que una amplia gama de tareas de ingeniería puede ser fácilmente replicada por esta nueva generación de herramientas. Al hacerlo, también debemos entender que todavía hay habilidades únicas que los humanos poseen y que no son tan fáciles de replicar. Es nuestro trabajo, como líderes, identificar cuáles son esas habilidades e invertir en personas para optimizar esa habilidad.

Este artículo es un llamado a la acción. Si eres líder de producto o tecnología, deberías tomar esto como un desafío para considerar cuál será el impacto de las herramientas de IA generativa en tus equipos, y debes incluir a tus equipos en responder esa pregunta.

Dándoles tiempo y espacio para considerar cómo estas herramientas les ayudarán, es muy probable que la fuente de innovación sea los propios equipos. Pero, como líder, también debes reconocer que es posible que algunos miembros del equipo se muestren renuentes a aceptar el cambio. Las personas pueden tener miedo y estar poco dispuestas a participar debido a la amenaza muy real a su empleo, y necesitarás aprovechar su talento para ayudarte a comprender si debes hacer recortes presupuestarios. Ser jefe es difícil, pero la alternativa es que tus competidores sean más implacables y decididos que tú.

Debemos dejar claro que los avances más interesantes, caóticos, indisciplinados, impactantes y emocionantes se producirán en esas pequeñas startups y en equipos fuera de la tecnología. No cometas el error de ignorar lo que las personas no técnicas en tu propia organización o las pequeñas empresas de la comunidad de startups están haciendo.

Comienza por educarte a ti mismo y luego a otros en tu propio negocio acerca de cuáles son los riesgos reales. Considera las oportunidades mirando tanto internamente a los primeros adoptantes curiosos dentro de tu negocio como externamente a lo que los gigantes tecnológicos y las pequeñas startups están haciendo. Ten en cuenta que estos avances probablemente remodelarán fundamentalmente tu ingeniería de productos, luego sal ahí, sé curioso, haz preguntas y anima a tus equipos a hacer lo mismo.

Aún no he logrado refutar mi propia hipótesis, pero ahora estoy pidiendo tu ayuda para diseñar el experimento.

Otros artículos en esta serie:

• Parte 1
• Parte 2
• Parte 3
• Parte 4
• Parte 5

P.D. Si estás disfrutando de estos artículos sobre equipos, echa un vistazo a mi podcast Teamcraft, donde mi coanfitrión Andrew Maclaren y yo hablamos con invitados sobre lo que hace que los equipos funcionen.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!