Eu nunca esqueço da primeira vez que tentei organizar documentação em equipe usando o Wiki do Azure DevOps. Era aquele velho dilema: ou a gente sofria com a experiência nativa, cheia de limitações, ou apelava pros docs externos e torcia pra não virar uma salada de versões. Toda vez que precisava editar um bloco de código ou alinhar uma tabela, sentia que tava fazendo gambiarra. Quem já passou por isso sabe bem a sensação de “só mais um ajuste” que vira meia hora de sofrimento.
Pois bem, hoje me deparei com uma notícia que promete mexer nesse vespeiro: o time do Azure DevOps anunciou um novo editor para as páginas de Wiki (veja aqui). A grande sacada? Agora o editor é baseado no Monaco Editor, o mesmo motor que equipa o Visual Studio Code. Parece que finalmente alguém escutou os gritos de quem queria uma experiência decente de edição sem precisar sair da plataforma.
O que aconteceu
Segundo o anúncio, o editor antigo do Azure DevOps Wiki tá dando lugar pra uma experiência de edição completamente nova, construída em cima do Monaco Editor. Pra quem não ligou o nome à pessoa: o Monaco é o editor open source mantido pela Microsoft, usado no Visual Studio Code. Ou seja, aquele ambiente de edição que muita gente já usa pra codar, agora dentro do Wiki.
A equipe promete que várias capacidades familiares do VS Code chegam junto: melhor destaque de sintaxe, atalhos de teclado, buscas mais inteligentes, múltiplos cursores, entre outras firulas que fazem a diferença no dia a dia. O objetivo declarado é trazer o conforto que desenvolvedor já sente no VS Code pra quem cuida da documentação — e, de quebra, manter tudo que já funcionava no editor antigo.
Por que isso importa
Documentação nunca foi um tema “sexy” em DevOps, mas é o tipo de detalhe que separa projetos saudáveis de verdadeiros buracos negros. Durante anos, o Wiki do Azure DevOps era aquela solução “meia boca”: resolvia o básico, mas qualquer coisa mais complexa (tipo blocks de código, tabelas, links entre páginas) virava um exercício de paciência. Eu mesmo já perdi mais tempo brigando com editor ruim do que escrevendo conteúdo útil.
Historicamente, muita gente fugia do Wiki interno e pulava pra ferramentas como Confluence, Notion ou até Markdown no repositório Git, só pra escapar da experiência travada do editor. Isso criava o efeito colateral clássico: documentação descentralizada, difícil de encontrar e, pior, rapidamente desatualizada. Quem nunca foi chamado pra resolver bug porque “tava documentado, mas no lugar errado”?
A chegada do Monaco Editor muda esse jogo porque padroniza a experiência de edição pra algo que já faz parte do workflow da maioria. E não é só estética — funcionalidades como autocompletar, atalhos e até linter de Markdown reduzem a fricção e incentivam atualizar a Wiki em vez de jogar tudo pro “README do repositório”. É uma aproximação prática do DevEx (Developer Experience) que muita ferramenta só promete no papel.
Outro ponto é integração. O Monaco já nasceu pra ser usado em aplicação web, com suporte a extensões e customizações. Isso abre caminho pra, no futuro, trazer até mais recursos pra Wiki, como snippets reutilizáveis, inserção de diagramas ou integrações com pipelines. Se a Microsoft quiser investir nisso, o potencial tá aí.
Na prática
Testando o editor novo (e fazendo aquele velho copy-paste de bloco de código), já deu pra perceber algumas diferenças que parecem pequenas no papel, mas são enormes no dia a dia. Por exemplo: agora dá pra selecionar múltiplas linhas e aplicar formatação com um atalho só, igualzinho ao que faço no VS Code. O preview de Markdown tá muito mais próximo do que realmente vai aparecer depois de salvar.
Pra quem tá acostumado a editar Markdown fora do DevOps, isso aqui vai ser familiar:
## Como rodar o build local
Executa a pipeline localmente
az pipelines run –name pipeline-teste
O que mudou: agora o highlight funciona direito, não bagunça indentação, e dá até pra usar Ctrl+D pra selecionar ocorrências iguais e editar tudo de uma vez. Parece besteira, mas quando entra naquele fluxo de revisar documentação pós-mudança de processo, cada detalhe conta.
Outra coisa que reparei é que o Monaco já avisa quando tem erro básico de Markdown (tipo esquecer fechar uma aspa ou uma tag). Isso evita aquele famoso deploy de documentação que quebra a página e deixa todo mundo perdido até alguém ir consertar.
## O que eu acho disso
Sou desconfiado por natureza quando vejo anúncio de "nova experiência" — já vi muito redesign atrapalhar mais do que ajudar. Mas, nesse caso, a escolha pelo Monaco Editor faz todo sentido. Já era uma dor antiga, e não faltava feedback da comunidade pedindo uma experiência menos sofrida pra editar Wiki. Melhorar o editor é apostar na documentação viva, não naquele lixo esquecido de 2018.
Minha única ressalva é a velha questão da integração: será que a Microsoft vai manter o ritmo de melhorias, ou esse update vira só uma maquiagem? Porque o Monaco tem potencial pra trazer features mais avançadas, mas só se o time realmente ouvir quem usa Wiki no campo de batalha — quem já ficou até de madrugada ajustando documentação sabe que detalhe faz diferença.
No fim das contas, ver o Monaco dentro do Wiki é um passo na direção certa. Mas, como toda feature nova, o valor real vai aparecer no uso do dia a dia. Se não ficar só no hype, talvez a gente finalmente pare de ouvir "depois eu documento" como desculpa.
E você, já testou o novo editor do Wiki no Azure DevOps? Sentiu diferença, ou ainda prefere documentar fora da plataforma?