Por muitos anos, contudo, manter o XP exigia um esforço disciplinar enorme das equipes. O custo de escrever testes exaustivos, refatorar constantemente ou manter o alinhamento em pares nem sempre escalava sem fricção.

Com a popularização dos Modelos de Linguagem (LLMs), Copilotos e Agentes de Código, essa dinâmica mudou drasticamente. As IAs generativas de código não vieram para substituir a engenharia de software, mas sim para eliminar a fricção mecânica do desenvolvimento.

Ironicamente, a IA tornou os princípios do Extreme Programming mais atuais, práticos e extremamente viáveis do que nunca.

⚡ A Recontextualização dos Princípios do XP com IA

1. Pair Programming $\rightarrow$ Desenvolvedor como Navigator, IA como Driver

No XP tradicional, dois desenvolvedores compartilham a mesma estação de trabalho: um Driver (escreve o código) e um Navigator (revisa em tempo real e pensa na arquitetura/cenários futuros).

Com assistentes e agentes modernos:

• A IA assume o papel de Driver: Escreve a sintaxe, cuida do boilerplate, lida com tipos e rascunha a implementação inicial.
• O Engenheiro assume o papel definitivo de Navigator: Foca na validação dos requisitos de negócio, arquitetura do sistema, edge-cases e alinhamento com a intenção original.

┌────────────────────────────────────────────────────────┐
│               FLUXO DE PAIR PROGRAMMING                │
├───────────────────────────┬────────────────────────────┤
│         XP TRADICIONAL    │        XP + IA             │
├───────────────────────────┼────────────────────────────┤
│ Driver: Dev 1 (Sintaxe)   │ Driver: Agente de IA       │
│ Navigator: Dev 2 (Design) │ Navigator: Engenheiro      │
└───────────────────────────┴────────────────────────────┘

2. Feedback Rápido & “Errar Mais Rápido”

Um dos pilares morais do XP é que falhar cedo é infinitamente mais barato do que descobrir um erro em produção.

Antes, rodar uma hipótese de arquitetura ou protótipo levava dias. Com ferramentas de geração e execução assistida:

• O ciclo de hipótese $\rightarrow$ código $\rightarrow$ execução $\rightarrow$ diagnóstico cai de horas para microssegundos.
• A IA permite gerar suítes de testes de estresse, simular falhas e validar ideias em minutos.
• Errar rápido e barato tornou-se a vantagem competitiva central de quem desenvolve com agentes.

3. TDD (Test-Driven Development) sem a Barreira do Custo

Apesar de ser aclamado, o TDD costumava ser abandonado em prazos apertados devido ao tempo necessário para escrever cenários de teste complexos e mocks.

Com IA, entramos no Generative-TDD:

1. O desenvolvedor escreve a especificação e as asserções de contrato (ou pede à IA para sugerir os cenários limite).
2. A IA gera a suíte de testes unitários ou de integração (fase Red).
3. O desenvolvedor/IA implementa a menor quantidade de código possível para fazer os testes passarem (fase Green).
4. A IA sugere otimizações mantendo a suíte verde (fase Refactor).

4. Refatoração Merciless (Sem Piedade)

No XP clássico, o código deve ser constantemente limpo e simplificado. Porém, em sistemas legados grandes, refatorar sem quebrar dependências implícitas causava apreensão.

Com modelos de contexto amplo e análise estática via IA:

• Refatorações de arquivos inteiros, renomeações de APIs, adequação a design patterns e migração de versões são realizadas de forma assistida e segura.
• A hesitação em “mexer no código que está funcionando” desaparece quando o custo do Refactor tende a zero e a suíte de testes valida as mudanças instantaneamente.

5. Design Simples (KISS / YAGNI)

O princípio YAGNI (You Aren’t Gonna Need It) prega que você não deve adicionar funcionalidades até que sejam estritamente necessárias.

Com a IA capaz de gerar centenas de linhas em segundos, a tentação da superengenharia aumenta. É aqui que a disciplina XP se destaca:

• O papel do engenheiro é restringir o escopo e exigir que a IA proponha o design mais simples possível.
• Em vez de aceitar abstrações desnecessárias criadas pelo modelo, o dev exige a solução mínima elegante.

🎯 Conclusão

A IA não eliminou a necessidade de bons princípios de software — na verdade, aumentou o valor deles.

Um desenvolvedor sem método usando IA apenas produz código ruim mais rápido. Por outro lado, um desenvolvedor que aplica os princípios do Extreme Programming (feedback contínuo, simplicidade, testes e parceria de código) consegue multiplicar a entrega de valor com um nível de qualidade sem precedentes.

