Cuando el software se lanza más rápido de lo que alguien alcanza a revisarlo

Empecemos por la buena noticia, porque es real y merece decirse con claridad. Trabajo que antes le tomaba a un equipo de software un trimestre entero hoy puede tomar días. No una demo. No una maqueta. Una función que funciona, conectada a datos reales, con pruebas alrededor y notas que explican cómo opera.

Escribimos antes sobre cómo la inteligencia artificial está cambiando el desarrollo de software en general. Esta es la parte que viene después, y es la parte que a la mayoría de los dueños de negocio no les están contando: cuando construir se vuelve así de rápido, el riesgo de tu software se mueve. No desaparece. Se mueve. Antes vivía en “no alcanzamos a construirlo a tiempo”. Ahora vive en “lo construimos, y nadie notó lo que estaba mal”.

Qué se volvió genuinamente más rápido

Conviene ser específico, porque la exageración es vaga a propósito. Esto es lo que de verdad se desplomó en costo:

• Los primeros borradores. Una pantalla, un formulario, un reporte, una página de configuración. La primera versión completa de casi cualquier cosa llega ahora en una o dos horas en lugar de una semana.
• La plomería. El trabajo de conexión poco glamoroso entre la base de datos, el servidor y la pantalla. Es repetitivo, es la mayor parte de un proyecto por volumen y ahora es casi gratis.
• Las pruebas y la documentación. Las dos cosas que todos los equipos se saltaban bajo presión de fecha. Se abarataron lo suficiente como para que saltárselas sea ahora una decisión y no una excusa.
• Los cambios de base de datos. Agregar un campo, reformar una tabla, mover registros viejos a un formato nuevo. Trabajo cuidadoso y quisquilloso que antes se comía días.

Y esto es lo que no se volvió más rápido en absoluto, ni un solo minuto:

• Decidir qué construir. Saber qué necesitan de verdad tus clientes, a diferencia de lo que dijeron en una junta, sigue siendo una conversación humana.
• Juzgar si está correcto. Alguien todavía tiene que mirar el resultado y saber, por experiencia, que se comporta bien para todos y no solo para la persona que lo está viendo.
• Responder por las consecuencias. Cuando algo se rompe frente a un cliente, la explicación nunca es “lo escribió la herramienta”. Una persona con nombre y apellido sigue respondiendo por ello.

El cuello de botella que nunca se movió

Aquí está la idea sobre la que descansa todo el artículo. Escribir código nunca fue el cuello de botella que más importaba. Revisarlo sí.

Piensa en una cocina. Acelerar el picado no te permite servir más platillos si una sola persona todavía tiene que probar cada plato antes de que salga. La inteligencia artificial volvió el picado casi instantáneo. Probar toma exactamente lo mismo que siempre, porque probar es atención, y la atención no escala.

Cuando el código se produce más rápido de lo que cualquier persona alcanza a leerlo, la brecha entre “escrito” y “verificado” se convierte en el lugar donde viven los problemas.

Esa brecha es la razón por la que un equipo rápido puede acumular lo que nosotros llamamos deuda invisible. No código desordenado, que al menos se anuncia solo. Algo más silencioso: cosas que se ven terminadas, están en el menú, aparecen en la demo, y no funcionan. Nadie las escribió mal a propósito. Nadie las revisó tampoco.

Cinco formas en que el software rápido falla en silencio

Son patrones, no acusaciones. Aparecen en toda la industria, en productos construidos por gente cuidadosa, porque todos comparten un rasgo: nada se cae. Nada se pone rojo. El software se comporta como si todo estuviera bien.

1. Puertas que parecen cerradas

Una pantalla revisa que hayas iniciado sesión. Nunca revisa si tú tienes permiso de ver eso. Así, cualquiera con una cuenta puede llegar a información pensada para unas pocas personas: sueldos, registros de otros clientes, notas internas.

Imagina un edificio de oficinas donde tu credencial abre la puerta principal. Esa parte funciona, y se siente como seguridad. Lo que nadie probó es que la misma credencial también abre todas las oficinas de adentro, incluidas las de los archiveros.

Cómo lo detectas: inicia sesión con tu usuario más restringido y luego intenta abrir una página o un registro que le pertenezca a alguien de mayor nivel. Si abre, la cerradura es decorativa.

2. Funciones que nunca funcionaron

No una función que se rompió. Una función que nunca ha funcionado ni una sola vez. Un formulario que siempre ha fallado al guardar. Una lista que siempre ha regresado vacía. Normalmente porque más tarde se agregó una regla en otro lado y nadie volvió a revisar las pantallas que dependían de la regla vieja.

Estas sobreviven meses por un reflejo muy humano: la gente que necesitaba la función asumió que la estaba usando mal. Encontró una forma de darle la vuelta, una hoja de cálculo, una llamada, y dejó de mencionarlo.

Cómo lo detectas: elige las funciones de las que nadie habla nunca e intenta completar cada una de principio a fin, hasta ver el resultado guardado regresar.

3. Pantallas que muestran datos de mentira

Durante la fase de diseño, alguien llena un dashboard con números de ejemplo verosímiles para poder revisar el acomodo. Eso es normal y útil. El problema es lo que pasa después: la pantalla se aprueba, el proyecto avanza y la página nunca se conecta a datos reales. Meses más tarde sigue en el menú de producción, mostrando los mismos números de aspecto autoritario a todo el que la abre.

Es un velocímetro pegado en sesenta. La aguja está firme, la carátula convence, y no está conectada a las ruedas.

Cómo lo detectas: cambia algo real en el sistema y luego revisa si el número de la pantalla se mueve. Si no se mueve, nunca estuvo escuchando.

