Un freno inesperado al vibe coding en Wall Street
Goldman Sachs ha decidido dar un paso atrás en uno de los experimentos internos más comentados de la banca de inversión durante 2026. Según reportes publicados el 2 de noviembre, el banco estadounidense limitó el acceso a las herramientas avanzadas de programación asistida por inteligencia artificial, entre ellas Claude Code, de Anthropic, y los productos de GitHub, propiedad de Microsoft, incluido Copilot. La restricción afecta a la mayoría de sus traders y banqueros, que hasta hace poco podían usar esos asistentes para construir pequeñas aplicaciones, scripts y prototipos por su cuenta. A partir de ahora, el uso queda concentrado en los ingenieros de software y en un grupo acotado de perfiles híbridos.
El cambio quedó reflejado en una guía interna que, de acuerdo con la información conocida esta semana, se actualizó en octubre. La entidad sostiene que antes de tomar la decisión revisó tanto la productividad obtenida como los riesgos asociados al uso de estas herramientas por parte de personal sin formación técnica formal. El resultado de esa evaluación ha sido un recorte claro: los asistentes de código vuelven a ser, principalmente, cosa de ingenieros.
La noticia tiene un peso simbólico considerable. Durante meses, Goldman Sachs fue presentado como uno de los ejemplos más visibles de cómo una gran institución financiera podía abrazar el llamado vibe coding, esa forma de programar describiendo en lenguaje natural lo que se quiere obtener y dejando que un modelo de lenguaje genere el código. El giro llega apenas unos cuatro meses después de que el propio director de sistemas de información del banco elogiara en público lo que estaban construyendo los empleados que no eran ingenieros. Lo que entonces parecía una apuesta decidida por democratizar el desarrollo de software ahora se reajusta bajo la lógica del control, el cumplimiento normativo y la gestión del riesgo.
Del entusiasmo a la evaluación: cómo se llegó hasta aquí
Para entender la decisión conviene reconstruir el recorrido. Durante buena parte del año, el banco permitió que banqueros y traders utilizaran asistentes de programación de última generación. La idea de fondo era sencilla y atractiva: el personal de negocio, que conoce de primera mano los problemas de los clientes y del mercado, podía construir prototipos rápidos de herramientas útiles para su día a día. Después, los equipos de ingeniería tomarían esos prototipos y los convertirían en aplicaciones robustas, revisadas y aptas para producción.
Ese modelo, que en la jerga empresarial se asocia a los llamados desarrolladores ciudadanos, prometía acortar el ciclo entre una necesidad detectada en la mesa de operaciones y una solución técnica. En lugar de redactar un requerimiento, esperar a que un equipo de tecnología lo priorizara y después iterar durante semanas, un trader podía presentar algo funcional en cuestión de horas. Para los ingenieros, la ventaja teórica era recibir especificaciones vivas, ya probadas en el terreno, en lugar de documentos abstractos.
Los usos concretos que se conocieron muestran hasta dónde había llegado la adopción. Según los reportes, algunos traders utilizaban estas herramientas para monitorizar los flujos de operaciones de clientes, modelar movimientos de mercado y cambios en las posiciones, y producir contenido escrito y visual. No se trata de tareas menores: son actividades cercanas al núcleo del negocio de una mesa de trading, donde la rapidez para interpretar información puede marcar diferencias.
Precisamente por esa cercanía al corazón del negocio, la evaluación interna adquirió otra dimensión. Una herramienta que ayuda a resumir un informe tiene un perfil de riesgo; una que procesa datos de flujos de clientes o modela posiciones tiene otro muy distinto. El banco decidió que la balanza entre productividad y riesgo, al menos para la mayoría del personal de negocio, no justificaba mantener el acceso abierto.
Qué cambia exactamente con la nueva guía interna
La actualización de octubre establece una frontera más nítida entre quién puede usar los asistentes avanzados de programación y quién no. La regla general es que la mayoría de traders y banqueros pierde el acceso. La excepción relevante son los empleados cuyos roles combinan trading, investigación cuantitativa e ingeniería de software, perfiles que en la cultura de Goldman Sachs se conocen tradicionalmente como strats.
Esta excepción no es casual. Los strats ocupan desde hace años un lugar particular dentro del banco: son profesionales con formación cuantitativa y técnica que trabajan codo con codo con las mesas de negocio, construyen modelos y herramientas, y suelen estar sometidos a los mismos procesos de control de código que el resto del área de ingeniería. Mantenerles el acceso equivale a reconocer que la herramienta no es el problema en sí misma, sino quién la utiliza, con qué formación y bajo qué marco de supervisión.
En la práctica, la medida reconfigura el flujo de trabajo que el banco había incentivado. Los traders que construían sus propias utilidades tendrán que volver a canalizar sus necesidades a través de los equipos técnicos o de los strats. Para algunos, eso supone perder una autonomía recién adquirida. Según los reportes, la decisión ha generado frustración entre parte de los traders, que veían en estas herramientas una forma de ganar velocidad frente a competidores y de reducir la dependencia de colas de trabajo tecnológicas.
El antecedente de Hong Kong y la preocupación por los datos
La restricción actual no surge de la nada. A comienzos de 2026, el banco ya había limitado el uso de Claude para su personal en Hong Kong. El motivo, según se informó entonces, era la preocupación de que información confidencial saliera de la firma a través de servicios de inteligencia artificial operados por terceros.
Ese episodio ofrece una pista importante sobre las prioridades de la entidad. En la banca de inversión, los datos son el activo más sensible: posiciones de clientes, órdenes pendientes, estrategias, información no pública sobre operaciones corporativas. Cualquier canal por el que esa información pueda abandonar el perímetro controlado de la empresa se convierte en un asunto de máxima atención para los equipos de seguridad, cumplimiento y riesgo.
Las herramientas de programación con IA funcionan, en la mayoría de sus configuraciones, enviando contexto a un modelo alojado en infraestructura externa. Ese contexto puede incluir fragmentos de código, nombres de tablas, estructuras de datos y, si el usuario no es cuidadoso, datos reales. Los proveedores ofrecen versiones empresariales con compromisos contractuales sobre retención y uso de la información, pero el riesgo de fuga de datos no depende solo de lo que firme el proveedor, sino también de lo que el usuario decida pegar en una ventana de conversación o exponer a un agente con acceso al sistema de archivos.
Cuando el usuario es un ingeniero formado en prácticas de seguridad, sometido a revisiones de código y a herramientas de análisis automático, la exposición se gestiona de una manera. Cuando el usuario es un profesional de negocio que trabaja con presión de tiempo y con acceso directo a información de clientes, el perfil cambia. La decisión de octubre parece leer ese contraste.
Vibe coding: la promesa y sus límites
El término vibe coding se popularizó en 2025 para describir una manera de programar en la que la persona describe la intención y deja que la IA escriba el código, a menudo sin leerlo línea por línea. Su atractivo es evidente: reduce drásticamente la barrera de entrada al desarrollo de software y permite que personas sin formación técnica construyan herramientas funcionales. El fenómeno ya generaba debate desde sus inicios, como recogimos en el vibe coding que sacudió 2025.
Los asistentes agénticos como Claude Code llevaron esa idea un paso más allá. Ya no se trata solo de autocompletar funciones, como hacían las primeras versiones de Copilot, sino de agentes capaces de leer un proyecto completo, ejecutar comandos, crear archivos, instalar dependencias y proponer cambios de gran alcance. En manos expertas, multiplican la productividad. En manos inexpertas, pueden producir software que funciona en apariencia, pero cuyo comportamiento real nadie del equipo entiende por completo.
En sectores poco regulados, ese riesgo suele ser aceptable. Una startup que prototipa una herramienta interna puede permitirse errores, corregirlos sobre la marcha y aprender. En la banca, el cálculo es diferente. Una utilidad que calcula mal una exposición, que muestra un dato de cliente a quien no debería verlo o que alimenta una decisión de trading con una lógica defectuosa puede tener consecuencias regulatorias, reputacionales y financieras.
Los defensores del modelo argumentan que la alternativa, prohibir o restringir, empuja a los empleados hacia soluciones no autorizadas. Los críticos responden que el código sin revisión técnica en entornos regulados no es una innovación, sino una deuda que alguien terminará pagando. Ambas posturas tienen argumentos sólidos, y la decisión de Goldman Sachs se sitúa claramente del lado de la cautela, sin renunciar del todo a la tecnología.
Shadow IT: un viejo conocido con nueva apariencia
El debate que reabre esta noticia no es nuevo para los departamentos de tecnología. Desde hace décadas, las grandes organizaciones conviven con lo que se conoce como shadow IT: hojas de cálculo críticas con macros que nadie documenta, bases de datos de escritorio que se convierten en sistemas de registro de facto, scripts que un analista escribió hace años y de los que depende un proceso entero.
La banca conoce bien los peligros de ese fenómeno. Los modelos financieros construidos en hojas de cálculo han estado en el centro de errores costosos en distintas instituciones a lo largo de los años, y los reguladores han insistido repetidamente en la necesidad de inventariar, validar y controlar las herramientas desarrolladas por usuarios finales, conocidas en el sector como EUC, por sus siglas en inglés.
La IA generativa cambia la escala del problema. Antes, construir una herramienta compleja requería cierta habilidad técnica, lo que actuaba como filtro natural. Hoy, cualquiera con acceso a un asistente avanzado puede generar en una tarde una aplicación con interfaz, conexión a fuentes de datos y lógica de negocio. Si esa aplicación escapa a los inventarios y a los controles, el shadow IT deja de ser un conjunto de hojas de cálculo dispersas para convertirse en un ecosistema de software paralelo.
Desde esa perspectiva, la restricción del banco puede leerse como un intento de evitar que el entusiasmo por la productividad genere un parque de aplicaciones no gobernadas difícil de auditar. El hecho de que la idea original fuera que los ingenieros tomaran los prototipos y los llevaran a producción sugiere que el banco era consciente de ese riesgo desde el principio. Lo que la evaluación posterior parece haber concluido es que el control de ese tránsito no resultaba suficiente.
Riesgo de modelo: la otra cara del problema
En la industria financiera existe una disciplina específica dedicada a gestionar los peligros de que un modelo cuantitativo produzca resultados erróneos o se use de forma inadecuada. Se conoce como gestión del riesgo de modelo y, en Estados Unidos, tiene como referencia la guía supervisora SR 11-7 de la Reserva Federal, publicada en 2011, que exige a los bancos inventariar sus modelos, validarlos de forma independiente y documentar su uso.
Cuando un trader utiliza un asistente de IA para modelar movimientos de mercado o cambios de posición, el resultado puede caer dentro de la definición amplia de modelo que manejan los reguladores. Si esa herramienta influye en decisiones, debería estar sometida a validación. Si nadie sabe que existe, la validación nunca ocurre.
A eso se suma una capa adicional: el propio modelo de lenguaje que genera el código. Los equipos de riesgo deben preguntarse no solo si la herramienta construida es correcta, sino también si el proceso por el que se construyó es reproducible y explicable. Un script generado por IA puede contener supuestos implícitos, manejos de casos límite poco evidentes o dependencias externas que nadie revisó. Para un regulador, la explicación de que una herramienta la escribió un asistente y funcionaba bien difícilmente resulta satisfactoria.
En Europa, el marco regulatorio también presiona en esa dirección. El Reglamento de Resiliencia Operativa Digital, conocido como DORA, aplicable desde enero de 2025, obliga a las entidades financieras a gestionar con rigor sus riesgos tecnológicos y los derivados de proveedores externos de tecnología. Un banco global como Goldman Sachs opera bajo varias jurisdicciones a la vez, y cada herramienta de terceros que se integra en sus flujos de trabajo multiplica las obligaciones de supervisión.
Las dos posturas del debate
La decisión ha sido recibida de forma desigual, y conviene presentar los argumentos de cada lado con equilibrio.
Quienes respaldan la restricción subrayan varios puntos. El primero es la protección de la información de los clientes, que en la banca no es negociable. El segundo es la trazabilidad: en una industria sometida a auditorías constantes, cada herramienta que interviene en una decisión debe poder explicarse. El tercero es la calidad del software: el código que llega a producción en una entidad sistémica debe pasar por revisiones, pruebas y controles que un usuario de negocio no está en condiciones de aplicar por sí solo. Según esta visión, la medida no es un rechazo a la IA, sino una reorganización de quién la usa y cómo.
Quienes la critican ponen el foco en el coste de oportunidad. Las mesas de trading compiten en velocidad e información, y limitar herramientas que permiten a los profesionales automatizar análisis puede restar competitividad. Además, argumentan, la experiencia demuestra que las prohibiciones rara vez eliminan la demanda: si los empleados encuentran valor en una herramienta, buscarán alternativas, y esas alternativas pueden ser menos seguras que una versión empresarial controlada. La frustración reportada entre parte de los traders apunta en esa dirección.
Existe también una posición intermedia, que probablemente refleja el pensamiento de muchos responsables de tecnología del sector. Según esta lectura, el error no estaba en permitir el uso de herramientas de programación con IA al personal de negocio, sino en hacerlo sin un marco completo de guardarraíles: entornos aislados, datos sintéticos, revisión obligatoria, inventario automático de lo que se construye. Restringir sería entonces una pausa razonable mientras se diseña ese marco, más que una decisión definitiva.
Qué significa para los ingenieros de software
Para los ingenieros del banco, y por extensión para los de cualquier gran organización regulada, la noticia contiene varios mensajes. Para quien quiera conocer la herramienta en cuestión, nuestra guía de Claude Code para principiantes desde la terminal explica su funcionamiento básico.
El primero es que su papel como guardianes de la calidad y la seguridad del software se refuerza. Durante 2025 y 2026 se ha extendido el discurso de que la IA reduciría la necesidad de ingenieros, al permitir que cualquiera construya aplicaciones. La decisión de Goldman Sachs matiza ese relato: en entornos donde el error cuesta caro, la figura del profesional capaz de entender, revisar y responsabilizarse del código sigue siendo central.
El segundo mensaje es que el trabajo de los ingenieros cambia de naturaleza. Si el modelo original preveía que los prototipos de negocio llegaran a ingeniería para su industrialización, los equipos técnicos debían convertirse en algo parecido a editores: tomar código generado por terceros con ayuda de IA, evaluarlo, reescribirlo cuando fuera necesario y llevarlo a estándares de producción. Ese rol exige habilidades de lectura de código, arquitectura y seguridad tanto o más que de escritura.
El tercero es una advertencia sobre la carga de trabajo. Si los usuarios de negocio generan prototipos a gran velocidad y todos aspiran a llegar a producción, el cuello de botella se traslada a ingeniería. Una parte de la evaluación de productividad que el banco dice haber realizado probablemente tuvo en cuenta esa dinámica: el beneficio de prototipar rápido se diluye si después los ingenieros deben dedicar tiempo considerable a revisar o rehacer lo construido.
Para los profesionales que se mueven entre ambos mundos, el mensaje es todavía más claro. La excepción para los strats demuestra el valor de los perfiles híbridos que combinan conocimiento del negocio, base cuantitativa y competencia técnica real. Son precisamente quienes pueden aprovechar la IA con mayor seguridad, porque entienden tanto el problema como el código que lo resuelve.
El papel de los equipos de plataforma
Más allá de los ingenieros que escriben aplicaciones, la noticia interpela a los equipos de plataforma, responsables de ofrecer al resto de la organización entornos, herramientas y servicios internos sobre los que construir.
En muchas empresas, la adopción de asistentes de IA ha ido por delante de la infraestructura necesaria para gobernarlos. Las licencias se distribuyen con rapidez, pero los mecanismos de control llegan después: registros de uso, políticas de qué datos pueden enviarse a un modelo externo, entornos de ejecución aislados para agentes que pueden lanzar comandos, integración con sistemas de gestión de identidades y permisos.
Una lectura constructiva del caso es que la democratización del desarrollo requiere una plataforma preparada para ello. Si un banco quiere que sus traders prototipen con IA, necesita ofrecerles espacios donde los datos de clientes no estén accesibles por defecto, donde el código generado quede registrado automáticamente y donde el paso a producción exija una revisión formal. Construir esa plataforma es un proyecto de ingeniería en sí mismo, y probablemente más complejo que repartir licencias.
Los equipos de plataforma también deben gestionar la relación con proveedores. Las herramientas afectadas por la restricción pertenecen a dos de los actores más relevantes del mercado de IA aplicada al desarrollo. Cada uno ofrece sus propias garantías empresariales, sus propios mecanismos de administración y sus propias formas de integración. Coordinar todo ello bajo un único marco de gobierno, coherente con las exigencias regulatorias de varias jurisdicciones, es uno de los retos técnicos menos visibles y más importantes del momento.
Un fenómeno que trasciende a un solo banco
Aunque la noticia se centra en Goldman Sachs, el dilema es compartido por buena parte del sector financiero y, en general, por cualquier industria regulada: sanidad, seguros, energía, administración pública. Todas enfrentan la misma tensión entre la presión por adoptar IA para ganar productividad y la obligación de mantener el control sobre datos, procesos y decisiones. La decisión llega, además, en un momento delicado para Anthropic, que acaba de presentar su S-1 de cara a su salida a bolsa.
En los últimos años, distintas entidades financieras han adoptado posturas variadas frente a la IA generativa, desde restricciones generalizadas en las primeras etapas hasta despliegues amplios de asistentes internos construidos sobre modelos comerciales. La tendencia general ha sido avanzar desde la prohibición inicial hacia una adopción controlada, con versiones empresariales y políticas de uso detalladas. Lo que hace singular el caso actual es que el movimiento va en la dirección contraria: de una apertura amplia a una restricción selectiva.
Ese retroceso parcial puede interpretarse como señal de madurez. Las organizaciones están pasando de la fase de experimentación, en la que el objetivo es descubrir qué es posible, a una fase de consolidación, en la que la pregunta es qué resulta sostenible. En esa transición, es razonable que algunas aperturas se revisen y que los permisos se ajusten a los perfiles que mejor pueden aprovecharlos con seguridad.
También es una señal para los proveedores de herramientas. Si los clientes más exigentes restringen el uso por parte de usuarios no técnicos, la presión se trasladará hacia funcionalidades de gobierno más sofisticadas: controles granulares por rol, entornos aislados, auditoría completa de las acciones de los agentes y mecanismos para impedir que datos sensibles salgan del perímetro. La competencia en el mercado empresarial no se decidirá solo por la calidad del código generado, sino por la capacidad de encajar en marcos de cumplimiento estrictos.
Lecciones para empresas que quieren democratizar el desarrollo
El caso deja enseñanzas aplicables a cualquier organización que esté considerando abrir las herramientas de programación con IA a perfiles no técnicos.
La primera es definir desde el principio el ciclo de vida de lo que se construye. Un prototipo creado por un usuario de negocio debe tener un destino claro: o se descarta tras cumplir su función exploratoria, o entra en un proceso formal de revisión e industrialización. Lo que no debería ocurrir es que permanezca indefinidamente en un limbo, usado en operaciones reales sin haber pasado por los controles necesarios.
La segunda es separar entornos y datos. Muchos de los riesgos asociados a los desarrolladores ciudadanos se reducen si trabajan con datos de prueba o anonimizados y en entornos que no tienen acceso directo a sistemas de producción. Esto exige inversión en plataforma, pero reduce de forma significativa la exposición.
La tercera es medir la productividad de manera honesta. Las ganancias aparentes en la fase de prototipado pueden verse compensadas por costes posteriores en revisión, corrección y mantenimiento. Goldman Sachs afirma haber evaluado la productividad junto al riesgo antes de tomar su decisión; cualquier empresa que se plantee iniciativas similares debería hacer lo mismo con métricas que abarquen el ciclo completo, no solo la velocidad inicial.
La cuarta es la formación. Abrir herramientas potentes sin un programa de capacitación en seguridad, privacidad y buenas prácticas de software equivale a delegar el control en el criterio individual de cada empleado. Incluso los perfiles más brillantes del negocio pueden desconocer riesgos que para un ingeniero son evidentes.
La quinta es la comunicación interna. Una restricción que llega tras meses de entusiasmo público puede generar desconcierto y frustración, como ha ocurrido con parte de los traders. Explicar los motivos, ofrecer alternativas y fijar criterios claros para recuperar el acceso ayuda a que la medida se perciba como una decisión de gestión y no como un castigo.
Gobierno de TI frente a innovación descentralizada
En el fondo, la noticia vuelve a poner sobre la mesa una tensión clásica del mundo corporativo: el equilibrio entre el control centralizado y la innovación que surge desde los equipos. El gobierno de TI en sectores regulados siempre ha estado diseñado para minimizar riesgos, lo que a menudo se traduce en procesos lentos y en una cierta resistencia al cambio. La IA generativa prometía romper esa inercia permitiendo que las ideas se materializaran sin pasar por los canales tradicionales.
Lo que muestra el caso es que la tecnología, por sí sola, no elimina la necesidad de esos canales. Puede acelerarlos, hacerlos más eficientes y reducir la fricción, pero no sustituir la responsabilidad que tiene una institución financiera sobre el software que utiliza. Los modelos de lenguaje no responden ante un regulador; los bancos, sí.
Al mismo tiempo, un exceso de control puede tener costes reales. Si los empleados más innovadores perciben que sus herramientas les son retiradas sin alternativas, pueden perder motivación o buscar entornos más flexibles. La competencia por el talento en las finanzas es intensa, y la disponibilidad de herramientas modernas forma parte del atractivo de un empleador. Encontrar el punto de equilibrio será una de las tareas de gestión más delicadas en los próximos años.
La figura del desarrollador ciudadano, en revisión
El concepto de desarrollador ciudadano lleva años circulando en el mundo empresarial, asociado inicialmente a plataformas de bajo código y sin código. La idea era que empleados de áreas de negocio pudieran construir aplicaciones sencillas mediante interfaces visuales, sin escribir código tradicional, y siempre dentro de plataformas que ofrecían cierto nivel de gobierno incorporado.
La llegada de los asistentes de IA cambió esa ecuación. Los desarrolladores ciudadanos en banca y en otros sectores ya no están limitados a plataformas visuales con reglas predefinidas: pueden generar código real, en lenguajes de propósito general, con capacidad para conectarse a prácticamente cualquier sistema. Eso amplía enormemente lo que pueden construir, pero también elimina las barreras de seguridad que las plataformas de bajo código incorporaban por diseño.
La decisión de Goldman Sachs sugiere que, al menos en las instituciones más reguladas, el desarrollador ciudadano equipado con IA necesita un marco distinto al que funcionaba con las herramientas de bajo código. No basta con abrir la puerta: hace falta diseñar el espacio en el que se trabaja, los límites de lo que se puede tocar y el camino que debe recorrer cualquier creación antes de influir en una operación real.
Situación actual de la historia
Al momento de escribir esta noticia, la guía interna actualizada en octubre está en vigor y la mayoría de traders y banqueros de Goldman Sachs ya no tiene acceso a las herramientas avanzadas de programación con IA, entre ellas Claude Code y los productos de GitHub, incluido Copilot. Los ingenieros de software conservan el acceso, al igual que los empleados cuyos roles combinan trading, investigación cuantitativa e ingeniería, los perfiles conocidos como strats.
El banco ha defendido que la decisión se tomó tras revisar la productividad obtenida y los riesgos asociados. No se han hecho públicos detalles adicionales sobre los criterios de esa evaluación ni sobre si la restricción tiene carácter temporal o definitivo. Tampoco se ha informado de un calendario para una eventual reapertura del acceso con nuevos controles.
Entre el personal afectado, según los reportes, la medida ha causado frustración en una parte de los traders que habían incorporado estas herramientas a tareas como el seguimiento de flujos de clientes, la modelización de movimientos de mercado y la elaboración de contenidos. La restricción se suma a la limitación aplicada a comienzos de año al personal de Hong Kong en relación con Claude, motivada por la preocupación sobre la posible salida de información confidencial a través de servicios de terceros.
El contraste con el tono de hace unos meses, cuando la dirección tecnológica del banco destacaba públicamente lo que estaban construyendo los empleados sin perfil de ingeniería, es uno de los elementos que más atención ha despertado en el sector. La historia queda abierta: el modo en que el banco gestione en adelante el equilibrio entre productividad y control servirá de referencia para otras entidades que afrontan el mismo dilema.
Conclusiones
La restricción aplicada por Goldman Sachs no es un rechazo a la inteligencia artificial, sino una corrección en la forma de desplegarla. El banco mantiene las herramientas de programación con IA en manos de sus ingenieros y de sus perfiles híbridos, mientras las retira a la mayoría de traders y banqueros tras evaluar productividad y riesgo. La decisión llega después de un periodo de apertura que había convertido a la entidad en ejemplo del vibe coding corporativo.
El caso ilustra con claridad las tensiones que atraviesan a los sectores regulados: protección de datos de clientes, trazabilidad de las herramientas que influyen en decisiones, gestión del riesgo de modelo y control sobre el código que llega a producción. Frente a ellas, los defensores de la democratización del desarrollo recuerdan el coste de perder velocidad y el riesgo de empujar a los empleados hacia soluciones no autorizadas. Ambas posturas tienen fundamento, y el equilibrio entre ellas dista de estar resuelto.
Para los ingenieros de software, la noticia refuerza el valor de su papel como responsables de la calidad, la seguridad y la sostenibilidad del software, y subraya la importancia de los perfiles que combinan conocimiento del negocio con competencia técnica. Para los equipos de plataforma, plantea el reto de construir entornos donde la experimentación sea posible sin comprometer datos ni procesos. Y para las empresas en general, deja una lección clara: abrir la puerta a la programación asistida por IA exige diseñar antes el camino que recorrerá todo lo que se construya, desde el primer prototipo hasta su eventual llegada a producción.