Hoy os cuento cómo ajusto los permisos de Codex para que pueda avanzar con autonomía sin tocar producción alegremente. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de storytelling en crowdfunding. Esta mañana veremos el papel de los colegas y amigos, y esta tarde los problemas que pueden aparecer al construir la historia de una campaña. ¡A por él! Ahora sí, vamos al lío. Un agente no se limita a contestar preguntas. Puede leer y modificar archivos, ejecutar comandos, conectarse a servicios y realizar cambios reales. Por eso es importante decidir qué autonomía necesita en cada momento. Codex separa esta cuestión en dos partes. Las aprobaciones determinan cuándo debe detenerse para pediros permiso. El sandbox establece qué archivos, directorios y recursos puede alcanzar aunque quiera continuar. En la app podéis encontrar perfiles como Ask for approval, Approve for me, Full access y perfiles personalizados, dependiendo de vuestra configuración. En la CLI podéis abrir el selector mediante /permissions. Cuando empecé, utilizaba siempre la opción más restrictiva. El problema es que el agente se detenía continuamente para preguntar si podía leer un archivo, modificar otro o conectarse a un servicio. Me marchaba pensando que la tarea estaba avanzando y, al regresar, descubría que llevaba una hora esperando la primera confirmación. Además, cuando aparece el mismo aviso treinta veces, acabáis aceptándolo por inercia sin leerlo. Y eso tampoco aporta demasiada seguridad. Actualmente prefiero dar autonomía suficiente dentro de proyectos que conozco y controlo, pero mantengo una frontera mucho más estricta alrededor de producción. Si una operación va a desplegar, modificar datos reales o afectar a usuarios, quiero revisarla expresamente. Esto no significa que todo el mundo deba activar Full access. Ese modo elimina las restricciones del sandbox y debe reservarse para entornos en los que entendéis perfectamente el alcance. Para la mayoría de trabajos, el acceso de escritura limitado al proyecto ofrece un equilibrio mucho más razonable. Si necesitáis un comportamiento específico, podéis definir perfiles en config.toml y añadir reglas que permitan, pregunten o prohíban determinados prefijos de comandos. Por ejemplo, podéis autorizar el trabajo local y exigir confirmación para las órdenes utilizadas en un despliegue. También podéis reforzar esa frontera mediante instrucciones permanentes y hooks, como vimos la semana pasada. Cada capa cumple una función distinta: los permisos limitan, las reglas controlan comandos concretos y las instrucciones recuerdan cómo queréis trabajar. Git ayuda a deshacer cambios en el código, pero no convierte producción en un lugar seguro para experimentar. Una web rota durante diez minutos sigue estando rota para todos sus usuarios, y una operación sobre la base de datos puede requerir algo más que volver a un commit anterior. Mi recomendación es que escojáis el perfil más estrecho que permita completar la tarea sin interrupciones absurdas. Dad libertad dentro del entorno de desarrollo y mantened producción detrás de una revisión consciente. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana jueves con más marketing online veraniego. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related