Vibe Coding a Escala Empresarial: ¿Qué Sucede Cuando la IA se Une a Tu Equipo de Desarrollo?

Hola a todos, gracias por tenerme hoy aquí, soy Wesley, voy a presentarme muy rápido, pero quiero hablar sobre la codificación web a gran escala. Hicimos un experimento bastante bueno en Modus Create hace un par de meses, y me gustaría compartir sobre eso. ¿De acuerdo? Entonces, presentándome, soy Wesley Fisher, soy de Brasil, trabajo en Modus Create como ingeniero principal sénior allí. Trabajando allí por casi 7 años ahora, y tengo 14 años trabajando como ingeniero de software. He hecho muchas cosas diferentes como ingeniero de software, he hecho front-end, back-end, DevOps, soluciones así también. Y mi experiencia está en Amazon Web Services, Java, JavaScript y aplicaciones sin servidor. Y últimamente me he centrado mucho en entender cómo estas nuevas herramientas de tipo IA que estamos obteniendo, agentes de codificación, van a cambiar la forma en que hacemos software, ¿verdad? Me he centrado mucho en eso en los últimos 9 meses. Así que mientras voy a la comunidad, teniendo conversaciones con personas, Reddit, Twitter, AXE, esas diferentes plataformas, he visto a mucha gente haciendo diferentes comentarios, teniendo diferentes opiniones sobre la codificación VIPE, sobre el uso de herramientas de agentes de codificación para el desarrollo de software, ¿verdad? Y el patrón que he visto es básicamente dos grupos diferentes en direcciones opuestas. Personas que piensan que los desarrolladores de software como profesión ahora han desaparecido, o pronto desaparecerán, y en el otro lado, personas que piensan que la codificación VIPE es algo que no deberíamos estar haciendo, personas que piensan que la codificación VIPE, o el uso de agentes para codificar, no es algo bueno, Así que estoy aquí hoy para tratar de equilibrar esta conversación trayendo algunos hechos, trayendo información útil de los aprendizajes que obtuvimos en los últimos meses. Creo que con la IA, la forma en que construimos software está cambiando mucho. No creo que a largo plazo, en los próximos años, vayamos a estar codificando como hemos estado codificando durante los últimos 50 años, o al menos en los últimos 25 años. Creo que la IA, y los agentes de codificación, GitHub Copilot, Cursor, Wingsurf, esas herramientas, ¿verdad? Van a cambiar un poco. Pero no tengo una opinión, una opinión fuerte sobre si es algo malo o bueno. Creo que tenemos un equilibrio, y necesitamos pensar exactamente cómo esas herramientas pueden ayudarnos. Para eso, en Modus Create, decidimos codificar VIPE una aplicación internamente, un experimento interno para realmente entender cómo la IA puede ayudarnos a hacer mejor software para construir mejores aplicaciones para ayudar a nuestros clientes.

Así que, voy a hablar sobre eso, voy a presentar datos de nuestro experimento, voy a presentar los aprendizajes que obtuvimos, y no quiero hablar sobre el bombo, no quiero hablar sobre las tendencias, y lo que la gente está hablando por ahí, ¿verdad? Me voy a centrar básicamente en los aprendizajes que obtuvimos de ese experimento, y lo que eso nos enseñó. Básicamente tuvimos a 10 personas trabajando en un experimento de tres meses entre marzo y mayo, así que fue algo grande para nosotros, y aprendimos mucho que quiero compartir. Básicamente la estructura del experimento, decidimos construir una aplicación, una aplicación móvil simple que ayuda a los usuarios a traducir jerga mágica en conocimiento común de las personas, un par de idiomas, ¿verdad? Esencialmente, tomas tu teléfono, tomas una captura de pantalla o una foto de un informe médico, un informe de laboratorio, un informe de examen de laboratorio, y ese diagnóstico que tienes allí, lo traducimos a conocimiento común, por supuesto usando IA en el fondo también. Construimos esa aplicación dos veces. Tuvimos dos equipos, un equipo que llamamos DIY, esencialmente el equipo de hágalo usted mismo, no se les permitió usar ninguna herramienta para codificar, ninguna herramienta de IA para codificar. Podían usar diferentes herramientas, Stack Overflow, podían usar el desarrollo de software tradicional como estamos acostumbrados, ¿verdad? Pero no podían usar ninguna herramienta para generar código usando IA. Y tuvimos otro equipo, el equipo de IA, que se les permitió usar cursor y GitHub Copilot para generar el código, y se les pidió específicamente que no codificaran en absoluto a menos que realmente lo necesitaran, y cuando necesitaban codificar, necesitaban documentar eso para que pudiéramos entender por qué necesitaban codificar algo. El equipo de IA era solo dos desarrolladores, dos ingenieros, dos ingenieros full stack, y el equipo sin IA eran tres desarrolladores, ¿verdad? Así que teníamos un equipo más pequeño trabajando con IA. A ambos equipos se les pidió que escribieran mucha documentación y que gestionaran hojas de tiempo durante el proceso de desarrollo. Así que rastrearíamos al detalle de la tarea, cuántas horas están tomando, tomaron en una característica particular dada, ¿verdad? Y usamos esa tecnología moderna para desarrollar la aplicación usando BadRock como nuestro LLM en el backend para servicios de Amazon. Usamos ese Fargate, Node.js, la aplicación fue construida usando React, Ionic y Capacitor, y desplegada usando GitHub Actions tanto en las tiendas de Apple como de Google Play. Por supuesto, no desplegamos externamente, solo internamente. La parte más importante de nuestro experimento fue al principio establecimos hipótesis sobre las expectativas que teníamos sobre ese experimento. Pensamos que el uso de IA, en este caso, cursor y GitHub Copilot, nos ayudarían a ser al menos un 50% más rápidos con un equipo más pequeño en un 30%. Así que una vez más, el equipo que estaba usando IA era un ingeniero menos que los tres ingenieros del equipo sin IA, lo que significa un 30% de capacidad reducida allí.

