Criador do Pandas fala sobre IA, Apache Arrow e o futuro da engenharia de software [YouTube]

• Com base na experiência de criar o Pandas e o Apache Arrow, considera que, mesmo na era da IA, expertise, julgamento e gosto para projetar sistemas de dados e software de alto desempenho continuam sendo centrais
• O Apache Arrow é uma camada universal em memória para dados tabulares, que padroniza a transferência e o processamento entre sistemas; quanto mais sistemas o adotam, maior fica o valor da interoperabilidade
• Sistemas sofisticados como DuckDB e DataFusion são difíceis de substituir apenas pela geração média de código de LLMs, e a competitividade do open source inclui não só código, mas também um histórico de confiança e qualidade acumulado ao longo de muito tempo
• Ferramentas de IA aumentam muito a produtividade de desenvolvedores com alta iniciativa, mas, se não estiver claro o que criar, soluções e código medianos podem se acumular e formar um atoleiro agêntico (agentic tarpit) do qual até agentes têm dificuldade de sair
• Daqui para frente, arquitetura, definição de problemas, comunicação e capacidade de avaliar resultados serão mais importantes do que sintaxe de linguagens e codificação manual; organizações também precisarão gerenciar a maior carga de decisões e custos de tokens

---

Da Pandas às ferramentas de desenvolvimento com IA

• Wes McKinney criou o Python Pandas há cerca de 18 anos e o lançou como projeto open source em 2010
• Seu livro Python for Data Analysis foi amplamente usado no ecossistema de ciência de dados em Python, e depois ele participou da criação de empresas e modelos de negócio que permitissem continuar o desenvolvimento open source
• Na Cloudera, iniciou o Apache Arrow com vários desenvolvedores open source e também se envolveu no ecossistema Arrow e no desenvolvimento do Parquet
• A Ursa Computing mais tarde se tornou a Voltron Data e, mesmo depois da reestruturação da Voltron Data, manteve sua relação com a Posit
• Atualmente, fundou uma nova empresa focada menos em bibliotecas de ciência de dados e mais em ferramentas e infraestrutura para desenvolvedores de IA, explorando formas de aumentar a produtividade da engenharia de software com IA

Como o Apache Arrow se difundiu

• O Arrow é uma camada universal de dados em memória para dados tabulares, que acelera o processamento na memória e a transferência de dados entre sistemas, além de aumentar a interoperabilidade
• No início, havia poucos usuários e sistemas consumidores, então o incentivo à adoção era baixo; também havia ceticismo quanto à possibilidade de várias comunidades open source chegarem a um consenso sobre um único formato
  • Ao criar um novo padrão unificado, é fácil cair no problema ao estilo XKCD em que os 13 padrões existentes viram 14
  • O Arrow cresceu oferecendo uma implementação estável e aguardando adoção, em um contexto em que quase não havia alternativas confiáveis para resolver o mesmo problema
• A tecnologia em si não mudou muito nos últimos 5 a 6 anos, mas, à medida que mais sistemas a adotaram, o valor aumentou de forma parecida com um efeito de rede
• O DataFusion permite que produtos sejam estendidos sem criar um mecanismo de consultas do zero, e estima-se que cerca de 30 a 40 empresas o usem como componente interno
  • A Arroyo, que desenvolvia um motor de dados em streaming, foi adquirida pela Cloudflare; depois, Arrow e DataFusion passaram a ser usados em parte da infraestrutura de dados em streaming da Cloudflare
  • O DataFusion Comet é usado para acelerar o Spark

Software de sistemas que a IA não substitui facilmente

• DataFusion e DuckDB são o tipo de projeto em que é difícil criar rapidamente substitutos por meio de vibe coding
• LLMs tendem a fazer uma média do código e das abordagens existentes, por isso é difícil que, no curto prazo, criem sistemas minuciosamente estruturados por especialistas, como motores de consulta de ponta
• Esses projetos se parecem mais com relógios suíços de precisão montados por artesãos do que com brinquedos de plástico moldados por injeção
  • Isso não significa que a IA nunca será capaz de criá-los, mas, no momento, a probabilidade de substituição é baixa
