Colocar inteligência artificial nas mãos de alguns desenvolvedores é relativamente fácil, o desafio real começa quando o piloto funciona. A partir daí, a pergunta deixa de ser qual copiloto gera mais código ou qual modelo performa melhor no benchmark da semana. Para um CTO, o desafio passa a ser muito mais estrutural: como transformar ganhos percebidos por algumas pessoas em melhoria de entrega para dezenas de times, produtos diferentes, sistemas legados, políticas corporativas e objetivos de negócio?
Esse é o ponto central da experiência relatada por Luiz Fernando Fausto, CTO da Softplan, em conversa com Leandro Oliveira no novo episódio do Vibbracast. Depois de pilotos iniciais, a Softplan levou seu fluxo de desenvolvimento com IA para aproximadamente 300 desenvolvedores distribuídos entre dezenas de equipes. O que surgiu na escala não foi simplesmente um problema de tecnologia, e sim diferenças entre processos, resistência, necessidade de capacitação, novos gargalos, mudanças nos papéis e a necessidade de tornar resultados visíveis para lideranças e para o próprio comitê executivo.
Confira o episódio completo onde Leandro Oliveira, CEO da Vibbra, conversa com Luiz Fernando Fausto, CTO da Softplan, sobre o que acontece quando a IA deixa de ser experimento e passa a ser o modo operante de uma organização com cerca de 300 desenvolvedores, múltiplos produtos e 35 anos de história.
O piloto prova que a IA funciona e a escala testa se a organização funciona
Um piloto responde uma pergunta relativamente limitada: uma determinada equipe consegue obter valor usando IA neste contexto?
Já a escala exige responder outra: a organização consegue reproduzir, governar e converter esse ganho em resultado sem depender das características excepcionais do time escolhido para o experimento?
A distinção é importante porque pilotos normalmente começam onde existe maior disposição para experimentar. Foi também o caminho descrito por Fausto: a Softplan começou em uma área interna naturalmente mais próxima de pesquisa e inovação e depois avançou para uma equipe de produção que possuía uma dor concreta de capacidade. Só depois desses aprendizados a adoção foi ampliada.
Esse detalhe parece operacional, mas carrega uma questão metodológica: um time voluntário, tecnicamente engajado e apoiado por especialistas não representa necessariamente todos os times que receberão a tecnologia depois. É um dos motivos pelos quais números sobre “ganho de produtividade com IA” precisam ser interpretados com cuidado.
Em um estudo publicado pela Microsoft Research em 2025, três experimentos de campo realizados na Microsoft, Accenture e em outra companhia Fortune 100 reuniram 4.867 desenvolvedores. Com os dados combinados, o acesso ao assistente de programação foi associado a um aumento de 26,08% nas tarefas concluídas; profissionais menos experientes apresentaram maior adoção e maiores ganhos.
A conclusão útil para quem lidera engenharia é outra: não existe um percentual universal de produtividade da IA que possa ser transportado diretamente de um estudo, fornecedor ou piloto para o business case da empresa. O efeito precisa ser medido no seu sistema, o qual inclui muito mais do que a etapa de codificação.
A escolha o problema antes da escala
Um dos princípios mais úteis apresentados por Fausto no episódio é também um dos mais fáceis de inverter: não comece com “temos IA, onde podemos usá-la?”. Comece com “qual dor de engenharia precisamos resolver e em que medida a IA pode ajudar?”
No segundo piloto relatado pela Softplan, o time possuía uma restrição bastante concreta: precisava aumentar significativamente a capacidade de entrega em um horizonte de aproximadamente seis meses, e simplesmente contratar mais pessoas não resolveria a pressão de curto prazo devido ao tempo necessário para contratação e ramp-up. A IA entrou como resposta a essa restrição operacional, e não como uma tecnologia procurando um caso de uso. Essa ordem muda a qualidade da decisão.
Quando uma organização começa pela ferramenta, indicadores como número de usuários, tokens consumidos, prompts enviados ou linhas geradas tendem a ganhar protagonismo. São dados de adoção, mas nenhum deles comprova sozinho que software útil chegou ao cliente mais rapidamente.
Quando começa pelo problema, a cadeia de raciocínio pode ser diferente, sendo:
Dor de negócio -> restrição do fluxo -> hipótese de mudança -> uso de IA -> indicador operacional -> resultado percebido pelo negócio.
Imagine que a dor seja time-to-market. Nesse caso a hipótese não deveria ser “aumentar uso de IA”. Poderia ser “reduzir o tempo entre uma especificação aprovada e uma funcionalidade validada em produção sem aumentar a taxa de falhas”. Assim, o consumo de IA continua sendo uma variável útil de diagnóstico, mas as métricas relevantes passam a incluir:
- Lead time;
- Rendimento;
- Frequência de deployment;
- Retrabalho;
- Falhas;
- Tempo de revisão;
- Resultado de produto.
Em outras palavras, a pergunta executiva não é “quanto código a IA escreveu?”, e sim “o que a organização passou a conseguir fazer que antes não conseguia?”
Escala exige um sistema operacional de engenharia
Quando cada desenvolvedor escolhe sua ferramenta, escreve seus próprios prompts e decide sozinho onde confiar na IA, a empresa pode até ter centenas de pessoas utilizando inteligência artificial. Isso ainda não significa que possui uma operação de engenharia orientada por IA.
A escala exige uma camada coletiva, feita por: processos, contexto, guardrails, padrões de qualidade, telemetria, mecanismos de aprendizagem e uma forma coerente de inserir humanos e agentes ao longo do fluxo.
Na Softplan, esse movimento passou por um fluxo interno de desenvolvimento agêntico chamado Softflow, utilizado pelos times para inserir agentes no trabalho de engenharia. A padronização tornou as diferenças entre equipes mais visíveis: práticas que pareciam homogêneas no nível organizacional se mostraram diferentes quando o mesmo fluxo começou a atravessar produtos, legados e equipes com histórias distintas.
Esse é um efeito importante da escala: a IA frequentemente expõe a variabilidade, ao invés de eliminar. Nesse cenário, uma boa plataforma interna reduz a necessidade de cada equipe reconstruir segurança, acesso, contexto e automação por conta própria, sendo um diferencial relevante entre IA como benefício individual e IA como capacidade organizacional.
A importância da Governança na padronização
Quando uma organização estabelece um fluxo comum, dezenas de times começam simultaneamente a encontrar exceções, demandas e oportunidades. Se toda alteração depender da pequena equipe que mantém a plataforma, o mecanismo criado para remover gargalos pode se transformar no próximo gargalo.
A resposta encontrada pela Softplan foi abrir seu fluxo internamente para contribuições em um modelo de InnerSource, permitindo que profissionais que vivenciam os problemas nos próprios times contribuam para a plataforma utilizada pela organização.
InnerSource aplica dentro da empresa práticas de colaboração associadas ao open source. Na documentação do GitHub, a abordagem é apresentada como forma de permitir que equipes distribuídas descubram, reutilizem e contribuam para trabalho interno, reduzindo duplicação e facilitando compartilhamento de conhecimento.
Há um princípio importante aqui para qualquer empresa tentando escalar engenharia com agentes: centralize padrões, e não todo o aprendizado.
Segurança, autorização, rastreabilidade, arquiteturas de referência e critérios de qualidade podem exigir forte padronização. A melhoria diária do workflow, porém, precisa incorporar rapidamente o conhecimento de quem está utilizando o sistema em contextos reais.
Essa arquitetura organizacional se torna especialmente importante porque a camada tecnológica continua mudando rapidamente. No episódio em questão, Fausto descreve uma postura deliberada de não se apegar à ferramenta ou à arquitetura vigente: a Softplan já havia mudado repetidamente a forma de disponibilizar modelos aos colaboradores durante o ano. Para uma operação de IA, isso é mais saudável do que construir o programa inteiro ao redor de um modelo específico.
Produtividade com IA deve ser medida no fluxo
À medida que a adoção cresce, surge uma tentação previsível: medir o que é mais fácil. Na prática, isso significa: licenças ativas, prompts, tokens, aceitações de código e usuários por semana são dados úteis. O problema começa quando são tratados como sinônimo de produtividade.
A própria experiência relatada pela Softplan mostra um uso mais amplo da telemetria. Fausto descreve painéis nos quais desenvolvedores e gestores conseguem observar entregas, consumo de IA e diferenças entre equipes, inclusive chegando a análises sobre custo de entrega. A visibilidade também é levada ao comitê executivo. Segundo ele, isso tornou possível identificar diferenças de processo e investigar por que times semelhantes obtinham resultados diferentes.
Comparar pessoas apenas por output, consumo de tokens ou número de commits cria incentivos fáceis de manipular e ignora diferenças de complexidade, domínio, manutenção, suporte e responsabilidade. Uma arquitetura de métricas mais útil separa pelo menos quatro camadas:
- Adoção mostra se as pessoas estão realmente incorporando a nova forma de trabalho.
- Eficiência do fluxo mostra se o trabalho atravessa engenharia mais rapidamente.
- Qualidade e estabilidade mostram se velocidade não está simplesmente gerando trabalho posterior.
- Resultado de negócio mostra se a capacidade adicional está produzindo algo economicamente relevante.
A análise através dessas métricas muda o que “produtividade” significa. Se uma IA gera uma implementação em dez minutos e um engenheiro precisa de duas horas para provar que ela pode ir para produção, a geração não é a unidade correta de análise.
Por isso, a organização que deseja medir IA de forma séria deveria acompanhar a passagem do trabalho desde a intenção até a produção e observar onde o gargalo se desloca. Fausto sintetiza essa realidade no episódio: quando um gargalo é resolvido, outro aparece. Nesse cenário, escalar com IA é, em grande parte, aprender a identificar esse próximo gargalo antes que o ganho anterior desapareça dentro dele.
A transformação mais difícil é humana: liderança, capacitação e papéis mudam juntos
Na experiência da Softplan, a adoção da IA foi colocada dentro do planejamento estratégico e acompanhada pela alta liderança. Fausto relata envolvimento do CEO, do comitê executivo e do conselho, além de um esforço contínuo para alinhar dezenas de lideranças que precisavam sustentar a mudança no cotidiano dos times.
O detalhe é importante porque a primeira linha de resistência raramente chega ao CEO, e sim ao líder imediato. Um desenvolvedor experimenta o novo fluxo e afirma que trabalha melhor da forma antiga. Nesse momento, o comportamento do gestor determina se a organização aprende com a objeção, melhora a plataforma e ajuda a pessoa a se adaptar, ou simplesmente cria uma exceção que preserva o processo anterior.
A mudança, portanto, exige uma liderança capaz de distinguir três situações diferentes:
- Uma ferramenta inadequada;
- Um processo mal desenhado;
- Uma dificuldade real de adaptação profissional.
A mistura das três situações produz decisões ruins.
A capacitação também precisa ir além de um curso sobre prompting. Na Softplan, o processo incluiu uma imersão de quatro semanas aberta à empresa e um desafio prático no qual participantes precisavam produzir algo em condições delimitadas. Segundo Fausto, profissionais de áreas que não eram desenvolvimento participaram, e uma pessoa de suporte ao cliente ficou entre as melhores colocações da iniciativa.
O caso aponta para uma consequência mais ampla: quando geração e prototipação se tornam mais acessíveis, as fronteiras entre tecnologia, produto e outras áreas começam a perder rigidez. Nesse cenário, equipes menores e multidisciplinares, com fronteiras menores entre produto, engenharia e qualidade e com uma parcela crescente da execução apoiada por agentes. Ao mesmo tempo, ele ressalta que simplesmente retirar os papéis atuais antes de preparar pessoas e processo “quebra” a operação.
O melhor caminho é uma engenharia capaz de mudar continuamente
Um dos pontos mais estratégicos do episódio aparece quando Fausto fala sobre planejamento. A Softplan possui direções de longo prazo, mas, para IA, transforma essas direções em ciclos de ação bem menores. A tecnologia pode mudar no intervalo entre duas reuniões de planejamento. Por isso, a empresa procura manter estabilidade no objetivo e flexibilidade na forma de alcançá-lo.
Esse princípio talvez seja mais importante do que qualquer escolha de ferramenta feita hoje:
- Tenha apego ao resultado, não ao stack de IA (para quem está saindo do piloto, isso produz uma disciplina prática).
- Primeiro, defina a dor que justifica a transformação.
- Depois, prove que existe valor em um contexto real.
- Em seguida, observe quais características daquele piloto não são reproduzíveis na organização inteira.
- Padronize acesso, contexto, governança e qualidade onde a escala exige consistência.
- Crie mecanismos para os próprios times contribuírem para a evolução do sistema.
- Capacite líderes antes de exigir mudança de comportamento dos liderados.
- Meça o fluxo entre ideia e produção, não somente o ponto em que a IA escreve código.
- E espere que cada melhoria desloque o gargalo para outro lugar.
Essa abordagem é bastante diferente de comprar licenças e estabelecer uma meta de adoção, pois o objetivo não deveria ser fazer cada desenvolvedor produzir o máximo possível com um assistente. É construir um sistema de engenharia no qual humanos e agentes consigam transformar decisões em software de qualidade com menos espera, retrabalho e risco.
Esse princípio também está por trás do modelo de Squads Cognitivos da Vibbra: redesenhar o processo para que humanos concentrem energia em negócio, contexto, julgamento e decisão, enquanto agentes assumem parcelas da execução dentro de um fluxo governado.
A Vibbra se posiciona com essa abordagem como parte da nossa consultoria estratégica de tecnologia, combinando diagnóstico da operação, implementação do novo fluxo e aceleração de entrega.
Para uma empresa que já obteve bons resultados em pilotos, a próxima pergunta é:
o que precisa mudar na própria operação para que essa nova capacidade atravesse a organização inteira?