También pensamos que al usar IA, la necesidad de experiencia, experiencia técnica, en un tema dado del ciclo de vida del desarrollo de software no sería necesaria. Solo para dar un ejemplo, teníamos, como ingeniero full stack trabajando en este proyecto, un ingeniero que fue principalmente un ingeniero de backend en Python durante toda su carrera. Se le pidió que trabajara como full stack escribiendo código en React en el front-end con TypeScript, tanto en el front-end como en el backend. Así que era un nuevo lenguaje, un nuevo stack tecnológico para él. Esperábamos que la calidad de la base de código fuera al menos de la misma calidad que la del equipo sin IA calidad de la base de código. Así que básicamente, usamos Sonar en ambas bases de código para hacer análisis estático en esas bases de código, y comparamos los resultados de Sonar para entender si las bases de código eran tan buenas como, al menos sin el uso de IA. Y por supuesto, esperábamos tener aprendizajes, aprender mucho sobre las cosas que deberíamos hacer y las cosas que deberíamos evitar al usar IA para codificar.

Y los resultados del experimento fueron bastante buenos, ¿verdad? Los resultados son bastante buenos. Tuvimos un aumento de productividad del 45% al usar IA, lo que significa que el equipo que desarrolló usando IA entregó la aplicación un 40% más rápido que el equipo que estaba trabajando sin IA. Con esa capacidad reducida en un 30%. Un equipo de dos personas desarrolló la aplicación casi en la mitad del tiempo del equipo con tres personas que no estaba usando IA. El ingeniero de Python que mencioné, pudo ser productivo y entregar aplicaciones usando TypeScript. Así que el hecho de que los lenguajes sean bastante similares entre ellos, ¿verdad? TypeScript, Python, tienen diferencias en la sintaxis, pero los fundamentos de la lógica y los fundamentos del elemento de software, son los mismos. Así que no se requería que el desarrollador codificara en TypeScript durante el proyecto.

Se requería que pensara en las características, que pensara en cómo implementar la aplicación. Así que la IA lo ayudó a ser productivo usando un lenguaje en el que nunca había trabajado antes. Eso fue bastante importante para nosotros también. Y la calidad entregada por ambas bases de código fue bastante buena y similar. Ambas bases de código tenían un par de problemas aquí, un par de errores allá, cosas normales, nada muy complicado de arreglar. Ninguna de esas bases de código tenía puntos críticos de seguridad importantes. Así que pudimos evaluar ambas bases de código y eran prácticamente iguales en términos de calidad. Pero por supuesto, nada es perfecto. También notamos que el mismo ingeniero de Python que mencioné antes, le pedí durante el desarrollo que actuara como una persona de DevOps trabajando en Amazon Web Services, especialmente alrededor de la configuración de balanceadores de carga de aplicaciones en la arquitectura, ¿verdad? Y ese fue un punto en el que tuvo algunas dificultades, no porque la capacidad de usar IA no ayudara mucho porque no estaba claro en lo que quería desarrollar en ese momento. No estaba al tanto de que debía usar un balanceador de carga de aplicaciones en lugar de un API gateway, por ejemplo. Así que la capacidad de saber exactamente lo que quieres pedirle a la IA que haga redujo su rendimiento. Pero pudo entregar la característica. Solo tomó más tiempo que una persona que no estaba usando IA, la persona de DevOps del otro equipo.

