Se ficou mais fácil construir, ficou mais importante saber o que construir

Antes de abrir uma ferramenta e pedir que ela construa alguma coisa, alguém precisa entender quem enfrenta o problema, como trabalha hoje e o que mudaria com a solução. Também precisa verificar se aquilo já existe no sistema que a empresa utiliza. Criar outro aplicativo nem sempre é a melhor resposta.

Cabe ao gestor definir o resultado esperado. Pedir que o time “use mais IA” é vago. Escolher um problema delimitado, estabelecer como a melhoria será medida e acompanhar o uso da solução oferecem uma direção muito mais clara.

Ao apresentar o desafio da T2S no Hackathon Unisanta, propus que os estudantes pensassem em um negócio digital inteiro. A expectativa ia além de uma apresentação convincente ou de algumas telas que simulassem um aplicativo. Queria que considerassem o trabalho de prototipar, construir, revisar, conquistar usuários e manter a solução funcionando.

Essa proposta reflete uma mudança naquilo que acredito que podemos cobrar de quem está aprendendo a desenvolver software.

Nos hackathons de uma madrugada que acompanhei antes da popularização da IA generativa, não vi a entrega do protótipo prometido. Em eventos mais longos, os protótipos ainda chegavam bastante crus.Hoje, sustento que podemos buscar um produto mínimo viável, o conhecido MVP, desde que o problema seja bem delimitado e a equipe saiba o que precisa demonstrar.

Isso não significa que uma madrugada seja suficiente para validar um negócio ou preparar um sistema para uma operação crítica. Significa que podemos elevar a expectativa sobre o que será construído e, principalmente, sobre a compreensão que os participantes têm daquilo que estão construindo.

A mesma discussão vale para as empresas.

Construir mais rápido não resolve a escolha do problema

Uma equipe pode usar IA para desenvolver uma funcionalidade em menos tempo e descobrir depois que ninguém precisa dela. Pode automatizar uma rotina que deveria ter sido eliminada. Pode entregar uma interface agradável que acrescenta mais uma etapa ao trabalho de quem já precisa alimentar vários sistemas.

A facilidade de implementação não corrige uma escolha ruim. Em alguns casos, apenas permite investir nela mais depressa.

Por isso, antes de abrir uma ferramenta e pedir que ela construa alguma coisa, alguém precisa entender quem enfrenta o problema, como trabalha hoje e o que mudaria com a solução. Também precisa verificar se aquilo já existe no sistema que a empresa utiliza. Criar outro aplicativo nem sempre é a melhor resposta.

Esse cuidado pode parecer pouco ambicioso quando as demonstrações de IA prometem aplicações prontas em minutos. Para quem administra uma empresa, porém, cada aplicação traz responsabilidades. Alguém terá de cuidar dos acessos, das integrações, das atualizações e do suporte. O custo de produzir a primeira versão é apenas uma parte dessa decisão.

Na T2S e no DYNApp Hub, essa discussão conecta o desenvolvimento de software à construção de produtos e negócios. Uma solução precisa encontrar espaço na rotina de alguém. A capacidade de escrever código ajuda a chegar até esse ponto, mas não substitui o trabalho de entender a demanda.

Conhecer a operação faz diferença

Pense em uma empresa de logística que queira usar IA para conferir documentos de uma operação. Em uma demonstração, o sistema recebe arquivos organizados, extrai campos e apresenta um resumo. Tudo parece funcionar.

No uso cotidiano, pode chegar uma versão antiga do documento, um arquivo incompleto ou uma informação que contradiz o registro de outro sistema. É preciso decidir qual fonte prevalece, quando interromper o fluxo e quem deve analisar a divergência. Uma resposta plausível não basta para autorizar a continuidade de uma operação.

O profissional que conhece essas situações participa do desenho da solução. Ele sabe quais exceções são frequentes, onde uma conferência adicional é necessária e quais erros podem comprometer um prazo.

Esse conhecimento precisa se encontrar com a competência técnica. Quem entende a operação pode não conhecer os riscos de uma integração. Quem domina a ferramenta pode não perceber que automatizou uma regra que só vale em parte dos casos. A aproximação entre essas pessoas continua necessária, mesmo quando a IA executa boa parte da implementação.

Para gestores de portos, transportadoras, recintos e empresas de comércio exterior, há uma oportunidade concreta: envolver quem conhece o trabalho desde a definição do problema, em vez de chamar a operação apenas para aprovar uma tela pronta.

