Saltar al contenido
← Todos los escritos
30 de junio de 2026 · 6 min de lectura

Construir ahora es barato. Así mido lo que no lo es.

Hace unos años, la parte difícil del software era construirlo. Hoy un agente escribe el boilerplate, redacta las pruebas, conecta la integración, y lo hace mientras lees el diff. El costo de producir código se cayó por un precipicio.

Así que todos dicen lo mismo: entregamos rápido. Es la frase más inútil de la ingeniería ahora mismo. ¿Rápido comparado con qué? ¿Rápido construyendo qué? Una landing en un día no es el mismo logro que una plataforma de detección de fraude en una semana, y "rápido" las aplana en la misma fanfarronada.

Si construir es barato, entonces "lo construí rápido" no es el mérito. El mérito es qué construiste rápido, y qué tan difícil era de verdad. Lo que significa que tienes que medir dos cosas con honestidad, no una: velocidad, y dificultad. Así lo hago yo, enteramente desde el historial de git, para que los números sean reproducibles y difíciles de manipular.

Velocidad: horas trabajadas, no tiempo de calendario

El tiempo de calendario miente. Un repo con el primer commit en abril y el último en junio no tomó tres meses; tomó un puñado de noches. Así que no cuento días. Agrupo las marcas de tiempo de los commits en sesiones de trabajo: un hueco de más de dos horas inicia una sesión nueva. Luego sumo el tiempo dentro de cada sesión, más un bloque fijo por sesión para el trabajo hecho antes de su primer commit.

Eso da horas trabajadas, una estimación honesta del tiempo humano frente al teclado, no la distancia de reloj entre el primer y el último commit. Es aproximada, y lo digo. Aun así le gana a la alternativa, que es un número que te halaga por un orden de magnitud.

Dificultad: un perfil, no un conteo de líneas

Aquí es donde casi todas las "métricas" hacen trampa. Las líneas de código son lo más fácil de medir y el peor proxy de dificultad. Un millón de líneas generadas por un ORM no son complejas. Doscientas líneas de lógica distribuida, con estado y regulada, sí lo son. El tamaño es volumen. La dificultad es otra cosa.

Así que la complejidad no es un número, es un perfil sobre seis ejes, cada uno puntuado de 0 a 4 contra una rúbrica fija de cosas contables, para que el mismo repo reciba la misma nota dos veces:

  • Estado es el modelo de datos, la persistencia, la consistencia que debe sostener.
  • Concurrencia es asincronía, colas, distribución, fallo parcial.
  • Integraciones son sistemas externos, cada uno un contrato y un modo de fallo.
  • Confianza es autenticación, datos personales, pagos, un dominio regulado.
  • Inteligencia es AI y agentes, no deterministas por naturaleza.
  • Código es complejidad ciclomática real, medida con una herramienta, no a ojo.

Cada nivel está anclado a criterios observables. Integraciones es un conteo: cero, una, dos a tres, cuatro a seis, siete o más. Estado es el número de entidades persistidas y si los datos están particionados. Código es la complejidad ciclomática promedio y la proporción de funciones sobre un umbral. No estás calificando la dificultad por intuición; la estás leyendo del repo.

Los seis ejes suman un índice sobre 24. Lo llamo índice a propósito, no medición. Sumar ejes ordinales asume peso igual y espaciado igual, que son supuestos, no hechos. El perfil es el artefacto real; el número es una conveniencia. Decirlo en voz alta es la diferencia entre una métrica y un gráfico de marketing.

El resultado

Ahora la parte que es todo el punto. Tengo una empresa que construí a la vieja usanza, antes de tener un framework y antes de que la AI pudiera escribir código conmigo: Insttantt, una plataforma de identidad y procesos regulados que ha servido a cerca de un millón de personas. Medida de la misma forma, tomó unas 19.766 horas trabajadas a lo largo de sus repos, durante años, y puntúa 19 de 24 en complejidad. Esa es la línea base. El "antes".

Luego está RootBlocks, una plataforma de seguridad, identidad y fraude con un motor de construcción agéntico, hecha ahora, sobre el framework, con la AI como co-arquitecta. Puntúa 20 de 24, tan compleja como Insttantt, y un poco más. Tomó unas 168 horas trabajadas frente a las 19.766 de Insttantt.

La misma clase de dificultad. Ajustando por el hecho de que RootBlocks es la más compleja de las dos, eso es unas 124 veces menos tiempo para el mismo tipo de construcción. En horas crudas ronda las 118; el resto es ese ajuste por complejidad.

No es una casualidad de un solo proyecto. Datta, una plataforma de propiedad de datos con una bóveda, una app en Flutter, workers y un gateway MCP, puntúa 18 de 24 y va por unos pocos cientos de horas trabajadas, todavía en progreso. El patrón se sostiene: lo que antes le tomaba años a un equipo ahora le toma semanas a una persona, a la misma complejidad, porque la restricción se movió.

Qué cambió de verdad

El cuello de botella ya no es construir. Durante casi toda la historia de este oficio, la pregunta "¿podemos construirlo?" se comía el presupuesto. Ahora construir es barato, y las preguntas que quedan son las que siempre fueron las difíciles y ahora son las únicas difíciles: por qué construir algo, qué construir, y cómo construirlo para que sobreviva. Ese criterio es el trabajo. No aparece en las horas trabajadas, y nunca lo hará, porque ocurre antes del primer commit.

Por eso no lo cuento en la página de velocidad. Soy preciso con eso: los números miden la construcción, que es la parte fácil. El tiempo de pensar, la parte extensa, la parte donde se crea el valor real, queda deliberadamente excluido. El gráfico no es una fanfarronada sobre lo rápido que escribo. Es evidencia para una tesis: construir es ahora un commodity, y el foso es el criterio.

Por qué me tomo el trabajo de ser tan cuidadoso

Porque en el momento en que un número impresiona, también es sospechoso, y uno descuidado se lleva por delante a los creíbles. Así que el método está hecho para sobrevivir el escrutinio:

  • Las horas trabajadas son una suma aproximada; los productos multi-repo cuentan de más un poco y lo digo.
  • La línea base está medida, no estimada, o toda la comparación descansa sobre una suposición.
  • El eje de Código lo lee una herramienta donde el lenguaje lo permite y lo leo a mano donde la herramienta se queda corta, y marco cuál es cuál.
  • El compuesto es un índice, no una medición fundamental.

Un escéptico puede verificar cada uno de estos contra los repos. Ese es el punto. En un mundo donde todos dicen que entregan rápido, la única afirmación interesante es la que puedes auditar.

Construir ahora es barato. Los números prueban que la parte fácil es fácil. Lo que en realidad están ahí para decir es lo contrario: si construir era lo que se interponía entre tú y lo que querías crear, ya no lo es. Ahora solo quedan tú y las preguntas difíciles, sin excusa.