Construir productos impulsados por inteligencia artificial generativa es mucho más que dominar una tecnología. La clave está en enamorarse del problema, no de la solución, y en gestionar las cargas cognitivas de los equipos para que cada persona aporte desde su mejor capacidad. Esta charla comparte errores reales, aprendizajes prácticos y un marco de trabajo para organizar equipos que desarrollan productos con Gen AI.
¿Por qué enamorarse del problema y no de la tecnología?
Antes de que ChatGPT sonara con fuerza, ya existían equipos con más de treinta y cinco proyectos de inteligencia artificial en producción. Procesamiento del lenguaje natural con PyTorch, sistemas de recomendaciones con seis algoritmos complejos, buscadores basados en el algoritmo de vecinos más cercanos (KNN) con Elasticsearch [01:28]. Todo funcionaba, pero había un error fundamental: el enfoque era técnico, centrado en aprender la tecnología y no en resolver un dolor real del usuario [02:12].
La primera recomendación es clara: identificar los pains del usuario y resolverlos sin sobreingeniería. No hace falta montar Kubernetes para un MVP. Hay que abrazar las imperfecciones a favor de la velocidad en tiempos de incertidumbre, un concepto conocido como blitzscaling [02:55]. En esta etapa inicial, el rol protagonista es el AI engineer, esa persona que consume APIs de modelos, entiende frameworks como LangChain y construye la primera versión funcional.
¿Cómo construir bases sólidas después del MVP?
Una vez que el producto entrega valor, llega el momento de apuntarle a tres pilares: seguridad, operaciones y métricas [03:35].
- Seguridad: el OWASP Top Ten para LLMs incluye amenazas como el prompt injection, donde un prompt manipulado puede extraer información que el sistema no debería mostrar [03:47].
- Operaciones: si OpenAI se cae, o AWS Bedrock deja de responder, ¿qué pasa? La respuesta fue crear un AI Gateway con fallback y detección automática para balancear proveedores y garantizar la experiencia del usuario [04:10].
- Métricas y evaluadores: medir qué tan precisa es la salida del modelo respecto al objetivo planteado resulta indispensable para iterar y mejorar [04:30].
En esta segunda etapa los roles se amplían. Ya no basta con el AI engineer: entran el equipo de plataforma (infraestructura), los data engineers que gestionan bases de datos vectoriales como Pinecone o PG Vector, y los Security Champions, un equipo de seguridad extendido que permea toda la organización [04:50].
¿Qué diferencia hay entre AI engineer, data scientist y ML engineer?
Las definiciones de roles se solapan y generan confusión. El data scientist se enfoca en análisis de datos y estrategias orientadas a data, combinando estadística con programación [07:20]. El machine learning engineer se concentra en teoría de ML, algoritmos y despliegue de modelos en producción [07:50]. El AI engineer, en cambio, abarca programación, procesamiento de lenguaje natural, redes neuronales, cloud computing, seguridad y hasta experiencia de usuario [08:05].
El problema es que estas job descriptions terminan pidiendo un perfil imposible, como aquella oferta que exigía más de cuatro años de experiencia en FastAPI cuando su propio creador, Sebastián Ramírez, no cumplía ese requisito [08:35].
¿Qué es la gestión de cargas cognitivas y por qué importa?
Imagina que te piden estudiar alemán, mandarín y árabe al mismo tiempo. Colapsas. Eso mismo ocurre en los equipos de desarrollo [09:05]. Existen tres tipos de carga cognitiva:
- Intrínseca: lo que necesitas aprender para tu trabajo diario. Se ataca con formación.
- Foránea o extraña: conocimiento que no forma parte de tu core, como entender stateful sets de Kubernetes siendo desarrollador backend. Se minimiza con herramientas.
- Germane: donde se genera el mayor impacto. Es el estado de enfoque profundo donde el equipo crea su mejor trabajo [10:05].
El error fue creer que todo el equipo de ingeniería debía desarrollar productos de AI en profundidad. Una cosa es usar AI y entender cómo funciona, y otra muy distinta es pretender que todos optimicen modelos mientras atienden el desarrollo de features funcionales [10:40].
¿Cómo organizar equipos con domain-driven design y team topologies?
La recomendación principal combina domain-driven design con Team Topologies [11:25]. Cada dominio de negocio, como pagos o cobros, tiene un owner que normalmente es la product manager. Las cargas se distribuyen por dominios, no por tecnología.
El modelo de Team Topologies propone cuatro tipos de equipos [12:15]:
- Stream-aligned teams: crean features de cara al usuario.
- Enabling teams: desbloquean a otros equipos enseñándoles a usar APIs y herramientas.
- Complicated Subsystem Teams: se concentran en la parte matemática y técnica del motor de AI, exponiendo su trabajo como un servicio (X as a service) [13:00].
- Equipos de plataforma: proveen herramientas internas y mejoran la experiencia de desarrollo (DevEx).
Un detalle importante: el Complicated Subsystem Team no habla directamente con quien construye el feature. El equipo de producto consume el trabajo del equipo especializado a través de una API. Esta separación protege las cargas cognitivas de ambos lados.
Para personas y líderes, las recomendaciones finales son potentes. El equipo es una entidad viva: si alguien llega o se va, ya es un equipo nuevo con conexiones sociales diferentes. Hay que garantizar seguridad psicológica para que cada contribución se sienta relevante, evitar el burnout y promover la redefinición dinámica de equipos para romper silos de información [13:40]. Operar con LLMs ya no es opcional para un software engineer; es parte fundamental del stack, como ser un centauro del desarrollo de software [14:20].
Según datos de Hacker News Hiring, el término AI ya impacta un veinticinco por ciento de las ofertas laborales [15:00]. La pregunta no es si integrar AI en los equipos, sino cuándo empezar a hacerlo de forma estructurada.