Visão de produto não é um cargo reservado a poucos

Tenho defendido que estudantes de tecnologia desenvolvam visão de gerente de produto. Não quero dizer que todos devam abandonar a programação ou disputar o mesmo cargo. Refiro-me à capacidade de relacionar decisões técnicas às necessidades de quem vai usar a solução.

Um desenvolvedor com essa visão procura entender por que determinada funcionalidade foi solicitada. Consegue discutir alternativas, reduzir um escopo excessivo e propor uma maneira de verificar se o resultado ajudou.

Às vezes, isso significa construir menos.

Se o problema é a demora para localizar um documento, talvez uma melhoria na busca resolva. Se o obstáculo é a falta de uma informação na origem, gerar relatórios mais sofisticados não elimina a deficiência. Se uma aprovação demora porque ninguém sabe quem é o responsável, o primeiro trabalho pode ser organizar o processo.

A IA pode ajudar a investigar essas possibilidades e a testar alternativas. Ainda assim, a empresa precisa assumir as escolhas. Um fornecedor de modelo não conhece, por conta própria, todos os compromissos que aquela operação tem com clientes, trabalhadores e órgãos reguladores.

Os fundamentos continuam no centro da formação

A facilidade de gerar código pode levar à conclusão de que aprender programação ficou menos importante. Minha leitura é outra: precisamos distinguir o domínio de uma ferramenta da compreensão do que ela produz. Continuo defendendo uma formação sólida em lógica de programação, arquitetura e segurança da informação.

A lógica permite perceber que uma regra está incompleta ou que uma exceção foi tratada de forma errada. A arquitetura ajuda a decidir como a solução se conecta aos sistemas existentes e o que acontece quando uma dessas partes falha. A segurança orienta os limites de acesso e o tratamento das informações.

Sem essa base, o profissional corre o risco de depender da mesma IA tanto para construir quanto para julgar se a construção está correta, sem conseguir questionar a resposta.

As ferramentas vão mudar. O estudante que aprende apenas a operar a interface do momento fica dependente dela. Quem compreende os fundamentos tem melhores condições de avaliar uma ferramenta nova, reconhecer suas limitações e escolher quando utilizá-la.

Isso também não exige saber tudo antes de começar. Um projeto pequeno, com uso real e acompanhamento adequado, pode ensinar muito. O importante é que a facilidade de produzir não sirva como desculpa para dispensar a revisão.

O que empresas e escolas deveriam cobrar

No desafio do hackathon, os papéis de prototipar, construir, revisar, crescer e manter, que já discuti aqui em outro artigo, ajudam a lembrar que o trabalho continua depois da primeira demonstração. Uma boa ideia precisa ser testada. Uma solução utilizável precisa encontrar usuários. Um sistema em uso precisa de manutenção.

Essa responsabilidade não deve ser confundida com a expectativa de que uma pessoa faça sozinha o trabalho de uma equipe inteira. Os papéis podem ser distribuídos. O que precisa existir é compreensão de como cada entrega afeta o restante.

Na formação, isso permite avaliar mais do que a aparência do aplicativo. O estudante consegue explicar o problema? Justifica as prioridades? Mostra como verificou o funcionamento? Reconhece o que ainda não está pronto?

Nas empresas, os mesmos critérios ajudam a contratar e desenvolver profissionais. Conhecer ferramentas de IA é útil, mas uma lista de ferramentas no currículo diz pouco sobre a capacidade de resolver uma necessidade da operação.

Também cabe ao gestor definir o resultado esperado. Pedir que o time “use mais IA” é vago. Escolher um problema delimitado, estabelecer como a melhoria será medida e acompanhar o uso da solução oferecem uma direção muito mais clara.

A possibilidade de construir mais rápido é bem-vinda. Ela permite testar ideias que antes poderiam ficar na fila por falta de tempo ou orçamento. Mas o benefício depende da qualidade dessas escolhas.

Se ficou mais fácil construir, precisamos dedicar mais atenção ao que merece ser construído. E formar profissionais capazes de acompanhar essa decisão até o momento em que alguém utiliza a solução e consegue trabalhar melhor com ela.

Ricardo Pupo Larguesa. Fundador da T2S, professor de Programação e Machine Learning da Faculdade de Tecnologia do Estado de São Paulo (Fatec) e autor do livro Engenharia de Prompt para Devs: Um guia para aprender a usar a IA antes que a IA aprenda a usar você.