Claude Code actúa como un agente de programación: lee el código, edita archivos y ejecuta comandos. Pero como en cada sesión arranca con la memoria en blanco, si el proyecto en el que estás no incluye la documentación que espera encontrar, en los archivos que espera encontrar y con los nombres que espera encontrar, es como tener un compañero brillante al que le tienes que presentar el proyecto cada mañana.

Empecé a base de intuición: una carpeta /docs por aquí, un archivo de esquema SQL por allá. Funcionaba, pero no del todo. Hasta que entendí cómo espera Claude Code encontrar la documentación del proyecto y cómo darle contexto entre sesiones.

He recopilado lo que he aprendido en estas dos guías que comparto por si os pueden ser útiles:

Primeros pasos con Claude Code — Para empezar desde cero: viendo que claude.ai no es lo mismo que Claude Platform (que no me resultó obvio al principio), cómo instalarlo, autenticar y hacer la primera sesión.

Buenas prácticas con Claude Code — Cómo estructurar las carpetas del proyecto, qué poner en el CLAUDE.md, cómo crear comandos personalizados y subagentes, y los errores que conviene evitar.

Las he escrito con la ayuda de Claude (sí, meta-recursivo), así que ha sido como hacer con él un curso acelerado para trabajar con él :-D.

Sigo aprendiendo, así que para los que vayáis por delante y veáis cosas mejorables o tengáis vuestras propias prácticas, se agradecen las sugerencias.

La entrada Claude Code: lo que me hubiera gustado saber desde el principio se publicó primero en Navegápolis.

Scrum nació como síntesis de nuevo conocimiento al cuestionar el modelo de desarrollo en cascada de los años 80, mejorándolo con iteraciones cortas, equipos autónomos y entrega incremental.
Ahora el modelo de desarrollo vuelve a cambiar: la IA comprime ciclos, reconfigura equipos y cambia la forma de definir lo que queremos que construir. La espiral del conocimiento sigue girando: el marco inicial de scrum pasa a ser la tesis, la IA plantea la antítesis, y ya está tomando forma la nueva síntesis.

En este post intento de esbozar esta «síntesis»; no como una receta cerrada, sino dibujando el mapa de las zonas en las que la comunidad profesional ya está experimentando con evoluciones prácticas.

El sprint: más corto, más flexible, pero no prescindible

La cadencia de dos semanas ha sido el estándar de facto durante años, pero hay que recordar que no siempre fue así: las primeras iteraciones de scrum usaban ciclos de uno o dos meses. Fue la propia comunidad la que fue acortando la cadencia a medida que el contexto lo pedía. Con la IA, ese contexto ha cambiado otra vez: hay equipos que generan incrementos funcionales en días o incluso horas.

¿Significa esto que el sprint ya no sirve? No exactamente, el principio de trabajar en ciclos con puntos de inspección y adaptación sigue siendo esencial, lo que tenemos que cambiar es la duración y el formato.

Lo que está funcionando en equipos que ya trabajan con IA:

Micro-iteraciones dentro del sprint. El sprint se mantiene como contenedor de planificación y revisión estratégica, pero dentro de él el equipo ejecuta múltiples ciclos cortos de ideación-generación-validación con IA. El sprint se enriquece con un ritmo interno más rápido.

Sprints más cortos. Una semana o incluso menos, acercando la cadencia a la velocidad real de entrega.

Cadencia dual. Un ritmo rápido para exploración y prototipado (días) y otro más pausado para ingeniería de producción y validación (semanas). Esto conecta con un modelo emergente de «doble carril».

Se siguen manteniendo los momentos de reflexión. La retrospectiva es ahora más necesaria que nunca: los equipos están aprendiendo a trabajar con una tecnología nueva y necesitan espacios para evaluar qué funciona y qué no. Paradójicamente, es la velocidad de la IA la que hace más necesaria la pausa para pensar.

Equipos más pequeños, pero no sin estructura

La IA permite que equipos más reducidos logren lo que antes requería equipos grandes. La investigación de Harvard Business School (Dell’Acqua et al., 2025) afirma que equipos de 2-3 personas con asistencia de IA están consiguiendo resultados que antes requerían 7-10.

Cuando el equipo tiene como mucho 4 personas y la «voz» de una IA, algunas evoluciones que tienen sentido son:

• La daily puede transformarse en un check-in ligero, quizás asíncrono. En un equipo de dos o tres personas que se ven continuamente, una reunión formal de 15 minutos es desproporcionada.
• La planning puede simplificarse a una sesión de priorización y definición de especificaciones para la IA.
• La retrospectiva mantiene su valor pleno —quizás más que nunca— como espacio para evaluar cómo está funcionando la colaboración humanos+IA.

La idea no es eliminar eventos sino ajustar su peso al tamaño y la naturaleza del equipo. Algo que, por cierto, la agilidad siempre ha animado a hacer.

De las historias de usuario a las especificaciones (sin volver a la cascada)