Porém, quando o assunto é dado estruturado ou semi-estruturado (como planilhas Excel, CSVs ou grandes JSONs), jogar a massa de dados inteira para a janela de contexto do modelo é um dos erros arquiteturais mais caros e ineficientes que podemos cometer.

A pergunta que devemos nos fazer é: Será que não existe uma maneira mais barata, rápida e precisa de resolver isso usando ferramentas determinísticas para auxiliar o modelo?

Neste artigo, compartilho a filosofia de usar o LLM apenas como um compilador de intenção, delegando o processamento pesado para motores determinísticos.

💡 O Paradigma: LLM como Roteador de Intenção, não como Engine de Execução

Modelos de linguagem são probabilísticos. Eles são ótimos para inferir o que precisa ser feito, mas não para realizar operações matemáticas, paginações ou transformações repetitivas em grandes volumes de dados.

A literatura acadêmica e a prática de engenharia já comprovaram limitações severas da dependência cega da janela de contexto:

1. Lost in the Middle: Pesquisadores de Stanford, UC Berkeley e Samaya AI (Liu et al., 2023) demonstraram no estudo “Lost in the Middle: How Language Models Use Long Contexts” que o desempenho dos LLMs cai drasticamente quando a informação necessária está no meio de um contexto longo, mesmo em modelos treinados para 100k+ tokens.
2. Custo e Latência Quadrática/Linear: Manter contextos massivos infla o custo por requisição e aumenta a latência de resposta a níveis inaceitáveis para produção.
3. Alucinação Numérica e Estrutural: LLMs prevêem o próximo token mais provável; eles não possuem uma ULA (Unidade Lógica e Aritmética) nativa para garantir agregamentos exatos ou estruturas de chave-valor estritas.

O Fluxo Híbrido LLM + Motor Determinístico

┌─────────────────┐       Sintaxe / Query       ┌────────────────────────┐
│   Prompt LLM    │ ──────────────────────────> │  Motor Determinístico  │
│ (Intenção/DDL)  │                             │  (DuckDB / JSONata)    │
└─────────────────┘                             └────────────────────────┘
                                                            │
                                                     Dados │ Filtrados
                                                           ▼
                                                ┌────────────────────────┐
                                                │ Mapeador Programático  │
                                                │  (JSON de Saída 100%)  │
                                                └────────────────────────┘

1. LLM (Probabilístico): Lê os metadados (esquema, nomes de colunas, chaves do JSON) + a intenção do usuário e gera uma instrução determinística (uma query SQL ou uma expressão JSONata).
2. Motor Determinístico: Executa essa instrução diretamente na memória do servidor com velocidade nativa (C++/Rust) e custo zero de tokens.
3. Mapeador Programático: Transforma o resultado no formato final esperado pela aplicação via código determinístico.

📊 Cenário 1: Processando Planilhas Grandes sem Estourar Contexto (O Padrão DuckDB)

O Problema Tradicional

Você tem uma planilha Excel com milhares de linhas ou múltiplas abas e precisa extrair apenas certas informações para alimentar uma API. A abordagem ingênua é converter a planilha para texto/HTML/Markdown e injetar tudo no prompt.

A Abordagem Determinística (DuckDB + SQL)

Em vez de enviar os dados da planilha para o modelo:

1. Envie apenas o Esquema (DDL): Converta a planilha para tabelas temporárias no DuckDB (um banco OLAP analítico de altíssima performance em memória) e extraia apenas a DDL dos esquemas (CREATE TABLE table_0 ("data" DATE, "valor" DOUBLE, ...)).
2. Peça ao LLM para Gerar SQL: O prompt recebe apenas o esquema e a lista de entidades desejadas. O LLM retorna uma consulta SQL compatível com DuckDB, utilizando aliases (AS) que correspondem exatamente aos identificadores dos campos solicitados.
3. Execução Local Nativa: O DuckDB executa a query em microssegundos direto na memória local.
4. Mapeamento via Código: Um script simples lê a tabela resultante já filtrada e monta a estrutura JSON de saída com 100% de precisão estrutural.

Ganha-se: Custo reduzido drasticamente (tokens caem de centenas de milhares para poucas centenas do esquema), zero risco de alucinação de dados e processamento instantâneo.

🔄 Cenário 2: Transformando e Filtrando JSONs Complexos (O Padrão JSONata)

O Problema Tradicional

Você recebe um payload JSON gigante de uma API externa com dezenas de níveis aninhados, arrays e atributos irrelevantes, e precisa reformatar esse JSON para um esquema simplificado. Passar o JSON inteiro para o LLM reescrever é ineficiente e propício a erros de digitação de chaves.

