Ingeniería de Software asistida por IA

Esta charla muestra cómo la inteligencia artificial puede apoyar la ingeniería de software como asistente en tareas de diseño, validación y desarrollo. Se destacan tres áreas: construcción del producto con foco en calidad y seguridad, descubrimiento de referencias de APIs y patrones, e ideación y experimentación a bajo costo. Se introducen técnicas como proyecciones, waywords para precisión semántica, generación desde pruebas, exploración de múltiples soluciones, lensing para refactorización y comunicación, y la estrategia de “resolver primero, luego preguntar”. Se resalta la importancia de los tests automatizados como contrato real, la elección de modelos adecuados y el trabajo en pasos pequeños e iterativos.

Transcript

1. Ingeniería de Software Asistida por IA
2. Fausto Almeida Staff Software Engineer - Galileo LatAm Liderando técnicamente iniciativas de desarrollo de capacidades para Cyberbank Core (BaaS API). Expositor
3. Disclaimer No vamos a hablar de herramientas de IA. No vamos a hablar de cómo implementar capacidades de IA en un producto. Vamos a hablar de técnicas y prácticas… de cómo la IA puede ser utilizada en tareas diarias de desarrollo y diseño de sistemas…
4. "All models are wrong, some are useful" George Box
5. "Las herramientas de IA harán a los malos desarrolladores peores y a los buenos, mejores."
9. Las 3 áreas de uso
10. Las 3 áreas de uso • Construir el producto ◦ Consideraciones de propiedad intelectual ◦ Seguridad y calidad ◦ Requiere de alta validación dependiendo del nivel de riesgo que queramos tolerar • Para descubrir referencias de APIs y features ◦ Encontrar respuestas ◦ Implementaciones de referencia ◦ Investigación • Ideación ◦ Intentar cosas diferentes ◦ Generación exploratoria de código y sandboxing ◦ Generar ideas, no entregables
11. Técnicas Proyecciones
12. Proyecciones - Diagramas como código Ver en Mermaid Live
13. Proyecciones - Diagramas como código Ver en Mermaid Live
14. Proyecciones - Representación matemática Ver en OverLeaf
15. Proyecciones - Representación matemática Ver en OverLeaf
16. Proyecciones - Representación matemática • Especificación precisa ◦ Define el comportamiento sin ambigüedades y sirve como contrato independiente de la implementación. • Verificación formal ◦ Permite demostrar propiedades (invariantes, pre/post condiciones) y usar herramientas de verificación/model checking. • Diseño de pruebas ◦ Facilita derivar casos límite y particiones de equivalencia de forma sistemática. • Mantenibilidad y refactorización ◦ Ofrece un referente para asegurar que cambios o reescrituras preservan la semántica.
17. Proyecciones • Buscamos tener visualización del mismo objeto desde diferentes ángulos. • Cuando cambiamos nuestra perspectiva, notamos cosas diferentes. • Muy útil cuando trabajamos sobre lógica de negocio no trivial. • Estamos expuestos a alucinaciones pero eso no resta su valor. • Ejemplos: ◦ Proyección a representación matemática ◦ Proyección a diagramas como código ◦ Proyección a otros lenguajes de programación ▪ Luego invertir (en sesiones diferentes)
18. Técnicas Waywords
19. Waywords • Los LLMs son muy buenos para inferir el contexto y entender diferentes connotaciones para palabras similares dependiendo del mismo. • Sin embargo, para la programación necesitamos comunicarnos de una forma muy precisa. • Los waywords son palabras "inventadas" que podemos definir dentro de nuestra sesión para poder evitar ambigüedades y tratar de tener resultados un poco más precisos.
20. Waywords
21. Waywords
22. Waywords ¿Cómo persistir waywords de una sesión a otra? • Cursor rules • Copilot guidelines, etc.
23. Técnicas Generar desde las pruebas
24. Generar desde las pruebas - Empezar por partes pequeñas: métodos, clases. - Hasta llegar a hacer el ejercicio con el aplicativo completo. - Ser específico para evitar soluciones rápidas (skipTests). - El proceso puede ser costoso pero realmente beneficioso. - Conocer capacidades de la herramienta (y modelo) que estás usando. - Otra forma de "validar" cobertura de tests Objetivo: - Aprender alternativas de resolución de problemas. - Aunque el código generado difícilmente tendrá la calidad esperada (sujeto a la arquitectura del código), vale la pena conocer estas alternativas.
26. Técnicas Pedir N soluciones
27. Pedir N soluciones - El factor diferenciador de todo este nuevo set de herramientas es el bajo costo que tiene el explorar diferentes alternativas - Ejemplo 1: - Muéstreme tres formas diferentes de calcular una dilatación morfológica binaria en una matriz de 32x32 en Java. - Ejemplo 2: - Muéstrame 5 alternativas de nombres para una nueva columna que se encargará de guardar este dato X en formato Y. Tomando en cuentas las reglas de diseño de base de datos del archivo Z.
28. Pedir N soluciones Aunque esto suele ser muy útil debemos ser conscientes de la carga cognitiva que nos conlleva revisar distintas alternativas que pudieran parecer muy similares. Trabajar dentro de nuestra propia tolerancia.
29. Técnicas Lensing
30. Lensing Ejemplo: - Describe las 7 responsabilidades más importantes de la clase X - Describe las 7 responsabilidades más importantes desde el punto de vista del usuario - Describe las 4 responsabilidades más importantes desde el punto de vista del usuario Bastante útil para: - Refactorizaciones: Extraer responsabilidades de una clase a otra - Comunicación: Explicar en términos de negocio reales lo que es una "responsabilidad" dentro del código
31. Lensing Apoyándonos con features como Cursor rules, por ejemplo: - analysis-methodology.mdc - business-domain-rules.mdc - project-rules.mdc - dsl-system-rules.mdc - search-patterns.mdc
32. Técnicas Resolver, luego preguntar
33. Resolver, luego preguntar Importante: No "mostrar" tu resultado a la herramienta antes de preguntar. Ejemplo: • "Analiza las clases X, Y y Z. Detecta comportamientos comunes y refactoriza las clases utilizando un Strategy Pattern para separar responsabilidades en condiciones específicas". Objetivo: • Comparar nuestras soluciones y ser "autocríticos" con las mismas.
34. Palabras finales
35. Palabras finales - Trabajar en pasos pequeños - Chequear cada paso - "Cuál hubiera sido un mejor nombre para este método/clase?" - Iterar expandiendo el área de análisis/contexto. - "Sugiere cambios de diseño que pudiesen reducir la latencia en esta operación" - Entender lo generado
36. Palabras finales - Reconocer qué herramientas son de propósito general y cuales fueron entrenadas para código - GPT‑4 / GPT‑5 (OpenAI) para hacer ideación. - Claude Sonnet 4 / Opus 4 (Anthropic) para generación de código para Producción. - Importancia de test automatizados, más que nunca… - El verdadero contrato que realmente describe el comportamiento del aplicativo - La red de seguridad para realizar refactorizaciones
37. Referencias • AI Assisted Programming - Michael Feathers ◦ https://leanpub.com/ai-assisted-programming • Where AI Meets Code - Michael Feathers ◦ https://www.youtube.com/watch?v=g9m3R0NMJ1Y • Bonus: Vibe Coding Is The Worst Idea Of 2025 - Dave Farley ◦ https://www.youtube.com/watch?v=1A6uPztchXk
39. "Writing code is NOT the hard part."