Construir una aplicación con ayuda de la IA ya es fácil. Lo que sigue costando es lo que viene después: que sea segura, que alguien más pueda revisarla, que no genere gastos inesperados y que no tenga que explicar cada decisión de memoria cuando me la preguntan.
Hace tiempo me di cuenta de que el eslabón más débil de mi proceso no era la tecnología: era yo, con prisa. Se me olvidaba preguntar algo, saltarme un paso o dejar una cosa "para después". Así que hice lo que haría con cualquier proceso que importa: lo escribí, y se lo di a un agente de IA para que lo siga siempre igual.
A esas instrucciones reutilizables les llamo skills. Hoy uso cuatro.
1. Antes de escribir una línea de código: decidir qué tan serio es
La primera skill es una entrevista. Antes de programar nada, me hace unas preguntas: de qué va, de quién es, quién lo va a usar, qué datos maneja, si usa IA con lo que escriben los usuarios y cuánto puede costar al mes.
Con eso decide un nivel de seguridad y lo deja por escrito en el proyecto. Un currículum o el material de una clase no necesitan lo mismo que una herramienta que toca información sensible. Y la regla que más me gusta: los datos deciden el nivel, no la comodidad. Si hay duda, se sube de nivel, no se baja.
2. Revisar el proyecto con un estándar propio, más estricto
La segunda skill audita un repositorio completo y, si yo lo autorizo, corrige lo que encuentra. Revisa cosas como:
- secretos o contraseñas que se hayan colado en el código, incluso en el historial;
- dependencias con vulnerabilidades reales y sus licencias;
- código de terceros;
- el contenedor y la infraestructura como código;
- la seguridad de la parte de IA;
- etiquetado, versionado y documentación.
Le puse reglas duras. Todo hallazgo se corrige o se documenta como excepción: ninguno se descarta porque "el modelo opina que no importa". Nunca guarda un cambio, lo publica ni amplía permisos sin que yo lo apruebe. Y nunca silencia una alerta por su cuenta.
Además, cuando una revisión externa encuentra algo que mi proceso no vio, ese hallazgo no se queda en un correo: se convierte en una regla nueva. Así cada tropiezo mejora el siguiente proyecto.
3. De "funciona" a "listo para producción"
La tercera skill lleva un desarrollo del estado "prototipo que funciona" al de "listo para que lo revisen". Sus principios:
- Primero mide, luego toca. Antes de cambiar nada, hace un inventario y un cuadro con semáforo. Yo decido con el cuadro en la mano.
- Costo cero por defecto. Todo lo que cuesta dinero se propone con su precio y solo se hace con mi sí.
- Todo es reversible. Antes de un lote de cambios deja un punto de respaldo y me dice cómo volver atrás.
- Se verifica contra el sistema real, no solo en local. Un control que no se probó en producción no cuenta como cerrado.
- Honestidad al reportar: qué quedó bien, qué no y por qué.
4. Documentar antes de que te lo pidan
La cuarta skill genera dos documentos: uno técnico, para quienes revisan la arquitectura y la seguridad, y una guía sin tecnicismos para quienes toman decisiones. Responden las preguntas antes de que alguien las haga.
Con una regla que me importa: solo hechos verificables. Cada cifra sale del código, de la infraestructura o de una prueba real. Si algo no se midió, el documento dice "pendiente", no lo estima. Y el documento declara con claridad cómo se construyó, con qué herramientas de IA y qué controles compensan el que no haya habido una revisión por pares. No lo escondo: lo demuestro.
Lo que me llevo
Ninguna de estas skills reemplaza a un equipo de seguridad ni a una revisión humana. Hacen algo más modesto y, creo, más útil: llegar a esa revisión con menos observaciones y con todo documentado.
Y me dejaron tres convicciones:
- Un agente de IA es mejor aliado cuando el proceso está escrito, y no cuando improvisa.
- La IA propone, yo apruebo. Esa frontera nunca se mueve.
- Un buen proceso se mide por lo que evita, no por lo que presume.
¿Tu proceso para llevar algo a producción vive en un documento, en la cabeza de alguien o en algo que se ejecuta solo cada vez?