Direto ao ponto

Uma cobrança duplicada exige um cuidado diferente de um ajuste na aparência de uma tela interna. O tempo dedicado ao código precisa acompanhar a falha que você está tentando evitar e o custo de corrigi-la depois. Eu defendo que a avaliação de desempenho considere essa relação, junto do prazo para colocar a funcionalidade em uso.

Considere uma situação: você dedica a semana a escolher os padrões de arquitetura para um novo projeto. Seu colega conclui uma tarefa parecida em uma hora. Na reunião de avaliação, o gestor já pode abrir a tela criada por ele. O seu trabalho ainda precisa de uma explicação sobre o que aquele tempo acrescentou à implementação.

A dificuldade aparece quando a justificativa termina em “é uma boa prática”. O gestor continua sem saber qual falha você encontrou ou por que a solução mais simples seria insuficiente. Para discutir o tempo gasto, vocês precisam examinar o comportamento do sistema e o trabalho necessário para mantê-lo.

Por que a funcionalidade pronta recebe reconhecimento

Uma tela que substitui o preenchimento manual de uma planilha permite observar um resultado logo no uso. O funcionário registra a informação no sistema e conclui uma tarefa que antes exigia copiar campos. Você consegue demonstrar essa mudança ao gestor sem precisar projetar um problema futuro.

O cuidado preventivo exige outra explicação. Um teste que reproduz uma cobrança duplicada, por exemplo, permite mostrar a falha mesmo sem esperar que um cliente seja cobrado duas vezes. Sem essa demonstração, o gestor pode ver apenas os dias adicionais de desenvolvimento e ter dificuldade para relacioná-los ao que foi corrigido.

Durante a espera pela funcionalidade, o preenchimento manual da planilha continua. Esse trabalho também precisa entrar na comparação. A semana dedicada à arquitetura pode ser justificável, mas você precisa explicar por que o cuidado exigia aquele tempo e qual consequência teria adiar a correção.

Uma justificativa vaga pode esconder um cuidado necessário

As duas tarefas do exemplo podem ter exigências diferentes. A aparência parecida das telas não informa se ambas alteram cobranças ou dão acesso às mesmas informações do cliente. A comparação precisa considerar o comportamento que cada implementação deveria apresentar.

O repertório técnico para avaliar a implementação permite comparar o que cada rotina faz. “Fica melhor organizado para manutenção” ainda deixa o benefício indefinido. A separação de uma rotina pode, por exemplo, permitir alterar o cálculo de uma cobrança sem modificar a tela que exibe o histórico. Nesse caso, a explicação ganha um objeto que você e o gestor podem examinar no código.

Uma explicação ruim também pode acompanhar uma escolha tecnicamente adequada. Por isso, eu separo a dificuldade de justificar o trabalho da qualidade do código. Quando a justificativa estiver vaga, vale investigar o que a organização facilita e quanto custou implementá-la. Com essa comparação, você avalia se o cuidado compensou o tempo investido.

O cuidado depende do que a funcionalidade pode afetar

Uma tela interna de consulta pode começar com uma implementação simples quando uma indisponibilidade permite continuar o trabalho por outro caminho. Você precisa conferir essa condição. Uma tela usada por poucos funcionários pode ser indispensável para fechar o faturamento, então o número de acessos não informa, por si só, o impacto de uma falha.

Na cobrança, considere o cliente que clica novamente porque a primeira confirmação demorou. Você precisa conferir como o sistema reconhece que as duas tentativas se referem à mesma cobrança. Ao repetir essa ação em teste, você confere os registros da cobrança e mostra ao gestor o comportamento que exigiu trabalho adicional.

O acesso ao endereço e à forma de pagamento exige uma conferência diferente. Com um perfil que deveria consultar apenas o histórico de atendimento, você tenta abrir essas informações e verifica a resposta do sistema. A tela precisa respeitar a permissão combinada, inclusive quando o acesso acontece por um caminho diferente da navegação habitual.

Uma integração com um serviço externo também pode exigir cuidado já na primeira versão. Quando esse serviço fica indisponível, o sistema precisa informar que a consulta falhou e permitir a ação combinada para esse caso. Você pode demonstrar essa situação em teste e discutir quais partes da aplicação precisam continuar disponíveis durante a falha.

A revisão continua necessária com o código gerado por IA

A implementação gerada pela IA pode ficar pronta rapidamente e ainda exigir trabalho para conferir o comportamento. No exemplo da cobrança, você precisa repetir a tentativa e verificar o registro criado. A leitura do código, isoladamente, pode deixar passar uma falha que aparece durante o uso da tela.

O mesmo cuidado vale para a implementação escrita manualmente. A base desta comparação é o funcionamento acordado para a tarefa, inclusive quando outro programador precisar alterar aquele código. A discussão sobre quando vale a pena escrever código à mão com agentes de IA disponíveis aprofunda essa escolha. O tempo de geração é apenas uma parte do trabalho necessário para colocar uma funcionalidade em uso.

Como combinar prazo e cuidado durante a tarefa

Na primeira conversa com o gestor de produto, você pode delimitar uma parte que já possa ser usada e explicar qual comportamento precisa estar verificado. Numa rotina de cobrança, esse acordo inclui o que deve acontecer quando o cliente repete a tentativa. O gestor consegue acompanhar o que falta para liberar a funcionalidade e discutir o prazo com você.

Uma cadência de lançamentos pequenos e frequentes permite avaliar partes concluídas durante o desenvolvimento. A tela de consulta do histórico pode estar disponível mesmo com uma alteração no cálculo ainda em teste, desde que essa separação faça sentido para o sistema. Você mostra o que já funciona e explica a parte que continua exigindo cuidado.

As simplificações também precisam ficar registradas com um motivo para revisá-las. Uma consulta manual ao serviço externo pode atender ao uso inicial, por exemplo. O registro deve explicar como essa consulta acontece e qual mudança no uso tornaria necessário automatizá-la. Assim, o acordo permanece consultável quando a funcionalidade precisar mudar.

O retrabalho também precisa aparecer na avaliação

Durante o desenvolvimento, você pode descobrir que a arquitetura escolhida exigiu uma semana para atender a uma necessidade que uma solução mais simples já cobria. Rever essa escolha faz parte do trabalho. Esperar por uma falha na implementação do colega apenas adia a conversa sobre o tempo que você gastou.

Na avaliação, o histórico da tarefa permite examinar a primeira versão e as correções posteriores. Quando uma funcionalidade exige novas intervenções, você consegue mostrar o tempo dedicado a corrigir o comportamento e o que ficou funcionando depois. Eu defendo que esse trabalho receba reconhecimento junto da publicação inicial, com a mesma atenção ao resultado para o negócio.

Para desenvolver essa capacidade de avaliar sistemas criados com IA, você pode conhecer a Formação Vibe Coding e o Plano IA Makers. Para examinar a arquitetura de um sistema que você já está construindo, o Diagnóstico de Produto e Arquitetura da Dev Side Studio oferece uma análise das escolhas técnicas e da sequência de trabalho.