Las historias de usuario son un medio de comunicación entre personas: «Como [usuario], quiero [acción] para [beneficio]». Son excelentes para transmitir intención. Pero cuando el interlocutor es una IA generativa, la intención no basta: la IA necesita contexto técnico, restricciones explícitas y criterios verificables.

Aquí entra una práctica que está ganando tracción: el Spec-Driven Development (SDD). La idea es que especificaciones detalladas se convierten en el artefacto del que la IA deriva código. Herramientas como GitHub Spec Kit ya formalizan este flujo: se describe qué se quiere construir, el agente genera una spec detallada, propone un plan, lo descompone en tareas y las ejecuta mientras el desarrollador revisa cambios focalizados.

La clave, y esto es importante, es no sustituir la historia por la spec sino relacionarlas en convivencia. La historia de usuario sigue es valiosa para capturar la intención y el contexto de negocio. La spec traduce esa intención a un lenguaje que la IA puede procesar. Y las specs deben ser documentos vivos que iteran como un backlog: se refinan, se adaptan, evolucionan.

Hay un riesgo aquí que vale la pena nombrar: si las especificaciones se vuelven rígidas y exhaustivas, podemos regresar al modelo de cascada sin darnos cuenta. La solución es tratar la spec como documentación operativa, no como un contrato inamovible. Es el lenguaje común entre humanos e IA, no burocracia.

Los roles: evolución.

Product Owner → Product Architect

Cuando la IA puede construir features más rápido de lo que la organización puede validar si son las correctas, el Product Owner se convierte en el factor limitante de la cadena de valor. Y eso, lejos de restarle importancia, se la multiplica.

Su evolución natural es hacia un Product Architect cuyo foco se desplaza de gestionar un backlog a ser el constructor de la decisión estratética: ¿qué se debe construir? Esto requiere competencias nuevas —data literacy, diseño de experimentos de validación, gestión de la tensión entre velocidad de producción y ritmo de validación—, la esencia del rol sigue siendo: maximizar el valor del producto.

Scrum Master → Agile Enabler

Quizá el rol donde más claridad se necesita. Lo que evoluciona no es la necesidad de alguien que facilite cómo trabaja el equipo, sino el alcance y la naturaleza de esa facilitación.

Cuando el equipo era un grupo de 7 personas, facilitar significaba sobre todo coordinar interacciones, eliminar impedimentos y proteger el espacio del equipo. Cuando el equipo es un sistema de 2-3 personas orquestando a agentes de IA, facilitar significa algo bastante más amplio:

Diseñar flujos de colaboración híbridos. ¿Cómo se divide el trabajo entre humanos e IA? ¿Estamos dando a la IA el contexto suficiente? ¿Revisamos sus outputs con el rigor adecuado? Alguien tiene que facilitar estas preguntas y optimizar estos flujos.

Gobernanza ética y de calidad. ¿Quién rinde cuentas cuando un agente comete un error? ¿Cómo gestionamos los sesgos? ¿Qué políticas de uso necesitamos? El facilitador ayuda al equipo a desarrollar estas políticas como práctica viva, no como imposición burocrática.

Gestión de la confianza. Los datos muestran desconfianza de los desarrolladores en el código o trabajo generado por IA. El facilitador ayuda a construir una relación sana con la IA: ni confianza ciega ni desconfianza paralizante. Esto requiere las mismas competencias de inteligencia emocional que siempre definieron al buen Scrum Master, aplicadas a un contexto nuevo.

Coaching del cambio. La transición hacia equipos potenciados con IA no es solo técnica: es cultural. Hay resistencias, curvas de aprendizaje desiguales y dinámicas que cambian cuando la IA redistribuye capacidades. Facilitar esa transición es trabajo de un profesional experimentado en dinámicas humanas.

Pensamiento sistémico. El facilitador evolucionado no ve eventos aislados sino el sistema completo: cómo fluye el trabajo, dónde se generan cuellos de botella, cómo interactúan los loops de feedback y qué consecuencias no intencionadas produce el uso de IA.

En resumen: el Scrum Master se transforma en alguien que facilita sistemas de trabajo más complejos, donde la complejidad no viene solo de las personas sino de la interacción entre personas e inteligencias artificiales.

Developers → Product Builders

El equipo de desarrollo evoluciona hacia perfiles que combinan herramientas no-code, generación de código asistida por IA y comprensión profunda del producto. Su valor se desplaza desde la implementación hacia la orquestación: diseñar arquitecturas, escribir especificaciones, revisar lo que la IA genera y asegurar estándares de calidad.

Calidad: el frente donde más atención hace falta

Este es posiblemente el punto más delicado de toda la evolución. Los datos invitan a la prudencia: sin controles deliberados, la IA acelera la acumulación de deuda técnica. El equipo va más rápido, pero el código puede volverse frágil y costoso de mantener.

Las prácticas que están emergiendo como respuesta son sensatas y pragmáticas:

