Qué es Knowledge Driven Development y por qué la IA lo necesita
Knowledge Driven Development es una práctica de desarrollo de software donde el conocimiento del proyecto se estructura, versiona y utiliza como contexto activo para humanos, equipos y agentes de IA. Su objetivo no es crear documentación pesada, sino mantener la mínima información suficiente para tomar mejores decisiones, reducir ambigüedad y mejorar la colaboración entre negocio, tecnología e inteligencia artificial.
Series: Knowledge Driven Development - KDD (7 articles)
- …
- 3Qué es Knowledge Driven Development y por qué la IA lo necesita This article
TL;DR
Knowledge Driven Development es una práctica de desarrollo de software donde el conocimiento del proyecto se estructura, versiona y utiliza como contexto activo para humanos, equipos y agentes de IA.
Su objetivo no es crear documentación pesada, sino mantener la mínima información suficiente para tomar mejores decisiones, reducir ambigüedad y mejorar la colaboración entre negocio, tecnología e inteligencia artificial.
Introducción
La conversación sobre inteligencia artificial en desarrollo de software suele girar alrededor de modelos, prompts, copilotos y agentes.
Hablamos de cómo generar código más rápido, cómo automatizar tareas, cómo crear pruebas, cómo documentar APIs o cómo pedirle a una IA que nos ayude a diseñar una arquitectura, pero hay una pregunta que muchas veces queda por fuera:
¿Qué tanto sabe la IA sobre nuestro proyecto?
Un modelo puede escribir código, un agente puede proponer una solución, un copiloto puede completar una función, pero si no entiende el contexto del negocio, las decisiones técnicas, las restricciones, la arquitectura, el roadmap, los riesgos y la historia del sistema, su ayuda será limitada y en algunos casos, peligrosa; ahí aparece una idea que cada vez se vuelve más importante: Knowledge Driven Development, o simplemente KDD.
Qué es Knowledge Driven Development
Knowledge Driven Development es una forma de desarrollar software donde el conocimiento del proyecto se convierte en una fuente activa para tomar decisiones, construir soluciones y colaborar mejor.
En otras palabras, KDD propone que el conocimiento no sea algo secundario, no debería vivir solamente en:
- reuniones pasadas,
- conversaciones de Slack,
- documentos olvidados,
- tickets incompletos,
- diagramas desactualizados,
- o en la cabeza de una sola persona.
El conocimiento del proyecto debería estar estructurado, versionado, disponible y conectado con el ciclo de desarrollo, no como burocracia, no como documentación eterna, sino como una herramienta práctica para construir mejor software.
El problema: desarrollamos con conocimiento fragmentado
En muchos equipos, el conocimiento está disperso, una parte está en Jira, otra parte está en Confluence, otra está en documentos de arquitectura, otra está en diagramas, otra está en conversaciones, otra está en el código y otra, la más peligrosa, está en la memoria de alguien que “sabe cómo funciona eso”.
Ese modelo ya era frágil antes de la inteligencia artificial, pero con IA se vuelve todavía más delicado, porque cuando un equipo trabaja con herramientas de IA sin contexto suficiente, la IA intenta completar los vacíos y ahí empieza el problema
- Puede sugerir una solución técnicamente válida, pero incorrecta para el negocio.
- Puede crear código que funciona, pero rompe una decisión arquitectónica previa.
- Puede proponer una librería innecesaria.
- Puede ignorar restricciones de seguridad.
- Puede duplicar lógica existente.
- Puede generar documentación que suena bien, pero no representa la realidad.
El problema no siempre es la IA, muchas veces el problema es que no le dimos suficiente conocimiento del proyecto.
La IA no necesita solo mejores prompts
Durante los últimos años hemos hablado mucho de prompt engineering, y sí, saber pedirle cosas a una IA ayuda, pero en proyectos reales, el reto no es solamente escribir un buen prompt, el reto es darle a la IA el contexto correcto.
Un prompt puede decir:
“Crea un endpoint para registrar usuarios”.
Pero un contexto de proyecto debería responder cosas como:
- ¿Qué reglas de negocio aplican?
- ¿Qué arquitectura usamos?
- ¿Qué convenciones sigue el equipo?
- ¿Cómo manejamos errores?
- ¿Qué librerías ya están aprobadas?
- ¿Qué decisiones técnicas no deberíamos romper?
- ¿Qué restricciones de seguridad existen?
- ¿Qué dominios del sistema están involucrados?
- ¿Qué deuda técnica debemos evitar aumentar?
Sin ese conocimiento, la IA responde desde lo genérico yel software real casi nunca es genérico.
Entonces, ¿qué propone KDD?
Knowledge Driven Development propone que el conocimiento del proyecto sea tratado como un activo del desarrollo:
- Así como versionamos código, también deberíamos versionar decisiones.
- Así como mantenemos pruebas, también deberíamos mantener contexto.
- Así como revisamos pull requests, también deberíamos revisar si el conocimiento del proyecto sigue actualizado.
KDD busca que el equipo pueda responder rápidamente preguntas como:
- ¿Qué estamos construyendo?
- ¿Por qué lo estamos construyendo?
- ¿Qué decisiones ya se tomaron?
- ¿Qué restricciones existen?
- ¿Qué partes del sistema están involucradas?
- ¿Quién es responsable de cada área?
- ¿Qué riesgos debemos considerar?
- ¿Qué debería saber una IA antes de ayudarnos?
La idea no es documentarlo todo, la idea es capturar la mínima información suficiente para tomar mejores decisiones.
KDD no es documentación pesada
Cuando alguien escucha “documentar conocimiento”, puede pensar en documentos enormes que nadie lee, pero KDD no busca volver al desarrollo lento, rígido y lleno de ceremonias innecesarias.
Knowledge Driven Development no se trata de escribir documentación por cumplir, se trata de mantener conocimiento útil.
La diferencia es importante:
- Una documentación pesada intenta describirlo todo.
KDD intenta capturar lo necesario para decidir, construir y evolucionar. - Una documentación tradicional suele quedar separada del código.
KDD busca que el conocimiento viva cerca del repositorio. - Una documentación tradicional explica lo que se hizo.
KDD también explica por qué se decidió hacerlo así. - Una documentación tradicional está pensada solo para humanos.
KDD también piensa en agentes de IA, copilotos y herramientas automatizadas.
Qué tipo de conocimiento necesita un proyecto
En KDD, no todo conocimiento tiene el mismo propósito, un proyecto de software necesita diferentes capas de conocimiento.
Conocimiento de negocio
Este explica el problema que se quiere resolver, incluye usuarios, objetivos, reglas, restricciones, procesos y prioridades, sin este conocimiento, el equipo puede construir algo técnicamente correcto pero poco útil.
Conocimiento de producto
Este define qué se está construyendo y por qué, incluye alcance, funcionalidades, roadmap, criterios de aceptación y decisiones de priorización, ayuda a evitar que el equipo construya cosas que no aportan valor.
Conocimiento técnico
Este describe cómo está diseñado el sistema, incluye arquitectura, stack tecnológico, integraciones, patrones, decisiones técnicas y restricciones, aquí entran elementos como ADRs, diagramas, contratos entre servicios y convenciones del equipo.
Conocimiento operativo
Este explica cómo se ejecuta, monitorea y mantiene el sistema, incluye despliegues, ambientes, observabilidad, seguridad, ownership, alertas y procesos de soporte, es clave para que el software no solo funcione en desarrollo, sino también en producción.
Conocimiento histórico
Este es uno de los más olvidados, incluye decisiones pasadas, razones de cambio, trade-offs y problemas ya aprendidos, sin conocimiento histórico, los equipos repiten errores con una confianza admirable, la clásica arquitectura basada en “no sé por qué, pero siempre se ha hecho así”.
Conocimiento para IA
Este es cada vez más relevante, es el conocimiento preparado para que una IA pueda ayudar mejor, no se trata solo de pegarle todo el README al modelo, se trata de darle contexto curado, actualizado y útil.
Por qué KDD se vuelve más importante con IA
La IA generativa cambió la forma en que muchos equipos construyen software.
Hoy podemos usar IA para:
- explicar código,
- generar pruebas,
- crear documentación,
- proponer arquitecturas,
- revisar errores,
- diseñar APIs,
- escribir scripts,
- analizar logs,
- crear historias de usuario,
- y acelerar tareas repetitivas.
Pero mientras más poder le damos a la IA, más importante se vuelve el contexto:
- Una IA con buen contexto puede ser una gran aliada.
- Una IA sin contexto puede convertirse en una fábrica de deuda técnica con interfaz conversacional.
- El riesgo no es solo que la IA se equivoque.
- El riesgo es que se equivoque de forma convincente.
- Puede generar una solución que parece correcta, compila, pasa pruebas básicas y aun así va en contra de una decisión importante del sistema.
Por eso KDD importa, porque ayuda a que la IA no trabaje desde la suposición, sino desde el conocimiento real del proyecto.
Diferencia entre documentación tradicional y KDD
| Documentación tradicional | Knowledge Driven Development |
|---|---|
| Se escribe al inicio o al final | Vive durante todo el ciclo de desarrollo |
| Está separada del código | Vive cerca del repositorio |
| Explica qué se hizo | Explica qué se hizo y por qué |
| Suele quedar desactualizada | Debe revisarse con los cambios |
| Está pensada para humanos | Sirve para humanos y agentes de IA |
| Es pasiva | Activa decisiones, contexto y trazabilidad |
| Puede ser extensa y poco usada | Busca mínima información suficiente |
KDD no reemplaza la documentación, la vuelve más útil.
Cómo se ve KDD en la práctica
Un flujo basado en Knowledge Driven Development podría verse así:
- El equipo define el contexto mínimo del producto.
- Se documentan reglas de negocio importantes.
- Se registran decisiones arquitectónicas mediante ADRs.
- Se mantiene una descripción del estado actual del sistema.
- Se conecta conocimiento con módulos, carpetas o dominios del código.
- Se genera contexto útil para humanos y agentes de IA.
- Se detecta cuando el código cambia pero el conocimiento queda atrás.
- Se transforma el roadmap en work items trazables.
- Se mantiene ownership sobre partes importantes del sistema.
La clave está en que el conocimiento no sea un documento aislado, debe estar conectado al trabajo real.
Ejemplo simple
Imaginemos que un equipo está construyendo una API, sin KDD, alguien podría pedirle a una IA:
Crea un endpoint para registrar órdenes.
La IA podría generar código válido, pero tal vez no sabe que:
- el proyecto usa arquitectura hexagonal,
- las órdenes deben publicar un evento,
- no se permite lógica de negocio en controladores,
- los errores deben seguir un formato estándar,
- existe una regla de negocio sobre órdenes duplicadas,
- el sistema usa colas para procesos asincrónicos,
- y ya existe un módulo parecido para pagos.
Con KDD, el agente de IA no solo recibe una instrucción, recibe contexto y eso cambia la calidad de la respuesta.
KDD y arquitectura de software
Knowledge Driven Development tiene una relación muy fuerte con arquitectura, porque muchas decisiones arquitectónicas fallan no por falta de tecnología, sino por falta de contexto compartido.
Un equipo puede usar microservicios, eventos, serverless, contenedores o arquitectura limpia, pero si no entiende las razones detrás de esas decisiones, tarde o temprano empieza a romperlas.
KDD ayuda a conservar la intención arquitectónica, no solo el diagrama, también el razonamiento.
- ¿Por qué usamos eventos?
- ¿Por qué evitamos dependencias directas?
- ¿Por qué separamos dominios?
- ¿Por qué elegimos una base de datos relacional y no una NoSQL?
- ¿Por qué este servicio debe escalar de forma independiente?
Ese conocimiento es oro para el equipo y también para la IA.
KDD en proyectos cloud
En proyectos cloud, KDD puede ser especialmente útil, cuando trabajamos con servicios como AWS Lambda, Amazon ECS, Amazon EKS, Amazon SQS, Amazon SNS, Amazon EventBridge, Amazon RDS, Amazon DynamoDB o Amazon API Gateway, las decisiones no deberían tomarse solamente por moda, cada servicio tiene ventajas, límites, costos, riesgos y escenarios ideales.
KDD permite documentar decisiones como:
- Por qué se eligió Lambda en lugar de ECS.
- Por qué se usó SQS para desacoplar procesos.
- Por qué DynamoDB era más adecuado que una base relacional.
- Qué restricciones de seguridad aplican.
- Qué servicios son críticos.
- Qué métricas deben observarse.
- Qué decisiones podrían cambiar en el futuro.
Esto conecta muy bien con prácticas como arquitectura bien diseñada, operación responsable y toma de decisiones basada en contexto.
KDD no reemplaza Agile, DevOps ni arquitectura
Knowledge Driven Development no compite con Agile, tampoco reemplaza DevOps, tampoco elimina la arquitectura; KDD funciona como una capa transversal, agile ayuda a entregar valor de forma iterativa, DevOps ayuda a integrar desarrollo y operación, la arquitectura ayuda a tomar decisiones estructurales, KDD ayuda a que el conocimiento que sostiene esas prácticas no se pierda, podríamos verlo así:
Agile organiza la entrega.
DevOps conecta construcción y operación.
Arquitectura guía las decisiones técnicas.
KDD mantiene vivo el conocimiento que permite decidir mejor.
Principios de Knowledge Driven Development
Estos son algunos principios que pueden guiar KDD:
- El conocimiento debe vivir cerca del código: mientras más lejos esté el conocimiento del repositorio, más fácil será que se desactualice.
- No todo debe documentarse: el objetivo no es capturar todo, el objetivo es capturar lo suficiente para reducir ambigüedad y mejorar decisiones.
- Las decisiones importan tanto como el código: el código muestra el resultado, las decisiones explican el camino.
- El conocimiento debe ser últil para humanos e IA: en la era de agentes y copilotos, el conocimiento también debe funcionar como contexto para herramientas inteligentes.
- El conocimiento debe tener ownership: si nadie es responsable de mantener una pieza de conocimiento, eventualmente se vuelve decoración.
- El conocimiento debe evolucionar: un documento que no cambia en un sistema que sí cambia es una posible mentira técnica.
- La IA debe trabajar con contexto, no con adivinanzas: un agente sin contexto puede producir velocidad, pero velocidad sin dirección es solo deuda técnica con buena autoestima.
Qué beneficios puede traer KDD
Aplicar Knowledge Driven Development puede ayudar a:
- reducir ambigüedad
- mejorar onboarding
- evitar pérdida de conocimiento
- documentar decisiones importantes
- mejorar la colaboración con IA
- reducir retrabajo
- mejorar revisiones técnicas
- conectar negocio y tecnología
- mantener trazabilidad entre roadmap, decisiones y código
- y disminuir la dependencia de conocimiento tribal
No significa que el equipo nunca se va a equivocar, pero sí puede equivocarse con más información, aprender más rápido y tomar mejores decisiones.
KDD y agentes de IA
Los agentes de IA están cambiando la manera en que pensamos el desarrollo, ya no hablamos solamente de autocompletar líneas de código, ahora hablamos de agentes capaces de:
- analizar un repositorio
- proponer cambios
- generar tareas
- crear documentación
- revisar arquitectura
- refactorizar módulos
- abrir pull requests
- asistir en decisiones técnicas
Pero para que eso funcione bien, el agente necesita contexto confiable, ahí KDD puede convertirse en una base importante, no se trata solo de tener mejores agentes, se trata de tener mejores sistemas de conocimiento para que esos agentes puedan operar con más precisión.
Una forma moderna de pensar KDD
Una definición moderna de Knowledge Driven Development podría ser:
Knowledge Driven Development es la práctica de convertir el conocimiento del proyecto en contexto vivo, versionado y accionable para equipos humanos y agentes de inteligencia artificial.
Esta definición tiene tres ideas importantes, lo primero, el conocimiento debe estar vivo, no puede ser una foto vieja del sistema. Lo segundo, debe estar versionado, debe evolucionar junto al proyecto y lo tercero, debe ser accionable, debe servir para decidir, construir, revisar o automatizar.
KDD y Kaddo
Esta reflexión me llevó a explorar una herramienta llamada Kaddo , Kaddo es un toolkit open source orientado a Knowledge Driven Development.
La idea de Kaddo es ayudar a mantener el conocimiento del proyecto cerca del código, generar contexto útil para trabajar con agentes de IA y reducir la distancia entre negocio, producto, arquitectura y desarrollo.
Kaddo no busca que la IA tome control del proyecto, al contrario, busca que los equipos tengan más claridad antes de pedirle ayuda a la IA, porque la IA puede acelerar mucho, pero primero necesita saber hacia dónde.
Conclusión
La inteligencia artificial está cambiando el desarrollo de software, pero no basta con tener mejores modelos, mejores prompts o mejores herramientas, también necesitamos mejores formas de gestionar el conocimiento de nuestros proyectos, porque el software no es solo código, también es contexto, decisiones, restricciones, historia, negocio, arquitectura y operación.
Knowledge Driven Development propone que ese conocimiento deje de estar disperso y empiece a convertirse en una parte activa del desarrollo.
En la era de la IA, esto ya no es solo una buena práctica, es una ventaja competitiva.
La IA no reemplaza la falta de contexto, la amplifica y por eso, antes de preguntarnos cómo hacer que la IA escriba más código, quizás deberíamos preguntarnos algo más importante:
¿Qué conocimiento necesita para ayudarnos mejor?
# knowledge-bases-for-bedrock# artificial-intelligence# viable-coding# vibe-coding# software-development
Series: Knowledge Driven Development - KDD (7 articles)
- …
- 3Qué es Knowledge Driven Development y por qué la IA lo necesita This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article