Ricardo Brandão – Senior Software Engineer e Team Lead
O Problema que Deu Início a Tudo
Imagine a situação: são 14h, você está no estado de flow profundo debugando um algoritmo complexo, quando de repente lembra – precisa verificar se seu PR de ontem recebeu algum feedback. Você dá alt-tab para o GitHub, examina os comentários, percebe que precisa atualizar o status de um ticket no Jira, abre outra aba do navegador, e então lembra que deveria revisar aquele PR que seu colega de equipe te atribuiu hoje de manhã. Vinte minutos depois, você está olhando para sua IDE se perguntando o que diabos estava debugando.
Parece familiar?
Nossa equipe de 7 desenvolvedores estava vivendo essa realidade diariamente enquanto trabalhava em um projeto cliente de alto risco. A gestão estava em cima da gente para melhorar nossas métricas DORA – frequência de deploy, lead time e taxa de falha de mudanças precisavam de atenção séria. Mas aqui está o problema: as próprias ferramentas destinadas a nos ajudar a rastrear e melhorar essas métricas estavam na verdade sabotando nossa produtividade através da constante troca de contexto.
Estávamos pulando entre VS Code, GitHub, Jira e Slack dezenas de vezes por dia. Cada troca de contexto não estava apenas custando minutos – estava fragmentando nosso foco e nos tornando mais lentos, não mais rápidos.
Foi aí que decidimos construir algo que mudaria tudo.
O Desafio: Entendendo o Fluxo de Trabalho Único do Nosso Cliente
Trabalhar em SaaS de saúde não é como construir seu aplicativo web típico. Nosso cliente opera em um ambiente B2B altamente regulamentado onde conformidade HIPAA não é apenas uma caixinha para marcar – está incorporada em cada decisão que tomamos. Quando você está lidando com dados sensíveis de pacientes, não pode simplesmente instalar qualquer ferramenta de produtividade que chame sua atenção.
O cenário técnico era igualmente complexo: uma arquitetura de microsserviços sprawling abrangendo múltiplos repositórios, com quatro equipes de desenvolvimento diferentes contribuindo código em todo o ecossistema. Cada equipe havia desenvolvido organicamente seus próprios fluxos de trabalho e “hacks de produtividade” para lidar com a dor, mas nada era padronizado ou escalável.
Como líder da equipe, eu sabia que precisávamos de dados, não de suposições. Começamos com pesquisas de Developer Experience (DX) em todas as equipes, mergulhando profundamente nas frustrações diárias e drenos de tempo. Passei semanas analisando nossas métricas DORA, procurando padrões em atrasos de deployment e taxas de falha de mudanças. Os insights reais vieram de conversas 1×1 com desenvolvedores individuais e discussões estratégicas com outros líderes de equipe.
O que emergiu foi um quadro de morte por mil cortes de papel. Nossos fluxos de trabalho do GitHub exigiam pelo menos dois aprovadores, zero testes falhados e todos os comentários de PR resolvidos antes do merge – requisitos razoáveis que estavam criando gargalos. Nossa instância do Jira usava campos customizados e fluxos de trabalho específicos para rastreamento de conformidade de saúde, significando que desenvolvedores estavam constantemente atualizando status de tickets e checkboxes de conformidade.
O pior? Por causa das restrições HIPAA, não podíamos simplesmente integrar com qualquer ferramenta ou serviço de terceiros. Cada solução tinha que ser cuidadosamente verificada, muitas vezes descartando ferramentas de produtividade populares inteiramente.
Percebemos que soluções prontas não serviriam. Precisávamos de algo construído especificamente para nosso fluxo de trabalho exato, requisitos de segurança e estrutura de equipe.
O Momento “Eureka”: Por que IA Era a Resposta
O timing não poderia ter sido mais perfeito. Isso foi no final de 2024, quando IA havia se tornado A palavra da moda e todo engenheiro de software que se preze estava explorando como integrá-la em seus fluxos de trabalho. Não estávamos apenas seguindo a onda do hype – estávamos genuinamente curiosos sobre como IA poderia resolver problemas reais.
A revelação veio durante uma reunião de equipe particularmente frustrante onde estávamos mais uma vez discutindo nossos desafios de produtividade. Alguém mencionou como havia estado usando ChatGPT para resumir notas de reunião e auto-gerar critérios de aceitação do Jira. Foi aí que clicou.
A maior barreira para construir ferramentas customizadas de desenvolvimento sempre foi tempo. Como você justifica gastar semanas construindo ferramentas internas de produtividade quando há um backlog infinito de features de cliente e solicitações de product manager? É uma conversa que todo líder de engenharia teve com seus stakeholders: “Poderíamos construir algo para ajudar nossos desenvolvedores, mas nos custará X ciclos de sprint…”
IA mudou essa equação inteiramente. Pense nisso como impressão 3D – de repente você pode criar um suporte descartável para sua cadeira que não é perfeito ou bonito, mas custa quase nada e resolve seu problema imediato. IA se tornou nossa impressora 3D de desenvolvimento.
Em vez de semanas construindo integrações tradicionais do zero, pudemos usar IA para gerar código boilerplate, escrever integrações de API e lidar com transformações de dados em minutos. Não estávamos apenas construindo ferramentas alimentadas por IA – estávamos usando IA para acelerar o desenvolvimento de ferramentas regulares. De repente, a análise custo-benefício virou. Pudemos criar um conjunto de soluções customizadas – revisão inteligente de código, atualizações automatizadas do Jira, resumos contextuais de PR – tudo sem o investimento massivo de tempo que normalmente tornaria tais projetos inviáveis.
A percepção não era sobre construir a solução empresarial perfeita. Era sobre IA removendo a barreira econômica que nos impediu de resolver esses problemas antes. Bom o suficiente, rápido e barato de repente se tornou possível.
Por Trás das Cenas: A Arquitetura Técnica
Construir uma extensão do VS Code que precisa fazer malabarismo com provedores de IA, APIs do GitHub, integração com Jira e monitoramento de arquivos em tempo real exigiu algumas decisões arquiteturais pensadas. O desafio não era apenas fazer funcionar – era fazer funcionar de forma confiável em um ambiente de saúde com requisitos rigorosos de conformidade.
Nossa primeira grande decisão foi evitar vendor lock-in com provedores de IA. Em vez de nos amarrarmos a um único serviço, construímos uma interface IAIService que abstrai as diferenças entre Google AI e AWS Bedrock. Essa escolha arquitetural se mostrou inestimável durante o desenvolvimento quando começamos com o tier gratuito generoso do Google AI para prototipagem rápida, depois mudamos sem problemas para AWS Bedrock uma vez que tivemos nosso BAA (Business Associate Agreement) em vigor para conformidade HIPAA. O padrão factory na ativação da nossa extensão lida com a troca de provedor baseada na configuração do usuário, exigindo zero mudanças de código quando fizemos a transição.
Watchers de arquivo tradicionais podem ser sugadores de recursos, especialmente em codebases grandes, então implementamos um sistema inteligente de detecção de mudanças. Usando hash SHA-256, mantemos um mapa de conteúdo de documentos abertos e só disparamos processamento quando mudanças reais de conteúdo ocorrem – não apenas quando arquivos são tocados ou salvos sem modificações. Essa abordagem reduziu drasticamente chamadas desnecessárias da API de IA durante desenvolvimento, mantendo nossos custos previsíveis.
A integração com GitHub nos ensinou uma lição importante sobre evolução de design de API. Inicialmente, começamos com a API REST do GitHub como a maioria dos desenvolvedores faz, mas rapidamente encontramos problemas de rate limiting e achamos a estrutura de dados pesada para nosso caso de uso específico. A revelação veio quando mudamos para GraphQL – de repente pudemos buscar exatamente os dados que precisávamos (threads de revisão de PR, status de resolução de comentários) em uma única solicitação em vez de múltiplas chamadas REST. Isso reduziu nosso uso de API em aproximadamente 70% e melhorou significativamente os tempos de resposta.
A UI da extensão evoluiu em torno do sistema nativo de tree view do VS Code, organizada em seções colapsáveis para Revisões de IA, Mudanças Salvas, PRs do GitHub e tickets do Jira. Cada seção usa classes de provider dedicadas que implementam a interface TreeDataProvider do VS Code, tornando o codebase modular e permitindo que desenvolvêssemos recursos independentemente. Isso se mostrou crucial quando precisamos iterar rapidamente baseado no feedback da equipe.
Um dos desafios mais interessantes emergiu em torno da otimização de custos. Para minimizar o uso de tokens de IA, implementamos minificação de código antes de enviar para provedores de IA – removendo comentários, espaços em branco extras e formatação desnecessária. Isso cortou nosso uso de tokens em cerca de 30-40%, mas criou um problema inesperado: quando a IA sugeria edições de código, elas referenciavam a versão minificada, tornando-as mais difíceis de aplicar ao código original formatado. Resolvemos isso mantendo source maps e implementando um algoritmo inteligente de diff-matching que podia traduzir sugestões de volta para a estrutura original do código.
Segurança permaneceu primordial durante todo o desenvolvimento. Dados os requisitos HIPAA, tudo roda localmente exceto pelas chamadas do provedor de IA. Credenciais de API são armazenadas usando a API de secrets segura do VS Code, e garantimos que nenhum código ou dados sensíveis sejam logados. A integração com AWS Bedrock usa chains de credencial AWS padrão, suportando tanto credenciais explícitas quanto roles IAM para ambientes empresariais. A extensão usa extensivamente o sistema de eventos do VS Code – mudanças de configuração reinicializam automaticamente serviços, salvamentos de arquivo disparam revisões, e todos os componentes limpam adequadamente seus recursos quando dispostos, garantindo que a extensão permaneça responsiva e não vaze memória durante longas sessões de desenvolvimento.
A Mágica em Ação: Recursos Principais e Experiência do Usuário
A verdadeira mágica aconteceu quando nossos desenvolvedores pararam de notar a extensão – ela apenas se tornou parte de seu fluxo de trabalho natural. A transformação foi sutil no início, depois subitamente óbvia quando percebemos quanto atrito havia simplesmente desaparecido de nossa rotina diária.
Pegue revisões de PR, por exemplo. A dança antiga era exaustiva: um PR é atribuído a você, notificação do Microsoft Teams pinga, você muda contexto para o canal do Teams, rola para encontrar o link do PR, abre o GitHub no navegador, navega para o pull request, e finalmente começa a revisar. Cinco minutos perdidos antes mesmo de ver o código, e seu contexto mental completamente despedaçado.
Agora, no momento em que uma revisão é solicitada, ela aparece na barra lateral da extensão. Um clique te leva diretamente ao PR do GitHub, mas aqui está o recurso matador que ninguém esperava que fosse tão valioso – se você tem aquele repositório aberto no VS Code e clica em um comentário de PR, ele te leva diretamente à linha exata sendo discutida. Não mais caçar através de arquivos se perguntando “onde estava aquele comentário mesmo?” A troca de contexto foi de minutos para segundos, mas mais importante, a sobrecarga cognitiva simplesmente desapareceu.
Os requisitos do nosso cliente de saúde em torno do rastreamento de status Dev/QA costumavam ser um ponto doloroso diário. O rastreamento meticuloso de tickets de suporte customizados significava que desenvolvedores gastavam 10-15 minutos por dia atualizando manualmente campos um ticket de cada vez na interface web do Jira. Era trabalho tedioso que ninguém gostava mas todos tinham que fazer para conformidade.
A extensão transformou isso completamente. Uma única lista colapsável na barra lateral da IDE mostra todos os tickets atribuídos com seu status atual. Atualizar o status Dev/QA de um ticket se tornou literalmente dois cliques – nenhuma aba de navegador, nenhuma navegação do Jira, nenhuma troca de contexto. O que costumava ser uma tarefa diária se tornou uma tarefa de 30 segundos que desenvolvedores podiam lidar sem quebrar seu fluxo de codificação.
O feedback da nossa equipe foi unânime: eles amaram poder ficar no VS Code durante todo seu dia de trabalho. Como um desenvolvedor colocou: “Esqueci quanta energia mental estava gastando apenas gerenciando todas essas ferramentas diferentes.” A extensão se tornou seu centro de comando central – verificando atribuições de PR, atualizando status de tickets, obtendo revisões de código de IA, tudo sem sair de seu ambiente de codificação.
Números não mentem: nossa pesquisa de Qualidade de Vida do Desenvolvedor mostrou uma melhoria de 20% entre membros da equipe usando a extensão comparado ao ciclo anterior. Mas além das métricas, você podia sentir a diferença – menos frustração durante standups, menos reclamações sobre “sobrecarga de processo”, e desenvolvedores que estavam genuinamente animados sobre uma ferramenta de produtividade. Isso não era apenas sobre economizar cliques ou reduzir tempo – era sobre preservar o estado de flow mental do desenvolvedor. Quando você pode lidar com todas suas tarefas periféricas sem sair de seu editor de código, você fica na zona por mais tempo e faz trabalho melhor.
Lições Aprendidas: O que Faríamos Diferente
Construir esta extensão nos ensinou lições que foram muito além de apenas resolver nossos problemas imediatos de fluxo de trabalho. A experiência reformulou como pensamos sobre abordar projetos similares e o que é possível quando você combina criatividade humana com capacidade de IA.
A maior surpresa foi como IA democratizou tarefas complexas de desenvolvimento que costumavam ser intimidantes. O desenvolvimento de extensões do VS Code foi de ser uma caixa preta completa para totalmente acessível, graças à assistência de IA. Antes deste projeto, construir extensões parecia que exigiria semanas mergulhando em documentação e vasculhando APIs. IA não apenas nos ajudou a escrever código – se tornou nosso guia através de território desconhecido, explicando conceitos e sugerindo padrões conforme caminhávamos. Isso dramaticamente encurtou nossa curva de pesquisa e aprendizado, transformando o que parecia uma empreitada maior em um projeto de fim de semana alcançável.
Olhando para trás, há uma decisão arquitetural que provavelmente mudaríamos. Se começássemos de novo, provavelmente começaríamos com um painel webview em vez de centralizar tudo em torno da tree view do VS Code. A tree view funciona muito bem e nos deu desenvolvimento inicial rápido, mas tem limitações inerentes para layouts complexos. Uma webview seria mais trabalho inicial mas ofereceria significativamente mais flexibilidade para recursos futuros. Às vezes o caminho de “início rápido” cria restrições que você não antecipa até estar fundo no desenvolvimento.
Uma das nossas melhores decisões foi tratar isso como uma verdadeira ferramenta interna desde o primeiro dia. Como estávamos construindo para nós mesmos, os testes aconteciam ao vivo – novo ponto doloroso? Adicione um recurso. Bug encontrado? Conserte imediatamente e faça push de uma atualização. Nenhum QA formal, nenhuma reclamação de cliente, apenas iteração rápida baseada em uso real. Essa abordagem funciona brilhantemente para ferramentas internas onde os desenvolvedores também são os usuários, mas exigiu que abraçássemos uma filosofia de desenvolvimento diferente do nosso trabalho usual com clientes.
Nem todo recurso aterrissou como esperado, porém. Nosso rastreamento de mudanças salvas e análise de IA se revelaram menos úteis do que antecipado, especialmente já que nossa equipe usa principalmente Cursor para desenvolvimento dia-a-dia. As capacidades de IA integradas do Cursor muitas vezes se provaram mais cost-effective que nossa integração direta de IA. Isso nos lembrou de validar suposições de recursos cedo e frequentemente, mesmo quando construindo para nós mesmos.
O padrão de adoção foi fascinante de observar se desdobrar. Começamos com nossa equipe white-label de 7 pessoas, então outros desenvolvedores na organização de 40 pessoas viram como nossas tarefas diárias se tornaram mais fáceis. Agora temos 36 instalações em todas as equipes – prova de que boas ferramentas se vendem sozinhas quando resolvem problemas reais.
O Quadro Maior: IA no Desenvolvimento Customizado
Estamos testemunhando uma mudança fundamental em como desenvolvimento de software funciona, e não é apenas sobre escrever código mais rápido. IA está democratizando desenvolvimento de ferramentas customizadas de formas que estão reformulando paisagens competitivas através da indústria.
Pense em desenvolvedores de software como artesãos – às vezes um carpinteiro precisa construir um gabarito customizado para cortar uma junta específica eficientemente. Tradicionalmente, apenas empresas FAANG e grandes corporações podiam se dar ao luxo de construir ferramentas internas sofisticadas. Os ciclos de pesquisa eram muito caros, a implementação muito demorada para equipes menores justificarem. IA está mudando essa equação inteiramente, agindo como o grande equalizador no desenvolvimento de tecnologia.
Quando uma equipe de 7 pessoas pode construir ferramentas de produtividade de nível empresarial em horas em vez de meses, os fossos competitivos nos quais grandes empresas confiavam começam a desmoronar. Empresas pequenas e médias agora têm acesso às mesmas capacidades de “ferramentas customizadas” que antes eram exclusivas de gigantes da tecnologia. Os ciclos de pesquisa mais rápidos e implementação rápida que IA permite estão nivelando o campo de jogo de formas sem precedentes.
Já estamos vendo essa disrupção se desenrolar em tempo real. Startups menores estão puxando o tapete de baixo de players estabelecidos como Microsoft ao inteligentemente aproveitar IA para construir soluções que teriam exigido equipes de engenharia massivas apenas alguns anos atrás. A questão não é se essa disrupção vai acontecer – está acontecendo agora, e o ritmo está apenas acelerando.
O insight crítico que aprendemos é que estamos pisando em uma linha cuidadosa entre “vibe-coding” e colaboração genuinamente produtiva com IA. O futuro não é IA escrevendo todo nosso código sem supervisão – isso leva a débito técnico e sistemas não mantíveis. Em vez disso, são engenheiros de software trabalhando simbioticamente com IA, fornecendo direção, validação e pensamento estratégico enquanto IA lida com detalhes de implementação e geração de boilerplate.
Empresas inteligentes estão identificando as frutas baixas que IA agora pode resolver quase instantaneamente. Ao limpar esses gargalos de produtividade dos pratos dos desenvolvedores, equipes podem focar sua inteligência humana nos problemas complexos que realmente geram valor de negócio. Nossa extensão é apenas um exemplo – o que costumava ser uma ferramenta interna “nice to have” se tornou um projeto rápido de fim de semana que entrega valor mensurável.
As empresas que reconhecem essa mudança e agem nela terão uma vantagem significativa sobre aquelas que continuam tratando IA como apenas mais uma ferramenta de desenvolvimento em vez de um equalizador estratégico que pode fundamentalmente mudar o que é possível para equipes de desenvolvimento pequenas e médias.
Esta extensão começou como uma solução para nossas próprias frustrações, mas representa algo maior – o poder de combinar criatividade humana com capacidade de IA para resolver problemas reais rapidamente e eficientemente.
Se você está enfrentando desafios similares com o fluxo de trabalho da sua equipe de desenvolvimento, ou se está curioso sobre como IA pode acelerar seus projetos de desenvolvimento customizado, adoraríamos ter uma conversa. Não estamos interessados em ser apenas mais um fornecedor de desenvolvimento – preferimos trabalhar como parceiros estratégicos que entendem que as melhores soluções vêm de colaboração, não de documentos de especificação.
Seja você lidando com gargalos de produtividade, desafios de integração, ou explorando como IA pode transformar seus processos de desenvolvimento, abordamos cada projeto como solucionadores de problemas, não fábricas de código.
Interessado em explorar o que é possível? Entre em contato conosco diretamente. Conecte-se conosco no LinkedIn.
Vamos construir algo impactante juntos.
PT 
EN