El creador de Pandas habla sobre IA, Apache Arrow y el futuro de la ingeniería de software [YouTube]

• A partir de su experiencia creando Pandas y Apache Arrow, considera que incluso en la era de la IA, la experiencia, el criterio y el gusto para diseñar sistemas de datos y software de alto rendimiento siguen siendo clave
• Apache Arrow es una capa universal basada en memoria para datos tabulares que estandariza la transferencia y el procesamiento entre sistemas; a medida que más sistemas lo adoptan, también crece el valor de la interoperabilidad
• Sistemas sofisticados como DuckDB y DataFusion son difíciles de reemplazar solo con la generación de código promedio de los LLM, y la competitividad del open source incluye no solo el código, sino también un historial de confianza y calidad acumulado durante mucho tiempo
• Las herramientas de IA aumentan mucho la productividad de desarrolladores con alta iniciativa, pero si no está claro qué se quiere construir, pueden acumularse soluciones y código promedio y aparecer un pantano agéntico (agentic tarpit) del que incluso los agentes tienen dificultades para salir
• En adelante, serán más importantes la arquitectura, la definición de problemas, la comunicación y la capacidad de evaluar resultados que la sintaxis de los lenguajes y la codificación manual; las organizaciones también deberán gestionar la mayor carga de decisiones y el costo de tokens

---

De Pandas a las herramientas de desarrollo con IA

• Wes McKinney creó Python Pandas hace unos 18 años y lo publicó como proyecto open source en 2010
• Su libro Python for Data Analysis se usó ampliamente en el ecosistema de ciencia de datos con Python, y luego participó en la creación de empresas y modelos de negocio que permitieran sostener el desarrollo open source
• En Cloudera inició Apache Arrow junto con varios desarrolladores open source, y también participó en el ecosistema de Arrow y en el desarrollo de Parquet
• Ursa Computing luego se convirtió en Voltron Data, y aun después del cierre de Voltron Data mantuvo su relación con Posit
• Actualmente fundó una nueva empresa enfocada más en herramientas e infraestructura para desarrolladores de IA que en bibliotecas de ciencia de datos, explorando cómo aumentar la productividad de la ingeniería de software con IA

Cómo se expandió Apache Arrow

• Arrow es una capa universal de datos en memoria para datos tabulares, que acelera el procesamiento en memoria y la transferencia de datos entre sistemas, además de mejorar la interoperabilidad
• Al principio había pocos usuarios y sistemas consumidores, por lo que el incentivo para adoptarlo era bajo, y también existía escepticismo sobre si varias comunidades open source podrían ponerse de acuerdo en un solo formato
  • Al crear un nuevo estándar unificado, es fácil caer en el problema al estilo XKCD en el que los 13 estándares existentes pasan a ser 14
  • Arrow creció ofreciendo una implementación estable y esperando la adopción, en un contexto donde casi no había alternativas confiables que resolvieran el mismo problema
• La tecnología en sí no ha cambiado mucho en los últimos 5 o 6 años, pero a medida que más sistemas la adoptan, se ha visto un aumento de valor cercano a un efecto de red
• Se estima que unas 30 a 40 empresas usan DataFusion como componente interno porque permite ampliar un motor de consultas según el producto sin construirlo desde cero
  • Arroyo, que desarrollaba un motor de datos en streaming, fue adquirida por Cloudflare, y luego Arrow y DataFusion pasaron a usarse en parte de la infraestructura de datos en streaming de Cloudflare
  • DataFusion Comet se usa para acelerar Spark

Software de sistemas que la IA no reemplaza fácilmente

• DataFusion y DuckDB son el tipo de proyectos para los que es difícil crear reemplazos rápidamente con vibe coding
• Los LLM tienden a promediar código y enfoques existentes, por lo que es difícil que en el corto plazo produzcan sistemas ajustados con detalle por expertos, como un motor de consultas de punta
• Estos proyectos se parecen más a un reloj suizo de precisión ensamblado por artesanos que a un juguete de plástico moldeado por inyección
  • Esto no significa que la IA nunca pueda crearlos, pero por ahora es poco probable que los reemplace
