Como escolher um notebook para programação

O notebook caro que travava com três containers

Um amigo gastou uma pequena fortuna num notebook gamer "para programar". Processador topo de linha, placa de vídeo dedicada, números lindos de benchmark. Aí ele tentou rodar a stack do trabalho — Postgres, Redis e dois serviços em Docker — com o navegador e o editor abertos, e a máquina começou a engasgar. O problema não era o CPU. Eram os 16GB de RAM virando 16GB com swap. Ele otimizou o número errado, porque comprou olhando o que vende notebook, não o que faz diferença no dia de quem programa.

Aqui eu vou no que importa de verdade para uma máquina de desenvolvimento, e na ordem certa. De passagem, se você ainda fica em dúvida com a sopa de letrinhas de arquitetura na hora de escolher, vale entender a diferença entre 32 bits e 64 bits — é a base para não comprar nada legado por engano.

RAM primeiro, sempre

Se você só pode otimizar uma coisa, otimize a RAM. É o recurso que mais limita o dia a dia de desenvolvimento, porque programar moderno é manter muita coisa aberta ao mesmo tempo: IDE com indexação rodando, navegador com 30 abas, containers, banco local, talvez uma VM.

• 16GB é o piso. Abaixo disso você vai conviver com swap e lentidão assim que abrir um stack mínimo. Funciona para front-end leve e estudo, mas é o mínimo.
• 32GB se você roda containers ou VMs. Docker com vários serviços, Kubernetes local, máquinas virtuais, datasets grandes na memória — aqui 16GB acaba rápido, e a diferença de RAM se paga em produtividade no primeiro mês.

E um detalhe que pega muita gente: em notebooks com RAM soldada (boa parte dos finos e dos Apple Silicon), você não troca depois. O que você compra é o que você tem pela vida útil da máquina. Por isso eu sempre digo: na dúvida entre subir o CPU ou subir a RAM, suba a RAM.

SSD: tamanho e tipo importam

Depois da RAM vem o armazenamento. SSD NVMe não é luxo, é o que torna build, instalação de dependências e indexação do projeto rápidos. HD mecânico para desenvolvimento em 2026 é autoflagelo.

Tamanho importa mais do que parece. node_modules, imagens Docker, toolchains, repositórios — isso engole espaço numa velocidade absurda. Eu não compraria menos de 512GB, e 1TB é o ponto confortável se você lida com várias stacks. Disco cheio degrada performance e vira fonte constante de "deixa eu apagar umas imagens Docker pra conseguir buildar".

CPU importa menos do que o marketing diz

Aqui vai a opinião impopular: para a maioria dos devs, o CPU é o componente mais superestimado. A diferença entre um processador de geração atual mediano e o topo de linha aparece em compilação pesada de C++/Rust ou em quem faz processamento de dados local o dia todo. Para o desenvolvedor web, mobile e de back-end típico, qualquer CPU recente é mais que suficiente — você passa o tempo esperando rede, I/O e você mesmo pensando, não o processador.

Gastar o orçamento inteiro num CPU topo de linha e economizar na RAM é exatamente o erro do meu amigo. A não ser que você compile projetos gigantes várias vezes por dia, o ganho de CPU é marginal e o de RAM é diário.

Tela e teclado: você olha e digita 8 horas por dia

Esses dois são subvalorizados de forma criminosa. Você passa o dia inteiro encarando a tela e batendo no teclado — são as interfaces que mais afetam seu corpo e seu cansaço, e não aparecem em nenhum benchmark.

