Review técnico: HP EliteBook 860 G11 para dev com Docker e WSL

Eu gosto de recomendar notebooks “para dev” quando eles não só têm ficha técnica boa, mas também entregam previsibilidade no dia a dia: compilar rápido, aguentar várias coisas abertas, teclado confortável, e segurança/gerenciabilidade que não vire dor de cabeça. Foi exatamente nessa régua que eu olhei o HP EliteBook 860 G11 do Amazon, que aparece com Intel Core Ultra 7 155U, 16 GB de RAM, SSD de 512 GB e Windows 11 Pro (segundo o Amazon, com a página “Sobre este produto” destacando desempenho multitarefa e SSD). O ponto é: para programador, o “custo-benefício real” depende muito de como você vai usar VMs, containers e builds longas — e aí entram as armadilhas.

O que eu entendi da página do Amazon sobre o EliteBook 860 G11 (e por que isso importa pra dev)

Segundo o Amazon, o EliteBook 860 G11 vem com:

Tela de 16″ WUXGA (1920 x 1200)
CPU Intel Core Ultra 7 155U
16 GB de RAM
SSD de 512 GB
Windows 11 Pro
Tecnologia vPro e recursos de conferência/câmera

Na prática, para dev, isso vira três perguntas:

CPU: quantos minutos (ou horas) eu economizo em build e testes?
RAM: ele aguenta meu workflow com Docker/WSL, IDE, navegador e serviços locais juntos?
SSD: dá para manter imagens de container, caches e repositórios sem ficar “estrangulando” com I/O?

Eu gosto de quando o notebook “já nasce” com gerenciabilidade (como vPro) porque, em ambiente de empresa, isso reduz atrito com TI. Mas desempenho puro é outra história: tem que olhar RAM e swap — e isso a ficha técnica não diz sozinho.

Comparando por cenário: compilação, containers e IA local

1) Para quem compila e testa (backend, mobile, bibliotecas)

O Core Ultra 7 155U é uma boa aposta para produtividade geral. O que eu observo em notebooks com CPU “U-série” é que eles tendem a ser excelentes em responsividade, mas podem cair em throughput sustentado se o sistema estiver quente e ajustando frequência. Para dev, isso significa:

Se seus builds duram muito, observe temperatura e clock sustentado.
Se você faz “build + run + debug” em ciclos curtos, tende a ficar confortável.

O grande ganho aqui não é só “ser rápido”, é ser estável. Estabilidade derruba menos o foco. Em sessões longas de debug, isso pesa mais do que benchmarks isolados.

2) Para Docker/WSL e múltiplos serviços locais

O Amazon destaca que com 16 GB você consegue rodar vários programas simultaneamente sem degradação (conforme “Sobre este item”). Eu concordo como regra geral para tarefas comuns. Mas tem um detalhe que dev experiente detecta rápido:

16 GB é “limite confortável”, não margem gigante, especialmente se você usa containers + navegador + IDE.
Quando falta RAM, o sistema começa a usar swap no SSD, e o SSD de 512 GB até ajuda, mas não transforma troca de memória em velocidade de RAM.

Se você roda:

IDE (com TypeScript/Java/Kotlin/Python language server)
navegador (várias abas + devtools)
Docker com bancos (Postgres/Redis) e fila
às vezes WSL2

… então 16 GB pode funcionar. Porém, se seu projeto usa muitos workers (ou se você abre uma segunda IDE/terminal com outro ambiente), você começa a sentir. O que resolve não é mágica: é mais RAM ou reduzir concorrência.

3) IA local (inferência, embeddings e experimentos)

Para IA local, o gargalo quase nunca é “CPU apenas”. Geralmente você depende de GPU para aceleração real. Sem uma GPU dedicada forte, dá para fazer:

processamento leve e experimentos
embeddings com modelos pequenos
scripts/ETLs e pipelines

Mas treino pesado não vai ser a proposta desse equipamento. Então, para IA, eu vejo esse notebook como:

um bom host para ambientes (Python/Node), testes e automações
um lugar para você escrever e orquestrar, não para “treinar até o fim” localmente

Tela 16: ergonomia para longas sessões de código (não é só “tamanho”)

O Amazon lista 16 polegadas WUXGA (1920 x 1200). Para dev, 1200 de altura é ouro: você vê mais linhas sem ficar “rolando com raiva”. Na minha experiência, isso melhora fluxo em três momentos:

diffs em GitHub/Git + editor aberto
debug com logs e stack trace lado a lado
análise em dashboards e docs

Se a tela tiver bom brilho e contraste (e o notebook for consistente), você passa menos tempo ajustando layout. Isso parece detalhe, mas muda produtividade.

SSD de 512 GB: o “custo invisível” do dev moderno

512 GB é o mínimo que eu considero saudável para um dev que usa:

repos grandes (monorepos)
node_modules e caches
imagens Docker e camadas
WSL2 distros
VM/containers

Quando o SSD fica cheio, o desempenho piora em cascata: indexação, builds incrementais e operações de I/O entram em modo “sofrimento”. Então, além de capacidade, o que importa é manter disciplina de limpeza e ter estratégia de caches.

Na Prática: como eu validaria esse notebook para meu workflow (sem achismo)

Se eu estivesse comprando (ou recomendando) o EliteBook 860 G11 para um dev, eu faria um checklist rápido em 60–90 minutos. Algo assim:

Teste de build/compilação: rode 1 build “real” (o que você usa no dia a dia) e meça tempo antes/depois.
Teste de multitarefa: abra IDE + 15 abas + 2 services locais e deixe 10–15 minutos.
Teste de Docker: suba Postgres + Redis + seu app, observe consumo de memória e uso de swap.
Teste de bateria e thermal behavior: se você trabalha fora da tomada, verifique se o desempenho “cai” muito em modo bateria.
Teste de I/O: copie e descompacte um repositório grande e rode um “npm install”/“pip install” (ou seu equivalente).

O ponto é capturar sinais de gargalo:

se CPU fica ok mas RAM vira swap demais, o notebook “parece lento”
se I/O está alto e SSD lota, você vai sentir travadas aleatórias
se thermal throttling aparece, builds longas ficam erráticas

Comandos rápidos para observar memória/swap no Windows (onde o dev erra mais)

No Windows, eu gosto de olhar rapidamente “o que está acontecendo” quando parece que a máquina travou. Um padrão comum é você achar que é CPU, mas na verdade é memória pressionada e swap.

# Abra o PowerShell como usuário normal
# Ver uso de memória (a cada ~2s)
while ($true) {
  $os = Get-CimInstance Win32_OperatingSystem
  $total = [math]::Round($os.TotalVisibleMemorySize / 1MB, 2)
  $free  = [math]::Round($os.FreePhysicalMemory / 1MB, 2)
  "{0:u} - RAM livre: {1} GB" -f (Get-Date), $free
  Start-Sleep -Seconds 2
}

Isso não substitui um perfil completo, mas serve para detectar quando o sistema entra em pressão cedo demais com 16 GB.

Erros Comuns: o que eu vejo devs fazerem (e depois culparem o notebook)

1) Assumir que “16 GB é sempre suficiente”

Para muita gente, é suficiente. Mas dev costuma ser “pior caso” involuntário: IDE pesada + browser + containers. O que pega é que você não sente no início. Você sente após 1–3 horas quando caches crescem e memória vira gargalo.

2) Ignorar espaço no SSD e acumular imagens Docker

Se você usa Docker, suas imagens/layers crescem. Sem limpeza, o SSD vai ficar cheio e tudo degrada. Aí qualquer notebook “fica lento”, mas não é culpa do hardware: é gerenciamento de cache.

3) Rodar IA local grande sem GPU dedicada

Você até consegue rodar coisas pequenas. Mas se você tenta “forçar” modelos grandes em CPU, vai ter latência enorme. O notebook vira um gerador de frustração.

4) Não testar térmica em builds longas

Um dev frequentemente testa só “abre e responde”. Em seguida vem build, testes e execução repetida. É aí que o comportamento pode mudar por temperatura. Eu sempre recomendo pelo menos um teste de build mais longo.

Sobre o vPro e o lado corporativo: onde isso pode te ajudar de verdade

O Amazon menciona Tecnologia vPro. Para mim, isso tem valor quando:

você trabalha em empresa com TI que gerencia dispositivos
precisa de políticas e manutenção remota
quer reduzir tempo parado (manutenções e diagnósticos)

Se você é dev freelancer, talvez não use tanto. Mas se você está montando stack para empresa/cliente, esse tipo de recurso é bem-vindo.

Vale a pena? Minha opinião técnica (com as condições certas)

Eu vejo o HP EliteBook 860 G11 como uma boa escolha para dev que quer:

um notebook “business” com qualidade de construção e recursos de gestão (vPro)
conforto de tela e produtividade em sessões longas
desempenho sólido para workflow padrão: IDE + navegador + serviços locais

As condições:

16 GB de RAM é ok para muitos, mas pode apertar com Docker + múltiplos serviços e muito navegador aberto.
SSD 512 GB é suficiente para começar bem, mas você precisa manter higiene de caches/imagens.
Para IA local pesada, sem GPU dedicada, ele vira “ambiente e automação”, não “motor de treino”.

Se você se encaixa nesses cenários, é uma máquina que tende a passar confiança no dia a dia. Se seu workflow é pesado (muitos containers, builds longas e simultâneos), eu consideraria buscar configuração com mais RAM (se for possível no modelo/linha) ou ajustar o modo de uso.

Onde eu vi e como comprar

Eu vi o modelo exatamente assim no Amazon com as especificações que comentei acima. Se você quiser conferir preço e disponibilidade agora, segue o link: https://link.amazon/B069KRbWt.

🛒 Ver na Amazon

FAQ (perguntas que devs realmente fazem)

1) Esse notebook aguenta Docker com Postgres e Redis junto da IDE?

Aguenta, sim, para muitos casos. O ponto de atenção é 16 GB de RAM. Se você subir vários serviços com muitos workers ou ficar com muitas abas e extensões abertas, pode começar a usar swap cedo.

2) O SSD de 512 GB é “só marketing” ou muda algo no dia a dia?

Muda. O dev moderno enche o disco com caches e imagens. 512 GB tende a evitar degradação imediata. Ainda assim, eu sempre recomendo manter rotina de limpeza de Docker e caches.

3) Dá para usar IA local nele?

Para inferência leve e experimentos, sim. Para modelos grandes com latência aceitável, normalmente você vai precisar de GPU dedicada (e aí é outro perfil de notebook/workstation).

4) Tela WUXGA 1920×1200 faz diferença real pra programar?

Faz. 1200 de altura dá mais linhas por tela. Em debug e revisão de código, isso reduz rolagem e melhora a velocidade de leitura.

5) O vPro é importante pra mim como dev?

Se você está em empresa, pode facilitar manutenção e políticas. Se você é autônomo, provavelmente é menos relevante. Mas é um sinal de que o equipamento foi pensado para ambiente corporativo.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.