• El valor de los proyectos open source no proviene solo de la implementación, sino también de la confianza que la comunidad ha acumulado durante mucho tiempo
  • La confianza en que los mantenedores consideran los intereses de la comunidad
  • La expectativa de que defenderán contra ataques a la cadena de suministro y corregirán bugs graves
  • Un historial de entregar software consistentemente bien diseñado y confiable
• McKinney no ha estado profundamente involucrado en el desarrollo de Pandas desde 2013, y hoy un gran grupo de desarrolladores mantiene el proyecto
  • Por eso considera que el agradecimiento y el patrocinio deben ir a los mantenedores reales
• Aunque con IA se puedan generar 10.000 líneas de código en un día, no se pueden publicar resultados que no alcancen los estándares de calidad acumulados en el pasado; por lo tanto, la revisión y el mantenimiento de la calidad se vuelven un desafío más importante que el volumen generado

De los videojuegos y las matemáticas a la programación

• A fines de los años 90 se obsesionó con GoldenEye 007 de Nintendo 64, y a fines de 1997 o principios de 1998 creó un sitio de fans en GeoCities y participó en una comunidad de speedrunning
• En ese momento administraba el sitio manualmente, pero al ver que Kisman, experto en programación competitiva, automatizaba las actualizaciones del sitio con un programa en C++, descubrió el efecto de la automatización que puede crear un gran programador
• En la secundaria se interesó por las olimpiadas de matemáticas y el uso de computadoras, y en MIT sintió una gran brecha de habilidad frente a compañeros que programaban desde niños
• Mientras obtenía un título en matemática pura, estudió parte de ciencias de la computación teóricas, como complejidad y algoritmos, pero por una experiencia negativa con Java no desarrolló mucho interés por la programación en sí
• Solo empezó a involucrarse de lleno cuando entendió la programación como una herramienta para resolver problemas y amplificar la productividad personal

Pandas nació en la investigación financiera

• En 2007, a los 22 años, entró a un hedge fund cuantitativo y descubrió que, a diferencia de la investigación centrada en fórmulas que esperaba, muchos análisis dependían de hojas de cálculo de Excel y trabajo manual
• También se usaban MATLAB y R, pero más como herramientas auxiliares, y para desplegar código MATLAB en servidores se requerían licencias costosas por cada servidor
• Concluyó que para un flujo de trabajo que fuera de la investigación a producción se necesitaba un lenguaje open source adecuado para construir sistemas
• Por recomendación de un colega, a principios de 2008 empezó a usar Python y bibliotecas de cómputo científico, y al rehacer las herramientas de investigación existentes en Python apareció la forma inicial de Pandas
• Al crear herramientas que aumentaban la productividad y ver a otras personas trabajar de forma más eficiente con ellas, sintió una inmersión similar a la del speedrunning de videojuegos

Experiencia de usuario simple y deuda técnica interna

• McKinney valora las herramientas simples y consistentes que otras personas también puedan entender y usar, más que herramientas de IA complejas adaptadas solo a una persona
• Un conjunto de herramientas demasiado personalizado puede volverse estructuralmente complejo, como una Winchester Mystery House que nadie salvo su creador puede recorrer
• La implementación inicial de Pandas se centró más en una API y una usabilidad fáciles de entender y escribir para las personas que en la arquitectura interna
• El desorden de la estructura interna dejó una carga de mantenimiento durante mucho tiempo, pero el éxito de Pandas muestra que el software puede triunfar ampliamente aunque no tenga una arquitectura perfecta

El rol y los límites de NumPy

• NumPy nació cuando Travis Oliphant unificó, alrededor de 2005-2006, Numeric, una biblioteca de arreglos multidimensionales iniciada por Jim Hugunin a mediados de los 90, con la línea Numarray, que agregaba funciones para arreglos grandes como memory mapping
• En ese momento Matplotlib, SciPy y herramientas estadísticas y de regresión lineal funcionaban alrededor de arreglos NumPy, por lo que para que una nueva herramienta de datos participara en el ecosistema era indispensable la compatibilidad con NumPy
• NumPy se enfocaba en grandes arreglos multidimensionales de números y enteros, y no fue diseñado como base para bases de datos o datos no numéricos
• Pandas inicialmente se basó en NumPy y sorteó las limitaciones de los datos no numéricos
  • Los valores que no eran números ni booleanos se almacenaban como objetos Python dentro de arreglos NumPy
  • En los datos de texto, el overhead de objetos y las referencias indirectas reducían la eficiencia
