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 rápidamente. Pero quiero hablar sobre Web Coding y Enterprise SQL. Hicimos un experimento bastante bueno en Modus Create hace un par de meses. Y me gustaría compartir sobre eso.

Muy bien. Entonces, presentándome, soy Wesley Fisher. Soy de Brasil. Trabajo en Modus Create como Ingeniero Principal Senior allí, trabajando allí durante casi siete años. 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 es en Amazon Web Services, Java, JavaScript y aplicaciones serverless. Y últimamente, me he enfocado 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. Me he enfocado mucho en eso en los últimos nueve meses. Así que, mientras voy a la comunidad, teniendo conversaciones con personas, Reddit, Twitter, X, esas diferentes plataformas, he visto a mucha gente haciendo diferentes comentarios, teniendo diferentes opiniones sobre la codificación VIP, sobre el uso de herramientas de agentes de codificación para el desarrollo de software. 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 VIP es algo que no se debería hacer. Personas que piensan que la codificación VIP 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 lo hemos estado haciendo 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, Coursera, 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 VIP una aplicación internamente y un experimento interno para realmente entender cómo la IA puede ayudarnos a hacer mejor software, a construir mejores aplicaciones, a ayudar a nuestros clientes. ¿Verdad? 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á diciendo 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. Esencialmente, tomas tu teléfono, tomas una captura de pantalla o una foto de un informe médico, un informe de laboratorio, informe de examen de laboratorio. Y ese diagnóstico que tienes allí, lo traducimos a conocimiento común. ¿Verdad? Por supuesto, usando IA en el fondo también. Y construimos esa aplicación dos veces. Tuvimos dos equipos. Un equipo, lo que llamamos DIY, esencialmente el equipo de hazlo tú 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 al que 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 Courser 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 entendiéramos por qué necesitaban codificar algo. El equipo de IA era solo dos desarrolladores, dos ingenieros, dos ingenieros full-stack. Y el equipo no-IA eran tres desarrolladores. 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 el detalle de la tarea, cuántas horas están tomando, tomaron en una característica particular dada, ¿verdad? Y usamos esa tecnología moderna. Desarrollamos la aplicación usando Bedrock como nuestro LLM en el backend para servicios de Amazon.

Usamos Fargate, Node.js. La aplicación fue construida usando React, Ionic, y Capacitor y desplegada usando GitHub Actions tanto en Apple como en Google Play stores. Por supuesto, no desplegamos externamente, solo internamente.

Y 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, Coursera y GitHub Copilot, nos ayudaría a ser al menos un 50% más rápidos. Vemos un equipo más pequeño en un 30%. Así que una vez más, el equipo que estaba usando IA tenía un ingeniero menos que los tres ingenieros del equipo sin IA, lo que significa un 30% de capacidad reducida allí.

También pensamos que usando IA, la necesidad de experiencia, experiencia técnica en un tema dado del ciclo de vida del desarrollo de software, no sería requerida. Solo para dar un ejemplo, teníamos como ingeniero full stack trabajando en este proyecto, un ingeniero que era principalmente un ingeniero de backend Python durante toda su carrera. Y se le pidió que trabajara como full stack escribiendo código React en el frontend con TypeScript, tanto en el frontend como en el backend.

Así que fue 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 base de código del equipo sin IA. 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. Los resultados fueron bastante buenos. Tuvimos un aumento del 45% en la productividad 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%. Así que un equipo de dos personas desarrolló la aplicación casi en la mitad del tiempo del equipo de 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, TypeScript, Python, tienen diferencias en la sintaxis, pero lo básico de la lógica y lo básico del desarrollo de software son los mismos.

Así que no se requirió que el desarrollador programara en TypeScript durante el proyecto. Se le pidió que pensara en las características, en cómo implementar la aplicación. Así que la IA le ayudó a ser productivo usando un lenguaje en el que nunca había trabajado antes. Eso también fue bastante importante para nosotros.

