El desarrollo orientado a especificación no es un tema solo de desarrollo. El punto crítico está en el análisis y la documentación, desde el principio: si la especificación no está madura y estandarizada, el resto del flujo no funciona, con o sin agente de código.
Por eso la consultoría empieza por el análisis, no por el código. Diseñamos el proceso con su equipo, lo aplicamos en un proyecto real y dejamos el método escrito en el repositorio. El efecto aparece donde la gestión lo ve: más entregas, menos bugs que regresan y menos retrabajo, medidos antes y después.
Licencias compradas, todos usándolas, y nadie puede mostrar cuánto ganó el equipo. Sin un punto de partida medido, la ganancia se queda en impresión.
En la prácticaMedimos contra la estimación: un portal previsto para 3 meses salió en 1.
Sale más código en menos tiempo, y regresan más bugs. Cuando la especificación llega vaga, el agente devuelve suposiciones, y el retrabajo crece.
En la prácticaEse mismo portal salió 3x más rápido, con bugs por debajo del 1% por funcionalidad.
Las entregas se atrasan y el lead time no baja, incluso con IA. Un desarrollador genera módulos enteros, otro solo autocompleta: sin una regla común, la entrega depende de quién la pidió y no del proceso.
En la prácticaUn sistema del tamaño de un ERP, previsto para 8 meses con 4 devs, salió en 6 meses con 3.
Cada uno aprende solo, por prueba y error, y nadie sabe qué demandas deberían ir a la IA y cuáles no.
Empezamos a usar IA para generar código en proyectos más simples.
En los primeros meses de Lovable ya hacíamos vibe coding. Ahí entendimos que la calidad y la seguridad exigirían un agente de IA propio.
Con la evolución de los modelos, ampliamos el uso a todos los proyectos, incluidos los complejos, las apps y los legados.
Diversos proyectos en producción 100% orientados a especificación, con calidad comprobada y cobertura de pruebas.
En DB1 Itênex, los proyectos se desarrollan orientados a especificación y con nuestros agentes, sea web, app, legado o complejo.
La ganancia viene de gente que sabe dónde el agente acelera, dónde se equivoca y dónde la decisión tiene que ser de una persona, y que le enseña eso a su equipo.
Desde 2024 aplicamos IA en proyectos reales, de los más simples a los legados y complejos. Lo que funcionó se volvió método, y quien lo conduce con su equipo es quien lo construyó, en su repositorio y no en un laboratorio.
La consultoría tiene plazo y entregables definidos en cada etapa, no horas asignadas. Lo que cuenta al final es la evolución medida contra el punto de partida de su equipo.
Indicadores y telemetría del ciclo para que su gestión siga el desempeño del equipo: entregas, lead time, bugs devueltos y retrabajo. El resultado deja de ser impresión y se vuelve dato.
Formación en el proyecto real, lado a lado: roles, rituales, estándares de documentación y especificación. Cuando la consultoría sale, su equipo conduce el ciclo.
El método funciona con el agente de código que su equipo ya usa. Cuando tiene sentido, traemos Clovis Agentic, nuestra herramienta, para orquestar el trabajo.
Cada etapa tiene formato, duración y entregables definidos. El cronograma final se cierra en el kick-off, con la agenda de las personas clave de su equipo.
Carga horaria a la medidaPresencial o remoto en vivo
Qué sucede
Qué queda con usted
1 día con su equipo, entrega en 7 díasPresencial recomendado
Qué sucede
Qué queda con usted
1 semana2 días presenciales y 3 remotos, en pair programming
Qué sucede
Qué queda con usted
Dentro del período totalMedición y seguimiento
Qué sucede
Qué queda con usted
Entre el Diagnóstico y Ponerlo a funcionar hay una ventana de su equipo: adecuar la documentación y especificar la funcionalidad piloto en el nuevo estándar. Puede llevar 30 días o más y depende de su ritmo, no de la consultoría.
Es la técnica que la consultoría implementa: cada etapa ejecutada por agentes con contexto propio, generando el insumo de la siguiente, y nada avanza sin la aprobación de quien responde por el resultado.
Tres proyectos reales conducidos con el mismo método, del portal al sistema del tamaño de un ERP. La estimación se redujo porque cambió la forma de trabajar.
BRK es un caso con nombre. Los otros dos están anonimizados. Barras proporcionales a la duración de cada proyecto.
La velocidad no vino de aflojar la supervisión. Vino de quitar del camino el trabajo de contexto, que es lo que consume el tiempo de quien decide.
26 años de ingeniería de software crítico, con un proceso auditado por gente de fuera.
Un ciclo de desarrollo rediseñado y funcionando en su proyecto real: etapas, roles, gates humanos, estándares de documentación y especificación, y el Harness de su contexto. Todo versionado en su repositorio, con su equipo formado para conducirlo solo y el resultado medido contra la baseline.
De 60 a 90 días, en cuatro etapas: Capacitación (con carga horaria a la medida), Diagnóstico (1 día con su equipo, entrega en 7 días), Ponerlo a funcionar (1 semana) y Resultados. Entre el diagnóstico y el piloto hay una ventana para que su equipo adecue la documentación, que puede llevar 30 días o más. El cronograma final se cierra en el kick-off.
No. La consultoría trabaja sobre una entrega que ya está en su backlog. El piloto es trabajo real, hecho con el método nuevo, lado a lado con nuestro equipo.
No para empezar. Muchos equipos no tienen la etapa de análisis formalizada, y eso es exactamente lo que muestra el diagnóstico. El plan de acción define quién asume el análisis y la validación en cada rol, con el equipo que ya tienen.
Es uno de los escenarios más comunes. La caída suele venir de la especificación vaga y de que cada persona usa la IA a su manera. El método pone la especificación antes del código, con escenarios de prueba y revisión humana en cada etapa, y medimos los bugs devueltos antes y después para mostrar la diferencia. En un portal que entregamos 3x más rápido de lo previsto, los bugs quedaron por debajo del 1% por funcionalidad.
Ese es el objetivo, y se mide. El bajo desempeño suele venir de especificaciones que llegan incompletas, del retrabajo y del uso desigual de la IA. En el diagnóstico medimos las entregas por mes y el lead time de su equipo; después de la implementación medimos de nuevo y mostramos la evolución, sin prometer un número antes. Como referencia: en un sistema del tamaño de un ERP, previsto para 8 meses con 4 devs, entregamos en 6 meses con 3.
No. No toda demanda debe migrar. En el diagnóstico separamos los perfiles de demanda que rinden con agentes de los que siguen mejor como están hoy, y elegimos el piloto a partir de ahí.
En el diagnóstico recolectamos una baseline de indicadores: entregas por mes, PRs abiertos, bugs devueltos y lead time. En la etapa de Resultados medimos de nuevo los mismos indicadores y entregamos el comparativo antes y después, con los nuevos cuellos de botella que aparecieron.
No. El método funciona con el agente de código que su equipo ya usa. Cuando tiene sentido, nuestro equipo usa Clovis Agentic para orquestar el trabajo, y usted decide si se queda después.
Es donde el método más rinde. El Descubrimiento lee el código legado, separa la regla de negocio del defecto y escala a quien decide lo que no se puede resolver con la evidencia, en lugar de copiarlo o corregirlo en silencio.
Los agentes operan dentro de los límites del Harness definidos para su contexto, con SAST/DAST antes de cada merge y un rastro auditable hasta el aprobador. Proceso certificado CMMI DEV/3, ISO 9001 e ISO/IEC 27001.
