¿Tiene sentido revisar el código de un software con IA antes de la recepción final?

Aquí hay un riesgo legal muy crítico. ¿Qué dicen las cláusulas de confidencialidad o propiedad intelectual del contrato que firmaste con la agencia? Subir código fuente privado de la empresa a un sistema de IA en la nube podría hacer que incorras en un incumplimiento contractual sin darte cuenta. Si los datos se usan para entrenamiento en servidores de terceros, quedarás en una posición indefendible.

Técnicamente la mayor limitación es la ventana de contexto. Un sistema de almacén de 26.000 EUR probablemente consta de docenas de servicios, esquema de base de datos e integraciones externas. Los modelos analizan los archivos de forma aislada. Al no ver la validación de datos que hace una función tres archivos más allá, puede dar una falsa alarma diciendo "aquí hay un fallo de seguridad".

En el marco del derecho contractual en Alemania, antes de firmar el acta de recepción hay que documentar los defectos de forma concreta. El texto generado por una IA no se considera una notificación de defectos válida. Es imprescindible que el fallo sea reproducible en el sistema en vivo y que se demuestre que no cumple con los requisitos de la especificación técnica.

El año pasado probamos justo esto con un portal B2B por el que pagamos 18.000 EUR. El modelo nos dio una lista de 47 puntos. Antes de mandárselo a la agencia, le pagamos 400 EUR a un senior freelance para que lo revisara. De esos 47 puntos solo 4 eran fallos reales, el resto no tenía sentido. Pero uno de esos 4 errores habría tumbado el sistema en producción. Como filtro es útil, como árbitro definitivo totalmente insuficiente.

en vez de pegar todo el codigo y decir busca errores vas a sacar mejores resultados si le das prompts enfocados tipo revisa modulo por modulo y lista dependencias y fallos de seguridad pero ni se te ocurra mandar la respuesta tal cual a la agencia xq no te van a tomar en serio.

No te compliques la vida. Lleva el proceso de recepción basándote directamente en la experiencia de usuario y la funcionalidad. Prepara escenarios de prueba: 1) ¿Qué pasa si metes un código de barras erróneo? 2) ¿Se rompe la sincro de stock si se va el internet y vuelve? 3) ¿Se congela el sistema al facturar? Tu trabajo no es auditar la literatura del código sino ver si cumple su función.

¿Había alguna cláusula en tu contrato sobre requisitos de pruebas automatizadas o porcentaje de cobertura de tests? ¿El repositorio entregado incluye pruebas unitarias escritas por la agencia? Si existen archivos de test, ejecutarlos da una métrica de aceptación mucho más clara e indiscutible que hacer leer el código a una IA.

Un cliente nuestro hizo algo parecido. Se plantó en la reunión con una lista de ocho páginas que sacó con un prompt diciendo "vuestro software es una basura". Uno de los puntos decía "la contraseña de la base de datos está hardcodeada", cuando en realidad era solo una plantilla de configuración de ejemplo y la contraseña real venía de una variable de entorno. Se tensó todo muchísimo y la entrega se retrasó dos meses para nada.

Lo que se dice aquí es exactamente lo que nos pasó. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Espero que le sea útil.

Llevé mucho tiempo con este asunto. Los primeros tres meses todo va bien los problemas aparecen en el cuarto.

Espero que le sea útil.

Entrando en detalle: Todos los que se apresuran con instrucciones de revisión de código se atascan en el mismo punto.

A nosotros nos pasó esto. Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla.

Corrijanme si me equivoco.

Creo que este consejo no sirve para todos. Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Por supuesto, cambia si tu situación es diferente.

Hay algo que no entiendo. Si no lo pones por escrito desde el principio, luego surgen discusiones.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. También me gustaría saber si alguien lo hace de otra manera.

Lo escribo para que no cometan el mismo error. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Si escribís el resultado aquí, también servirá de ayuda a otros.

¿Y cómo resolvieron esto? Cada "lo miramos luego" en una reunión es trabajo no presupuestado.

Eso es todo, disculpa si me he extendido demasiado.

Han surgido tres opiniones distintas, todas se complementan. Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla.

Las decisiones apresuradas son las que hay que corregir seis meses después.

tiene razón. lo que más tiempo nos hacía perder era no saber quéin tomaba las decisiones.

por supuesto, cambia si tu situación es diferente.