• O valor de projetos open source vem não apenas da implementação, mas também da confiança acumulada pela comunidade ao longo de muito tempo
  • A crença de que os mantenedores consideram os interesses da comunidade
  • A expectativa de que defenderão contra ataques à cadeia de suprimentos e corrigirão bugs graves
  • Um histórico de entrega consistente de software bem projetado e confiável
• McKinney não participa profundamente do desenvolvimento do Pandas desde 2013; hoje, um grande grupo de desenvolvedores mantém o projeto
  • Portanto, ele acredita que o reconhecimento e o patrocínio devem ir para os mantenedores reais
• Mesmo que seja possível gerar 10 mil linhas de código por dia com IA, não se pode publicar resultados que não atendam aos padrões de qualidade acumulados no passado; por isso, revisão e manutenção da qualidade se tornam desafios mais importantes do que volume de geração

Dos games e da matemática à programação

• No fim dos anos 1990, ficou obcecado por GoldenEye 007, do Nintendo 64, e, no fim de 1997 ou início de 1998, criou um fansite no GeoCities e participou de uma comunidade de competição por tempos
• Na época, gerenciava o site manualmente, mas, ao ver Kisman, que era bom em programação competitiva, automatizar atualizações do site com um programa em C++, teve contato com o efeito da automação criada por um programador habilidoso
• No ensino médio, interessou-se por olimpíadas de matemática e uso de computadores; no MIT, percebeu uma grande diferença de habilidade em relação a colegas que programavam desde a infância
• Ao se formar em matemática pura, estudou parte da ciência da computação teórica, como complexidade e algoritmos, mas uma experiência negativa com Java o impediu de se interessar muito pela programação em si
• Só começou a mergulhar de fato quando passou a enxergar a programação como uma ferramenta para resolver problemas e amplificar a produtividade pessoal

Pandas nasceu na pesquisa financeira

• Em 2007, aos 22 anos, entrou em um hedge fund quantitativo e descobriu que, ao contrário da pesquisa centrada em fórmulas que esperava, muitas análises dependiam de planilhas Excel e trabalho manual
• MATLAB e R também eram usados, mas mais como ferramentas auxiliares; para implantar código MATLAB em servidores, era preciso pagar licenças caras para cada servidor
• Concluiu que, para um fluxo que fosse da pesquisa à produção, era necessária uma linguagem open source adequada à construção de sistemas
• Por recomendação de um colega, começou a usar Python e bibliotecas de computação científica no início de 2008, e, ao recriar ferramentas de pesquisa existentes em Python, surgiu a forma inicial do Pandas
• Ao criar ferramentas que aumentavam a produtividade e ver outras pessoas trabalhando com mais eficiência graças a elas, sentiu uma imersão parecida com a das competições de velocidade em games

Experiência de usuário simples e dívida técnica interna

• McKinney valoriza ferramentas simples e consistentes que outras pessoas também consigam entender e usar, em vez de ferramentas de IA complexas feitas apenas sob medida para uma pessoa
• Um conjunto de ferramentas excessivamente personalizado pode se tornar tão estruturalmente complexo quanto a Winchester Mystery House, impossível de navegar para qualquer um que não seja seu criador
• A implementação inicial do Pandas se concentrou mais em APIs e usabilidade fáceis de entender e escrever do que na arquitetura interna
• A bagunça na estrutura interna deixou um fardo de manutenção por muito tempo, mas o sucesso do Pandas mostra que um software pode ter grande sucesso mesmo sem uma arquitetura perfeita

O papel e os limites do NumPy

• O NumPy foi criado quando Travis Oliphant, por volta de 2005–2006, unificou a biblioteca de arrays multidimensionais Numeric, iniciada por Jim Hugunin em meados dos anos 1990, com a linhagem Numarray, que adicionava recursos para arrays grandes, como mapeamento de memória
• Na época, Matplotlib, SciPy e ferramentas de estatística e regressão linear funcionavam em torno de arrays NumPy; por isso, para uma nova ferramenta de dados participar do ecossistema, a compatibilidade com NumPy era essencial
• O NumPy se concentrava em grandes arrays multidimensionais de números e inteiros, e não foi projetado como base para bancos de dados ou dados não numéricos
• O Pandas inicial tomou o NumPy como base e contornou as limitações de dados não numéricos
  • Valores que não eram numéricos nem booleanos eram armazenados como objetos Python dentro de arrays NumPy
  • Dados de string tinham overhead de objetos e referências indiretas, o que reduzia a eficiência
