Como preparar uma empresa de software para usar IA

Em muitas empresas de software, a IA já entrou pelo uso cotidiano da equipe antes de existir um desenho claro de prontidão. A adoção de IA em equipes de software precisa organizar quais competências estão distribuídas, quais decisões podem ser assistidas e quais evidências mostram aumento real de capacidade. Sem isso, a empresa pode ganhar velocidade em tarefas pontuais e, ao mesmo tempo, perder clareza sobre risco, qualidade e responsabilidade.

Por que a adoção de IA precisa começar pela capacidade da empresa

A cena já é comum em empresas de software: parte da equipe usa IA para escrever testes, resumir tickets, explicar trechos de código, comparar alternativas técnicas ou acelerar rascunhos de documentação. Algumas pessoas parecem mais produtivas. Outras usam pouco. A liderança percebe movimento, mas não consegue responder a três perguntas simples: que decisões melhoraram, que riscos aumentaram e que evidência mostra que a capacidade da equipe ficou mais forte.

A partir daí, a liderança precisa avaliar o sistema de trabalho, não apenas a ferramenta.

IA não opera no vácuo. Ela depende da qualidade do problema formulado, do contexto fornecido, da revisão humana, da documentação disponível, da clareza de responsabilidade e da maturidade com que a organização aprende com erros e acertos. A apresentação do relatório DORA 2025 descreve a IA como amplificadora das forças e fraquezas existentes na organização e destaca a importância do sistema organizacional para o retorno do investimento. Isso não significa que a IA garanta produtividade. Significa que a liderança precisa olhar para o ambiente onde a tecnologia será usada.

Uma empresa com decisões confusas, documentação frágil e baixa disciplina de aprendizagem tende a usar IA para acelerar ambiguidades. Uma empresa com boas práticas de engenharia, produto e operação tem melhores condições de usar IA para investigar, comparar opções e apoiar tarefas de menor julgamento, desde que preserve responsabilidade humana onde ela é necessária.

Preparar a empresa, portanto, não é escolher primeiro o fornecedor. É organizar três camadas antes de ampliar o uso:

• Competências mínimas distribuídas no sistema, não concentradas em entusiastas.
• Decisões classificadas por risco, impacto, reversibilidade e responsabilidade.
• Evidências observáveis de capacidade, não apenas relatos de velocidade.

Essa leitura complementa discussões mais amplas sobre estratégia de inteligência artificial conectada ao negócio e maturidade em IA. Aqui, o recorte é mais específico: como uma liderança de software decide se a organização está pronta para ampliar o uso de IA em engenharia, produto e operação.

Antes de escolher a ferramenta, a liderança precisa responder: “que capacidade precisa existir para que o uso da ferramenta melhore decisões sem esconder riscos?”.

Quais competências precisam existir antes de ampliar o uso de IA

A prontidão organizacional para IA começa quando a empresa deixa de tratar competência como habilidade individual isolada. Ter algumas pessoas muito boas em prompts pode ajudar, mas não basta. Em software, a capacidade precisa aparecer nas práticas compartilhadas da equipe: como problemas são formulados, como respostas são revisadas, como decisões são documentadas e como erros viram aprendizagem.

A primeira competência é formular bons problemas. IA responde melhor quando recebe objetivo, contexto, restrições e critério de avaliação. Em uma equipe de software, isso significa transformar pedidos vagos em perguntas operáveis. “Melhore este fluxo” é fraco. “Compare três alternativas para reduzir fricção neste cadastro, considerando impacto para usuários recorrentes, esforço de engenharia e riscos de suporte” já orienta uma investigação mais útil.

A segunda competência é revisar saídas. Revisar não é apenas procurar erro evidente. É comparar a resposta com o contexto do produto, a arquitetura existente, a experiência do usuário, os limites de segurança e os padrões da equipe. Quanto mais sensível for a decisão, maior deve ser o peso do julgamento humano.

A terceira competência é proteger contexto sensível. Equipes de software lidam com código, incidentes, dados de clientes, estratégias de produto e informações internas. A empresa precisa definir o que pode ser compartilhado, em que ambiente, com que nível de anonimização e sob qual autorização. A ausência de regra costuma virar permissão informal.

A quarta competência é documentar decisões. Se a IA ajudou a comparar alternativas, gerar hipóteses ou produzir um rascunho técnico, a decisão final precisa ter registro humano: qual opção foi escolhida, por quê, com que premissas e quais riscos foram aceitos. Sem esse registro, a organização não aprende. Ela apenas acumula interações.

