IA y Lean Software Development: Reflexiones desde la experimentación

Explorando cómo la inteligencia artificial podría estar cambiando las reglas del juego en el desarrollo de software - ideas preliminares desde la trinchera

Una exploración en territorio inexplorado

Quiero ser transparente desde el inicio: lo que voy a compartir no son conclusiones definitivas ni principios probados. Son reflexiones abiertas que surgen de unos meses de experimentación personal intensa con IA aplicada al desarrollo de software, explorando sus posibilidades y tratando de entender cómo afecta esto a las prácticas Lean que habitualmente utilizamos.

Estos pensamientos no son conclusiones definitivas basadas en experiencia prolongada, sino reflexiones abiertas que me gustaría seguir experimentando y discutiendo con otros interesados en este fascinante tema. No hablo como alguien que ya tiene las respuestas, sino como alguien que está explorando preguntas fascinantes y que sospecha que estamos ante un cambio de paradigma que apenas empezamos a entender.

La paradoja fundamental: velocidad versus validación

Una idea central que estoy observando es que, aunque la inteligencia artificial nos permite trabajar más rápido, eso no implica que debamos ampliar automáticamente el alcance inicial de nuestras funcionalidades. Mi intuición me dice que debemos seguir entregando valor en pequeños incrementos, validar rápidamente y decidir en función del feedback real y no simplemente de la velocidad con que ahora podemos ejecutar tareas.

Pero aquí hay un matiz interesante que he empezado a considerar: en contextos de baja incertidumbre, donde tanto el valor como la implementación son claros y el equipo está muy seguro, podría tener sentido avanzar algo más antes de validar. Sin embargo, mis sensaciones me llevan a pensar que mantener la disciplina para evitar caer en diseño especulativo es fundamental, ya que aunque la IA lo facilite, puede poner en peligro la simplicidad y flexibilidad futura del sistema.

La crisis cognitiva que no vemos venir

Gráfico: Mientras la velocidad de desarrollo con IA crece exponencialmente, nuestra capacidad cognitiva humana permanece constante, creando una "zona de peligro" donde podemos crear complejidad más rápido de lo que podemos gestionarla.

Aquí sí que tengo una convicción que cada día se vuelve más clara: ahora deberíamos ser mucho más radicales a la hora de borrar y eliminar código y funcionalidades que no están generando el impacto esperado.

Lo que me muestra esta visualización es algo que siento visceralmente: tenemos que ser implacables para evitar que la complejidad nos devore, porque por mucha IA que tengamos, la capacidad cognitiva de los humanos no ha cambiado - tanto para gestionar la complejidad técnica como para que los usuarios gestionen el número creciente de aplicaciones y funcionalidades.

Estamos en ese punto crítico donde la línea azul (velocidad de IA) se cruza con la roja (nuestra capacidad), y mi intuición me dice que o desarrollamos disciplinas radicales ahora, o nos adentramos en esa zona roja donde creamos más complejidad de la que podemos manejar.

La paradoja del Lean amplificado

Pero aquí está el quid de la cuestión, y creo que esta tabla lo visualiza perfectamente:

Tabla: La IA elimina las restricciones naturales que nos mantenían disciplinados (al menos a algunos), creando la paradoja de que necesitamos recrear artificialmente esas restricciones a través de disciplina radical.

Esta visualización me parece que captura algo fundamental que estoy observando: la IA elimina las restricciones naturales que nos mantenían aplicando principios Lean. Antes, el alto coste de implementación naturalmente nos forzaba a hacer batches pequeños. Ahora tenemos que recrear esa disciplina artificialmente.

Por ejemplo, fíjate en el línea de "Small Batches": tradicionalmente la velocidad de desarrollo era la restricción natural que nos forzaba a validar temprano. Ahora, con IA, ese freno desaparece y corremos el riesgo de crecimiento inconsciente del scope. La contramedida no es técnica, es cultural: redefinir explícitamente qué significa "pequeño" en términos de carga cognitiva, no de tiempo.

Lo mismo pasa con YAGNI: antes el alto coste de implementación era una barrera natural contra el diseño especulativo. Ahora la IA "sugiere mejoras" y hace que el overengineering sea tentador y fácil. La respuesta es hacer YAGNI aún más explícito.

Esta es la paradoja que más me fascina: tenemos que volvernos más disciplinados justo cuando la tecnología nos lo pone más fácil.

A partir de esta intuición general, he identificado varios patrones específicos que me preocupan y algunas oportunidades que me emocionan. Son observaciones que surgen de mi experimentación diaria, algunas más claras que otras, pero todas me parecen lo suficientemente relevantes como para compartirlas y seguir explorándolas.

Sobre el scope y la complejidad

Cambio en el "tamaño por defecto" del trabajo

La IA facilita el desarrollo inmediato de funcionalidades o refactors, lo que puede llevarnos inconscientemente a aumentar su tamaño. El riesgo que percibo es perder la disciplina de small batch size clave para validación temprana.

Exploración en curso: Mi intuición sugiere redefinir explícitamente lo que significa "pequeño" en un contexto con IA, enfocado en tamaño cognitivo y no solo en tiempo de implementación. Una forma de conseguirlo es apoyándonos en prácticas como BDD/ATDD/TDD para limitar cada ciclo a un test o comportamiento externo validable.

Diseño especulativo amplificado

En varias ocasiones he tenido que deshacer trabajo hecho por la IA porque intenta hacer más de lo necesario. He observado que la IA carece de sensibilidad al diseño orientado a objetos y no tiene ningún tipo de consciencia sobre la complejidad que genera, creándola muy rápido hasta llegar a un punto del que no sabe salir y entra en bucle, arreglando una cosa y rompiendo otras.

Reflexión: Esto me sugiere reforzar prácticas deliberadas como TDD, walking skeletons o feature toggles estrictos.

Nuevo tipo de "overengineering"

Mi experiencia inicial sugiere que la facilidad que ofrece la IA puede llevar a añadir funcionalidades innecesarias. No es el overengineering clásico del arquitecto que diseña una catedral cuando necesitas una cabaña. Es más sutil: es añadir "solo una funcionalidad más" porque es fácil, es crear "solo una abstracción adicional" porque la IA puede generarla rápidamente.

Sensación clave: Reforzar el principio YAGNI de forma aún más explícita parece necesario.

Sobre el flujo de trabajo y las validaciones

Diferenciar trabajo visible vs. trabajo liberado

Mi experiencia me indica que el rápido desarrollo no debe confundir "listo para desplegar" con "listo para liberar". Mi sensación es que mantener clara la separación entre deployment y release sigue siendo fundamental.

También he desarrollado varias veces pequeñas funcionalidades que luego no se han usado. Aunque, siendo honesto, como tengo muy interiorizado eliminar desperdicio y coste basal, simplemente he borrado el código posteriormente.

Oportunidad que veo: La IA puede acelerar desarrollo mientras validamos con pruebas controladas como A/B testing.

Más trabajo en curso, pero con límites

Aunque la IA puede permitir más trabajo paralelo, mi intuición me dice que esto puede fragmentar la atención del equipo y complicar la integración. Es tentador tener tres o cuatro funcionalidades "en desarrollo" simultáneo porque la IA hace que avancen rápido.

Mi preferencia actual: Usar IA para reducir tiempo de ciclo por historia, priorizando feedback rápido, en lugar de paralelizar más trabajo.

Cambio en el tipo de errores que cometemos

Mis observaciones sugieren que con IA, los errores pueden propagarse rápidamente, generando complejidad innecesaria o decisiones superficiales. Una decisión superficial o un malentendido del problema puede materializarse en código funcional antes de que haya tenido tiempo de reflexionar sobre si es la dirección correcta.

Exploración: Mi intuición apunta hacia reforzar guardrails culturales y técnicos (tests, revisión de decisiones, principio de mínima solución viable).

Sobre la cultura y el aprendizaje

Impacto en la cultura y el aprendizaje

Siento que existe el riesgo de confiar excesivamente en IA, lo que podría reducir la reflexión colectiva. La capacidad cognitiva humana no ha cambiado, y seguimos siendo mejores enfocándonos en pocas cosas a la vez.

Intuición de trabajo: Pair programming asistido por IA, rotaciones de ownership y revisiones explícitas de decisiones de producto podrían contrarrestar este efecto.

Ideas que estoy explorando para gestionar estos riesgos

Después de identificar estos patrones, la pregunta natural es: ¿qué podemos hacer al respecto? Las siguientes son ideas que estoy explorando, algunas ya las he probado con resultados mixtos, otras son hipótesis de trabajo que me gustaría contrastar. Siendo honestos, estamos en una fase muy embrionaria de entender todo esto.

Disciplina en la Eliminación Radical Mi intuición sugiere introducir "Deletion Reviews" periódicas para eliminar activamente código sin impacto real. Sesiones específicas donde el objetivo principal sea identificar y borrar lo que no está generando valor.

"Sunset by Default" para experimentos La sensación es que podríamos necesitar una política explícita de caducidad automática para experimentos no validados. Si no demuestran valor en X tiempo, se eliminan automáticamente, sin excepciones.

Tracking de Impacto más riguroso Mi experiencia me lleva a pensar en definir criterios explícitos de impacto antes de escribir código y eliminar despiadadamente lo que no cumpla expectativas en el tiempo establecido.

Fomentar la Mentalidad de "Disposable Software" Mi sensación es que etiquetar explícitamente funcionalidades como "disposable" desde el inicio podría facilitar psicológicamente la eliminación si no cumplen expectativas.

Reducción continua de "Legacy generado por IA" Siento que podrían ser valiosas las sesiones regulares para revisar código generado automáticamente y eliminar complejidades innecesarias que la IA haya introducido sin que nos diéramos cuenta.

