Kaizen + IA: la evolución del developer

Empecemos con el dato más incómodo de esta industria: solo 1 de cada 4 empresas obtiene valor real de su inversión en inteligencia artificial. No es una opinión — es el resultado de la encuesta de BCG a 1,000 ejecutivos en 59 países: apenas 26% logró pasar de las pruebas de concepto a resultados que se puedan medir.

La lectura fácil de ese dato es «la IA está sobrevalorada». La lectura honesta es otra: en la mayoría de esos casos la tecnología funcionó perfecto. Lo que estaba roto era el proceso al que se le puso encima. Automatizaron el desperdicio. Y lo automatizaron muy bien.

Hay una salida, y combina algo de 1950 con algo de 2026: Kaizen + IA. Pero quiero contarla desde un ángulo que casi nadie está mirando, porque es el que más me interesa: en esta ecuación, el que más tiene que cambiar no es el gerente general. Es el developer.

Primero, lo que sí conocés: Kaizen

Kaizen es la filosofía de mejora continua que nació en las fábricas de Toyota. Su formato intensivo es el Kaizen Event: una semana, un equipo, un proceso. Rediseñarlo de punta a punta. La estructura es brutalmente simple:

• Día 1 — Gemba Walk. Vas al lugar donde el trabajo ocurre de verdad. No opinás, no arreglás nada. Solo mirás. En una empresa de servicios eso significa compartir pantalla con quien hace la tarea, contar los clics reales y preguntar «¿y después qué?» hasta llegar al final.
• Día 2 — Causa raíz. Preguntás «¿por qué?» cinco veces. El ejemplo clásico que se cuenta en los cursos de Lean es el del Jefferson Memorial: había que lavar el mármol cada semana. ¿Por qué? Excremento de pájaros. ¿Por qué tantos pájaros? Arañas. ¿Por qué arañas? Insectos. ¿Por qué insectos? Las luces del atardecer los atraían. La solución no fue un mejor detergente ni más personal de limpieza: fue encender las luces más tarde.
• Día 3 — Diseño. Rediseñás el proceso y traés a gente que no lo toca a diario. Los ojos frescos ven lo que los de siempre ya dejaron de ver.
• Día 4 — Experimento. Un piloto chico y medible. Antes: 10 minutos por caso. Después: 1. Si no se puede medir, no cuenta.
• Día 5 — Estandarizar. La nueva forma queda como el estándar. Y —esto es lo que casi nadie hace— se apaga la vieja.

Hasta acá, nada nuevo. Kaizen clásico, con setenta años de kilometraje encima.

El Día 4 era donde todo se moría

Si alguna vez trabajaste en mejora de procesos, sabés exactamente dónde se rompía esto. El Día 4.

Diseñabas la solución, el equipo salía convencido… y después necesitabas developers. Un ticket. Una estimación. Priorización contra otros veinte tickets. Un sprint. Otro sprint. El Kaizen terminaba el viernes con una presentación y un compromiso, la idea entraba al backlog el lunes, y tres años después alguien la implementaba. O no.

Nadie tenía la culpa. Era estructural: implementar costaba tanto que cada mejora tenía que competir por presupuesto contra el roadmap del producto. Y perdía casi siempre.

Lo que cambió

El costo de implementar se colapsó. LLMs, agentes, herramientas de prototipado: lo que tomaba semanas hoy toma horas. Pero el cambio importante no es la velocidad en sí — es el momento. Ya no se implementa después del evento. Se implementa durante.

El Día 4 dejó de ser «esperemos a que sistemas tenga disponibilidad» y pasó a ser «abramos el editor y lo sacamos hoy, antes del almuerzo». El ciclo de mejora pasó de meses a días. Kaizen siempre fue una filosofía poderosa y lenta de ejecutar; ahora es absurdamente rápida. Si querés ver cómo se siente una operación donde ese ciclo ya corre solo, armamos una experiencia interactiva sobre eso.

Y acá viene la parte que me interesa: el developer