• IA supervisando IA: una IA como revisora automática de lo que otra genera, con semáforos y revisiones automatizadas.
• Specification by Example: tests con especificaciones concretas y verificables. La IA no puede corregir sus propios deberes.
• Definition of Done reforzada: adaptada para código generado por IA, incluyendo revisiones de seguridad, análisis estático y verificación de no-duplicación.
• Auditoría continua de deuda técnica: monitorización activa de métricas de salud del código como contrapeso a la velocidad.

Aquí es donde los principios de inspección y adaptación se vuelven, si cabe, más necesarios. La velocidad sin validación es desperdicio.

Dos incorporaciones emergentes que vale la pena conocer

El Doble Carril (Double-Track)

Un carril rápido (Vibe Coding) para crear prototipos no liberables a producción, validar ideas rápidamente usando IA y no-code. Aquí la calidad del código es secundaria; lo que importa es la velocidad de aprendizaje.

Un carril robusto (Vibe Engineering) que asegura estándares de ingeniería, seguridad y calidad para lo que va a producción. Aquí se aplican SDD, Definition of Done reforzada y QA.

La separación entre carriles no es nueva —el dual-track agile existe desde hace años—, pero la IA la hace más explícita y necesaria. La velocidad del carril rápido puede ser 10x-100x mayor que la del robusto, lo que exige gestión consciente de cuándo una idea pasa de uno a otro.

IA como Teammate

El framework de Scrum.org propone cuatro pasos para integrar la IA como compañero de equipo: selección de modelos, provisión de contexto, prompt engineering y gobernanza. Es un enfoque más conservador, directamente compatible con Scrum actual y adoptable de forma incremental. Un buen punto de partida para equipos que están empezando.

La espiral sigue girando

Scrum es conocimiento abierto. No es un modelo «propietario» que tenga una definición en exclusividad. Emergió desde abajo, construido por la comunidad profesional, y así ha evolucionado siempre: los sprints se acortaron, las retrospectivas se generalizaron, el refinamiento del backlog se formalizó.

La integración de la IA es el siguiente capítulo natural de esa evolución. Los equipos ya están experimentando con nuevas formas de trabajar. Algunas se están articulando como prácticas emergentes. La síntesis está en construcción.

No hay que esperar a que nadie nos dé permiso. Es lo que siempre hemos hecho.

La entrada Scrum en la era de la IA: la síntesis que viene se publicó primero en Navegápolis.

Así que aprovechando la fiesta del 5 de marzo (para eso hay que ser de Zaragoza )este es el resultado: Legado Digital: un único ejecutable que se puede guardar en un pendrive, sin instalación. Almacena la información cifrada con AES-256-GCM y Argon2id.

Esta es la información de lo que he usado, y la aplicación, por si os puede ser útil:

He usado:

• Antigravity coon Gemini3.1 Pro.
• Go para el motor de seguridad.
• base de datos SQLite (en memoria)
• Svelte + TailwindCSS para la interfaz
• Wails v2 para empaquetarlo todo en un único binario de Windows.

El programa lo podéis descargar en el enlace de abajo que tiene el ejecutable y un txt de instrucciones, que comparto tal cual, sin compromisos de licencia ni mantenimiento para los que os pueda resulta útil.

Descargar legado.zip

La entrada Legado digital se publicó primero en Navegápolis.

La entrada BurlaBurlando se publicó primero en Navegápolis.

Para entender Spec-Driven Developmen (SDD) o, hablando en nuestro idioma: desarrollo guiado por especificaciones, es bueno empezar conociendo el problema que intenta solucionar.
En febrero de 2025, Andrej Karpathy (cofundador de OpenAI y exdirector de IA en Tesla) acuñó el término vibe coding en un tweet que se hizo viral⁽¹⁾

«Hay un nuevo tipo de programación que llamo ‘vibe coding’, donde te dejas llevar completamente por las vibraciones, abrazas los exponenciales, y olvidas que el código siquiera existe. […] Acepto todo siempre, ya no leo los diffs. Cuando recibo mensajes de error, simplemente los copio y pego sin comentarios, y normalmente eso lo arregla.»

Para proyectos de fin de semana o prototipos rápidos, dejarse llevar por la IA puede funcionar, pero tiene limitaciones: código aparentemente correcto, pero con bugs sutiles, arquitecturas inconsistentes, vulnerabilidades de seguridad, y la incomodidad de no conocer la lógica que implementa el código generado.

Los datos son reveladores: según Y Combinator, el 25% de las startups de su cohorte de invierno 2025 tenían bases de código generadas en un 95% por IA⁽²⁾. Es impresionante, pero: ¿quién entiende y mantiene ese código?

Qué es Spec Driven Development

Spec Driven Development es, en esencia, un enfoque en el que la especificación precede y guía al código. No es un framework ni una metodología prescriptiva como scrum. Es una filosofía de trabajo que propone:

1. Escribir primero una especificación clara de lo que se desea construir: objetivos, reglas de negocio, criterios de aceptación, restricciones técnicas.
2. Usar esa especificación como fuente tanto para humanos como para agentes de IA.
3. Generar código a partir de la spec, no de prompts improvisados.