• Estas limitaciones se convirtieron luego en una motivación para crear Arrow, una base alternativa en memoria para sistemas como Pandas

Crecimiento del ecosistema de ciencia de datos con Python

• Varias empresas respaldadas por capital de riesgo promovían que cada empresa debía construir una infraestructura de datos como la de Google, lo que atrajo enormes inversiones a proyectos open source de big data
• No todas las empresas necesitaban infraestructura de esa escala, pero sin ese financiamiento probablemente habría sido mucho más difícil reunir a los desarrolladores necesarios para Arrow
• En ese momento, la industria competía por definir qué significaban ciencia de datos y científico de datos, y dónde encontrar talento que combinara habilidades de negocio, estadística y software
• Python permitió que personas con poca experiencia de programación pero con conocimientos de estadística pudieran acceder a la ciencia de datos
  • Al aprender herramientas como Python for Data Analysis y scikit-learn, era posible empezar a hacer análisis útiles para el trabajo en 2 o 3 semanas
  • Considera que si primero hubiera que aprender lenguajes como Scala, la barrera de entrada habría sido más alta y el periodo de aprendizaje más largo

Publicación de Pandas y formación de la organización de Arrow

• Se decidió publicar Pandas en la víspera de Año Nuevo de 2009, y su primera presentación en PyCon en febrero de 2010 lo conectó de lleno con la comunidad Python
• McKinney inició un doctorado en estadística en Duke en 2010, pero tomó una licencia al ver el interés de las empresas financieras por las herramientas de datos en Python y el potencial de crecimiento de Pandas
• En ese entonces Pandas 0.1 tenía funciones limitadas, hasta el punto de no soportar todos los tipos de joins, y dejó el posgrado para enfocarse en el crecimiento del proyecto
• Tras evaluar un negocio de tecnología financiera, pasó a escribir Python for Data Analysis y a fundar una startup de BI; en 2013 concluyó que sería difícil competir con Looker en el mercado de BI y se unió a Cloudera
• En Cloudera se conectó con desarrolladores de Impala y conoció a varios ingenieros que luego trabajaron en Iceberg, Databricks y otros lugares; esa experiencia se convirtió en la base de su carrera posterior
• El proyecto Arrow comenzó a principios de 2016 en Cloudera, pero en ese momento era difícil conseguir presupuesto para un equipo dedicado a tecnología experimental dentro del mercado de software empresarial
• Entre 2016 y 2018, aplicó Arrow a sistemas reales en una empresa financiera para acelerar cargas de procesamiento de datos y mejorar Parquet
• En 2018, varias empresas querían financiar el desarrollo de Arrow, pero por las normas de la empresa financiera era difícil administrar fondos externos, así que en abril fundó una organización independiente capaz de recibir patrocinios corporativos
  • Participaron unas seis empresas patrocinadoras, incluidas compañías de hardware como Nvidia y empresas financieras
  • Se formó un equipo de desarrollo de unas 8 personas
• Tras confirmar la oportunidad comercial, en 2020, durante la pandemia de COVID-19, la organización se convirtió en Ursa Computing

Problemas de ingeniería de datos que aún persisten

• Incluso hoy, el campo de datos sigue resolviendo una y otra vez los problemas de mover datos de A a B, convertir formatos, cargarlos en memoria y ejecutar consultas y transformaciones de forma eficiente
• Pandas se convirtió en una base que sostiene muchos más flujos de datos empresariales de lo esperado, y actualmente es posible que los LLM generen más código Pandas del que las personas escribieron en el pasado
• DuckDB es una herramienta tan poderosa que habría sido difícil de imaginar para un desarrollador de hace 20 años
  • Se puede instalar gratis y ejecutar en muchos entornos
  • Puede funcionar incluso en teléfonos y navegadores web
  • Ofrece análisis de alto rendimiento en una sola máquina sin instalaciones complejas
• A través de muchas incomodidades y prueba y error, se volvió clara la necesidad de tecnologías como DuckDB y Arrow, y varias soluciones, incluido Parquet, fueron influenciadas por tecnologías creadas por grandes empresas de internet como Google para reducir costos y tiempo
• Parquet no es el mejor formato, pero ha mejorado mucho frente al pasado y casi todos los sistemas lo soportan
  • Aunque existan alternativas especializadas como Vortex y Lance, se sigue usando gracias a una compatibilidad suficientemente buena
