Por Andrew Tan
Por qué estoy escribiendo esto
Debido a que la IA está en auge en este momento, algunos CTO se preguntan: "¿Debería la IA reemplazar a la mitad de nuestro equipo de ingeniería de datos?"
Ese es el estado de la IA en la ingeniería de datos en este momento. Todos están publicando contenido sensacionalista. Nadie está siendo específico. Así que aquí está mi opinión sobre el tema:
Con qué ayuda genuinamente la IA
La generación de SQL es el triunfo más claro. Las herramientas estilo Copilot reducen el tiempo para escribir un borrador inicial de una consulta analítica en un 50-70% para ingenieros con sólidos fundamentos de SQL. Aún necesitas revisarlo. Aún necesitas saber cómo debería verse la respuesta. Pero el problema de la página en blanco ha desaparecido.
La documentación de esquemas es dramáticamente más rápida. Pasar de "tenemos 400 tablas" a "hemos documentado 400 tablas" solía tomar meses de tiempo de analistas. Con buenas herramientas LLM, los equipos pueden lograr esto en semanas. La documentación no es perfecta, pero es lo suficientemente buena para ser útil, lo cual a menudo no era antes.
El análisis ad-hoc ha cambiado significativamente para los no ingenieros. Los analistas de negocios que solían presentar tickets para "¿puedes escribirme una consulta que…" ahora pueden obtener respuestas funcionales a preguntas simples por sí mismos. Esto es productividad real. También es una reducción significativa en el trabajo impulsado por interrupciones para los equipos de ingeniería de datos.
Borradores de revisión de código. No es un reemplazo para la revisión, pero detectar lo obvio — uniones sin índice, comprobaciones de nulos faltantes, desajustes de tipo — antes de que un humano lo revise ahorra tiempo en conjunto.
Estas son reales y son importantes. No quiero descartarlas.
Con qué no puede manejar la IA de manera confiable
Aquí es donde se abre la brecha entre las afirmaciones de los proveedores y la realidad de producción.
Evolución de esquemas a gran escala
La parte más difícil de mantener pipelines de producción no es escribir el código, es saber qué hacer cuando un sistema aguas arriba cambia un tipo de campo, desaprueba una columna o comienza a enviar datos en un formato diferente. Esto requiere entender la lógica de negocio detrás de los datos, los consumidores aguas abajo, el contexto histórico de por qué existe el campo. Un LLM que no estuvo presente cuando se tomaron esas decisiones no puede razonar de manera confiable sobre la respuesta correcta. Te dará algo que parece correcto. A menudo no lo es.
Procesamiento de flujos con estado
Un equipo puede pasar tres meses tratando de lograr que un LLM implemente correctamente una agregación con ventana y manejo de llegadas tardías para su pipeline de detección de fraude en tiempo real. El LLM podría escribir el código. El código también se ejecuta. Produce respuestas incorrectas en casos límite que solo aparecen en producción, bajo condiciones de orden específicas, en días con volúmenes de eventos inusuales. Esos errores son del tipo difícil: no lanzan errores, simplemente corrompen silenciosamente tus métricas. El modelo no tiene forma de probar su propia salida contra los casos límite reales que enfrentará.
Recuperación de fallos en producción
Cuando un consumidor de Kafka se queda atrás por 48 horas y necesitas decidir si reproducir, descartar o deduplicar, eso no es un problema de generación de código. Es una decisión que requiere conocer tu negocio, tus SLA y el costo de cada opción. Aún no he visto un LLM tomar esa decisión correctamente sin un andamiaje humano significativo.
Un ingeniero líder en una empresa de ciberseguridad me dijo: "Logramos alrededor del 70% de automatización en nuestros patrones estándar de ETL. El último 30% es lo que realmente se rompe en producción". No se estaba quejando. Entendía por qué. Pero el 30% es lo que mantiene empleados a los ingenieros de datos.
El problema del "80% de automatización"
Gartner publicó una predicción el año pasado de que el 80% del trabajo de ingeniería de datos se vería afectado para 2027. Entiendo por qué lo escribieron.
Aquí está la cuestión sobre el 80%: el 80% del que están hablando es andamiaje. Plantillas. Borradores iniciales. La parte que es genuinamente 80% automatizable, por ejemplo, es la parte que ya era relativamente rápida.
Lo que queda es el 20% que toma el 80% del tiempo: depurar por qué los datos se ven mal, negociar cambios de esquema con equipos aguas arriba, razonar sobre la fiabilidad del pipeline bajo condiciones que nadie anticipó. Ese 20% también es el 20% donde una respuesta incorrecta es costosa.
No digo esto para ser pesimista. El 80% importa. Liberar a los equipos de ingeniería del andamiaje es genuinamente valioso. Pero los equipos que planean para un mundo donde esta automatización significa menos ingenieros están haciendo una apuesta específica de que los problemas costosos también se volverán más fáciles. Podrían. Aún no veo evidencia de ello.
Lo que les digo a los equipos que consideran reducciones de personal
No lo hagan todavía. No porque la tecnología no sea real, sino porque están apostando al variable incorrecto.
Los equipos que obtienen más de las herramientas de IA no son los que reducen personal, son los que toman el mismo personal y lo enfocan en problemas más difíciles. Los ingenieros que solían pasar sus días en trabajo rutinario de ETL ahora están trabajando en marcos de calidad de datos, gobernanza de esquemas, fiabilidad de pipelines en tiempo real. La producción por ingeniero es mayor. La calidad de la producción es mayor. El equipo es más difícil de reemplazar, no más fácil.
Esa es la historia. La IA es un multiplicador de productividad para los ingenieros de datos. No es EL ingeniero de datos.
Una visión general simple
Sé que dije que evitaría el formato de tabla comparativa. Pero esta es genuinamente la forma más clara de mostrarlo:
| Tarea | La IA ayuda | La IA tiene dificultades |
|---|---|---|
| Generación de SQL | Borradores iniciales, 50-70% más rápido | Lógica compleja con reglas de negocio sutiles |
| Documentación de esquemas | Primer pase, semanas no meses | Semántica precisa sin contexto de negocio |
| Análisis ad-hoc | Preguntas simples para no ingenieros | Preguntas que requieren contexto de sistemas cruzados |
| Código de pipeline | Plantillas, patrones estándar | Lógica con estado, manejo de casos límite |
| Evolución de esquemas | — | Casi totalmente juicio humano |
| Recuperación de fallos | — | Requiere conocimiento de negocio + operativo |
| Depuración en producción | — | Los LLM no conocen tu historia específica |
La columna de la izquierda es real. La columna de la derecha es por qué los equipos de ingeniería de datos aún existen.
Dónde encaja layline.io
Seré directo: las ganancias de productividad de la IA que describí anteriormente son más fáciles de capturar cuando tus pipelines tienen una estructura explícita que los LLM pueden entender y extender.
En layline.io, construimos pipelines con configuración declarativa: la lógica está en operadores estructurados, no incrustada en código personalizado (excepto por el ocasional Javascript o Python aquí y allá y solo donde realmente es necesario). Resulta que esto se combina bien con el desarrollo asistido por IA. Cuando un ingeniero le pide a un LLM que agregue un paso de procesamiento, el LLM puede razonar sobre ello claramente. Cuando algo se rompe, el fallo está en un lugar conocido en lugar de enterrado en código a medida.
Esa no es la razón por la que lo construimos de esa manera. Lo construimos así porque los pipelines declarativos son más fáciles de depurar y mantener para los humanos. La afinidad con la IA resultó ser un efecto secundario.
Pero significa que los equipos que construyen sobre una base estructurada obtienen más de las herramientas de IA que los equipos que trabajan en código personalizado. Algo que vale la pena considerar cuando estás tomando decisiones arquitectónicas que importarán en dos años.
La pregunta que vale la pena hacerle a tu equipo
Prueba esto: elige tus últimos cinco incidentes de datos. Para cada uno, pregúntate si una IA podría haberlo prevenido o diagnosticado más rápido.
Para la mayoría de los equipos, la respuesta es "tal vez 1 de cada 5". Los otros cuatro son problemas que un LLM no puede razonar de manera confiable: lógica de negocio incorrecta que es código técnicamente correcto, un cambio de esquema de un equipo aguas arriba que nadie anunció, un caso límite en el procesamiento de flujos que solo se manifiesta en volúmenes de eventos específicos.
Si estás evaluando herramientas de IA, ese es tu punto de referencia. No "¿cambiará la IA la ingeniería de datos?" — por supuesto que lo hará. Sino "¿eliminará la IA los problemas que realmente nos perjudican?" Esa respuesta es no, aún no, y probablemente no sin que algo cambie que no ha cambiado.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
