Por primera vez en mucho tiempo, me cuesta muchísimo predecir cómo va a impactar la IA en el negocio de la tecnología. Hay dos grandes motivos. Primero, la IA avanza tan rápido que la mayoría de las predicciones quedan desactualizadas en cuestión de meses. Segundo, «IT» llega a tantos rincones de la sociedad que en realidad es un conjunto de negocios distintos cuyo único hilo común es un fuerte componente tecnológico.
Aun así, creo que podemos trazar algunas líneas que ayuden a quienes trabajamos en tecnología a entender cómo podría ser el futuro cercano y a prepararnos para lo que viene. En este artículo me centro en el desarrollo de software. Puede que más adelante escriba sobre otras áreas, como staffing, IoT o hardware.
Los equipos de negocio están construyendo sus propias herramientas
En los últimos seis meses he visto pruebas claras, en BairesDev y en muchas otras grandes empresas, de que los equipos de negocio están resolviendo por su cuenta sus necesidades de aplicaciones, flujos de trabajo y herramientas internas. En la práctica, se están saltando a los equipos tradicionales de I+D.
No se trata de una rivalidad mezquina. Es el resultado de expectativas que la industria del software lleva sin poder cumplir desde que tengo memoria.
Lo que dicen los equipos de negocio
Si les preguntas a los equipos de negocio, normalmente vas a escuchar alguna versión de esto:
- I+D es demasiado lento, demasiado rígido o está demasiado lejos del negocio. Cualquiera que haya trabajado en esta industria ha escuchado esta queja de una forma u otra.
- Sus necesidades no se priorizan. Cuando un equipo de I+D atiende a varias unidades de negocio, unas pocas suelen acaparar casi toda su atención.
- Es demasiado caro, y el coste real es difícil de ver al principio. Sobre todo el coste de operar la solución una vez construida.
Lo que dicen los equipos de I+D
Para ser justos, los equipos de I+D también tienen su versión de la historia, y es igual de real:
- Los equipos de negocio no saben realmente lo que necesitan hasta que ven una primera versión.
- Los equipos de negocio no entienden la parte de seguridad. Se centran en las funcionalidades y se olvidan de cosas como roles, permisos y auditoría. Todo eso hay que construirlo igualmente en el producto, pero desde el lado del negocio parece «burocracia».
- Iterar cuesta dinero. Cada ronda de cambios sube el precio y alarga los plazos. Y cuando I+D intenta evitarlo con un proceso más formal, como requisitos detallados desde el principio, al negocio eso también le parece burocracia.
Vibe-coding: prometedor, pero arriesgado
El resultado es que los equipos de negocio de todas partes están pasando a un modelo más de autoservicio. Acuden a I+D solo para soluciones por encima de cierto nivel de complejidad y resuelven todo lo demás por su cuenta con «vibe-coding»: le describen a una herramienta de IA lo que quieren y dejan que ella escriba el código.
Los resultados varían mucho. Dependen de las habilidades técnicas del equipo, de la complejidad de la tarea, de si están disponibles los datos adecuados y, muchas veces, de la pura suerte. Y como las buenas prácticas de seguridad suelen brillar por su ausencia, la industria ha visto unos cuantos pilotos costosos que acabaron exponiendo datos sensibles o siendo hackeados. En el mejor de los casos, terminas con aplicaciones que no acaban de funcionar e ignoran las directrices y políticas de la empresa, que es justamente lo que los equipos de I+D se enorgullecen de incorporar en sus procesos.
Mi propuesta: I+D construye la plataforma, no las aplicaciones
Entonces, ¿podemos cerrar esa brecha? Llevo un tiempo pensándolo y estoy convencido de que, con las herramientas de IA actuales, tiene sentido difuminar la línea entre negocio e I+D. Bien hecho, eso resuelve, o al menos reduce mucho, los problemas de los que se quejan ambos lados.
En la práctica, esto significa dos cosas:
- I+D se centra en construir y mantener herramientas de IA que los equipos de negocio puedan usar.
- El resto de la capacidad de I+D se integra directamente en los equipos de negocio para impulsar esas herramientas.
El trabajo de I+D sería construir las herramientas (agentes, frameworks, capas de acceso a datos, etc.) que garanticen que los equipos de negocio sigan las prácticas de seguridad adecuadas, manteniéndolo todo accesible en lenguaje natural. Esas mismas herramientas darían coherencia a las aplicaciones creadas por distintas unidades de negocio: interfaces de usuario, permisos, acceso a datos, autenticación y auditoría.
Dicho de otro modo, el papel principal de I+D sería permitir que los equipos de negocio construyan su propio software y sus procesos con la menor intervención directa posible de I+D, sin salirse de unos límites aceptables en prácticas de ingeniería, seguridad y coherencia. I+D también mantendría un catálogo de aplicaciones e iniciativas, para que distintos equipos no terminen construyendo lo mismo dos veces.
Qué cambia para los equipos
Esto no tiene por qué cambiar la plantilla, pero sí cambia cómo trabajan los equipos y de qué son responsables.
Para I+D, significa pasar de construir aplicaciones a construir herramientas y frameworks. Las personas de I+D más cercanas al negocio, como analistas y project managers, encajarían mejor dentro de los equipos de negocio.
Para los equipos de negocio, significa asumir el reto de construir sus propias aplicaciones con las herramientas de I+D. Para lograrlo, deberían incorporar a los ingenieros que I+D ya no necesita y usarlos como «forward deployed engineers»: perfiles técnicos integrados en el equipo que conectan lo que sabe el negocio con el conocimiento técnico necesario para sacarles el máximo partido a las herramientas.
El tiempo dirá
Esta es mi propuesta tal como están las cosas hoy. Voy a seguir de cerca cómo evoluciona y compartiré lo que aprenda. Si estás viendo algo parecido en tu empresa, o algo completamente distinto, me encantaría que me lo contaras.