A quinta competência é testar hipóteses. IA pode sugerir caminhos, mas sugestão não é evidência. Uma melhoria de produto, uma mudança de arquitetura ou um novo fluxo operacional precisa ser tratada como hipótese quando seu efeito ainda é incerto. A liderança deve exigir clareza sobre o que será observado antes de ampliar uma prática.

A sexta competência é reconhecer quando não automatizar. Essa talvez seja a mais subestimada. Nem todo trabalho repetitivo deve ser automatizado. Algumas tarefas carregam julgamento, responsabilidade, contexto político ou impacto no usuário que não aparecem no enunciado técnico. Em outras, o custo de revisar uma automação ruim pode ser maior do que executar manualmente com critério.

Essas competências não precisam estar igualmente profundas em todas as pessoas. Mas precisam existir de forma distribuída. Produto, engenharia, dados, qualidade e operação devem conseguir conversar sobre o uso de IA sem depender de uma pessoa que “entende da ferramenta”. Caso contrário, a empresa não tem capacidade organizacional em software. Tem ilhas de habilidade.

Um bom sinal de prontidão é quando a equipe consegue explicar não apenas como usou IA, mas por que usou, que alternativa descartou, quem revisou e que evidência sustentou a próxima decisão.

Quais decisões podem ser apoiadas por IA e quais devem permanecer humanas

O uso responsável de IA em software depende de uma distinção simples: apoiar uma decisão não é tomar a decisão. A IA pode investigar, resumir, comparar, simular argumentos, gerar rascunhos e apontar inconsistências. Mas a organização precisa definir quem autoriza mudanças relevantes, especialmente quando há impacto para usuários, arquitetura, segurança, operação ou reputação.

Um critério prático é classificar decisões por quatro dimensões.

A primeira é reversibilidade. Uma decisão facilmente reversível, como sugerir nomes alternativos para uma função interna ou rascunhar uma mensagem de release, pode aceitar uso mais amplo de IA, desde que haja revisão proporcional. Uma decisão difícil de reverter, como alterar um componente central da arquitetura, exige mais contexto, debate e responsabilidade explícita.

A segunda é impacto no usuário. Quanto maior a chance de afetar experiência, acesso, confiança, privacidade ou suporte, menor deve ser a autonomia concedida à IA. Ela pode ajudar a mapear cenários e antecipar efeitos, mas a decisão precisa permanecer atribuída a uma pessoa ou fórum definido.

A terceira é dependência de contexto. Algumas decisões parecem técnicas, mas dependem de histórico do produto, incidentes anteriores, acordos com clientes, restrições comerciais ou decisões de arquitetura que não estão bem documentadas. Nesses casos, uma resposta plausível da IA pode ser perigosa justamente por parecer completa.

A quarta é necessidade de responsabilidade explícita. Se uma decisão exige alguém que responda por ela depois, a IA não pode ocupar esse lugar. Ela não comparece à reunião de pós incidente, não sustenta tradeoffs diante de usuários e não assume consequências organizacionais.

Essa classificação ajuda a separar usos comuns:

• Apoio adequado: investigar causas possíveis de um bug, resumir logs não sensíveis, comparar alternativas de implementação, sugerir casos de teste, rascunhar documentação, revisar clareza de uma especificação.
• Apoio com atenção: recomendar priorização de backlog, sugerir mudanças de experiência do usuário, interpretar padrões de incidentes, propor refatorações relevantes.
• Uso bloqueado ou restrito: aprovar mudanças críticas sem revisão, decidir prioridade de produto sem critério humano, executar alterações relevantes sem registro, substituir análise de incidente quando a documentação é incompleta.

A governança de IA em engenharia não precisa começar pesada. Ela precisa começar visível. A equipe deve saber onde a IA pode ajudar livremente, onde precisa de revisão e onde não deve ser usada como decisora.

Esse ponto é especialmente relevante para empresas que já têm um roadmap de IA. Um roadmap com muitas iniciativas e poucos direitos de decisão definidos tende a produzir atrito. As pessoas usam IA, mas não sabem quando pedir autorização, quando registrar premissas e quando interromper uma automação.

Um bom desenho de decisão não reduz a autonomia da equipe. Ele reduz ambiguidade. E ambiguidade é cara quando uma tecnologia passa a influenciar código, produto e operação.

