O Web Console, novo IDE em beta do Summer '26, roda direto do navegador e resolve dores antigas de governança e produtividade que o Developer Console nunca endereçou. Ele ainda não substitui checkpoints e test runner, mas o sinal para quem arquiteta tooling já é claro.
Alguém entra na org numa segunda de manhã, procura o Developer Console no menu de engrenagem e ele simplesmente não está mais lá do jeito que sempre esteve. Comentário vem, ninguém tem certeza se é bug, rollout de feature, permissão que sumiu ou se é o início do fim de um dos velhos e queridos IDEs da plataforma. Trabalho com Salesforce há tempo suficiente para saber que quando esse tipo de dúvida vira thread com dezenas de respostas, tem alguma coisa estrutural por trás.
E tem mesmo. O Summer '26 trouxe o Web Console em beta, um IDE embutido no navegador, vivendo dentro da própria org, e a comunidade rapidamente começou a juntar os pontos: será que o Developer Console está sendo descontinuado? A resposta oficial da Salesforce é "não diretamente", mas quem lê release note com espírito crítico sabe separar o que a empresa diz do que o produto está sinalizando.
Vale contextualizar o tamanho do problema que o Developer Console sempre teve. Ele nasceu em 2011, ainda na era pré-Lightning, virou o lugar padrão para rodar Apex anônimo, ler debug log e disparar SOQL rápido, mas nunca evoluiu de verdade. Nunca ganhou suporte a Lightning Web Component, perdeu autocomplete pelo caminho e continua rodando numa stack de JavaScript que já era datada há uma década. Se você é dev pleno pra cima, sabe exatamente do que estou falando: aquele texto cru de log que não muda desde sempre, sem highlight decente, sem inteligência de código nenhuma.
O Web Console chega para cobrir exatamente esse buraco. Ele roda direto do navegador, autenticado com a sessão da própria org, sem precisar instalar nada, e cobre o fluxo de investigação e correção rápida: visualizador de debug log, execução de SOQL, Query Plan, Apex anônimo e edição pontual de Apex com navegação de metadados ciente do contexto da org. É pensado para aquele cenário clássico de sexta-feira à tarde, job em lote quebrado em produção, você sem VS Code configurado na máquina, precisando investigar rápido. Isso o Developer Console sempre tentou ser e nunca conseguiu ser bem.
A diferença prática que interessa pra quem arquiteta solução: o Web Console preserva o modelo de segurança e as guardrails de produção. Em org produtiva, Apex fica somente leitura, sem escalonamento de privilégio, suas permissões na interface são as mesmas permissões dentro da ferramenta. Isso resolve uma dor real de governança que o Developer Console clássico nunca tratou direito, porque lá dentro sempre foi fácil um usuário com acesso amplo demais editar coisa que não devia em produção sem processo de deploy nenhum.
Só que, oficialmente, o Web Console não é um substituto feature-a-feature. Ele ainda não cobre checkpoints nem test runner, duas coisas que o Developer Console segura sozinho até hoje. Então o post que motivou a discussão no fórum provavelmente reflete alguma combinação de: rollout de beta que mudou visibilidade de menu para parte da base, org com Web Console habilitado pelo admin sem aviso prévio ao time, ou simplesmente confusão de quem viu o nome novo aparecer e achou que o antigo tinha sumido de vez.
…
O que muda na prática
Não existe data de retirada anunciada para o Developer Console. Ele continua ali, funcional, especialmente para quem depende de checkpoints em debug complexo. Mas o sinal é claro: zero investimento nele há anos, nenhuma novidade relevante, e agora um sucessor natural nascendo do lado. Quem decide arquitetura de tooling em cliente grande já devia estar migrando hábito de time para o Web Console nos cenários que ele cobre, mantendo o antigo só como plano B.
Esse tipo de mudança de tooling parece cosmético, mas afeta diretamente onboarding de dev júnior, runbook de suporte e até decisão de qual ferramenta ensinar em treinamento interno. Se sua consultoria ou seu time interno ainda constrói documentação de troubleshooting em cima do Developer Console como única opção, está construindo em cima de uma ferramenta sem roadmap de evolução, num momento em que a Salesforce está claramente investindo em outro lugar.
Para arquiteto de solução, o ponto mais importante não é o IDE em si, é o modelo de segurança. Um Web Console que herda permissão de UI e trava Apex em produção resolve uma lacuna de governança que muita org carregava sem perceber, principalmente em ambientes multi-time onde acesso amplo ao Developer Console virava porta para gambiarra fora de processo de deploy.
Gosto de ver a Salesforce finalmente atacando uma dívida técnica dessas dimensões, porque o Developer Console sempre foi aquela ferramenta que todo mundo usa, ninguém elogia e ninguém defende quando o assunto é modernização. Mas o jeito como a comunidade reage com desconfiança a esse tipo de mudança silenciosa de menu mostra uma coisa que já vejo há anos: quando a comunicação de rollout não acompanha a velocidade do rollout técnico, quem paga o preço de confusão é o consultor e o admin no campo, não quem decide o roadmap.
- Verifique se o Web Console já está disponível para o tipo de edição da sua org (Enterprise, Unlimited, Performance, Developer nos EUA, além de Government Cloud e China Cloud durante o beta) e avalie habilitar em sandbox primeiro.
- Trate o Web Console como ferramenta de investigação e correção pontual (debug log, SOQL, Apex anônimo, ajuste rápido de Apex fora de produção), não como substituto do fluxo VS Code mais Salesforce CLI para desenvolvimento orientado a source.
- Reveja runbooks de suporte e materiais de onboarding que hoje assumem Developer Console como única ferramenta disponível; comece a introduzir o Web Console como opção padrão para triagem rápida.
- Mantenha o Developer Console disponível e documentado enquanto checkpoints e test runner não tiverem equivalente no Web Console, isso ainda é motivo legítimo para não abandoná-lo de vez.
O Web Console está em beta, feature incompleta, e o próprio time da Salesforce é explícito que o escopo do beta é intencionalmente restrito a fluxo de investigação e correção rápida. Não é hora de tirar o Developer Console do time de suporte de produção, e muito menos de reescrever processo crítico assumindo paridade de recursos que ainda não existe. Também vale desconfiar de qualquer post ou vídeo afirmando "data oficial de fim do Developer Console": não há confirmação disso, e quem afirmar isso com certeza está especulando.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.