• Essas limitações mais tarde motivaram a criação do Arrow como uma base alternativa em memória para sistemas como o Pandas

Crescimento do ecossistema de ciência de dados em Python

• Várias empresas financiadas por venture capital promoveram a ideia de que toda empresa precisava construir uma infraestrutura de dados como a do Google, o que trouxe investimentos massivos para projetos open source de big data
• Nem toda empresa precisava de uma infraestrutura dessa escala, mas, sem esse dinheiro, provavelmente teria sido muito mais difícil reunir os desenvolvedores necessários para o Arrow
• Na época, o setor disputava o significado de ciência de dados e de cientista de dados, além de onde encontrar pessoas com capacidades combinadas de negócios, estatística e software
• Python permitiu que pessoas com conhecimento de estatística, mas pouca experiência em programação, também acessassem a ciência de dados
  • Ao aprender ferramentas como Python for Data Analysis e scikit-learn, era possível começar a fazer análises úteis para o trabalho em 2 a 3 semanas
  • Ele considera que, se fosse necessário aprender primeiro uma linguagem como Scala, a barreira de entrada seria maior e o período de aprendizado, mais longo

Lançamento do Pandas e formação da organização do Arrow

• A decisão de lançar o Pandas foi tomada na véspera de Ano Novo de 2009, e a primeira apresentação na PyCon, em fevereiro de 2010, conectou o projeto de forma efetiva à comunidade Python
• McKinney iniciou o doutorado em estatística na Duke em 2010, mas tirou licença ao ver o interesse de empresas financeiras por ferramentas de dados em Python e o potencial de crescimento do Pandas
• Na época, o Pandas 0.1 tinha recursos limitados a ponto de não suportar todos os tipos de joins, e ele deixou a pós-graduação para se concentrar no crescimento do projeto
• Depois de avaliar um negócio de tecnologia financeira, passou a escrever Python for Data Analysis e a fundar uma startup de BI; em 2013, concluiu que seria difícil competir com a Looker no mercado de BI e entrou na Cloudera
• Na Cloudera, conectou-se aos desenvolvedores do Impala, conheceu vários engenheiros que mais tarde atuariam em Iceberg, Databricks e outros projetos, e essa experiência serviu de base para sua carreira posterior
• O projeto Arrow começou no início de 2016 na Cloudera, mas, no mercado de software empresarial da época, era difícil garantir orçamento para uma equipe dedicada a tecnologias experimentais
• Entre 2016 e 2018, aplicou o Arrow a sistemas reais em empresas financeiras para acelerar workloads de processamento de dados e melhorar o Parquet
• Em 2018, várias empresas quiseram financiar o desenvolvimento do Arrow, mas, devido às regras das instituições financeiras, era difícil administrar recursos externos; então, em abril, ele criou uma organização independente capaz de receber patrocínio corporativo
  • Cerca de seis patrocinadores participaram, incluindo empresas de hardware como Nvidia e instituições financeiras
  • Foi formada uma equipe de desenvolvimento de cerca de oito pessoas
• Depois de confirmar oportunidades comerciais, a organização se transformou na Ursa Computing durante a pandemia de COVID-19, em 2020

Problemas de engenharia de dados que ainda permanecem

• Ainda hoje, a área de dados resolve repetidamente os problemas de mover dados de A para B, converter formatos, carregá-los na memória e executar consultas e transformações com eficiência
• O Pandas se tornou uma base que sustenta muito mais fluxos de dados corporativos do que se esperava, e hoje é possível que LLMs gerem mais código Pandas do que humanos escreveram no passado
• DuckDB é uma ferramenta tão poderosa que desenvolvedores de 20 anos atrás dificilmente conseguiriam imaginá-la
  • Pode ser instalado gratuitamente e executado em diversos ambientes
  • Pode funcionar até em celulares e navegadores web
  • Oferece análise de alto desempenho em uma única máquina, sem instalações complexas
• Longos períodos de incômodo e tentativa e erro deixaram clara a necessidade de tecnologias como DuckDB e Arrow, e várias soluções, incluindo Parquet, foram influenciadas por tecnologias criadas por grandes empresas de internet como o Google para reduzir custos e tempo
• O Parquet não é o melhor formato, mas melhorou muito em relação ao passado e é compatível com praticamente todos os sistemas
  • Mesmo havendo alternativas especializadas como Vortex e Lance, ele continua em uso graças à sua compatibilidade boa o suficiente