Que evidências mostram que a equipe ganhou capacidade, não apenas velocidade

Velocidade é uma evidência incompleta. Uma pessoa pode escrever mais código, gerar mais testes ou responder tickets mais rapidamente sem que a organização tenha melhorado sua capacidade de entregar software confiável. A pergunta é: a equipe está decidindo melhor, aprendendo mais rápido e reduzindo dependência de conhecimento tácito?

Sinais fracos são fáceis de encontrar. Entusiasmo com a ferramenta. Aumento de uso. Demonstrações convincentes. Relatos de economia de tempo. Nada disso deve ser descartado, mas também não deve ser tratado como prova suficiente. Em adoção de IA, percepção positiva pode indicar oportunidade, não capacidade consolidada.

Evidências mais fortes aparecem no trabalho registrado.

Uma primeira evidência é a qualidade das decisões. A empresa consegue encontrar por que uma alternativa foi escolhida? Consegue ver que opções foram consideradas? Consegue entender que riscos foram aceitos e quais premissas precisam ser revisitadas? Se a IA participou da análise, isso deve aumentar a rastreabilidade, não substituí-la por um histórico informal de prompts.

Uma segunda evidência é a documentação encontrável. Quando uma pessoa nova entra no time, quando alguém precisa revisar uma decisão antiga ou quando a IA é usada para apoiar investigação, as informações básicas estão claras e localizáveis? O DORA, em sua página sobre qualidade da documentação, avalia documentação por atributos como clareza, facilidade de localização e confiabilidade, além de recomendar criação e manutenção ativa. Essa é uma base prática para pensar prontidão de IA, sem transformar documentação em promessa de retorno automático.

Uma terceira evidência é a existência de hipóteses testadas. Se a equipe usa IA para propor uma melhoria de produto, a mudança foi tratada como aposta verificável? Havia um impacto esperado? Havia condição para manter, ajustar ou interromper? Sem isso, a empresa confunde geração de ideias com aprendizagem.

Uma quarta evidência é a revisão de saídas. A liderança consegue observar se respostas da IA foram revisadas por pessoas com contexto suficiente? Consegue ver onde a equipe aceitou, adaptou ou rejeitou uma sugestão? A revisão é parte da capacidade, não uma etapa burocrática.

Uma quinta evidência é a análise de incidentes e retrabalho. Quando algo dá errado, a organização identifica se o uso de IA contribuiu, se faltou documentação, se o problema estava no critério de decisão ou se a revisão foi inadequada? A capacidade aumenta quando o erro melhora o sistema, não quando vira culpa individual.

Uma sexta evidência é a atualização dos próprios critérios de uso. Empresas maduras não escrevem uma regra de IA uma vez e abandonam. Elas revisam limites conforme aprendem, mudam ferramentas, alteram produtos e encontram novos riscos.

A diferença entre velocidade e capacidade aparece em uma frase: velocidade é fazer mais em menos tempo; capacidade é repetir boas decisões em contextos diferentes, com menos dependência de improviso.

Como usar documentação como infraestrutura de confiança para IA

Documentação costuma ser tratada como obrigação posterior ao trabalho. Com IA, essa visão fica ainda mais frágil. Se a equipe quer usar IA para apoiar análise, comparação e rascunho, ela precisa alimentar o processo com contexto confiável. Caso contrário, a ferramenta tende a operar sobre fragmentos, suposições ou memória informal.

Documentação, nesse sentido, é infraestrutura de confiança. Não porque elimina erro, mas porque permite que pessoas e sistemas encontrem contexto, revisem decisões e reduzam ambiguidade.

Em uma empresa de software, a documentação relevante para IA não se limita a manuais. Ela inclui decisões de arquitetura, critérios de produto, histórico de incidentes, padrões de qualidade, convenções de código, acordos de operação, glossário de negócio e razões para escolhas anteriores. Uma IA pode ajudar a resumir, reorganizar ou encontrar lacunas, mas não deve ser usada para mascarar documentação contraditória ou desatualizada.

Há três perguntas concretas para avaliar essa camada:

• A informação que orienta decisões está em um lugar que a equipe realmente usa?
• O conteúdo está claro o suficiente para alguém fora do contexto imediato entender?
• Existe responsável por manter a documentação quando o produto, a arquitetura ou o processo mudam?

Se a resposta for negativa, ampliar IA pode aumentar a confiança em respostas frágeis. A ferramenta pode produzir um texto convincente a partir de premissas ruins. A aparência de clareza não substitui a confiabilidade do contexto.