• A medida que la IA concentra la atención de la industria, la ingeniería de datos se ha vuelto menos llamativa, y aunque Databricks anuncie un nuevo motor de datos, recibe menos atención que antes
• En sentido contrario, para los desarrolladores de herramientas de datos esto abre espacio para enfocarse en la madurez técnica sin perseguir modas, y la IA puede aprovecharse en tareas repetitivas e incómodas como escribir pruebas

Convergencia hacia la tecnología de bases de datos

• Una de las principales lecciones de la era del big data es que se debieron aprovechar antes los artículos y resultados de conferencias de investigadores de bases de datos
• Es importante leer, implementar y colaborar a partir de investigaciones de bases de datos de instituciones como TU Munich, CWI, MIT, CMU y Berkeley
• En la época centrada en NoSQL y almacenamientos no relacionales, los sistemas escalables agregaban tanto overhead que a veces terminaban siendo más lentos que una implementación bien hecha de una sola máquina y un solo hilo
• El estudio Scalability! But at what COST?, en el que participaron Frank McSherry, Michael Isard y otros, aborda el problema del costo que se paga por obtener escalabilidad
• El stack de datos moderno vuelve a converger alrededor de la tecnología de bases de datos y el procesamiento columnar
  • Polars, Daft y DataFusion usan Arrow
  • El nuevo motor de dbt utiliza ADBC
  • Databricks Photon adopta una estructura columnar, independientemente de si usa Arrow o no
• A medida que los principales sistemas convergen en arquitecturas y enfoques similares, ahora el desafío más importante ya no es tanto el método central de procesamiento, sino qué tan fácil es usar realmente el software

Mejoras de usabilidad desde Hadoop hasta DuckDB

• En la era de Hadoop, por Java, archivos de configuración XML y numerosos parámetros de ajuste, a veces se dedicaban unos dos días a configurar antes de poder empezar el trabajo real
• Spark fue una gran mejora en el sentido de que permitía escribir un conteo de palabras en una sola línea, pero aún requería preparar infraestructura y archivos de configuración
• La forma de instalación y ejecución de DuckDB es un modelo de usabilidad que muestra cuán simples pueden llegar a ser los sistemas de datos
• Los sistemas distribuidos también deberían reducir la complejidad operativa ofreciendo valores predeterminados razonables y configuraciones que funcionen de inmediato
• DuckDB también se está expandiendo hacia el ámbito cliente-servidor y colabora estrechamente con MotherDuck

Capa de datos multimodal para IA generativa

• Los lakehouses existentes se centran en datos tabulares y Parquet, pero para la IA generativa y el entrenamiento y fine-tuning de grandes modelos se necesitan imágenes, video, texto, documentos y logs en conjunto
• El lakehouse de datos multimodales que aborda LanceDB corresponde a un problema empresarial real
• Al generar embeddings a partir de grandes volúmenes de datos no estructurados se consume energía y tiempo de GPU, por lo que los embeddings resultantes adquieren valor económico por el costo de cómputo invertido
• En entornos de producción se necesita un almacén de datos capaz de guardar, gestionar y procesar de forma confiable los datos originales y los resultados generados
• Si cada empresa construye su propio almacenamiento multimodal, puede repetir bugs, pérdida de datos y problemas de rendimiento, por lo que es más eficiente que proveedores de software especializados ofrezcan soluciones comunes
• Aunque se puedan operar directamente tablas Iceberg, delegar la administración a proveedores como Databricks, Snowflake o AWS reduce la complejidad operativa; la misma lógica aplica a los datos multimodales para IA generativa
• En el mercado de datos para IA generativa aún queda espacio para resolver distintas capas, desde búsqueda vectorial de documentos y procesamiento de alto QPS hasta gestión del ciclo de vida de los datos

Competitividad de los desarrolladores en la era de la IA