• Com a IA ocupando a atenção do setor, a visibilidade da engenharia de dados diminuiu, e até anúncios de novos motores de dados pela Databricks recebem menos atenção do que antes
• Por outro lado, para desenvolvedores de ferramentas de dados, isso abre espaço para não correr atrás de modas e focar na maturidade técnica, além de usar IA em tarefas repetitivas e incômodas, como escrever testes

Convergência para tecnologia de bancos de dados

• Uma das principais lições da era do big data é que teria sido melhor aproveitar mais cedo os artigos e resultados de conferências dos pesquisadores de bancos de dados
• É importante adotar uma abordagem de ler, implementar e colaborar com pesquisas de bancos de dados de instituições como TU Munich, CWI, MIT, CMU e Berkeley
• Na era centrada em NoSQL e armazenamentos não relacionais, sistemas escaláveis às vezes adicionavam tanto overhead que ficavam mais lentos do que implementações bem feitas em uma única máquina e uma única thread
• O estudo Scalability! But at what COST?, com participação de Frank McSherry, Michael Isard e outros, trata do custo pago para obter escalabilidade
• A stack moderna de dados converge novamente em torno de tecnologia de bancos de dados e processamento colunar
  • Polars, Daft e DataFusion usam Arrow
  • O novo motor do dbt utiliza ADBC
  • O Databricks Photon adota uma estrutura colunar, independentemente de usar Arrow ou não
• À medida que os principais sistemas convergem para arquiteturas e abordagens semelhantes, a questão mais importante passa a ser a facilidade de usar o software na prática, mais do que o método central de processamento

Melhoria de usabilidade do Hadoop ao DuckDB

• Na era Hadoop, por causa de Java, arquivos de configuração XML e inúmeros parâmetros de ajuste, às vezes era preciso gastar cerca de dois dias configurando tudo antes de começar o trabalho real
• O Spark foi uma grande melhoria por permitir escrever contagem de palavras em uma linha, mas ainda exigia preparar infraestrutura e arquivos de configuração
• A forma de instalação e execução do DuckDB é um modelo de usabilidade que mostra o quanto sistemas de dados podem se tornar simples
• Sistemas distribuídos também deveriam oferecer padrões razoáveis e configurações que funcionem de imediato para reduzir a complexidade operacional
• O DuckDB também está se expandindo para a área cliente-servidor e colabora estreitamente com a MotherDuck

Camada de dados multimodais para IA generativa

• Lakehouses existentes são centrados em dados tabulares e Parquet, mas treinamento e fine-tuning de IA generativa e grandes modelos exigem imagens, vídeos, textos, documentos e logs em conjunto
• O lakehouse de dados multimodais tratado pela LanceDB corresponde a um problema empresarial real
• Quando embeddings são gerados a partir de grandes volumes de dados não estruturados, há consumo de energia e tempo de GPU, de modo que os embeddings resultantes também passam a ter valor econômico pelo custo computacional envolvido
• Em ambientes de produção, é necessário um armazenamento de dados capaz de guardar, gerenciar e processar de forma confiável os dados originais e os resultados gerados
• Se toda empresa criar seu próprio armazenamento multimodal, pode repetir problemas de bugs, perda de dados e desempenho; por isso, é mais eficiente que fornecedores especializados de software ofereçam soluções comuns
• Mesmo que seja possível operar diretamente tabelas Iceberg, delegar a gestão a provedores como Databricks, Snowflake e AWS reduz a complexidade operacional; a mesma lógica se aplica a dados multimodais para IA generativa
• No mercado de dados para IA generativa, ainda há espaço para resolver diferentes camadas, de busca vetorial em documentos e processamento de alto QPS até gestão do ciclo de vida dos dados

Competitividade dos desenvolvedores na era da IA

