La IA necesita desarrolladores, no solo data scientists

9 min de lectura

La misma palabra, otro oficio

Dos oficios aplastados dentro de una palabra

La definición breve más limpia sigue siendo la de Drew Conway en Data Science Venn Diagram: la ciencia de datos vive donde se cruzan habilidades prácticas de programación, estadística y matemáticas, y conocimiento sustantivo del dominio. Quite la parte de estadística y matemáticas y ya no está haciendo ciencia de datos. Está haciendo desarrollo de software con datos.

El trabajo de un data scientist consiste en convertir una realidad desordenada en una inferencia defendible. Formular bien una pregunta. Traer datos. Limpiarlos. Explorarlos. Ajustar un modelo. Discutir con los resultados. Cuantificar la incertidumbre. Decidir si la respuesta es lo bastante sólida como para actuar. El entregable suele ser un hallazgo, un pronóstico, una recomendación o un artefacto de modelo entrenado.

El trabajo de un desarrollador de software consiste en construir y mantener vivo un sistema que haga algo útil para usuarios reales. Decidir qué debe hacer realmente el sistema. Modelar el dominio. Diseñar los límites. Escribir el código. Cubrirlo con pruebas. Integrarlo en CI/CD. Hacerlo observable. Manejar fallos. Mantenerlo seguro. Mantenerlo cambiante. El entregable es un producto o una plataforma que sobrevive al contacto con clientes, auditores, reguladores y el lunes por la mañana.

Ambos son trabajos técnicos. Ambos tocan código. La forma del trabajo es muy distinta.

De dónde sale la confusión

En 2012, Davenport y Patil publicaron Data Scientist: The Sexiest Job of the 21st Century en Harvard Business Review. Una década después, los mismos autores retomaron la idea en Is Data Scientist Still the Sexiest Job of the 21st Century? y admitieron que el rol se había fragmentado. Machine learning engineers, data engineers, especialistas de MLOps y analytics engineers habían absorbido silenciosamente una gran parte de lo que el titular original había empaquetado dentro de una contratación mítica.

Esa fragmentación es la señal de verdad.

El boom del “data scientist” chocó con el boom de la “IA” y produjo una historia ejecutiva muy conveniente: contrate data scientists y la IA ocurrirá sola. Casi nunca ocurre, porque la mayor parte del trabajo necesario para convertir un modelo en un producto no es trabajo de ciencia de datos en absoluto. Es desarrollo de software, infraestructura, seguridad, integración y operaciones.

Eso no es una opinión. Está bien documentado.

El 95 % que no es el modelo

La cita clásica aquí viene de Google: D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015. La figura central del artículo muestra el código de ML como un rectángulo negro diminuto rodeado de configuración, recolección de datos, extracción de features, verificación de datos, gestión de recursos de máquina, herramientas de análisis, gestión de procesos, infraestructura de serving y monitoreo. Los autores llaman a los sistemas de ML “la tarjeta de crédito de alto interés de la deuda técnica” y advierten que cargan con todos los costes habituales del software complejo más un conjunto de costes específicos del ML.

El propio texto de Google MLOps: Continuous delivery and automation pipelines in machine learning desarrolla el mismo punto: un modelo entrenado no es un producto. Llevar un modelo a producción exige datos versionados, entrenamiento reproducible, integración continua, entrega continua, monitoreo de drift de datos, rutas de rollback y responsabilidades claras. Todo eso son disciplinas de desarrollo de software.

Andrej Karpathy planteó la versión cultural del argumento en Software 2.0. Su punto no era que los programadores desaparezcan. Su punto era que cambia el artefacto que se moldea: pesos en lugar de reglas escritas a mano. La pila que lo rodea — pipelines, evaluación, despliegue, tooling — sigue necesitando personas que sepan construir y mantener software.

Si su tesis de inversión en IA supone que contratar a unos cuantos PhD reemplaza una capacidad real de desarrollo, la literatura de este campo lleva más de una década argumentando lo contrario.

En qué destacan los data scientists

Esto no es un ataque contra el rol. Los buenos data scientists son extraordinariamente valiosos.

Un buen data scientist detecta cuando una métrica está filtrando futuro hacia el pasado. Puede decirle que su prueba A/B no tiene potencia suficiente y que la victoria que está a punto de celebrar es ruido. Puede mostrarle que una segmentación de clientes es inestable a lo largo del tiempo y evitar que construya una estrategia encima de ella. Puede elegir el modelo correcto para la pregunta en lugar del más de moda. Puede cuantificar cuánta confianza merece un pronóstico, que es exactamente la parte que los ejecutivos más quieren saltarse.

También son las personas que notan cuando una demo de IA “exitosa” solo funciona sobre un recorte curado de los datos. Eso es un servicio.