• McKinney llegó a preguntarse si él mismo tendría futuro como ingeniero de software, pero concluyó que la IA distingue con mayor claridad a las personas según su nivel de iniciativa
• Las personas con alta iniciativa pueden obtener una gran amplificación de productividad con IA, basándose en el gusto y el criterio para pensar qué construir y evaluar buenos resultados
• Los LLM ofrecen para la mayoría de los problemas un enfoque de nivel B+ promedio y razonable, pero no crean experiencia, gusto ni criterio en lugar del usuario
• Si se sigue agregando código generado sin buen juicio, se forma un pantano complejo, y hasta los agentes tienen dificultades para seguir trabajando bajo el peso del contexto y la estructura
• En el pasado, al implementar directamente se desarrollaban al mismo tiempo habilidades técnicas y criterio, pero en adelante, al reducirse el tiempo de codificación manual, habrá que cultivar por separado la comprensión de sistemas y la capacidad de diseño

Qué estudiar en la era de la IA

• Los nuevos desarrolladores necesitan estudiar diseño y arquitectura de software, además de la estructura de los sistemas de datos, en lugar de limitarse a aprender la sintaxis de Python o Java
• En ingeniería de datos, deben entender cómo funcionan distintos sistemas, como las arquitecturas Lambda y Kappa, y para qué problemas son adecuados
• Deben poder comunicar con precisión al agente el resultado que quieren y detectar cuándo avanza en una dirección equivocada
• Si el usuario no puede juzgar si A o B es mejor, el agente tampoco puede garantizar en su lugar la elección correcta
• Es probable que ingenieros de software, ingenieros de datos y científicos de datos dediquen más tiempo a definir problemas y comunicarse que a escribir código
• Si no puedes explicar lo que quieres, tampoco podrás obtener el resultado deseado con IA; simplemente agregar IA a una organización no eleva automáticamente la productividad ni los resultados económicos
• Dar IA a personas con poca experiencia y criterio puede convertirla en un cañón de slop (slop cannon) que genera en masa deuda que otros deben procesar, más que resultados útiles

Más decisiones e inversión organizacional en IA

• Durante los próximos 2 a 5 años, la contratación de desarrolladores, las entrevistas técnicas y la diferenciación de roles pueden cambiar de forma confusa y rápida
• Antes, mediante reuniones, planificación de sprints y planning poker, los equipos generaban una convicción compartida sobre el trabajo y luego se dividían la implementación
• Ahora, el proceso tradicional de planificación ágil se comprime dentro del modo de planificación de Claude, y surge una situación en la que un solo desarrollador debe tomar muchísimas decisiones por su cuenta
• Un desarrollador que debe tomar 10 veces más decisiones al día que antes puede quedar paralizado por la fatiga de decisión y la ambigüedad
• Quien juzga rápido y define una ruta eficiente puede aprovechar la productividad de la IA, pero para quien no tiene certeza sobre qué debe hacer, la IA no resuelve ese problema
• Las empresas pueden pagar grandes sumas a Anthropic y OpenAI y aun así tener dificultades para verificar el retorno de su inversión en IA
  • Junto con algunos resultados positivos, también aparecen desperdicio, entregables de baja calidad y el costo de limpiar esos entregables
  • Los proveedores de modelos de IA obtienen ingresos mientras continúe la venta de tokens, pero es probable que los clientes apliquen presupuestos de tokens más estrictos

Modelos de pesos abiertos y economía de tokens

• McKinney ejecutó el modelo chino de pesos abiertos GLM 5.2 en infraestructura física y evaluó que los resultados fueron buenos
• GLM 5.2 no es un modelo pequeño, y para ejecutarlo correctamente se necesitan alrededor de 8 GPU B200
  • Se estima que una B200 cuesta aproximadamente entre 30.000 y 50.000 dólares
  • El costo total de hardware puede llegar a unos 250.000 a 400.000 dólares
• A largo plazo espera que, si mejora la calidad de los modelos de pesos abiertos y el hardware se abarata, sea posible no pagar continuamente a empresas externas de IA y asumir solo el costo eléctrico de un servidor propio
• Al calcular los tokens usados en los últimos 30 días con el precio de lista de la API, el monto fue de unos 37.000 dólares, pero lo que realmente pagó a los proveedores de modelos fue mucho menor
• Es posible que los precios actuales de tokens incluyan grandes subsidios, y no está claro qué estructura de costos será sostenible a largo plazo
• La adopción de IA tampoco es tan uniforme como sugiere la atención de la industria: algunas empresas permanecen en una larga cola donde solo se discute a nivel de directorio y CTO, sin haber iniciado una aplicación real