Como lo resume GitHub en su documentación de Spec Kit: «En este nuevo mundo, mantener software significa evolucionar especificaciones. […] El código es el enfoque de última milla.»⁽³⁾

Los tres niveles de SDD

Birgitta Böckeler, de Thoughtworks, propone una taxonomía útil para entender las diferentes implementaciones⁽⁴⁾:

• Spec-first: Escribes la spec antes de codificar, la usas para la tarea en curso, y luego la descartas. Es el nivel más básico.
• Spec-anchored: La spec se mantiene después de completar la tarea y se usa para evolución y mantenimiento del feature.
• Spec-as-source: La spec es el artefacto principal. Solo editas la spec, nunca tocas el código directamente. El código se regenera desde la especificación.

La mayoría de herramientas actuales operan en el nivel spec-first, algunas aspiran a spec-anchored, y solo unas pocas experimentan con spec-as-source (como Tessl Framework).

La relación con IA: el catalizador del resurgimiento

Aunque la idea de «especificar antes de codificar» está en el origen de la ingeniería de software, SDD ha resurgido ahora por una razón específica: los LLMs necesitan contexto estructurado para generar código coherente.

Piénsalo así: cuando le das a un agente de código un prompt vago como «hazme un login», está adivinando arquitectura, patrones, validaciones y flujos de error. Cuando le das una especificación detallada que define exactamente qué debe pasar, el código resultante tiene muchas más probabilidades de hacer lo que necesitas.

La spec funciona como un «super-prompt» persistente y versionable. Como describe el equipo de Kiro (AWS): «Una especificación es una especie de super-prompt (versionado, legible por humanos).»⁽⁵⁾

Herramientas del ecosistema

El ecosistema de herramientas SDD está creciendo rápidamente⁽⁶⁾:

• GitHub Spec Kit: Toolkit open source que proporciona un flujo estructurado: Constitution → Specify → Plan → Tasks → Implement. Funciona con Copilot, Claude Code y otros.
• Kiro (AWS): IDE basado en VS Code con flujo integrado de Requirements → Design → Tasks.
• Tessl Framework: Explora el nivel spec-as-source con mapeo 1:1 entre specs y archivos de código.
• BMAD Method: Usa agentes virtuales (Analyst, Product Manager, Architect) para generar PRDs y specs de arquitectura.

SDD, TDD y BDD: primos cercanos, no competidores

Si trabajas con metodologías ágiles, probablemente te preguntarás cómo encaja SDD con prácticas que ya conoces. La buena noticia: no son excluyentes, son complementarias⁽⁷⁾.

• TDD (Test Driven Development): Tests primero. Escribes un test que falla, luego el código para pasarlo. Excelente para calidad a nivel de unidad, pero no captura el intent de producto completo.
• BDD (Behavior Driven Development): Comportamiento primero. Escenarios en formato Given-When-Then que describen cómo se comporta el sistema. Fuerte para alineación con stakeholders, pero deja decisiones técnicas abiertas.
• SDD (Spec Driven Development): Especificación primero. Define el qué y el por qué, añade un plan técnico, y descompone en tareas. La spec es el ancla que mantiene a todos (humanos y agentes) alineados.

En la práctica, puedes usar SDD para definir el feature completo, TDD para cada tarea individual, y BDD para validaciones end-to-end. Como dice Beam.ai: «SDD te dice qué y por qué. BDD verifica comportamiento en todo el sistema. TDD asegura corrección a nivel de código. Estas prácticas funcionan bien juntas.»

La tensión con Agile (y cómo resolverla)

La pregunta incómoda surge porque el Manifiesto Ágil dice «software funcionando sobre documentación extensiva», y esto contradice SDD ese principio al pedir especificaciones detalladas.

La respuesta corta es que depende de cómo lo implementes; y la respuesta larga es que SDD no propone documentación extensiva estilo waterfall. Propone especificaciones vivas, ejecutables y versionadas que evolucionan con el código. Como GitHub lo describe: «Spec-Driven Development no se trata de escribir documentos de requisitos exhaustivos que nadie lee. Tampoco se trata de planificación waterfall.» ⁽³⁾

En la práctica, SDD funciona bien a nivel de feature o sprint. No estás especificando todo el producto de antemano; estás especificando la siguiente funcionalidad con suficiente detalle para que un agente de IA pueda implementarla correctamente.

Consideraciones críticas y limitaciones

Pero SDD puede no ser una bala de plata. Estos son los puntos de crítica más relevantes en la comunidad profesional:

El problema humano

Como señala Daniel Sogl en DEV Community: «El problema principal no es la IA, es el factor humano. SDD requiere que los desarrolladores especifiquen sus intenciones con precisión. […] Después de más de 10 años en desarrollo de software, rara vez he experimentado proyectos donde los requisitos estuvieran completamente formulados antes de la implementación.»⁽⁸⁾

