Desenvolvimento assistido por IA não começa no prompt nem no código. Na LYPES, usamos uma regra simples: investir cerca de 80% do trabalho em contexto e 20% em execução, para que a IA atue sobre um problema real, com limites e validação.

Por que o contexto vem antes do desenvolvimento assistido por IA

Uma IA pode produzir código plausível a partir de uma instrução curta. Plausível, porém, não significa adequado ao produto, à arquitetura ou à operação.

Contexto responde ao que a execução não consegue decidir sozinha: qual problema merece atenção, quem é afetado, quais regras não podem ser quebradas e como reconhecer uma mudança correta. Os 80% são uma orientação de trabalho, não uma métrica universal nem uma promessa de produtividade.

A engenharia de contexto descrita pela Anthropic segue essa lógica: selecionar e atualizar o menor conjunto de informações de alto sinal, como instruções, histórico, ferramentas e dados relevantes. Mais informação não é automaticamente mais clareza.

O que compõe os 80% de contexto

Preparar contexto não significa despejar documentos em uma ferramenta. Significa organizar o que a IA precisa saber para raciocinar dentro do produto.

  • Objetivo: qual problema de negócio ou de uso deve ser resolvido.
  • Estado atual: comportamento observado, fluxo afetado, arquivos, integrações e restrições conhecidas.
  • Regras: políticas do produto, permissões, dados sensíveis e compatibilidades que precisam ser preservados.
  • Critérios: o que deve mudar, o que deve continuar igual e quais testes ou evidências indicarão que a alteração está correta.

Exemplo hipotético: um formulário de cadastro falha quando o endereço é alterado depois da validação. Em vez de pedir apenas “corrija o cadastro”, a solicitação deve registrar a etapa que falha, a regra esperada, a resposta da API, os arquivos envolvidos e o teste que precisa passar. A IA pode ajudar a localizar a causa e sugerir a alteração, mas a equipe continua responsável por confirmar o diagnóstico.

Os 20% de execução: gerar, testar e revisar

Com o contexto preparado, a execução pode ser curta e controlada. Uma boa solicitação define o objetivo, o escopo, as ferramentas disponíveis e a forma de validação; depois, a entrega é examinada em partes.

Para geração de código, as orientações de prompt engineering da OpenAI destacam instruções claras, exemplos de uso de ferramentas e testes de validação como práticas para melhorar a confiabilidade do resultado.

  • Pedir um plano de alteração antes de solicitar a implementação.
  • Limitar a mudança aos arquivos e comportamentos necessários.
  • Executar testes automatizados e verificações manuais relevantes.
  • Revisar o diff, as mensagens de erro e os efeitos sobre integrações existentes.
  • Registrar o que foi aprendido e atualizar o contexto antes da próxima iteração.

O estudo do SWE-agent relata melhora significativa em tarefas de engenharia de software quando o agente dispõe de uma interface para criar e editar arquivos, navegar por repositórios e executar testes. O ponto prático não é dar autonomia irrestrita, mas conectar a execução a ferramentas e verificações observáveis.

Como aplicar a filosofia em um produto real

Na rotina de uma software house, a proporção 80/20 ajuda a decidir onde usar capacidade técnica. Um pedido entra como hipótese; antes de virar tarefa, precisa ser relacionado ao objetivo, ao impacto, ao esforço e ao risco.

  • Descrever o problema: registrar o que acontece, quem é afetado e qual consequência precisa ser evitada.
  • Separar fato de suposição: distinguir evidências, como logs e relatos de uso, das explicações ainda não confirmadas.
  • Escolher a menor mudança útil: considerar correção, teste, melhoria de fluxo ou observabilidade antes de ampliar o escopo.
  • Validar e decidir: conferir o resultado no produto e usar o aprendizado para orientar a próxima prioridade.

Exemplo hipotético: uma operação depende de uma integração que falha ocasionalmente. Antes de gerar um conserto, a equipe verifica a frequência, a consequência, os logs, o contrato da API e o caminho alternativo. Se o maior risco for duplicidade de dados, talvez a primeira mudança adequada seja registrar o estado e criar um teste para garantir que repetir a mesma solicitação não crie dois registros, em vez de reescrever o fluxo inteiro. A IA pode apoiar investigação, código e testes dentro desse recorte.

Esse modo de trabalhar preserva o papel da LYPES como parceira técnica: entender, priorizar e implementar. Em um contrato recorrente por horas, o contexto ajuda a redirecionar a capacidade para a prioridade validada; em um projeto de escopo fechado, ajuda a manter o resultado delimitado. Em ambos, a decisão vem antes da ferramenta.

Próximo passo: identifique um gargalo concreto do seu sistema — uma etapa lenta, retrabalho recorrente ou regra difícil de manter — e converse com a LYPES. Podemos discutir as melhorias prioritárias e se o caminho adequado é capacidade recorrente por horas ou um escopo fechado.