Para lo que normalmente no están optimizados es para entregar. Construir servicios fiables con APIs versionadas, autenticación, rate limiting, audit trails, pipelines de despliegue, turnos de guardia y degradación elegante no suele ser parte central de su formación. Muchos pueden crecer hacia ahí. Muchos no quieren, y no tendrían por qué hacerlo.

En qué destacan los desarrolladores de software

La ventaja de un desarrollador de software está en lograr que algo funcione en producción, otra vez mañana, bajo carga y con auditores mirando.

Eso incluye las partes que parecen aburridas: escribir pruebas que impidan regresiones silenciosas, dividir un sistema en módulos que puedan cambiar de forma independiente, decidir dónde viven los datos, decidir qué llamadas son síncronas y cuáles no, integrar APIs de terceros que mienten sobre su disponibilidad, diseñar observabilidad para que un incidente a las tres de la madrugada pueda depurarse y dar forma al código para que el siguiente cambio no cueste más que el anterior.

En IA, en concreto, los desarrolladores de software son quienes:

• envuelven modelos detrás de APIs limpias, versionadas y autenticadas
• mueven datos con seguridad entre sistemas y respetan su procedencia
• construyen arneses de evaluación para que realmente sepa si un modelo nuevo es mejor
• imponen seguridad, rate limiting y controles de coste sobre las llamadas a LLM
• diseñan rutas de retrieval, caché y fallback
• integran funciones de IA en productos existentes sin romperlos
• mantienen todo dentro de la postura de seguridad y cumplimiento de la empresa

Sin ese trabajo, un modelo es una curiosidad. Con él, el modelo se convierte en una funcionalidad.

Una nota personal sobre la honestidad

Lo dije hace poco en una entrevista y lo repito aquí. Yo soy quien construye las herramientas, los pipelines, las integraciones y la superficie de producción que permite que el trabajo de un data scientist llegue hasta los clientes. Con más de cuarenta años en software, entiendo el funcionamiento interno de los LLM y de los sistemas modernos de IA como software: tokens, ventanas de contexto, embeddings, retrieval, evaluación, latencia, costes, modos de fallo y patrones de despliegue. Esa es justo la parte que la dirección sigue subestimando.

Lo que no finjo ser es matemático. La teoría de la medida profunda, la inferencia estadística avanzada o el último giro en investigación de optimización no son mi terreno. Cuando esa profundidad importa, quiere un data scientist de verdad o un investigador aplicado. Cuando la pregunta es si su sistema de IA va a correr, escalar, integrarse, mantenerse seguro y no arruinarlo en costes de inferencia, quiere un desarrollador que lleve décadas poniendo sistemas en marcha.

Dos hojas distintas. La misma caja de herramientas.

Lo que esto significa para su estrategia de IA

Si usted es CEO, CTO o inversor y está evaluando un plan de IA, unas cuantas preguntas prácticas le ahorran mucho dinero.

1. Pregunte quién convierte el modelo en producto.

   Si el plan está cargado de data scientists pero es débil en desarrolladores, gente de plataforma y SRE, el modelo no llegará a clientes de forma fiable. El primer MVP quizá sí. El segundo lanzamiento dolerá.

2. Pregunte dónde vive la disciplina de desarrollo.

   Control de versiones, revisión de código, pruebas automatizadas, CI/CD, observabilidad, revisión de seguridad, respuesta a incidentes. Si ninguna de esas palabras aparece en el plan de IA, usted no tiene un plan de IA. Tiene un experimento con presupuesto de marketing.

3. Pregunte cómo evalúa el equipo los modelos en producción.

   La exactitud offline sobre un conjunto de datos estático no es evaluación. Usted quiere evaluación continua, monitoreo de drift y una respuesta clara a la pregunta: "¿cómo sabríamos esta semana que esto empeoró?". Eso es trabajo de software, no de notebook.

4. Pregunte por costes y modos de fallo.

   Las funcionalidades basadas en LLM pueden quemar presupuestos de inferencia en silencio, filtrar datos o fallar de maneras que parecen éxito. Los desarrolladores que entienden el runtime son quienes ponen guardarraíles alrededor de todo eso.

5. No despida a los desarrolladores que construyeron su producto.

   La forma más rápida de hacer fracasar una iniciativa de IA es tratar su capacidad de desarrollo existente como headcount heredado mientras vierte dinero en un "equipo de IA" paralelo que no puede entregar nada. Los equipos que ganan combinan conocimiento profundo del dominio en el código con nueva capacidad de IA dentro del mismo sistema, no al lado.

El marco útil

Data scientist y desarrollador de software no son sinónimos. Son complementarios.

Necesita data scientists para hacer preguntas afiladas y para mantener honesta a la organización sobre lo que los datos realmente sostienen. Necesita desarrolladores de software para construir y operar los sistemas que convierten esas respuestas en productos que los clientes usan todos los días.

Si su estrategia de IA tiene uno sin el otro, no es una estrategia. Es una apuesta a que la mitad que falta aparecerá sola.

No va a pasar.