Y la calidad entregada por ambas bases de código fue bastante buena y eran similares. Ambas bases de código tenían un par de problemas aquí, un par de errores allá. Ya sabes, 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 en torno a la configuración de balanceadores de carga de aplicaciones en la arquitectura. Y ese fue un punto en el que tuvo algunas dificultades. No porque la capacidad de usar IA no ayudara mucho, sino porque no tenía claro 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 le tomó más tiempo que a una persona que no estaba usando IA, la persona de DevOps del otro equipo. Así que esto prueba que la IA puede hacer el trabajo, 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 salida, la salida 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 algo como la nube como proveedor, Amazon, las cosas que quieres usar en Amazon, ese tipo de cosas, aún necesitas tomar decisiones y proporcionar eso como contexto al LLM. Y nos enseñó algo bastante importante. Y quiero ser claro sobre la diferencia entre la vibra, el bombo de la programación o la naturaleza de la programación de vibra, que se definió a principios de este año. Y lo que hicimos allí como parte del experimento. Correcto. Entonces, la programación con IA o la programación con agentes para nosotros significa usar IA para acelerar el proceso de escritura del código. Pero el humano en el bucle debe ser una persona lo suficientemente capacitada para tomar decisiones sobre cómo debería funcionar y lo suficientemente capacitada para hacer la revisión del código, para hacer la revisión del código generado por la IA. Mientras que la programación de vibra 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 ModuScript 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 sigue siendo necesario para ser un ingeniero de software, para ser una persona capacitada en ingeniería, en escribir aplicaciones. Y 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 la IA. Esta persona es necesaria para ejecutar el proceso de validación de la aplicación y el código que fue generado por la 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 sigas enfocándote en tener ingenieros muy buenos y sigas enfocándote en escalar tu equipo de ingeniería para usar IA, esos ingenieros 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 lluvia de ideas, tomar decisiones, escribir un plan de implementación y pedirle a la herramienta de programació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í? 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 esperas 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. Y para mí, comienza con tener tareas a nivel atómico. Básicamente, imagina que tienes una historia de usuario en tu tablero de JIRA que quieres usar, que quieres implementar, ¿verdad? Esa historia necesita desglosarse en unidades más pequeñas. Pueden ser sub-tareas y a partir de las sub-tareas puedes crear un plan de implementación, que contiene, que esencialmente para mí el plan de implementación es un archivo markdown en tu repositorio. Y ese archivo markdown, defines acciones a nivel atómico, grandes pasos que quieres que la IA revise de manera interactiva. Así que básicamente creas ese plan de implementación, puedes usar eso con 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 de viñeta.

En cada punto de viñeta, cuando la IA ha terminado, 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, proporcionas retroalimentación. Cuando estás satisfecho, entonces lo comprometes a Git y te salva si en el siguiente prompt la IA alucina y comienza a borrar código. Así que comprometerse a menudo, trabajar en unidades más pequeñas, pasos de bebé más pequeños en interacciones es la forma que encontramos que MondoScript en ese experimento sea la forma más productiva de trabajar con agentes de codificación.

Por supuesto, dar contexto al LLM 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 estrecho en la información que está relacionada con la tarea que deseas realizar. Demasiado contexto podría hacer que tu IA comience a alucinar. Eso no es algo que queremos. Así que encontrar formas de alimentar al LLM 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.

Ahora, por supuesto, hay diferentes maneras de hacer eso. Usar archivos de instrucciones para configurar patrones de codificación que son acordados por el equipo o tener MCPs para alimentar al LLM con contexto externo de Stack Overflow, una búsqueda en Google, una consulta de perplexity. O, por supuesto, hacer un buen trabajo al escribir 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, ser claro y conciso al explicar lo que esperas que la IA logre para ti. No solo escribir, hey, haz algo por mí, ¿verdad? Escribe SAS aquí o escribe SAS para ese componente.

Necesitas ser más claro. {{^}}Necesitas ser específico y tener un enfoque láser en lo que quieres que la IA logre. Para mí, no uso tantos 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 elementos de acción claros y concisos ayuda mucho porque puedes ir al LLM 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 la tarea. Ese es el primer paso allí. La IA, el LLM genera algo de código para mí. Esa tarea siendo específica, con un enfoque láser, una tarea de gran paso me ayuda a tener un lote más pequeño para revisar en lugar de un lote grande. Sería como 100 archivos por solicitud. Eso 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 feedback. Escribo un prompt grande sin el feedback que quiero. La IA va y comienza a refactorizar, cambiando el código según mi feedback. Hago mi trabajo de QA humano, mis tareas manuales, ¿verdad? Voy allí y hago tareas manuales para asegurarme de que la aplicación que se está desarrollando funcione como se espera desde la perspectiva del usuario.

Digamos que uso Lizard para calcular la complejidad, la complejidad cognitiva de una función. Y luego uso ese feedback en el LLM para que sepa qué está mal y luego lo arregle.

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 Git commit. A menudo hago commit para evitar perder código debido a la locura de la AI 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 estrechas y enfocadas, eso es TDD. TDD se basa en escribir pasos más pequeños, en codificar con tareas en unidades más pequeñas.

Escribes la prueba, escribes la función y luego intentas que la función pase la prueba. Esas acciones más pequeñas son muy productivas para hacer con AI también, especialmente cuando estás construyendo componentes complejos con diferentes condiciones o construyendo un conjunto complicado de funciones de un modelo de negocio. La depuración también es importante. También es muy bueno usar AI. Puedes usar un MCP para obtener registros de CloudWatch, registros de Grafana, información externa sobre un problema que estás tratando de resolver.

Y luego le pides a la AI que no codifique, sino que descubra qué está mal en la base de código basándose en esos registros. Y luego, una vez que tienes un diagnóstico de lo que está sucediendo allí, puedes pedirle a la AI que escriba un plan de implementación para solucionarlo. Y luego revisas ese plan de implementación. Así que para mí, la AI no es magia. Pero con prompts claros, tareas enfocadas, contexto rico, un ciclo de validación que asegura que se mantenga la calidad, puede ser una ventaja injusta.