4. Cosas que funcionan para ti y fallan para todos los demás

El software normalmente lo prueba la persona que lo construyó, y esa persona casi siempre tiene el nivel de acceso más alto del sistema. Todo se le abre. Así que la versión que ve un empleado común, con menos permisos y datos distintos, nunca se mira de verdad. Puede estar rota, o vacía, o sin la mitad de sus botones, y nadie con el poder de arreglarlo llega a ver esa pantalla.

Es el dueño del restaurante probando un platillo en su propia cocina, en su propia mesa, con los buenos cubiertos, y concluyendo que el servicio de la cena va bien.

Cómo lo detectas: pide un recorrido hecho desde una cuenta con el menor acceso, no con el mayor. Mira esa sesión, no la pulida.

5. Configuraciones que están escritas pero nunca surten efecto

Existe una protección. Está escrita, se lee correcta, cualquiera que la revise asentiría. Y en otro lugar del sistema, una segunda instrucción la anula en silencio. La regla está presente y no hace nada. Esta es la más difícil de encontrar, porque leer el software te dice que está protegido. Solo ejecutarlo te dice la verdad.

Piensa en una alarma de humo montada, cableada y etiquetada, con el compartimento de la batería vacío. Todo en ella dice “protegido” menos la parte que importa.

Cómo lo detectas: no preguntes si la regla existe. Pídele a alguien que te demuestre que bloquea algo. Una regla que no puedes ver actuar es una regla que no tienes.

Y una sexta: trabajo que nunca le llega a nadie

Vale la pena mencionarla porque es facilísima de pasar por alto. Una función está terminada, aprobada y correcta, y nunca llega a los clientes, porque el proceso que publica las nuevas versiones está roto por algo no relacionado. Todo el mundo está mirando el trabajo. Nadie está mirando la entrega. Semanas de software terminado pueden quedarse a un paso de las personas para las que se construyó, y el único síntoma es una sensación vaga de que el producto no está cambiando mucho.

Diez registros no son cien mil

Vale la pena entender una falla más, porque llega tarde y de golpe. El software construido rápido suele construirse contra un puñado de registros de prueba. Con diez clientes en el sistema, casi cualquier enfoque se siente instantáneo, incluidos algunos genuinamente derrochadores: cargar todos los registros de la base de datos para mostrar los primeros veinte, buscar sin el equivalente de un índice al final de un libro, nunca dividir una lista larga en páginas.

Nada de eso duele con diez registros. Con cien mil es la diferencia entre una página que abre ahora y una que abre en cuarenta segundos, o que no abre. El arreglo suele ser barato cuando se hace temprano y caro cuando se hace en pánico, así que conviene hacer la pregunta antes del lanzamiento y no después: ¿alguien ha corrido esto contra una cantidad realista de datos?

Cómo se ve lo bueno ahora

Si construir es rápido y revisar no, entonces revisar es el trabajo. Ese es todo el ajuste. Un equipo que ya lo hizo tiene estos hábitos, y puedes preguntar por cada uno de ellos sin saber nada técnico.

• Revisa lo que se construyó, no solo si arranca. “Funciona” normalmente significa “no se cayó”. Pregunta qué se revisó, no si cargó.
• Prueba como el usuario con menos privilegios. Toda demo debería darse desde la cuenta con menos permisos. Es la forma más rápida de encontrar tanto el problema de la puerta con cerradura decorativa como el de “a mí me funciona”.
• Prueba desde cero. Abre la función como lo haría un cliente nuevo: fresco, desde la página principal, en un dispositivo que nunca la ha usado. No desde la pantalla que ya está abierta en el segundo monitor de quien la programó.
• Que alguien distinto al autor la mire. A estas alturas, el autor y la inteligencia artificial son el mismo revisor dos veces. Una segunda persona que no lo escribió es la herramienta de calidad más barata que existe.
• Mantén un lugar real para probar. Una copia separada del sistema con volúmenes realistas de datos, donde se puedan intentar y romper cosas sin riesgo antes de que las vean los clientes.
• Vigila la publicación, no solo el código. Alguien debería poder decirte, hoy mismo, cuándo salió la última versión exitosa y qué está esperando en la fila.

Convertido en preguntas que le puedes hacer a tu equipo o a tu proveedor, en cualquier proyecto y en cualquier etapa: ¿quién revisó esto además de la persona que lo escribió? ¿Me lo puedes mostrar funcionando en una cuenta con el acceso más bajo? ¿Esta pantalla está leyendo datos reales y podemos ver cambiar un número? ¿Me puedes mostrar esta regla bloqueando algo? ¿Cuándo llegó a los clientes la última versión publicada? Ninguna de ellas te exige leer una línea de código, y todas son difíciles de responder de forma vaga.

La velocidad vale la pena

Queremos ser claros con nuestra postura. La velocidad es real, la usamos todos los días y no regresaríamos. Ideas que antes eran demasiado caras para intentarse ahora son lo bastante baratas como para probarse en una tarde. Equipos pequeños de verdad lanzan lo que antes lanzaban los grandes. Es una buena década para construir software.

Pero la velocidad por sí sola es solo movimiento. Lo que la convierte en algo confiable es la mitad poco glamorosa: alguien mirando con cuidado, desde afuera, como el usuario con menos poder, aquello que se acaba de construir. Ese hábito es ahora la diferencia entre un producto que se mueve rápido y un producto que se mueve rápido en la dirección correcta.

Si eres dueño de un software y alguno de los cinco patrones de arriba te sonó incómodamente familiar, vale la pena que alguien lo revise. Si estás por construir algo, vale la pena decidir desde el inicio quién hace la revisión. En cualquier caso, hablemos, o mira lo que hemos construido.