Esse ponto se conecta à discussão sobre liderança e humano ampliado. O julgamento humano não entra apenas no fim para corrigir a máquina. Ele precisa aparecer no desenho do ambiente: que informação será considerada fonte confiável, quem pode alterá-la, quando ela deve ser revisada e como conflitos serão resolvidos.

Uma prática simples é separar três níveis de documentação:

• Referência atual: conteúdo que a equipe reconhece como base para decisão.
• Registro histórico: decisões antigas, incidentes e alternativas descartadas que ajudam a entender contexto.
• Rascunho assistido: material gerado ou reorganizado com apoio de IA, ainda dependente de revisão humana.

Essa separação evita um erro comum: tratar todo texto bem escrito como verdade operacional. Em empresas de software, confiança não nasce do formato. Nasce da responsabilidade sobre o conteúdo.

Como governar a evolução dos usos de IA

A evolução dos usos de IA fica mais controlável quando a empresa distingue descoberta, hipótese e experimento.

Descoberta é exploração. A equipe investiga usos possíveis, observa tarefas repetitivas, identifica gargalos e conversa sobre dores reais. Nessa fase, é aceitável abrir possibilidades. A pergunta é: onde a IA poderia ajudar?

Hipótese é uma aposta formulada. A equipe escolhe um uso específico e declara que efeito espera observar. Por exemplo: “usar IA para sugerir casos de teste pode melhorar a revisão de cenários esquecidos em histórias com regras de negócio complexas”. Essa frase ainda não prova nada. Ela apenas torna a aposta discutível.

Experimento é a hipótese submetida a uma observação planejada. A equipe define como vai comparar o antes e o depois, quem revisará as saídas, que riscos serão monitorados e em que condição a prática será ajustada ou interrompida. A Microsoft descreve sua plataforma de experimentação ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. A lição aplicável aqui é o raciocínio experimental, não a ideia de que qualquer feedback retreina automaticamente um modelo.

O DORA também relaciona cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização. Para a adoção de IA, isso sugere uma mudança de postura: a empresa não deve apenas perguntar quem está usando a ferramenta, mas o que o uso ensinou sobre o sistema de trabalho.

Um ciclo simples pode funcionar assim:

• Escolher uma tarefa ou decisão específica, não “usar IA em engenharia” de forma genérica.
• Formular uma hipótese testável sobre qualidade, risco, esforço ou aprendizagem.
• Definir quem revisa a saída e quem autoriza a decisão.
• Registrar evidências observáveis, inclusive rejeições e falhas.
• Revisar a prática antes de ampliar para outras equipes ou etapas críticas.

O cuidado aqui é não transformar toda adoção em laboratório permanente. Times de software precisam entregar. O ciclo de aprendizagem deve caber no fluxo de trabalho, não virar uma camada paralela que paralisa decisões. A disciplina está em escolher poucos usos relevantes, medir com honestidade e ajustar critérios.

Quando a empresa governa a evolução dos usos dessa forma, a IA deixa de ser apenas ferramenta individual e passa a revelar onde o processo está claro, onde a documentação falha, onde a decisão depende de poucas pessoas e onde a liderança precisa desenhar limites melhores.

Checklist de prontidão para adoção de IA em equipes de software

O checklist abaixo é um instrumento prático para decidir se a empresa deve ampliar, limitar ou redesenhar o uso de IA em software. Ele não substitui análise técnica, jurídica, de segurança ou de produto quando essas dimensões forem relevantes. Sua função é organizar uma conversa de liderança sobre capacidade organizacional.

Competências mínimas distribuídas

Aprovado: a equipe sabe formular problemas, revisar saídas, testar hipóteses, documentar decisões e identificar usos inadequados de IA.

Atenção: algumas pessoas dominam o uso, mas o conhecimento depende de iniciativa individual e não aparece nas práticas do time.

Bloqueado: a empresa mede adoção apenas por acesso à ferramenta ou quantidade de uso.

O critério aqui é distribuição. Se a competência desaparece quando uma pessoa muda de equipe, a organização ainda não incorporou a capacidade.

Decisões classificadas por risco

Aprovado: há distinção clara entre decisões reversíveis, decisões de impacto moderado e decisões críticas que exigem responsável humano nomeado.

Atenção: a equipe revisa decisões importantes, mas o critério depende do julgamento informal de cada líder.

