O que a IA faz e o que continua humano num projeto de software: a divisão de trabalho que adotamos

Neste artigo7 partes

1. O que muda e o que não muda quando a IA entra num projeto de software
2. O que entregamos à IA
3. O que nunca entregamos à IA
4. Como essa divisão aparece na rotina de um projeto
5. Os riscos da programação assistida e como reduzir
6. Quando não vale a pena usar IA no desenvolvimento
7. Por onde começar e o que perguntar ao seu fornecedor
8. Perguntas frequentes

O que muda e o que não muda quando a IA entra num projeto de software

Quando alguém pergunta se a inteligência artificial deixou o desenvolvimento de software mais rápido ou mais barato, a resposta curta é: algumas partes do trabalho, sim. A natureza da responsabilidade, não. Um sistema continua precisando de alguém que entenda o problema, escolha a arquitetura, decida o que entra e o que fica de fora, e responda quando algo quebra numa sexta-feira à noite.

O que mudou foi o ritmo de uma parte do caminho. Tarefas que antes tomavam horas de trabalho repetitivo, como montar a estrutura inicial de um módulo, escrever testes para casos já definidos ou organizar a documentação de uma reunião, hoje podem sair em minutos, desde que alguém revise. Isso libera tempo. E tempo, num projeto de software, costuma ser a diferença entre entregar o que foi pedido e entregar o que o negócio precisava.

Na Pocket Lab, adotamos uma regra de casa para não confundir as duas coisas: a IA tira o repetitivo do caminho; arquitetura, decisão e revisão continuam humanas. Não é uma ressalva de rodapé. É o critério que usamos para decidir, em cada etapa, quem faz o quê.

A IA tira o repetitivo do caminho; arquitetura, decisão e revisão continuam humanas.

Compartilhar esta frase

Por isso a pergunta útil não é quanto a IA faz num projeto. É quem responde por cada decisão. Quando essa resposta está clara, a IA vira ganho. Quando não está, vira risco.

Para quem decide a contratação, isso tem consequência prática. Um fornecedor que usa IA sem fronteira clara pode entregar mais rápido no começo e mais caro depois, quando o código que ninguém revisou direito começa a cobrar manutenção. Um fornecedor que usa IA com método tende a entregar com o mesmo cuidado de antes, só que com mais tempo para o que importa: entender o negócio, testar com casos reais e acompanhar o sistema depois do lançamento.

O que entregamos à IA

O critério é o mesmo para todas as tarefas: entregamos à IA o que é repetitivo, cujo erro é reversível e que alguém consegue revisar antes de seguir adiante. Se uma tarefa falha em qualquer um desses três pontos, ela fica com uma pessoa.

Tarefa repetitiva e de baixo risco

Boa parte de um projeto é trabalho que se repete de um módulo para outro: a estrutura inicial de um componente, a conversão de dados de um formato para outro, a migração de conteúdo em lote, os testes de casos que já foram definidos, a documentação técnica de rotina. Nessas tarefas, a IA acelera a primeira versão e a pessoa revisa, ajusta e aprova.

O ganho não está em pular a revisão. Está em começar a revisão de um rascunho pronto, em vez de começar de uma tela vazia.

Monitoramento e detecção de falha

Sites e sistemas em produção geram sinais o tempo todo: tempo de resposta, erros, formulários que deixam de enviar, certificados perto de vencer. Vigiar tudo isso é exatamente o tipo de trabalho repetitivo em que a IA vai bem. Ela monitora, detecta o que fugiu do padrão e corrige o que já é conhecido e reversível, muitas vezes antes de o cliente perceber.

O que é novo, nunca visto antes, vai para uma pessoa. A IA avisa. Quem decide o que fazer com um incidente inédito é alguém do time.

Organização de ideias, rascunhos e documentação, com revisão

Uma reunião de levantamento gera muita informação solta. A IA ajuda a transcrever, resumir e organizar o que foi dito em requisitos, dúvidas abertas e próximos passos. A mesma lógica vale para rascunhos de documentação e de especificação.

Usamos isso dentro de casa. Com reuniões gravadas e transcritas alimentando ferramentas próprias, o tempo para montar uma proposta comercial passou de semanas para menos de uma hora. Mas nenhuma proposta sai sem que uma pessoa revise o diagnóstico, a recomendação e o valor. A IA organiza. Quem assina é gente.

O que nunca entregamos à IA

Se o critério acima define o que a IA pode fazer, esta lista define a fronteira. São três decisões que ficam sempre com pessoas, em qualquer projeto.

Arquitetura e decisão técnica

Que tecnologia usar, como os dados vão ser organizados, como o sistema vai conversar com o ERP ou com o CRM que a empresa já tem, onde ele vai rodar e como vai ser protegido. Essas escolhas definem quanto o sistema vai custar para manter, quão fácil vai ser evoluir e quanto risco ele carrega.

A IA pode listar alternativas e ajudar a comparar caminhos. A decisão, e a responsabilidade por ela, é de uma pessoa com nome, que conhece o contexto do cliente e vai estar lá quando a escolha for posta à prova.

Um exemplo comum: a IA sugere uma solução elegante para guardar dados de um portal, mas que não conversa bem com o sistema financeiro que a empresa já usa. No papel, parece ótima. Na operação, gera retrabalho todo mês. Quem conhece o contexto enxerga isso antes. Quem só olha para o código, não.

Revisão do que vai para produção