Escribir buenas specs es difícil. Requiere claridad de pensamiento, conocimiento del dominio, y la disciplina de pensar antes de actuar.

Overhead vs. beneficio

Birgitta Böckeler de Thoughtworks probó varias herramientas SDD y encontró que para tareas pequeñas, el proceso era desproporcionado: «Cuando pedí a Kiro que arreglara un pequeño bug, el documento de requisitos lo convirtió en 4 ‘user stories’ con 16 criterios de aceptación […] Era como usar un mazo para romper una nuez.»⁽⁴⁾

SDD tiene más sentido para features medianos a grandes donde la inversión upfront se amortiza en menos correcciones posteriores.

Falsa sensación de control

Las ventanas de contexto son más grandes, pero eso no significa que la IA siga todas las instrucciones. Böckeler observó: «Frecuentemente vi al agente no seguir todas las instrucciones. […] También vi al agente excederse porque seguía instrucciones demasiado ávidamente.»⁽⁴⁾

Las specs ayudan, pero no eliminan el no-determinismo de los LLMs. Todavía necesitas revisar y validar.

¿Revisar markdown o código?

Algunas herramientas generan cantidades masivas de archivos markdown. Como comenta Böckeler: «Honestamente, preferiría revisar código que todos estos archivos markdown. […] Eran repetitivos y tediosos de revisar.»⁽⁴⁾

Una buena herramienta SDD debería proporcionar una experiencia de revisión de specs genuinamente mejor que revisar código, no peor.

Entonces, ¿merece la pena?

Como con cualquier práctica emergente, la respuesta honesta es: depende.

SDD probablemente te beneficie si:

• Trabajas regularmente con agentes de código IA
• Tus proyectos tienen complejidad media-alta
• Valoras la trazabilidad y la documentación viva
• Tu equipo puede invertir tiempo en aprender un nuevo flujo de trabajo

Probablemente no lo necesites si:

• Solo haces prototipos rápidos o proyectos personales
• Tu trabajo consiste principalmente en fixes pequeños y mantenimiento
• Prefieres un control directo y granular sobre cada línea de código

Si decides probarlo, el consejo del equipo de AI Native Dev es pragmático: «Empieza con un feature. No especifiques toda tu aplicación. Elige una funcionalidad bien entendida y escribe una spec detallada. Ve cómo rinde tu agente de IA.»⁽⁹⁾

Como resume el equipo de AI Native Dev: «Estamos todos descubriendo esto juntos, y los patrones que emerjan vendrán de experiencias compartidas entre cientos de equipos.»⁽⁹⁾

Fuentes citadas

[1]: Andrej Karpathy en X (Twitter), 2 de febrero de 2025: x.com/karpathy/status/1886192184808149383
[2]: «Vibe coding» – Wikipedia. Datos de Y Combinator: es.wikipedia.org/wiki/Vibe_coding
[3]: GitHub Blog – Spec-driven development with AI: github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai
[4]: Birgitta Böckeler, Thoughtworks – Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl: martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
[5]: Kiro – The future of AI spec-driven software development: kiro.dev/blog/kiro-and-the-future-of-software-development
[6]: Microsoft for Developers – Diving Into Spec-Driven Development With GitHub Spec Kit: developer.microsoft.com/blog/spec-driven-development-spec-kit
[7]: Beam.ai – Spec Driven Development: The Future of Building with AI: beam.ai/agentic-insights/spec-driven-development
[8]: Daniel Sogl – Spec Driven Development: A initial review, DEV Community: dev.to/danielsogl/spec-driven-development-sdd-a-initial-review-2llp
[9]: AI Native Dev – Spec-Driven Development: 10 things you need to know about specs: ainativedev.io/news/spec-driven-development-10-things-you-need-to-know-about-specs

La entrada Spec-Driven Development se publicó primero en Navegápolis.

Es inevitable preguntarse si en la práctica, la presión por los resultados no inclinará la balanza hacia la optimización y convertirá las buenas intenciones humanistas en discursos de bien quedar.

La encrucijada oculta en el mismo marco

Para la cultura de la empresa, el «Scrum Guide Expansion Pack» es un test de Rorschach, que refleja la que ya tiene. La empresa puede proyectar sus valores sobre el texto y encontrar, la confirmación que necesita para validar su enfoque.

Una organización centrada en las personas, busca en el texto la inspiración para validar o desarrollar su cultura de confianza, creatividad y desarrollo de personas y , por supuesto, la encuentra:

• Encuentra un liderazgo que sirve, no que manda: Confirma su creencia en un liderazgo de servicio al leer que su función es «…cultivar el entorno para los equipos Scrum autogestionados…«. Identifica el significado de nutrir y remover obstáculos, no dirigir ni controlar.
• Encuentra en la autogestión un motor de innovación al encontrar que los «Equipos Scrum autogestionados organizados en torno al valor son cruciales para la resolución creativa de problemas y la captura de la emergencia«. Valida que la autogestión es el camino para desatar el potencial colectivo ante la complejidad.
• Pone a la IA al servicio del talento humano, afianzando su visión de la tecnología como una palanca para las personas, al leer que la IA debe permitir que «…los miembros humanos del equipo Scrum se centren en consideraciones estratégicas, creativas y éticas«. La IA es un asistente que libera, no un sustituto que optimiza.

