El código anda. No es lo mismo que esté bien.
Generar código dejó de ser lo caro. Saber si aguanta usuarios reales, no. Una revisión de alcance cerrado sobre el camino que concentra más riesgo, entregada como un informe escrito que es tuyo, con el criterio para que tu equipo juzgue la próxima tanda solo.
Hablar con un ingenieroCuándo nos llaman
- Una función se armó en dos días y falla de manera intermitente hace dos meses, y nadie sabe en qué parte.
- Las pruebas pasan, la revisión se aprobó, y la función igual falló para todos los usuarios reales.
- El código creció más rápido que la comprensión que alguien tiene de él, y un cambio chico ahora toca cosas que nadie esperaba.
- Un prototipo llegó a producción sin que nadie decidiera que tenía que llegar.
- Hay mucho código y muy poco acuerdo sobre qué partes son confiables.
- Todo funciona en la máquina de quien lo generó, y las fallas empiezan en los bordes: otro formato, otra versión, otro huso horario.
Qué hacemos
Leer lo que realmente se generó
No es pasar un analizador. Seguimos a mano los caminos críticos y comprobamos si el código hace lo que el código de alrededor supone que hace. El código generado es verosímil por construcción, y eso es justamente lo que lo vuelve difícil de revisar rápido.
Ejercitar el camino que recorre una persona
La mayoría de las pruebas generadas cubren el caso que su autor ya tenía en la cabeza. Probamos el otro: el formato real que manda el navegador, la entrada vacía, el segundo clic, la versión de la biblioteca que está instalada y no la del ejemplo.
Encontrar los supuestos que nadie escribió
Reintentos silenciosos, tiempos de espera que no existen, una biblioteca usada como funcionaba dos versiones mayores atrás. Pasan la revisión porque parecen normales.
Hacer visible la falla
Instrumentación en los caminos que importan, para que el próximo problema intermitente tenga una ubicación en lugar de una teoría. Un sistema que nadie puede observar es un sistema que nadie puede arreglar bajo presión.
Dejar el criterio
Por escrito: qué se revisó, qué se encontró y qué mirar la próxima vez. El objetivo es que tu equipo deje de necesitarnos para esto, no que nos siga llamando.
Proyectos típicos
Un camino crítico, una semana, precio cerrado
Tomamos el camino donde equivocarse sale más caro —el pago, la autenticación, lo que mueva dinero o datos personales— y lo leemos en serio. Un informe escrito al final. Autocontenido: podés parar ahí, y usarlo con quien quieras.
Auditar una función que falla de forma intermitente
Reproducir la falla, encontrar el supuesto que la causa, corregirlo, e instrumentar el camino para que la próxima se vea en minutos y no en semanas.
Revisar un código antes de que crezca más
Leer las partes que concentran el riesgo, escribir qué se rompe primero y por qué, y priorizar por consecuencia y no por lo feo que se vea el código.
Montar una revisión que el equipo pueda sostener
Comprobaciones que corren en cada cambio, y un estándar corto y escrito sobre qué tiene que mirar igual una persona. Automatizar donde es confiable, criterio donde no.
Llevar un prototipo que anda a algo operable
Manejo de errores, límites, secretos fuera del código, registros que digan algo, y un despliegue que se pueda revertir.
Qué se lleva
- Un informe escrito: qué se revisó, qué se encontró y la consecuencia de cada hallazgo
- Las correcciones aplicadas en tu repositorio, pasando por tu proceso de revisión
- Pruebas que cubren el camino de una persona real, no sólo el feliz
- Instrumentación en los caminos que fallan en silencio
- Un estándar corto que tu equipo pueda aplicar sin nosotros
Preguntas que nos hacen
¿Están en contra de usar IA para escribir código?
No. La usamos todos los días y es una ganancia real. El problema no es que un modelo escriba código, es que el código verosímil pasa la revisión más rápido de lo que alguien puede verificarlo. La velocidad conviene conservarla; lo que falta es el paso que hacemos nosotros.
¿No alcanza con correr una herramienta de análisis estático?
Esas atrapan una categoría, y conviene tenerlas. No atrapan una función correcta por separado y equivocada para el sistema que la rodea, que es la mayoría de lo que encontramos. Eso requiere leer el código teniendo el resto del sistema en la cabeza.
¿Le van a decir a nuestro equipo que lo hizo mal?
No, y sería inútil. Casi nada de lo que encontramos es descuido: es código que parecía correcto, en un lenguaje que nadie tuvo tiempo de cuestionar. El informe va a quien lo pidió, y el punto es qué hacer ahora.
¿Cómo empieza y cuánto cuesta?
Un camino crítico, una semana, precio cerrado, un informe escrito. Sabés qué estás comprando antes de la primera llamada. Desde ahí podés parar, darle el informe a quien quieras, o seguir —y casi todo lo que encontramos conviene arreglarlo lo arregle quien lo arregle—.
¿En qué se diferencia de la revisión de arquitectura?
La revisión de arquitectura mira la forma del sistema: cómo encajan las piezas, qué cede primero bajo carga, qué te va a costar el diseño el año que viene. Esta mira el código en sí, sobre todo lo escrito hace poco y rápido. Si no sabés si el problema es el diseño o la implementación, empezá por la revisión.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.