Si implementar ya no es el cuello de botella, entonces el trabajo escaso del developer cambió de lugar.

Durante veinte años el valor del developer estuvo en poder construir lo que otros no podían. Escribir el código era la habilidad rara. Hoy escribir código es la parte barata del trabajo. Lo escaso es decidir qué merece existir.

Eso convierte al developer en algo distinto: no en un implementador más rápido, sino en la persona que hace el Gemba Walk. Que pregunta cinco veces por qué. Que se sienta al lado de quien lleva cuentas por pagar y cuenta los catorce clics que hace para conciliar una factura — en vez de recibir un requerimiento de tercera mano que ya da por sentado que esos catorce clics son necesarios.

Ese es el salto: de tomar tickets a rediseñar procesos. Y no es un salto cosmético. El developer que solo ejecuta lo que le piden hoy es más peligroso que antes, no menos: automatiza el desperdicio a una velocidad que hace cinco años era imposible. Llega más rápido al lugar equivocado.

Es un salto incómodo, además. Requiere salir del editor. Requiere hablar con gente cuyo trabajo no entendés todavía. Requiere aceptar que el requerimiento que te llegó está mal formulado y decirlo en voz alta. Cuando lo aplicamos a la gestión de proyectos y la reportería de avance, casi siempre el pedido original era «automatizá este reporte» y la respuesta correcta era «este reporte no debería existir».

Process-first, AI-second

Que puedas automatizar rápido no significa que debas automatizar cualquier cosa. «Primero el proceso, después la IA» no es un eslogan bonito: es la única regla que importa.

• Sin Kaizen, la IA acelera procesos rotos. Llegás más rápido al lugar equivocado — y ahora con factura mensual.
• Sin IA, Kaizen es lento ejecutando. Llegás al lugar correcto… en tres años, si el backlog te acompaña.
• Juntos: procesos sanos, implementados en horas.

Primero arreglás el proceso. Después lo automatizás. En ese orden, siempre. Y ese orden es también la razón por la que medir el impacto real de la IA resulta más fácil de lo que la gente cree: si hiciste bien el Día 4, tenés el número de antes y el número de después. No hay nada que discutir.

Lo raro es que casi nadie lo esté haciendo

Las piezas existen por separado. Hay process mining (Celonis, UiPath) que te dice dónde está el desperdicio, pero no lo arregla. Hay design sprints —el formato de Google Ventures— que producen prototipos, pero apuntan a producto nuevo, no a procesos internos. Hay reportes de McKinsey y BCG sobre «Lean + AI» que explican muy bien por qué deberías hacerlo.

Lo que no veo por ningún lado es a alguien tomando la ceremonia completa del Kaizen Event —sus cinco días, sus roles, sus reglas, la inmersión— y poniendo IA como motor de implementación adentro del evento. No como consultoría de estrategia con un PDF al final. Como una semana de trabajo donde el proceso sale funcionando el viernes.

Puede que sea un espacio vacío. Puede que sea una categoría nueva. Lo que sí sé es que no requiere un ejército de consultores ni un presupuesto de millones: requiere un equipo, una semana, un proceso que duela de verdad, y herramientas que ya existen y en muchos casos ya están pagadas. Tampoco requiere un departamento de sistemas grande — ya escribimos sobre cómo implementar IA sin equipo técnico interno.

La pregunta honesta

Si tuviera que resumir la tesis en una línea: la próxima evolución del developer no es escribir código más rápido. Es aprender a ir al gemba.

Y ahora la parte genuina, no retórica: ¿alguien más está pensando en esto? ¿Conocés equipos aplicando Kaizen + IA de verdad — no en un PDF de estrategia, sino con un proceso rediseñado y corriendo esta semana? Me interesa saberlo en serio, y si estás corriendo algo parecido me gustaría que me lo cuentes.

Y si preferís empezar por tu propia casa: elegí el proceso que más duele, poné el número de «antes» en la calculadora de ROI y tratá eso como tu Día 0. Es la forma más barata de averiguar si el proceso merece IA — o si primero merece un rediseño.