A Abordagem Determinística (JSONata)

Em vez de pedir para o LLM reescrever a string do JSON:

1. Apresente o Esquema ao LLM: Passe uma amostra das chaves do JSON e a estrutura desejada.
2. Gere uma Expressão JSONata: O LLM atua apenas gerando uma consulta declarativa em JSONata (linguagem leve de consulta e transformação de dados JSON).
3. Execução pelo Evaluator JSONata: Um evaluator JSONata na sua aplicação aplica a expressão diretamente sobre o JSON original em memória.

Ganha-se: Nenhuma mutação acidental de dados, garantia de tipo, performance de microssegundos e facilidade de auditar a regra de transformação gerada.

🛠️ O Paralelo com Agentes Modernos (ex: Claude Code)

Esta filosofia de não confiar a memória inteira ao LLM e sim delegar para ferramentas determinísticas não é nova. É a base de engenharia por trás do Claude Code e de agentes autônomos de código:

• Gerenciamento de Memória por Apontadores: O Claude Code não mantém o histórico completo do seu repositório na janela de contexto (o que destruiria o orçamento de tokens e a atenção do modelo).
• Offloading para Sistema de Arquivos: Ele lê e grava arquivos locais (CLAUDE.md, arquivos temporários de planejamento) como estado de verdade e dispara ferramentas determinísticas nativas (grep, glob, ast-grep) para recortar cirurgicamente apenas as linhas necessárias antes de raciocinar sobre elas.

🛡️ Pormenores e Resiliência na Prática

Quando aplicamos essa estratégia no dia a dia em produção, é crucial incluir pequenas camadas de proteção (Guardrails):

1. Normalização Prévia de Esquemas: Nomes de colunas em planilhas humanas frequentemente vêm sujos, com espaços ou caracteres especiais. Fazer uma higienização simples (col.strip().lower().replace(" ", "_")) reduz falhas de sintaxe SQL drasticamente.
2. Prompts Rígidos de Identificadores: Instrua o LLM a sempre utilizar aspas duplas nos identificadores de colunas e tabelas ("coluna" AS "entidade") para evitar erros de parser SQL no DuckDB.
3. Fallbacks Gracioso em Camadas: Se o LLM gerar uma consulta SQL/JSONata com erro de sintaxe, sua aplicação deve tratar o erro de forma resiliente:
   • Fallback por Tabela: Se a query de uma aba falhar, capture o erro e recupere a tabela original completa via SELECT * FROM table_name.
   • Fallback por Pipeline: Se o motor falhar por completo, a aplicação pode recorrer à estratégia tradicional de loteamento/paginação.

📌 Conclusão

Sempre que você estiver prestes a enviar uma massa de dados estruturados para um LLM, pergunte-se: Eu preciso que a IA processe estes dados, ou preciso apenas que ela entenda o que fazer e escreva a instrução de processamento?

Na maioria das vezes, combinar a capacidade de interpretação do LLM com motores determinísticos em memória como DuckDB e JSONata vai te entregar uma solução mais barata, infinitamente mais rápida e com zero margem para alucinações.

Para responder a essa pergunta com dados reais, desenvolvi um inspector de tecnologia assíncrono em Python capaz de coletar, resolver domínios e analisar a tech stack de todas as 5.571 prefeituras catalogadas pelo IBGE.

Neste artigo, compartilho os principais achados do estudo, os gráficos com as estatísticas nacionais e os detalhes técnicos do crawler que desenvolvi.

📊 Principais Descobertas e Análise dos Dados

Dos 5.571 municípios catalogados pelo IBGE, o crawler localizou e analisou com sucesso 5.107 prefeituras ativas (91,67% de taxa de resolução).

1. PHP é o Rei Absoluto do Backend Municipal

Ao analisar as linguagens e linguagens server-side identificadas:

• PHP: Está presente em 77,8% (3.973 prefeituras) dos sites analisados.
• ASP.NET (Microsoft): Representa 26,2% (1.338 sites), refletindo portais legados e sistemas corporativos.
• Java: Presente em 16,4% (838 sites).
• Laravel (PHP): Aparece em 8,0% (408 sites) como a escolha moderna para novos portais sob medida.
• Python e Node.js: Representam juntos cerca de 5,5% do total.

2. CMS: WordPress Domina a Comunicação Institucional

Em termos de Gerenciadores de Conteúdo (CMS):

