Que el código compile no significa que haga lo que pediste. Antes de acercar una modificación de IA a una cuenta, define el comportamiento esperado, examina el cambio completo y prepara una prueba capaz de revelar sus fallos.
La respuesta del asistente puede sonar segura aunque haya entendido mal una condición. Microsoft pide comprender cada modificación generada y probarla con el mismo rigor que el código escrito a mano (guía de Microsoft sobre código asistido por IA). NIST, por su parte, sitúa las prácticas de desarrollo seguro dentro del ciclo de vida del software, no como un trámite al final (marco SSDF de NIST).
Antes de abrir el editor, define qué debe pasar
Describe el cambio con resultados observables: qué lo activa, qué debe quedar intacto y cómo se resuelven los casos límite. “Añade un filtro horario” no basta. En un ejemplo hipotético, habría que concretar de qué zona horaria salen las horas y qué sucede con una posición abierta cuando comienza el periodo excluido.
Anota también una situación que debería impedir la acción. Así podrás preguntar si la modificación respeta el propósito original o si ha cambiado algo más.
La revisión empieza en el diff
Compara la propuesta con la versión anterior. Sigue sus efectos hasta las condiciones de entrada y cualquier valor que pueda afectar a volumen, stops, selección de posiciones, horario o estado del cBot. No des por inocuo un cambio solo porque ocupe pocas líneas.
Deja constancia de estas preguntas:
- ¿Qué necesidad concreta resuelve y qué comportamiento queda fuera del alcance?
- ¿Qué supuestos hace sobre símbolo, hora, datos incompletos y estado de la cuenta?
- ¿Qué ejemplo debería rechazar o manejar de forma segura?
- ¿Qué resultado vas a observar para decidir si funciona?
Es una pauta de revisión, no un certificado. NIST presenta el SSDF como prácticas integrables en distintos procesos de desarrollo; no valida una estrategia ni un cBot concreto (NIST SSDF).
Separa la compilación de la prueba de comportamiento
Compilar confirma algo limitado: el proyecto se construyó en ese entorno. No demuestra que las entradas y salidas sigan la intención de la estrategia. Microsoft advierte que el código generado puede parecer correcto y contener errores sutiles, por eso pide probarlo igual o más que el código manual (recomendaciones de Microsoft).
Una secuencia prudente puede ser:
- Construye el proyecto y aclara cualquier aviso que no entiendas.
- Prueba justo los límites de la condición modificada, incluyendo datos ausentes y posiciones ya abiertas.
- Ejecuta la versión editada y la original con el mismo historial y configuración. Revisa las operaciones alrededor de la regla, no solo el resumen final.
- Si el código va a ejecutarse en directo, observa registros y acciones primero en demo.
Ninguna de esas comprobaciones predice el rendimiento futuro. Un backtest y una observación breve en demo tampoco prueban que un sistema sea rentable o seguro en todas las condiciones.
Protege también lo que compartes
El proceso de revisión incluye el contexto enviado al asistente. Microsoft desaconseja incluir credenciales, datos personales o lógica privada sin autorización, y recomienda validar las entradas en vez de confiar en ellas directamente (Microsoft Learn). Usa ejemplos sintéticos; elimina tokens, identificadores de cuenta y detalles privados del bróker.
Y no confundas escribir código con otorgar autoridad. Una sugerencia no debería adquirir permiso para operar solo porque el encargo diga “haz que funcione”. En nuestra guía sobre permisos de una IA de trading en cTrader se trata ese límite; el artículo sobre cómo auditar el registro de decisiones de un cBot aborda la reconstrucción de sus acciones.
Cuándo descartar la propuesta
No aceptes un cambio que no puedas explicar, contrastar con un caso concreto o revertir con claridad. Pide una modificación más pequeña y un ejemplo de prueba; después vuelve a revisar el diff desde cero. La explicación del modelo no sustituye la evidencia.
Guarda juntos el requisito, la diferencia de código, la prueba, el resultado observado y la decisión de conservar o revertir. Así el cambio queda inspeccionable, aunque no se convierta por ello en una ventaja de mercado.
Si no puedes explicar el cambio ni demostrar cómo lo comprobaste, el cBot aún no está listo para una cuenta.
GitHub también advierte que las pruebas propuestas por un asistente pueden dejar casos sin cubrir. El ejemplo DevSecOps de NIST incorpora controles repetibles y retroalimentación antes de avanzar cambios (guía de uso responsable de GitHub Copilot; modelo de referencia DevSecOps de NIST).