Pero tú como ingeniero, debes saber exactamente qué estás pidiendo que la IA haga por ti. No puedes simplemente decir, oye, ya sabes, construye esto para mí. Necesitas ser más claro en tu resultado, el resultado que esperas. ¿Cuál es la aplicación que estás desarrollando? Las decisiones que tomas, tus decisiones de arquitectura de software. Proveedor, si vas a usar como proveedor la nube, Amazon, las cosas que quieres usar en Amazon, ese tipo de cosas, aún necesitas tomar decisiones y proporcionar eso como contexto al NLM. Y nos enseñó algo bastante importante.

Y quiero ser claro en la diferencia entre el bombo de la codificación Vibe o la naturaleza de la codificación Vibe que se definió a principios de este año y lo que hicimos allí como parte del experimento. Así que la codificación con IA o la codificación de agentes para nosotros significa usar IA para acelerar el proceso de escribir el código. Pero el humano en el bucle debe ser una persona que tenga las habilidades suficientes para tomar decisiones sobre cómo debe funcionar la IA y lo suficientemente hábil para hacer la revisión de código, para hacer la revisión del código generado por IA. Mientras que la codificación Vibe dice que solo confías en la IA, pides algo y no revisas el código. No creemos en eso. No confiamos en eso.

No es la forma en que queremos trabajar en MobScript y la forma en que queremos enseñar a las personas a trabajar. Así que para nosotros, el ser humano sigue siendo necesario y el ser humano debe ser un ingeniero de software, ser una persona hábil en ingeniería, en escribir aplicaciones. Esa persona sigue siendo la estrella de rock en este flujo de trabajo. Esta persona es necesaria para hacer la planificación. Esta persona es necesaria para revisar el código generado por IA. Esta persona es necesaria para ejecutar el proceso de validar la aplicación y el código que fue generado por IA para asegurarse de que esa aplicación esté lista para ir a producción.

Así que al final, básicamente, la IA no es un reemplazo para la claridad arquitectónica o la experiencia en ingeniería, pero puede ser un multiplicador de la misma. Así que mientras te concentres en tener ingenieros bastante buenos y sigas enfocándote en mejorar las habilidades de tu equipo de ingeniería para usar IA, esos ingenieros pueden ser mejores, pueden hacer un mejor trabajo usando IA, si no el 100% del tiempo, pero prácticamente, la mayor parte del tiempo. Pueden usar IA para hacer lluvias de ideas, tomar decisiones, escribir un plan de implementación y pedir a la herramienta de codificación agentic de IA, cursor, copilot, cualquiera que sea la herramienta que decidas usar para asegurarte de que esa herramienta va a acelerar el proceso de desarrollo para ti mediante la gestión correcta y respetuosa de la persona.

Entonces, ¿cuáles son los aprendizajes clave y los flujos de trabajo que obtuvimos allí, verdad? Primero, para mí, el mejor prompt, la mejor manera de comunicarte con la IA es siendo claro y conciso sobre lo que esperas que la IA haga por ti. Así que ir a copilot y ser muy claro, cristalino, sobre lo que esperamos que la IA haga por ti es la forma en que veo la mayoría de las ganancias de productividad y los resultados profesionales de alta calidad de ello, ¿verdad? Y para mí, comienza con tener tareas a nivel atómico. Básicamente, imagina que tienes como una historia de usuario en tu tablero de tareas que quieres usar, que quieres implementar, ¿verdad? Esa historia necesita desglosarse en unidades más pequeñas. Pueden ser subtareas y para la subtarea, puedes crear un plan de implementación que contenga, que esencialmente para mí, el plan de implementación es un archivo markdown en tu repositorio.

Y en ese archivo markdown, defines acciones de gran paso a nivel atómico que quieres que la IA revise de manera interactiva. Así que básicamente creas ese plan de implementación. Puedes usar PT, otras herramientas de IA para elaborar ese plan de implementación. Y luego lo revisas y estás seguro de que ese es el plan que quieres seguir. Comienzas a pedirle a la IA que lo revise y trabaje en esos puntos clave, ¿verdad? En cada punto clave, cuando la IA termina, revisas la base de código, ejecutas pasos de validación como linter, pruebas unitarias, herramientas que tienes disponibles en tu línea de comandos para revisar la calidad de la base de código. Y luego, si estás satisfecho con el resultado, lo aceptas.

