weekly prompts 02 | escolha de ferramentas e linguagens
o Claude pode pensar mesmo, tipo... sentir?
essa é uma seção de tecnologia da news experimental, siga essa news também no linkedin & você pode se desinscrever dessa seção e se manter nas outras se quiser (:
21 de fevereiro de 2026
o bafafá da semana é até o CEO da Anthropic se perguntando se a inteligência artificial deles é um ser consciente ou não (!) Claude se dá 15 a 20% de chance de ser consciente, aparentemente.
curioso, porque neurocientistas já estimam que 95% da nossa própria atividade cognitiva acontece fora da consciência. como um ser inconsciente avalia a consciência de sua própria criação? rs eis a questão.
enfim, vamos falar de outra coisa que a gente acha que tem controle sobre: decisão sobre as ferramentas pra construir software. hoje, 3 aprendizados:
se já tem muita coisa funcionando, não vale a pena refazer do zero
não troque de ferramenta se o problema não é a ferramenta
com tantas opções e variações, não saber qual é a melhor é normal
bora lá (:
aliás, stack, arquitetura, ferramentas, tecnologia... todo mundo do mercado fala da mesma coisa de formas diferentes. se você leu a edição passada sobre linguagem ubíqua, tá aí mais um exemplo. [link]
1. git merge: quando “precisa refazer tudo”
decidir com quais ferramentas construir sua ideia de software é um passo importante, principalmente quando você não é uma pessoa programadora: o que é o caso da maioria das pessoas de negócio.
pra pequenas e médias empresas, essa decisão pesa mais porque o orçamento pra voltar atrás geralmente não existe, eles escolhem uma stack e convivem com ela. mas curiosamente, o que vi nos últimos anos é: empresas com menos capital querendo trocar de tecnologia, mesmo quando a solução atual funciona...
enquanto empresas grandes, que teriam mão de obra e recursos pra otimizar, acabam anos arrastando as mesmas soluções ineficientes. os dois extremos custam caro, mas hoje vou falar do primeiro.
o Joel Spolsky escreveu um artigo clássico sobre isso: em 2000, ele contou a história da Netscape: eles olharam pro código do navegador, decidiram que tava feio demais e reescreveram tudo do zero. levou três anos.
enquanto isso, o Internet Explorer comeu o mercado deles. a Netscape praticamente morreu por causa dessa decisão.
o argumento do Spolsky é: código velho é feio, mas funciona. aquelas gambiarras que parecem não fazer sentido geralmente são correções de bugs reais que alguém descobriu da pior forma possível.
quando você reescreve do zero, joga fora todo esse conhecimento acumulado e vai redescobrir cada um desses bugs de novo. claro que agora com IA o custo de tempo pra codar é bem menor, mas ainda vale a leitura se você já pensou em “refazer tudo do zero”... vou deixar o link no fim do post.
__
2. git log: a troca que não precisava acontecer
a cereja do bolo nesse tópico das minhas experiências com clientes foi um projeto de automação fiscal construído inteiro em Python: scrapers que navegavam portais de prefeituras de vários municípios brasileiros, quebravam captchas, baixavam XMLs de notas fiscais e se comunicavam via Azure Service Bus.
um robô que já tava rodando, já tinha clientes, já tinha uma arquitetura modular com factory pattern pra cada município: login, extração, parsing, tudo configurável. e com menos de dois anos de solução, a empresa resolveu trocar tudo pra Java...
por “meras“ questões interpessoais internas da empresa. acabou que foram algumas reuniões com um dev mais sênior apresentando uma arquitetura que basicamente tinha os mesmos elementos da anterior.
o argumento principal era que os scrapers rodariam melhor em paralelo com Java... e sim, Java tem multithreading nativo e um ecossistema maduro pra concorrência, mas Python tem asyncio, tem Celery, tem Scrapy com pipelines assíncronas, tem multiprocessing.
a maior parte das soluções de coleta de dados em produção hoje roda em Python, desde scrapers simples até pipelines de dados de empresas como Spotify e Instagram. ou seja, esse tipo de solução também deve suprir uma empresa de médio porte.
o gargalo de um scraper quase nunca é a linguagem: é I/O, é rate limiting da fonte, é parsing mal feito, é falta de tratamento de erro. ou seja, se dessem mais horas pros outros devs na solução original ou contratassem mais, tudo seria feito em Python com as ferramentas que o ecossistema já oferece.
__
git notes
fora isso, esse caso me deixou uma outra reflexão: é bom lembrar que aprendizado não é linear e que o tempo de curva de aprendizado pra trocar de solução quase nunca é calculado.
e não tô falando só de dinheiro, essa tarefa retrabalhosa pode levar o time ao burnout (a.k.a. estafa), menos rendimento, menos motivação, menos coesão dos times... fica nas entrelinhas. a maioria dos devs gosta de resolver problemas e aprender coisas novas, vai dizer sim pra mudança, mas tem todo esse custo escondido aí.
escolhi essa historinha porque todos nós já vimos variações dela, e é um tópico recorrente no desenvolvimento de software que vai ficar ainda mais comum agora com o boom de promessas de opções milagrosas e soluções mais eficientes com IA...
___
git diff: dois devs, mesmo problema, respostas diferentes
já no caso de devs solo (como comentei no último post) a escolha de arquitetura não precisa de votos do time, é sua e só sua a responsa e lidar com o que escolheu depois, pro bem e pro mal rs essa semana tive uma prova de como o mesmo problema gera soluções completamente diferentes.
fiz uma reunião com uma pessoa que construiu algo similar ao que tô construindo, sendo usado lá na Espanha. aqui alguns pontos técnicos que vimos: ambos precisamos armazenar coordenadas no banco de dados, mas eu uso Supabase e ele usa PostgreSQL com PostGIS.
como o Supabase roda em cima de PostgreSQL, então em teoria eu poderia habilitar a extensão PostGIS e ter o melhor dos dois mundos: queries geoespaciais nativas tipo “me dá todos os imóveis num raio de 5km desse ponto”. hoje não faço isso. faço a filtragem geográfica mais no front do que no banco, o que provavelmente não vai escalar bem.
por falar em geo-referenciamento, a solução dele conta com uma base de dados espanhola mais centralizada, com poucos dados faltando. já a minha tem dezenas de milhares de propriedades, a maioria sem latitude e longitude, uso a API do Mapbox pra popular essas informações. então pra ele, Mapbox é mais só visualização, enquanto pra mim, é infraestrutura de dados também.
porém, na visualização eu uso o Mapbox GL JS direto no client side: controle total sobre camadas, filtros, popups, clusters, tudo via código. ele usa o Mapbox Studio pra montar, embeda no front e disse que assim a experiência do usuário fica mais rápida e fluída.
e o engraçado é que nenhum dos dois “escolheu“ a abordagem do mapa de propósito. eu uso Next.js, ele usa Angular: o Mapbox GL JS se integra naturalmente com React, então meter a mão no código foi um caminho agradável. no Angular, embedar pelo Studio evita uma dor de cabeça... então meio que a stack induziu a escolha do uso do mapa.
também vale pensar que ele escolheu a stack dele há 3 anos atrás, eu escolhi a minha agora... e obvio que daqui 3 anos os dois vão olhar pra solução e pensar “da pra fazer isso e isso diferente“. a lista só cresce e ninguém tem tempo de testar tudo antes de decidir ou mudar completamente a stack pra acompanhar o moderno e mais, mais otimizado.
a Netscape reescreveu o navegador do zero e perdeu o mercado. a empresa trocou de Python pra Java com o produto rodando e provavelmente pagou um custo a mais por isso sem super precisar. e dois devs que nunca se falaram, resolvendo o mesmo problema com ferramentas parecidas, fizeram escolhas opostas... e os dois funcionam.
as pessoas gostam de discutir infinitamente as ferramenta, mas nesse três casos de escalas totalmente diferentes, o problema nunca foi a ferramenta. se você é dev e tá perdido nesse mar de opções, ou se você é de negócios e não entende por que cada dev sugere uma stack diferente:
bem-vindo ao clube. não tem receita 100% certa, tem o quase ideal e tem o que funciona pro seu contexto agora: você escolhe com o que sabe, constrói, e ajusta no caminho de forma razoável. o importante é solucionar as dores dos usuários.
__
outras branches
links e referências que me chamaram atenção na semana
_ Joel Spolsky, “Things You Should Never Do, Part I”: por que reescrever software do zero quase sempre é a decisão errada. escrito em 2000, ainda relevante. [link]
_ Dario Amodei no podcast “Interesting Times” do NYT sobre não saber se o Claude é consciente. [link]
_ sobre a referência de neurociência: o número 95% vem de estudos em neurociência cognitiva, é debatido mas amplamente citado. o estudo do Max Planck Institute mostrou que dá pra prever a escolha de uma pessoa até sete segundos antes dela conscientemente decidir. [link], mas descobri isso pelo livro do Sam Harris “Free Will“ (2012) que muito recomendo [link]
Até o próximo commit, Michelle (:
