zetarıx

Blog

El cuello de botella se mudó

Escrito en marzo de 2026 · 2 min de lectura

Las herramientas y modelos que menciona esta nota cambian rápido; conviene leerla con su fecha en mente.

Los números que circularon este trimestre son difíciles de ignorar. Más de nueve de cada diez desarrolladores en Estados Unidos usan herramientas de IA a diario. En las organizaciones de adopción alta, cerca de la mitad del código nuevo sale de un modelo. Las cifras varían según quién mida, pero la dirección es una sola y se confirma en cualquier equipo que uno mire de cerca, incluido el nuestro.

Lo interesante no es el porcentaje. Es lo que el porcentaje le hace al resto del proceso.

Escribir dejó de ser lo caro

Durante décadas, la escritura de código marcó el ritmo de todo lo demás. Las estimaciones, los equipos, los precios: todo se organizaba alrededor de cuánto costaba producir las líneas. Ese costo se desplomó, y el cuello de botella, como siempre que se destraba un tramo, se mudó al tramo siguiente: decidir si lo producido sirve.

Leer código siempre fue más difícil que escribirlo. La industria lo sabía y lo toleraba, porque la lectura era la parte corta del día. Ya no lo es. Hoy un equipo puede generar en una mañana más código del que puede revisar con seriedad en una semana, y esa asimetría es el problema central de esta etapa.

Revisar en capas

Lo que dejamos de hacer: leer un diff grande línea por línea, de arriba hacia abajo, con la esperanza de que el error salte a la vista. A ese método el volumen actual lo venció.

Lo que hacemos en su lugar es revisar en capas. Primero la forma: qué archivos toca el cambio y si ese alcance tiene sentido para lo que se pidió. Después los bordes, que es donde se esconden los problemas caros: manejo de errores, permisos, datos que entran y salen. Recién al final el detalle fino, y solo en las partes que las dos pasadas anteriores señalaron.

La maquinaria participa de su propia revisión: análisis automático, pruebas, verificación de tipos. La lectura completa la hace la máquina, que no se cansa; el ingeniero revisa lo señalado y decide. Un test, visto así, es una lectura del código que se repite sola cada vez que algo cambia. Por eso escribimos más tests que hace un año, no menos.

Un oficio que sube de precio

Hay una consecuencia laboral que casi no se discute. Si escribir vale menos y revisar vale más, la experiencia cambia de precio. Detectar que una solución correcta está resolviendo el problema equivocado, o que un cambio prolijo deja una deuda que va a doler en seis meses: eso no lo produce el volumen, lo produce haber visto muchas cosas fallar.

El desarrollador que solo escribía compite ahora con una máquina. El que sabe leer, cada vez menos.