• Tela: priorize resolução decente (Full HD é o mínimo aceitável num painel de 13–14"), boa densidade de pixels para texto nítido, e brilho suficiente para o seu ambiente. Mais pixels = mais código visível = menos scroll.
• Teclado: curso de tecla confortável e layout sem firulas. Um teclado ruim você sente no fim do dia, nos dedos e na vontade de continuar.

Eu trocaria meio benchmark de CPU por uma tela melhor sem pensar duas vezes. Conforto sustentado bate pico de performance que você quase nunca usa.

ARM (Apple Silicon) versus x86

A pergunta de arquitetura virou real desde que o Apple Silicon (M1 e sucessores) mostrou que ARM em laptop não é compromisso — é, em muitos casos, superior em performance por watt. Bateria absurda, máquina silenciosa, performance excelente.

Para desenvolvimento, o ecossistema ARM amadureceu muito. Quase tudo roda nativo. Os poucos gotchas que sobram:

• Imagens Docker x86 antigas que não têm variante ARM rodam via emulação, mais lentas — cada vez mais raro, mas ainda acontece em stacks legadas.
• Dependências nativas muito específicas (binários compilados só para x86) podem dar trabalho.
• Ferramentas que assumem x86 em scripts de build mal escritos.

Na prática, para a esmagadora maioria dos devs em 2026, Apple Silicon é uma escolha excelente. Se a sua stack tem dependência pesada de imagens x86 legadas que você não controla, x86 ainda evita dor de cabeça. Caso contrário, ARM ganha em bateria e silêncio sem perder em capacidade.

Linux, WSL e bateria

Sobre sistema: se você trabalha o dia todo com ferramentas Unix (a maioria do back-end e DevOps), rodar Linux nativo ou WSL2 no Windows muda a sua vida — paridade com o ambiente de produção, sem a fricção de emular um Unix por cima do Windows. WSL2 hoje é bom o suficiente para que muita gente nem precise dual-boot.

Sobre bateria: ela importa mais se você é mobile de verdade (café, trem, reunião sem tomada). Máquinas x86 de alto desempenho costumam trocar bateria por potência; ARM entrega as duas. Mas se você vive plugado na mesa, não pague caro por autonomia que não vai usar — redirecione esse dinheiro para RAM ou tela.

Perguntas frequentes

Quanta RAM eu realmente preciso?

16GB é o piso absoluto e serve para desenvolvimento front-end leve e estudo. Se você roda containers Docker, VMs, ou múltiplos serviços locais ao mesmo tempo, vá de 32GB — e prefira RAM maior a CPU melhor quando o orçamento apertar, porque em muitos notebooks a RAM é soldada e você não atualiza depois.

Apple Silicon serve para qualquer tipo de desenvolvimento?

Para a grande maioria, sim, e com excelente bateria e performance. Os gotchas são raros: imagens Docker x86 legadas sem variante ARM rodam emuladas e mais lentas, e dependências nativas só compiladas para x86 podem dar trabalho. Se a sua stack não depende disso, ARM é uma escolha ótima.

Vale a pena pagar mais por um CPU topo de linha?

Só se você compila projetos grandes (C++, Rust) várias vezes por dia ou faz processamento de dados local intenso. Para web, mobile e back-end típico, qualquer CPU recente já sobra — o gargalo é rede, I/O e você pensando, não o processador. Coloque esse dinheiro em RAM, SSD e tela.

Linux ou Windows para programar?

Depende da stack. Para back-end e DevOps com ferramentas Unix, Linux nativo ou WSL2 dá paridade com produção e tira fricção. Para desenvolvimento .NET, jogos ou ferramentas que assumem Windows, o Windows nativo faz mais sentido. WSL2 hoje cobre bem a maioria dos casos Unix sem precisar de dual-boot.

O critério que eu aplicaria

Compre olhando o que faz diferença no seu dia, não o que faz a propaganda brilhar. A ordem é clara: RAM primeiro (16GB de piso, 32GB se há containers ou VMs), depois um SSD NVMe generoso, depois uma tela e um teclado que o seu corpo aguente por oito horas — e só então o CPU, que para a maioria dos devs já vem suficiente em qualquer máquina recente. Decida ARM versus x86 pela sua stack: Apple Silicon ganha em bateria e silêncio salvo dependência pesada de x86 legado. RAM e uma boa tela vencem benchmark de CPU para quase todo desenvolvedor — o notebook caro do meu amigo travava por ter otimizado exatamente o número errado.