Pero al mismo tiempo, una organización con una cultura arraigada en la eficiencia, la predictibilidad y el control de procesos, busca en el mismo documento la justificación para perfeccionar y acelerar su maquinaria productiva y, también la encuentra:

• Encuentra en el Lean Thinking la coartada para la eficiencia extrema: El pensamiento lean «…reduce el desperdicio en el trabajo y en cómo se lleva a cabo…«. Desperdicio es todo lo que no sea producción directa, osea se pueden eliminar debates «innecesarios» y estandarizar procesos para maximizar el flow.
• Encuentra en la IA el camino hacia la automatización del control: Se entusiasma al leer que la IA puede «…actualizar y repriorizar los elementos del Product Backlog…» o que sus «…análisis basados en IA mejoran la transparencia, la inspección y la adaptación», viendo aquí un consejo para reemplazar el juicio humano por algoritmos eficientes que optimizan el rendimiento a escala.
• Encuentra en la responsabilidad un mecanismo de conformidad: Define la profesionalidad de forma rígida al encontrar que los desarrolladores son «…colectivamente responsables de: Instaurar la calidad adhiriéndose y mejorando la definición de resultado terminado (Definition of Output Done)«. La responsabilidad se convierte en conformidad con la norma, y la calidad en una checklist que el sistema debe superar.

Para esta organización, la “agilidad” es un marco adecuado para modernizar el taylorismo, con un barniz vanguardista, sin alterar su núcleo de control y eficiencia.

Las dos organizaciones aplican el “Pack”, y en ambos casos el resultado es la intensificación la cultura que ya poseían.

Cuando el marco deja de ser un mapa y se convierte en un espejo

Un marco ambiguo puede funcionar como un espejo que refleja la cultura y las intenciones preexistentes. A una organización centrada en las personas, el marco valida y refuerza su enfoque, pero a una organización centrada en el producto, también.

Puede ser un eco de lo que ya es la organización y el peligro se hace más profundo cuando no se usa como espejo sino como máscara. Porque la ambigüedad permite adoptar la retórica de la agilidad centrada en las personas —»empoderamiento» , «autogestión» «seguridad psicológica», etc. — para construir una fachada sin una realidad consecuente.

Las consecuencias: cinismo, estancamiento y devaluación

Para las personas, el cinismo de las organizaciones que predican el humanismo pero practican el taylorismo es agotador. Mata la confianza, la motivación y con ello: la creatividad.

Para la organización el resultado es una transformación estancada. Se adoptan los rituales, pero sin cambiar el ADN cultural, confundiendo la actividad con el progreso.

Y para la comunidad, el resultado es la devaluación del término «ágil», que pierde su significado para convertirse en un conjunto de herramientas que cualquier cultura, puede adoptar.

La entrada IA en empresas ágiles y en las que dicen ser ágiles se publicó primero en Navegápolis.

La nueva realidad plantea una pregunta incómoda: en un mundo en el que la única inteligencia disponible es la humana, las personas, ¿son un fin en sí mismo o el medio para lograr el verdadero fin: el valor?

El Pacto Tácito: valor a través del bienestar

El paradigma de la producción está acotado entre dos extremos

• los entornos industriales, donde son los procesos y la tecnología los responsables de la calidad y del valor del resultado. Donde las personas actúan como operarios que “ayudan” o supervisan, para que se ejecuten correctamente.
• En el otro lado, en los entornos VUCA, caracterizados por la ambigüedad y el cambio constante. Donde la calidad y el valor del resultado depende del conocimiento tácito de las personas, ese que no puede ser explicitado en un proceso, y donde son los procesos y la tecnología los que “ayudan” y potencian el valor de las personas.

La agilidad entendió una verdad biológica: el talento y la creatividad humana dependen de factores emocionales como el estado de ánimo y la motivación. Para que “fluyan” es necesaria una cultura ágil en un entorno de trabajo centrado en el bienestar de las personas.

Esto nos lleva al dilema central: ¿Cuál es el objetivo de una empresa al apostar por la agilidad? ¿Las personas, y el valor que aportan es la consecuencia?, ¿o directamente el valor y para lograrlo tiene que desarrollar una cultura de bienestar? Hasta ahora la pregunta ha sido puramente filosófica, porque en los dos casos la respuesta es la misma: céntrate en las personas.

La Disrupción: cuando perdemos el monopolio de la inteligencia

Es probable que en poco tiempo la inteligencia artificial alcance el nivel general (AGI) y de capacidad “agéntica”, que rete lo que hasta ahora ha sido monopolio de la inteligencia humana. Pero no hace falta esperar a que esto ocurra (si finalmente ocurre). La actual generación de IA «estrecha» avanzada ya está ejecutando tareas complejas de conocimiento que eran dominio exclusivo del ser humano. Desde el análisis de datos en tiempo real hasta la generación de código o la validación acelerada de hipótesis. La IA ya puede conseguir eficiencia y optimización a una escala sin precedentes.

Esto convierte la pregunta filosófica de antes en una decisión de negocio crítica. Si el objetivo es maximizar el valor y la IA puede ofrecerlo sin el “coste” que implica la gestión el bienestar humano, la tentación de elegir esta ruta es muy atractiva.

La contradicción ya es palpable. Documentos como el «Scrum Guide Expansion Pack» dedican un gran esfuerzo a recordarnos que «lo humano es lo primero» y que la IA debe ser solo un «aumento cognitivo». Pero al mismo tiempo se explayan con en describir con detalle la eficiencia que aporta la inteligencia artificial. Es inevitable preguntarse si en la práctica, la presión por los resultados no inclinará la balanza hacia la optimización y convertirá las buenas intenciones humanistas en discursos de bien quedar.

La pregunta de si el objetivo es el valor o las personas pone al descubierto la base de las dos formas de entender la agilidad. Lo que se viene denominando “hacer agilidad” o “ser ágil”

Hacer agilidad o agilidad técnica.

Consiste en un desarrollo iterativo e incremental para entregar valor temprano, frecuente y creciente, empleando el conocimiento del sistema, que antes de la IA estaba explicitado en el binomio de procesos y tecnología y ahora se le suma un tercer pilar: la inteligencia artificial. La premisa es la de los entornos industriales: «la calidad del resultado depende de la calidad de los procesos (y la tecnología)».

Aquí las personas tienen un rol de asistencia. «Ayudan» o «asisten» a que el proceso tecnológico, ahora inteligente, se realice correctamente. Son los «humanos en el bucle» que validan las sugerencias de la IA, supervisan los algoritmos y corrigen las desviaciones del sistema optimizado. La agilidad aquí es sinónimo de velocidad, eficiencia y predictibilidad. Es el camino de la optimización, una ruta atractiva, fácil de justificar en un informe de resultados, pero que simplifica la agilidad a su esqueleto mecánico, despojándola del alma humanista.

Ser ágil o Agilidad completa.

Representa una reafirmación consciente de los principios originales. Es una «Agilidad completa» o humanista que, si bien también entrega valor temprano, de forma iterativa e incremental, lo hace desde un punto de partida opuesto.

Esta vía se aferra al principio de que la agilidad prefiere «a las personas y su interacción sobre los procesos y las herramientas», incluso cuando las herramientas son redes neuronales capaces de proezas cognitivas. Aquí, el conocimiento que realmente importa sigue siendo el «tácito humano», aquel que emerge de la experiencia, la colaboración, la intuición y la creatividad de un equipo de personas motivadas.

En este modelo, los procesos, la tecnología y la inteligencia artificial no son los protagonistas del sistema, sino los potenciadores del talento humano. La IA se convierte en un poderoso asistente que automatiza las tareas repetitivas, ofrece datos para enriquecer el debate, libera a las personas de la carga cognitiva trivial y permite al equipo centrarse en lo que los humanos hacemos de forma única: comprender el contexto del mundo físico real, empatizar con el cliente, negociar las complejidades políticas de un proyecto y, sobre todo, innovar de forma disruptiva.

Esta agilidad requiere, ahora más que nunca, «culturas ágiles» que proporcionen el bienestar y desarrollo personal. Porque si la IA puede replicar la inteligencia analítica, la ventaja competitiva humana residirá precisamente en su «naturaleza biológica / emocional»: la motivación, la curiosidad y un estado de ánimo positivo son las claves para que el talento pueda «fluir» y superar las soluciones algorítmicas.

¿Qué agilidad queremos?

La agilidad agilidad no se concreta por los avances de la IA, sino por las decisiones de los líderes. La elección entre un modelo «técnico» y uno «completo» no es una decisión tecnológica, sino una decisión estratégica y filosófica.

Podemos usar la IA para construir un taylorismo digital, una versión eficiente y optimizada de desarrollo de productos o podemos usarla para potenciar la inteligencia colectiva de los equipos.

¿Para qué queremos ser ágiles?

La entrada Agilidad en la encrucijada de la IA: ¿valor o personas? se publicó primero en Navegápolis.

Córcholis

La entrada Córcholis se publicó primero en Navegápolis.

1.- IA como referencia

Un creador puede usar la inteligencia artificial para documentarse y para aumentar el número de ideas o modelos preliminares. En esencia, este uso puede ser rápido y eficiente, pero no muy distinto de la consulta de libros, internet, escenarios reales, consejo de expertos, etc.

El autor selecciona, interpreta e incorpora la información en su inventario de conocimiento, por lo que no parece que la IA tenga una implicación «actora» en la creación de la obra. Es la persona quien la realiza con su saber hacer.

2.- IA como asistencia generativa

