Por Qué "Terminado" Ya No Significa Lo Que Creías en 2026
El desarrollador envió el pull request, el PM cerró el ticket, el diseñador entregó el Figma. ¿Proyecto terminado? En realidad, apenas está empezando su verdadero ciclo de vida.
Una verdad incómoda que la mayoría de equipos está ignorando: si tu trabajo no puede ser entendido, consultado y construido por un LLM, no está terminado. Está abandonado. Y esto cambia completamente cómo debemos definir "done" en nuestros proyectos de software.
Esta realidad se vuelve crítica para empresas en Perú y Latinoamérica, donde la rotación de talento técnico y la necesidad de documentar conocimiento son desafíos constantes en la industria del software.
La Vieja Definición de "Terminado" Solo Funcionaba Para Humanos
Durante décadas, "terminado" significaba algo así: el diseño está aprobado, el código está desplegado, los stakeholders están contentos, y el ticket de Jira se mueve a la columna correcta. Tal vez alguien escribe una página en Confluence. Tal vez no.
El conocimiento sobre por qué existe esa funcionalidad, qué se probó y se rechazó, qué investigación de usuario informó la decisión, vive en un solo lugar: la cabeza de alguien.
Esto es conocimiento tribal. Y el conocimiento tribal tiene fecha de caducidad. La persona se va, el hilo de Slack se entierra, el contexto se evapora.
Hemos tolerado esto durante años porque los únicos consumidores de ese conocimiento eran otros humanos, y los humanos son bastante buenos tocando el hombro de alguien y preguntando. Pero tocar el hombro no escala.
El Nuevo Consumidor: Los LLMs en Tu Flujo de Trabajo
Cada equipo con el que trabajo ahora usa un LLM en algún lugar de su flujo de trabajo. Cursor para código, Claude para builds, ChatGPT para investigación, Copilot para pull requests. Las herramientas varían, el patrón no: la gente está apuntando IA a su trabajo esperando que lo entienda.
Pero aquí está el problema. Cuando ese LLM trata de entender tu proyecto, ¿qué encuentra?
- Un archivo Figma sin anotaciones
- Un código base sin registros de decisiones de arquitectura
- Una especificación de producto de hace seis meses que nunca se actualizó después del pivot
- Un sistema de diseño sin justificación documentada
El LLM no puede tocar el hombro de nadie. Solo puede leer lo que escribiste. Y la mayoría de equipos escriben casi nada.
Esto explica por qué el concepto de LLM Wiki de Andrej Karpathy se volvió viral esta semana. Karpathy describió un sistema donde alimentas material crudo (artículos, investigación, documentos, transcripciones) en una carpeta, y un LLM lo compila en un wiki estructurado e interconectado.
Cómo Esto Se Aplica a Empresas en Perú y Latinoamérica
En nuestra región, este problema se intensifica por factores específicos del mercado local. La alta rotación de desarrolladores, la competencia por talento técnico, y la necesidad de escalar equipos rápidamente hace que el conocimiento tribal sea especialmente peligroso.
Una startup peruana que pierde a su arquitecto principal sin documentación adecuada puede retrasarse meses. Una consultora que no puede explicar sus decisiones técnicas anteriores a nuevos clientes pierde credibilidad y oportunidades de crecimiento.
La nueva definición de "terminado" debe incluir documentación estructurada para consumo de LLMs. No solo consumo humano. Ambos.
Para desarrolladores, esto significa: tus decisiones de arquitectura, patrones de código, APIs, y justificaciones técnicas deben vivir en una base de conocimiento consultable. Cuando un nuevo desarrollador se una al equipo, debería poder apuntar un LLM a esa base de conocimiento y ser productivo en horas, no semanas.
¿Cómo Aplica Esto en Tu Empresa?
Implementar esta nueva definición de "terminado" no requiere herramientas complejas. Puedes empezar hoy mismo:
1. Audita tu conocimiento tribal: Identifica qué decisiones críticas solo existen en cabezas de personas. Prioriza documentar las más riesgosas primero.
2. Establece un repositorio central: Usa herramientas simples como Notion, Obsidian, o incluso archivos Markdown en tu repositorio. Lo importante es la consistencia, no la herramienta.
3. Modifica tu Definition of Done: Incluye como requisito que cada feature, decisión técnica o cambio importante tenga su contexto documentado de forma que un LLM pueda entenderlo.
4. Prueba con LLMs: Regularmente, apunta ChatGPT o Claude a tu documentación y pregunta sobre decisiones pasadas. Si no puede responder, tu documentación necesita mejoras.
5. Construye relaciones entre conocimientos: No solo documentes hechos aislados. Conecta decisiones con investigación, código con justificaciones, problemas con soluciones.
En Consultoría-Ti hemos empezado a implementar esto en nuestros proyectos de Odoo y desarrollo custom. Los resultados son inmediatos: onboarding más rápido, menos dependencia de personas específicas, y capacidad de iterar sobre decisiones pasadas con contexto completo.
El futuro pertenece a los equipos que pueden hacer su conocimiento accesible tanto para humanos como para máquinas. La pregunta no es si esto va a suceder, sino qué tan rápido tu empresa se va a adaptar.
¿Necesitas ayuda implementando estas prácticas en tu equipo de desarrollo? En Consultoría-Ti no solo desarrollamos software, también ayudamos a establecer procesos que escalen con tu empresa. Conversemos sobre cómo podemos optimizar tu Definition of Done para la era de la IA.
Fuentes y Referencias
Done — Is a Lie. Your Definition of Done Is Broken in 2026 - Dev.to