Bloqueado: a IA é usada para recomendar ou executar mudanças relevantes sem registro de responsável, contexto ou critério.

O ponto não é impedir uso. É impedir que decisões sensíveis fiquem sem dono.

Documentação confiável e encontrável

Aprovado: as informações usadas pela equipe são claras, localizáveis, atualizadas e reconhecidas como referência de trabalho.

Atenção: há documentação suficiente para humanos experientes, mas lacunas dificultam revisão, entrada de novas pessoas ou uso assistido por IA.

Bloqueado: a IA é usada para compensar documentação desatualizada, contraditória ou inexistente.

Quando a documentação é fraca, a IA pode acelerar a produção de respostas plausíveis. Plausibilidade não é confiabilidade.

Evidências de capacidade

Aprovado: a liderança acompanha evidências como qualidade das decisões, redução de retrabalho por aprendizagem registrada, revisão de saídas e hipóteses testadas.

Atenção: existem relatos positivos, mas pouca evidência comparável entre equipes ou ciclos de entrega.

Bloqueado: o sucesso é declarado por percepção de velocidade, sem critério de qualidade, risco ou aprendizagem.

A pergunta é simples: se alguém pedir prova de que a equipe ficou melhor, o que será mostrado além de depoimentos?

Ciclo de experimentação

Aprovado: cada ampliação de uso parte de uma hipótese testável, define impacto esperado, observa resultado e revisa a prática.

Atenção: a empresa testa usos de IA, mas mistura exploração, piloto e experimento sem separar objetivo e evidência.

Bloqueado: a empresa amplia o uso porque a demonstração foi convincente, sem hipótese, métrica ou condição de interrupção.

Demonstração serve para abrir conversa. Experimento serve para orientar decisão.

Limites explícitos de automação

Aprovado: a organização definiu situações em que a IA pode apoiar, não deve decidir ou não deve ser usada.

Atenção: os limites existem na conversa dos líderes, mas não são visíveis para quem executa o trabalho.

Bloqueado: a ausência de regra é tratada como permissão para automatizar.

Limite claro não é medo de tecnologia. É desenho de responsabilidade.

Exemplo fictício: IA em bugs, testes e priorização

Imagine uma empresa de software que quer usar IA para apoiar análise de bugs, escrita de testes e priorização de melhorias. O exemplo é fictício, mas a aplicação do checklist mostra como a decisão pode ser mais concreta.

Na escrita de testes, o uso pode avançar como assistência se houver revisão humana, critérios de cobertura útil e registro dos casos aceitos ou rejeitados. A hipótese a medir poderia ser que a IA ajuda a lembrar cenários que a equipe costuma esquecer. O efeito não deve ser presumido. Deve ser observado no fluxo real de revisão.

Na priorização de melhorias, o uso fica em atenção se a empresa ainda não definiu critérios de impacto no usuário, esforço, risco e responsável pela decisão final. A IA pode resumir feedbacks, agrupar temas e levantar perguntas. Mas priorizar envolve escolhas de produto, contexto comercial e responsabilidade. A decisão não deve ser delegada a uma recomendação automática sem critério explícito.

Na análise de bugs, a automação plena fica bloqueada se a documentação de incidentes for incompleta ou difícil de localizar. A IA pode apoiar investigação, sugerir causas prováveis e organizar evidências. Mas, se o histórico é frágil, a ferramenta pode reforçar suposições. Antes de automatizar, a empresa precisa melhorar o registro dos incidentes e definir quem valida a conclusão.

Esse exemplo mostra o valor do checklist: a mesma empresa pode aprovar um uso, manter outro em atenção e bloquear um terceiro. A decisão deixa de ser “adotar ou não adotar IA” e passa a ser “onde temos capacidade suficiente para avançar, onde precisamos ajustar e onde o risco ainda está mal desenhado”.

Preparar uma empresa de software para trabalhar com IA é decidir o que precisa estar pronto antes de escalar: competências distribuídas, decisões classificadas, documentação confiável, evidências de capacidade, ciclo de experimentação e limites de automação. O passo prático é escolher um uso específico, aplicar o checklist e decidir se ele deve avançar, ficar em atenção ou ser bloqueado por enquanto.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• IA no desenvolvimento de software: processo, produto e aprendizagem

Fontes

• DORA 2025
• DORA: cultura de aprendizagem
• DORA: qualidade da documentação
• Microsoft: Experimentation Platform ExP