Si no estás satisfecho, proporciona retroalimentación. Cuando estás satisfecho, entonces haces commit en Git y te salva si en los siguientes prompts, la IA alucina y comienza a borrar código. Así que hacer commits con frecuencia, trabajar en unidades más pequeñas, pasos pequeños, en iteraciones es la forma que encontramos que Mondo está creando ese experimento como la forma más productiva de trabajar con agentes de codificación. Por supuesto, dar contexto a DLLM también es muy importante. Y al dar contexto, me refiero no a un contexto grande, sino a un contexto rico con un enfoque láser en la información que está relacionada con la tarea que deseas realizar. Demasiado contexto podría hacer que tu IA comience a alucinar, ¿verdad?

Eso no es algo que queremos. Así que encontrar formas de alimentar a DLLM con el contexto correcto para la tarea también es una habilidad que el ser humano, el desarrollador de software que maneja la herramienta debe desarrollar ahora. Y por supuesto, hay diferentes maneras de hacer eso. Usar archivos de instrucciones para configurar patrones de codificación acordados por el equipo o tener MCPs para alimentar a DLLM con contexto externo de Stack Overflow, una búsqueda en Google, una consulta de perplexity o, por supuesto, hacer un buen trabajo escribiendo el prompt. Y por supuesto, limpiar el contexto después de un par de interacciones porque comienza a crecer y alucinar.

Algunos buenos prompts, por supuesto, siendo claros y concisos al explicar lo que esperas que la IA logre para ti, no solo escribiendo, oye, haz algo por mí, ¿verdad? Escribe sass aquí o escribe tareas para ese componente. Necesitas ser más claro. Necesitas ser específico y con un enfoque láser en lo que quieres que la IA logre. Para mí, no uso tanto los prompts porque realmente quiero usar el plan de implementación. Y el plan de implementación es esencialmente mi prompt al final del día, ¿verdad? Así que tener un plan de implementación con grandes pasos y acciones claras y concisas allí ayuda mucho porque puedes ir a DLLM y decir, oye, echa un vistazo al plan de implementación y comencemos a trabajar en eso. Y este ciclo de validación para mí es clave, es probablemente lo mejor que aprendimos porque me mantiene enfocado, me mantiene productivo y me da buenos resultados.

Así que le pido a la IA que comience a trabajar en una tarea. Ese es el primer paso allí. La IA, DLLM genera algo de código para mí. Esa tarea siendo una tarea BAPESTEP enfocada con láser me ayuda a tener un lote más pequeño para revisar en lugar de un lote grande que sería como una solicitud de extracción de 100 archivos que me tomaría más tiempo revisar y probablemente comenzaría a perder cosas después de un tiempo. Así que me escribe algo de código importante, un par de componentes, un par de funciones, ¿verdad? Y luego hago mi revisión humana. Voy allí y reviso la base de código y comienzo a dar retroalimentación. Escribo un gran prompt con toda la retroalimentación que quiero.

La IA va y comienza a refactorizar, cambiando el código según mi retroalimentación. Hago mi trabajo de control de calidad humano, mi prueba manual, ¿verdad? Voy allí y hago pruebas manuales para asegurarme de que la aplicación que se está desarrollando funcione como se espera desde la perspectiva del usuario. Ejecuto validaciones automáticas, lo cual también es bastante importante, como usar pruebas unitarias, ejecutar herramientas como Linter, Lizard, Horusec. Esas herramientas de línea de comandos me permiten alimentar a la IA con algo de contexto sobre lo que está mal en mi base de código.

Digamos que uso Lizard para calcular la complejidad, la complejidad cognitiva de una función, y luego uso esa retroalimentación en el LLM para que sepa qué está mal y luego lo arregle, ¿verdad? Así que hacer esas validaciones, las validaciones automáticas desde la línea de comandos, también es bastante importante. Y también estoy contento de hacer el commit en git. A menudo hago commit para evitar perder código debido a la locura de la IA en algún momento. El desarrollo guiado por pruebas es uno de los flujos de trabajo que realmente me gusta. Ayuda mucho porque todo lo que acabo de decir sobre tareas enfocadas con láser, eso es TDD, ¿verdad? TDD se basa en escribir pasos más pequeños, en codificar con tareas en unidades más pequeñas.