Reforzar radicalmente el Principio de "YAGNI" Mi intuición me dice que deberíamos integrar explícitamente preguntas críticas en revisiones para evitar diseño especulativo: "¿Realmente necesitamos esto ahora? ¿Qué evidencia tenemos de que será útil?"

Mayor rigor en Pair Programming Asistido por IA Mi experiencia inicial sugiere promover "Pair Programming híbrido" para asegurar reflexión suficiente y calidad estructural. Nunca dejar que la IA tome decisiones arquitectónicas sola.

Una oportunidad fascinante: Cross Cutting Concerns y el YAGNI reforzado

Más allá de gestionar los riesgos, he empezado a notar algo prometedor: la IA también parece abrir nuevas posibilidades para decisiones arquitectónicas y funcionales que tradicionalmente debían anticiparse desde el principio.

Me refiero específicamente a elementos como:

• Internacionalización (i18n): ¿Realmente necesitamos diseñar para múltiples idiomas desde el día uno?
• Observabilidad y monitorización: ¿Podemos empezar simple y añadir instrumentación después?
• Cumplimiento normativo (compliance): ¿Es posible construir primero y adaptar regulaciones más tarde?
• Escalabilidad horizontal y adaptación a arquitecturas distribuidas: ¿Podemos diferir estas decisiones hasta tener evidencia real de necesidad?

Mi sensación es que estas decisiones pueden posponerse deliberadamente y ser introducidas más tarde gracias a las capacidades de refactorización automática que parece brindar la IA. Esto podría fortalecer aún más nuestra capacidad de aplicar YAGNI y defer commitment.

Los guardrails que creo necesarios

Para que esto funcione, siento que necesitamos mantener ciertos guardrails técnicos:

• Separación clara de responsabilidades: Para que los cambios posteriores no rompan todo
• Pruebas automatizadas sólidas: Para refactorizar con confianza
• Documentación explícita de decisiones pospuestas: Para no olvidar lo que diferimos
• Uso de IA especializada para spikes arquitecturales: Para explorar opciones cuando llegue el momento

Pero insisto: esto son solo intuiciones que me gustaría validar colectivamente.

Hipótesis de trabajo que me encantaría contrastar

Después de estos meses de experimentación, estas son las hipótesis que han emergido y que me encantaría discutir y probar colectivamente:

1. Velocidad ≠ Amplitud

Hipótesis: Deberíamos usar la velocidad de la IA para validar más rápido, no para construir más grande.

2. YAGNI radical

Hipótesis: Si antes YAGNI era importante, ahora podría ser crítico. La facilidad de implementación no debería justificar la complejidad adicional.

3. Eliminación como disciplina central

Hipótesis: Tratar la eliminación de código como una práctica de desarrollo de primera clase, no como una actividad de mantenimiento.

4. Pair Programming híbrido

Hipótesis: Combinar la velocidad de la IA con la reflexión humana podría ser clave. Nunca dejar que la IA tome decisiones arquitectónicas sola.

5. Separación deployment/release reforzada

Hipótesis: Mantener esta separación más clara que nunca. La facilidad de implementación podría crear espejismos de "producto terminado".

6. Cross-cutting concerns diferidos

Hipótesis: Podemos posponer más decisiones arquitectónicas que antes, aprovechando las capacidades de refactorización de la IA.

Una invitación honesta al aprendizaje conjunto

En definitiva, estas son ideas y reflexiones iniciales, abiertas a discusión, experimentación y aprendizaje. Mi intuición me dice que la inteligencia artificial está cambiando radicalmente la forma en que desarrollamos producto y software, potenciando nuestras capacidades, pero sugiriéndome la necesidad de una disciplina aún mayor en validación, eliminación y simplificación radical del código.

Mi hipótesis más fuerte es esta: la IA amplifica tanto nuestras buenas como nuestras malas prácticas. Si tenemos disciplina para mantener pequeños batches, validar rápido y eliminar desperdicio, la IA podría hacernos extraordinariamente efectivos. Si no la tenemos, podría ayudarnos a crear desastres más rápido que nunca.

Pero esto es solo una corazonada que necesita validación.

¿Qué experiencias habéis tenido vosotros? ¿Habéis notado estos mismos patrones, o completamente diferentes? ¿Qué prácticas estáis probando? ¿Habéis notado estos mismos efectos en vuestros equipos? ¿Qué sensaciones os genera la integración de IA en vuestros procesos Lean?

Estamos en los primeros compases de entender todo esto. Necesitamos las perspectivas de toda la comunidad para navegar este cambio que intuyo puede ser de paradigma, pero que aún no comprendo del todo.

Continuemos la conversación. La única forma de avanzar es explorando juntos.

¿Te resuenan estas reflexiones? ¿Has notado patrones similares o completamente diferentes? Me encantaría conocer tu experiencia y seguir aprendiendo juntos en este territorio fascinante y aún inexplorado.