En Ratatouille, el chef Gusteau cree que cocinar debería estar al alcance de todos. Remy no está tan convencido: saber cocinar no significa necesariamente que alguien deba quedar suelto en la cocina. Su breve intercambio captura una tensión que ahora resulta familiar en el desarrollo de software.
Dale a alguien un asistente de programación con IA y podrá convertir una idea en una aplicación funcional. Un panel de control. Un portal para clientes. Una automatización que elimine horas de trabajo repetitivo.
Es una oportunidad extraordinaria. Las personas que entienden un problema de negocio pueden participar directamente en su solución, incluso si nunca se han considerado desarrolladoras.
Pero una aplicación funcional es el comienzo de una responsabilidad.
Alguien todavía debe decidir dónde deben residir sus datos, quién puede acceder a ellos, cómo llegan los cambios a producción y qué ocurre cuando algo falla. Alguien debe asegurarse de que encaje con los sistemas, las políticas y las formas de trabajo de la empresa.
Cualquiera puede preparar un plato. Un restaurante necesita toda una cocina detrás.
Cuando un experimento se vuelve esencial
Consideremos un escenario.
Una empleada quiere una forma mejor de hacer seguimiento de las solicitudes de los clientes. Con un asistente de programación con IA, crea una pequeña aplicación. Tiene buen aspecto, ahorra tiempo y pronto atrae a varios compañeros.
La conecta a datos reales de clientes. Añade un proceso en segundo plano para mantenerlo todo actualizado. Para hacerla accesible, comparte un enlace.
En pocas semanas, el equipo depende de ella.
Pero la aplicación se ejecuta en el portátil de la empleada. Su integración utiliza una credencial personal. Nadie ha acordado quién debería tener acceso, ha probado la restauración de una copia de seguridad ni ha documentado cómo mantenerla. Cuando se cierra el portátil, el proceso en segundo plano se detiene.
Puede que el código funcione exactamente como se esperaba. Aun así, el negocio tiene una dependencia sin gestionar.
Nada de esto requiere una intención maliciosa ni una herramienta de programación incompetente. Cada paso puede parecer razonable cuando el objetivo inmediato es simplemente crear algo útil.
La dificultad está en reconocer cuándo un experimento se ha convertido en un sistema del que dependen otras personas.
El trabajo más allá del código
El desarrollo de software contiene mucho trabajo que apenas se ve en una demostración exitosa:
- Arquitectura y coherencia. ¿Debería esta funcionalidad ampliar una aplicación existente? ¿Qué base de datos, framework y componentes compartidos debería utilizar? ¿Cómo encaja con los sistemas y las convenciones de interfaz existentes de la empresa?
- Integridad de los datos. ¿Cómo puede cambiar la estructura de la base de datos sin dañar los registros existentes ni interrumpir otras aplicaciones? Si una solicitud se reintenta, ¿creará un pago, ticket o cliente duplicado?
- Gestión de cambios. ¿Dónde se versiona el código? ¿Qué rama contiene el cambio? ¿Cómo se gestionan el trabajo simultáneo, los rebases, las revisiones, los lanzamientos y la recuperación?
- Requisitos y evidencias. ¿Qué se solicitó y qué se considera un resultado exitoso? ¿Puede alguien seguir un issue de Jira o un ticket de soporte desde la implementación, las pruebas y las evidencias hasta el lanzamiento? ¿Cerrar el ticket significa que el problema del usuario se ha resuelto realmente?
- Entornos y estaciones de trabajo. ¿Qué runtimes, dependencias, contenedores y servicios locales están aprobados? ¿Puede otra persona reproducir la configuración? ¿Están adecuadamente separados los datos y las credenciales de desarrollo, pruebas, staging y producción?
- Operaciones y responsabilidades. ¿Quién supervisa la aplicación, controla sus costes, actualiza sus dependencias, responde ante los fallos y la mantiene cuando su creador deja de trabajar en ella?
También hay decisiones sobre la experiencia que reciben las personas. Dos aplicaciones pueden funcionar correctamente y, aun así, presentar interfaces contradictorias, calcular de forma diferente la misma métrica de negocio o mantener versiones enfrentadas del mismo registro de cliente.
Además, las políticas de la empresa se aplican durante todo el proceso. Una política de uso de IA puede determinar qué herramientas y cuentas están aprobadas. Los requisitos de privacidad influyen en qué datos pueden introducirse en prompts, registros, capturas de pantalla y evidencias de pruebas. Las reglas de acceso determinan qué sistemas puede leer o modificar una persona —o un agente que actúe en su nombre—.
Estas responsabilidades se mantienen incluso a medida que mejora la generación de código.
De hecho, podemos defender este argumento sin debatir si la IA escribe buen código: aunque cada línea generada fuera correcta, estas preguntas seguirían necesitando respuestas.
Dar contexto a la IA
Codex y Claude Code pueden ayudar con gran parte de este trabajo. Un agente puede inspeccionar una arquitectura existente, preparar un cambio en la base de datos, trabajar en una rama, ejecutar pruebas, documentar evidencias y actualizar un issue.
Pero necesita el contexto de la empresa. Una solicitud para «crear un panel de clientes» no explica por sí sola qué sistema de clientes es la fuente de verdad, qué campos son sensibles ni qué aprobación se requiere antes del lanzamiento.
Lo mismo se aplica a desarrolladores experimentados que se incorporan a una organización desconocida. La capacidad técnica y el conocimiento institucional son cosas distintas. Ambas importan.
La parte alentadora es que este conocimiento puede formar parte del entorno de desarrollo.
Codex admite instrucciones de proyecto compartidas mediante AGENTS.md. Claude Code admite orientación persistente mediante CLAUDE.md. Las skills, los plugins personalizados y las integraciones pueden proporcionar flujos de trabajo reutilizables y acceso a los sistemas donde se registra el trabajo.
En lugar de explicar repetidamente cómo desarrolla software la empresa, los equipos pueden mantener la orientación junto al propio software: qué componentes reutilizar, cómo probar un cambio, dónde colocar las evidencias y qué debe ocurrir antes de considerar completo un issue.
Respaldar las instrucciones con controles
Una instrucción que indique a un agente que evite los datos de producción debe estar respaldada por credenciales y permisos que restrinjan el acceso. Un requisito de ejecutar pruebas debe contar con comprobaciones de lanzamiento. Los entornos aprobados deberían facilitar la reproducción de la configuración esperada.
La documentación de Claude Code distingue explícitamente entre las instrucciones que guían el comportamiento y los permisos que controlan las acciones. Esta distinción es esencial para establecer un entorno de desarrollo fiable en la empresa.
Las personas también necesitan comprender con claridad sus responsabilidades. La libertad para experimentar puede ser amplia, mientras que el acceso a información sensible y la autoridad para publicar cambios dependen del rol de cada persona y de las consecuencias de la aplicación.
Los ingenieros experimentados siguen siendo fundamentales en este modelo. Su criterio da forma a la arquitectura, establece los controles, revisa los cambios importantes y convierte las lecciones de proyectos individuales en cimientos que otros pueden reutilizar.
Cómo ayuda Guanta
En Guanta, ayudamos a las empresas a construir ese entorno en torno al desarrollo asistido por IA.
El trabajo comienza con la organización: sus sistemas, datos, políticas, equipos y responsabilidades operativas. A partir de ahí, reunimos orientación para el desarrollo, componentes reutilizables, integraciones, entornos controlados y flujos de trabajo que conectan una solicitud de negocio con un resultado verificable.
El objetivo es convertir los estándares de la empresa en parte de la forma en que se realiza el trabajo, para que las personas puedan dedicar más tiempo a resolver problemas útiles con IA.
Así es como una participación más amplia se vuelve sostenible. Alguien con una buena idea debería poder explorarla, construir sobre cimientos existentes y seguir un camino claro hacia algo que la organización pueda respaldar.
La promesa de que «cualquiera puede programar» merece hacerse realidad.
Ofréceles una cocina diseñada para ello.