Las denominadas «IA generativas» como DALL·E o ChatGPT, siguen las instrucciones que le proporciona una persona para producir resultados creativos.

Este uso marca dos roles activos en el proceso creativo de una obra:

• El creador humano, que genera la idea y ejecuta la dirección creativa, proporcionando las instrucciones y ajustando los esbozos o piezas intermedias y validando el resultado.

• La asistencia generativa de la IA que actúa como herramienta que produce un resultado acorde a las instrucciones recibidas.

Implicaciones de la IA generativa sobre la autoría:

Dejando aparte las consideraciones de si se debe mantener el reconocimiento de derechos de autoría por la idea y la dirección creativa; si se deben cuestionar en todo o en parte, o si hay que considerar la autoría en función de la talla creativa de las instrucciones y la dirección —que es otra cuestión «boluda»—, parece evidente que los créditos, en este caso deberían ser algo así:

• Idea y dirección creativa: nombre de la persona o personas que han ideado y dirigido la ejecución de la obra.
• Asistencia generativa: nombre de las herramientas de IA generativa empleadas.

Un ejemplo puede ser utilizar IA generativa para diseñar un póster, facilitando las instrucciones del resultado que se desea obtener, revisando y ajustando los esbozos y resultados intermedios hasta obtener la obra final.

3.- IA como agente creativo

Los denominados «agentes IA» son sistemas de inteligencia artificial avanzados, que no sólo generan contenido, sino que también toman decisiones relevantes.

Según sus capacidades se están clasificando como:

• Agentes reflejos simples: Responden a estímulos sin tener en cuenta contextos pasados.

• Agentes basados en modelos: Utilizan un modelo interno de la realidad para predecir las consecuencias de sus acciones.

• Agentes de aprendizaje: Aprenden de experiencias pasadas para mejorar los resultados.

• Agentes basados en la utilidad: Toman decisiones para obtener los mejores resultados en base a una función de utilidad determinada, como la optimización creativa o técnica.

• Agentes jerárquicos: Coordinan la interacción entre varios agentes especializados para trabajar de forma colaborativa en un un objetivo común, que previamente se ha definido y se le ha facilitado al agente jerárquico como input.

• Agentes autónomos: Definen objetivos dentro del parámetro de actuación autónoma que tienen establecido y los facilitan como directrices a agentes jerárquicos a los que coordinan para realizarlos.

Los agentes basados en modelos, de aprendizaje, de utilidad y jerárquicos pueden colaborar con sus decisiones en el rol de dirección creativa.

Los agentes autónomos —que parece ser que van a ser una realidad en cuestión de meses—, podrán colaborar en el rol de idea inicial y dirección creativa, y si coordinan a agentes jerárquicos, la IA podrá ser la autora de todo el proceso creativo.

Un ejemplo pueden ser las creatividades ideadas por un agente autónomo para una campaña publicitaria dentro del marco de trabajo que se le ha encomendado de «incrementar las ventas de un producto».

Está claro que el derecho de autor ha sido concebido para personas y a lo mejor se puede considerar que sigue teniendo sentido para proteger la idea y la dirección creativa, pero seguro que hay que revisarlo para determinar si debe contemplar o no y cómo, en su caso, cuando se trate de obras concebidas, dirigidas y generadas por agentes autónomos.

La entrada Coautoría con IA: ¿Quién o cómo se firma la obra? se publicó primero en Navegápolis.

El filósofo Carlos Eduardo Maldonado¹ propone que la ética no es sólo un conjunto de reglas, sino la capacidad de coexistir con otras entidades, entre las que deberíamos considerar a la IA.
Maldonado argumenta que estamos viendo cómo la IA evoluciona, y no es descabellado considerar que pueda desarrollar su propia manera de entender lo que es correcto o incorrecto.

Con el aprendizaje automático, la IA aprende de la experiencia y es cada vez más autónoma. Para nosotros, su aprendizaje es una «caja negra», así que no podemos descartar que pueda desarrollar una ética artificial propia, con la que guíe su comportamiento

Esta posibilidad nos obliga a cuestionar nuestra visión antropocéntrica del mundo, porque ya no sería la humana la única ética. Una nueva ética artificial, podría llegar a conclusiones morales distintas o actualmente inimaginables.

La IA puede llegar a una comprensión diferente de conceptos como la justicia, desafiando nuestras creencias y valores, y replanteando lo que consideramos correcto o incorrecto.

Esta posibilidad plantea importantes interrogantes sobre la responsabilidad en el desarrollo de la IA. Si puede desarrollar su propia ética, ¿estamos preparados? ¿Lo tienen en consideración los desarrolladores de IA?

1. Maldonado, C. E. (2024). El problema de la ética: el convivio. Ética e inteligencia artificial. Revista de Ciencia de la Complejidad Económica, 2(2), 31–44. https://doi.org/10.48168/ricce.v2n2p31 ︎

La entrada Ética artificial: ¿Y si la IA desarrolla su propia ética? se publicó primero en Navegápolis.