Depois de tanto tempo desenvolvendo, é curioso ver uma ferramenta produzir código a partir de uma conversa. Uma atividade com a qual construí tanta familiaridade pode começar com uma descrição do que preciso e continuar com uma implementação pronta para avaliar.
Isso me faz pensar no que aprendi durante esses anos. Quanto desse conhecimento está em escrever o código? E quanto está nas decisões que tomo antes de começar, nas perguntas que faço e nos problemas que consigo antecipar?
Quando penso no desenvolvimento de um sistema, vejo muita coisa que acontece antes da implementação. Entender uma solicitação, descobrir qual dificuldade ela tenta resolver, perceber o que já existe e avaliar onde uma mudança pode interferir.
Com a experiência, algumas dessas decisões ficam tão familiares que quase deixam de parecer decisões.
Você olha para uma solução e sente que alguma coisa precisa ser revista. Talvez ela complique uma rotina simples, repita uma regra que já existe ou resolva o caso apresentado deixando uma situação importante de fora. Esse olhar tem uma história. Vem de coisas que você construiu, corrigiu e precisou acompanhar funcionando na prática.
É nessa capacidade de avaliar e dar direção que vejo o valor da minha experiência hoje.
Penso, por exemplo, em pedir uma função para gerar um pedido. A descrição parece simples até começarem as perguntas: quem pode executar essa ação? O que acontece se a pessoa clicar duas vezes? Como ela descobre que deu certo? Se houver uma falha no meio, o que fica salvo?
São perguntas sobre o funcionamento da solução e suas consequências. Elas precisam ser respondidas mesmo quando a implementação inteira é feita pela IA.
Ao orientar uma ferramenta, preciso explicar coisas que antes talvez ficassem apenas no meu raciocínio. Preciso organizar o contexto, dizer quais restrições importam e reconhecer o que ainda está mal definido.
Isso também pode revelar lacunas no meu próprio entendimento. Se tenho dificuldade para explicar o comportamento esperado, vale investigar melhor o problema antes de seguir. Receber uma implementação rapidamente pode dar uma sensação de avanço mesmo quando algumas decisões continuam em aberto.
A validação exige atenção semelhante. Preciso verificar se as regras foram respeitadas, se as informações estão corretas e se a pessoa consegue realizar a tarefa. Uma solução também precisa se comportar bem quando faltam dados, quando uma operação falha ou quando alguém faz algo diferente do caminho que imaginei.
Na forma como quero trabalhar, escrever e conhecer cada detalhe do código deixa de ser o centro da minha contribuição. Quero concentrar meu esforço em compreender o negócio, definir o comportamento esperado e ter critérios para aceitar ou recusar o que foi entregue.
Isso muda também o que preciso aprender. Explicar melhor uma necessidade, desenhar uma experiência de uso e avaliar segurança, desempenho e impacto na operação passam a ocupar mais espaço.
Ainda estou me adaptando a essa mudança. Depois de tantos anos acostumado a transformar uma ideia em código, preciso aprender a reconhecer meu trabalho nas decisões que orientam a construção.
Quero conseguir olhar para uma entrega e explicar por que ela resolve o problema, quais situações foram consideradas e o que ainda precisa melhorar. É nessa capacidade de conduzir o desenvolvimento que quero continuar evoluindo.