Nada vai para produção sem revisão humana. Código gerado com ajuda de IA costuma parecer correto, e é justamente por isso que precisa ser lido com atenção. A revisão verifica se o código resolve o problema certo, se trata os casos de erro, se respeita as regras de segurança do projeto e se outra pessoa vai conseguir entender e manter aquilo daqui a um ano.

E quem revisa precisa ter autoridade para dizer não. Revisão que só carimba não é revisão. Na prática, isso significa que a pessoa que aprova uma entrega entende o problema do cliente, conhece as regras do projeto e responde pelo que foi para o ar.

Decisão criativa e de produto

O que o usuário vê, como a marca fala, o que entra no escopo e o que fica para depois. Essas são decisões de produto e de criação, e dependem de entender pessoas, contexto e prioridade de negócio. A Pocket Lab não vende entrega criativa feita por IA. A IA pode ajudar a organizar referências e ideias. A escolha é humana.

Como essa divisão aparece na rotina de um projeto

Os riscos da programação assistida e como reduzir

Usar IA no desenvolvimento traz riscos reais. Ignorá-los é o caminho mais rápido para um sistema frágil. Os três que mais aparecem são estes.

Nenhum deles é motivo para deixar a IA de fora. São motivos para usá-la com regra. O ponto em comum é o mesmo: o risco aparece quando a velocidade da ferramenta é maior do que a capacidade de revisão de quem a usa.

Código plausível, mas errado

A IA escreve código que parece certo: bem formatado, com nomes coerentes, às vezes com comentários convincentes. O problema é que parecer certo não é estar certo. Uma condição invertida, um caso de erro esquecido ou uma regra de negócio mal interpretada passam fácil por quem só lê na diagonal.

O que reduz o risco: revisão por quem entende a regra de negócio, testes escritos a partir de casos reais e a disciplina de nunca aceitar um trecho que ninguém consegue explicar.

Segurança e dependências

Sugestões de código podem trazer bibliotecas desatualizadas, padrões inseguros ou dependências que ninguém pediu. Cada dependência é uma porta a mais para manter e proteger.

O que reduz o risco: checagem das dependências antes de entrar no projeto, revisão de segurança como etapa obrigatória e atualização contínua depois do lançamento.

Dado do cliente em ferramenta de terceiro

Quando alguém cola um trecho de banco de dados, um contrato ou uma planilha de clientes numa ferramenta de IA, esse dado sai do ambiente controlado. Se houver dado pessoal, o assunto passa a envolver a LGPD.

O que reduz o risco: uma regra clara sobre que dado pode circular em qual ferramenta, acesso restrito e preferência por trabalhar com dados fictícios ou anonimizados sempre que possível. Se o tema é usar os documentos da própria empresa como base para respostas de IA, o cuidado é ainda maior, e vale ler o que precisa estar pronto antes de um projeto de RAG.

Quando não vale a pena usar IA no desenvolvimento

Dizer onde a IA não ajuda faz parte do método. Há situações em que usá-la traz mais risco do que ganho:

• A arquitetura ainda não foi decidida. Acelerar a construção de algo que ainda não tem forma só produz retrabalho mais rápido.
• O sistema é crítico e não há quem revise. Sem revisão qualificada, o ganho de velocidade vira risco acumulado.
• O dado não pode sair do ambiente do cliente. Nesse caso, a regra vale mais que a conveniência.
• Ninguém entendeu o problema ainda. A IA responde com confiança a perguntas mal formuladas. Primeiro vem o entendimento.
• A tarefa acontece poucas vezes. Automatizar o que roda duas vezes por ano raramente compensa o esforço de configurar e revisar.

Por onde começar e o que perguntar ao seu fornecedor

Se a sua empresa está avaliando um projeto de software com IA, ou um fornecedor que diz usar IA, o primeiro passo é sóbrio: escolher um processo, aplicar as cinco perguntas acima e conversar com quem vai construir sobre a divisão de responsabilidades.

Algumas perguntas ajudam a separar o fornecedor que usa IA com método do que usa como argumento de venda:

Um começo pequeno e reversível

Para quem ainda não usou IA em nenhum projeto, o melhor começo costuma ser pequeno: uma tarefa interna, repetitiva, cujo erro não chega ao cliente final, com alguém definido para revisar e um critério claro do que encerra o teste. Se funcionar, amplia. Se não funcionar, desfaz sem dano. Esse é o mesmo raciocínio que aplicamos dentro de casa antes de levar qualquer prática para um cliente.

Para ir mais fundo em cada frente, vale ler sobre onde um agente de IA funciona e onde ainda não funciona, como integrar IA ao CRM, ao ERP e ao site sem reescrever tudo e o que entra na conta depois que o projeto termina. Se o seu projeto já está na mesa, conheça como trabalha a Software House da Pocket Lab.

Perguntas frequentes

A IA substitui o desenvolvedor num projeto de software?

Não. Ela assume tarefas repetitivas, mas arquitetura, decisão técnica e revisão continuam com pessoas, que respondem pelo que vai para produção.

Quais riscos existem no código gerado por IA?

Código que parece correto e não é, falhas de segurança por dependências e exposição de dado sensível em ferramenta externa. A revisão humana e regras claras sobre onde o dado circula são a resposta.

Como saber se um processo vale automação com IA?

Ele é repetitivo, o erro é reversível, existe quem revise, há dado disponível e o risco de LGPD é conhecido. Sem isso, é melhor não automatizar agora.