• WordPress: É a plataforma isolada mais utilizada, identificada em mais de 1.480 prefeituras (~30% do total).
• Joomla: Mantém presença histórica em 170 prefeituras.
• Drupal & GovBR/Plone: Utilizados principalmente por capitais e grandes metrópoles devido aos requisitos de acessibilidade e governança.
• Wix: Identificado em 72 pequenos municípios.

3. Servidores Web e a Crescente Adoção de Cloudflare

• Apache (32,5%) e Nginx (26,1%) dividem a liderança do processamento web.
• Cloudflare: Detectado em 994 sites (19,4%), revelando uma forte preocupação das prefeituras com proteção contra ataques de negação de serviço (DDoS), aceleração via CDN e certificados SSL gratuitos.

4. Frontend: Bootstrap Universal e Elementor em Alta

• Bootstrap: Presente em impressionantes 86,3% (4.406 sites) dos portais. Tornou-se o padrão de facto para garantir responsividade no setor público.
• jQuery: Ainda acompanha 55,5% (2.836 sites).
• Elementor: O page builder visual do WordPress foi detectado em 551 prefeituras (10,8%), facilitando a edição por equipes municipais sem conhecimento técnico de código.
• React & Vue.js: Apresentam adoção em crescimento (5,2% e 2,0% respectivamente), impulsionados por novos portais de transparência construídos como Single Page Applications (SPAs).

🛠️ A Engenharia por Trás do Crawler (3 Minutos para 5.570 Sites)

Varrer mais de 5.500 domínios com checagem de respostas HTTP, parsing de cabeçalhos e análise de HTML pode levar horas se feito de forma síncrona.

Para resolver o problema da escala e da performance, a arquitetura do projeto foi estruturada em módulos desacoplados:

1. Coleta de Dados e Resolução de Domínios:
   • Integração com a API do IBGE + cruzamento com dados abertos da comunidade.
   • Algoritmo de normalização e permutação de URLs (.gov.br, pm...gov.br, sem conectores de/da/do).
2. I/O Assíncrono com aiohttp e asyncio:
   • Utilização de asyncio.Semaphore para controlar a concorrência sem sobrecarregar a rede ou a resolução DNS local.
   • Ajuste de connect timeout para 2.5s, descartando rapidamente domínios inativos sem travar o worker.
   • Com concorrência em 100 requisições simultâneas, o pipeline completo executou em apenas 2 minutos e 40 segundos (uma taxa de ~30 sites/segundo).
3. Tech Inspector (Fingerprinting):
   • Inspeção de cabeçalhos HTTP (X-Powered-By, Server, Set-Cookie, X-Generator).
   • Parsing do HTML com BeautifulSoup em busca de meta tags, caminhos de scripts estáticos (wp-content, sites/all/themes) e objetos em memória de frameworks SPA/SSR (__NEXT_DATA__, __NUXT__).

⚠️ Limitações da Pesquisa: Os 8,33% Não Raspados

Cerca de 464 prefeituras (8,33%) não puderam ter sua tech stack raspada ou identificada durante esta edição da pesquisa. As razões observadas foram:

1. Domínios Inativos ou Inexistentes: Pequenos municípios que não possuem portal próprio oficial ativo no momento da varredura.
2. Bloqueios de Segurança (WAF / Rate Limit): Firewalls que rejeitam requisições automatizadas em lote sem navegação completa de browser.
3. Erros de SSL/TLS & Servidores Fora do Ar: Certificados com erro de cadeia ou servidores temporariamente inalcançáveis.

🤝 Créditos e Fontes de Dados Abertos

Construir um estudo dessa magnitude exige reconhecer o trabalho fundamental da comunidade de dados abertos no Brasil:

• API de Localidades do IBGE: Fonte dos dados cadastrais dos 5.571 municípios.
• Dataset sites_prefeituras: Crédito e agradecimento especial ao projeto mantido por Franklin Baldo. A base pré-catalogada de URLs municipais acelerou significativamente a resolução de domínios.

🎯 Conclusão

O estudo revela uma infraestrutura municipal brasileira fortemente ancorada no ecossistema PHP + WordPress + Bootstrap + Apache/Nginx, combinada com uma transição contínua para camadas de segurança em nuvem (Cloudflare).

Código-Fonte e Dataset Aberto

O projeto completo, com código-fonte em Python estruturado em módulos e o dataset final em CSV e JSON com as 5.571 prefeituras, está disponível publicamente no GitHub:

🔗 GitHub: stacks-usadas-sites-prefeituras-brasil

Sinta-se à vontade para explorar o repositório, clonar o projeto ou utilizar a base de dados em suas próprias análises!