• McKinney já se perguntou se ele próprio ainda teria futuro como engenheiro de software, mas concluiu que a IA diferencia as pessoas de forma mais clara pelo nível de iniciativa
• Pessoas com alta iniciativa, que refletem sobre o que criar e têm gosto e julgamento para identificar bons resultados, conseguem grande amplificação de produtividade com IA
• LLMs oferecem, para a maioria dos problemas, uma abordagem de nível B+ média e aceitável, mas não criam experiência, gosto e julgamento no lugar do usuário
• Se código gerado continuar sendo adicionado sem bom julgamento, forma-se um atoleiro complexo, e até agentes passam a ter dificuldade de continuar trabalhando, pressionados pelo contexto e pela estrutura
• No passado, a implementação manual desenvolvia ao mesmo tempo habilidade técnica e julgamento; daqui para frente, como o tempo de codificação manual diminui, será preciso cultivar separadamente a compreensão de sistemas e a capacidade de design

O que estudar na era da IA

• Novos desenvolvedores precisam estudar design e arquitetura de software e a estrutura de sistemas de dados, em vez de apenas aprender a sintaxe de Python ou Java
• Em engenharia de dados, é preciso entender como sistemas diferentes, como arquiteturas Lambda e Kappa, funcionam e para quais problemas são adequados
• É necessário comunicar com precisão ao agente o resultado desejado e perceber quando ele segue em uma direção errada
• Se o usuário não consegue julgar se A ou B é melhor, o agente também não pode garantir a escolha correta no lugar dele
• Engenheiros de software, engenheiros de dados e cientistas de dados provavelmente passarão mais tempo em definição de problemas e comunicação do que escrevendo código
• Se você não consegue explicar o que quer, também não conseguirá obter o resultado desejado com IA; simplesmente adicionar IA a uma organização não aumenta automaticamente produtividade e resultados econômicos
• Fornecer IA a pessoas sem experiência e julgamento suficientes pode transformá-las em um canhão de slop (slop cannon) que gera, em massa, mais dívida a ser resolvida por outras pessoas do que resultados úteis

Mais decisões e investimento organizacional em IA

• Nos próximos 2 a 5 anos, contratação de desenvolvedores, entrevistas técnicas e distinção de funções podem ficar confusas e mudar rapidamente
• Antes, por meio de reuniões, planejamento de sprints e planning poker, a equipe construía uma convicção comum sobre o trabalho e depois dividia a implementação
• Agora, o processo tradicional de planejamento ágil pode ser comprimido dentro do modo de planejamento do Claude, criando situações em que um único desenvolvedor precisa tomar inúmeras decisões sozinho
• Um desenvolvedor que precisa tomar 10 vezes mais decisões por dia do que antes pode travar por fadiga decisória e ambiguidade
• Pessoas que julgam rapidamente e definem caminhos eficientes conseguem aproveitar a produtividade da IA, mas, para quem não tem certeza do que deve fazer, a IA não resolve esse problema
• Empresas podem pagar muito dinheiro à Anthropic e à OpenAI e ainda assim ter dificuldade de verificar o retorno do investimento em IA
  • Junto com alguns resultados positivos, também surgem desperdício, entregas de baixa qualidade e custos para limpar essas entregas
  • Provedores de modelos de IA lucram enquanto a venda de tokens continua, mas clientes provavelmente passarão a aplicar orçamentos de tokens mais rigorosos

Modelos de pesos abertos e economia de tokens

• McKinney executou o modelo chinês de pesos abertos GLM 5.2 em infraestrutura física e avaliou que os resultados foram bons
• O GLM 5.2 não é um modelo pequeno e, para executá-lo corretamente, são necessárias cerca de 8 GPUs B200
  • O preço de uma B200 é estimado em cerca de US$ 30 mil a US$ 50 mil
  • O custo total de hardware pode chegar a cerca de US$ 250 mil a US$ 400 mil
• No longo prazo, espera-se que, com a melhora da qualidade dos modelos de pesos abertos e a queda do preço do hardware, seja possível não pagar continuamente a empresas externas de IA e arcar apenas com a eletricidade de servidores próprios
• Calculados pelo preço de tabela da API, os tokens usados nos últimos 30 dias somariam cerca de US$ 37 mil, mas o valor realmente pago aos provedores de modelos foi muito menor
• É possível que os preços atuais de tokens incluam grandes subsídios, e ainda é incerto qual estrutura de custos será sustentável no longo prazo
• A adoção de IA também não é tão uniforme quanto a atenção do setor sugere; algumas empresas continuam na cauda longa, apenas discutindo o tema em nível de conselho e CTO, sem iniciar a aplicação prática