Como usei IA para criar uma Central da Copa 2026, e por que isso não foi “só pedir para a IA fazer”
Por Lucas Sodré.
Recentemente desenvolvi um projeto chamado Central da Copa 2026, uma aplicação web para acompanhar a Copa do Mundo FIFA de 2026, reunindo informações como jogos, tabela e transmissões em uma experiência simples, direta e pensada para quem quer consultar rapidamente o que importa.
O projeto está disponível aqui:
A ideia nasceu de uma necessidade bem comum: quando chega uma Copa do Mundo, as informações ficam espalhadas. Você quer saber quando tem jogo, quem joga, em qual fase, onde assistir, quais partidas estão próximas e como acompanhar tudo sem precisar abrir vários sites diferentes.
A Copa de 2026 tem um desafio adicional: ela é maior do que as edições anteriores. São mais seleções, mais jogos, mais fases, mais horários e mais possibilidades de confusão para quem só quer acompanhar o torneio de forma prática.
Por isso, meu objetivo foi criar uma central simples, organizada e útil.
Mas o ponto principal deste relato não é apenas o produto final. É o processo.
Eu sou engenheiro de software sênior e usei IA para desenvolver praticamente toda a aplicação. Mas isso não significa que eu simplesmente escrevi “crie um site da Copa” e aceitei qualquer resultado.
Na prática, o trabalho foi muito mais parecido com liderar um desenvolvedor extremamente rápido, mas que precisa de direção clara.
IA não substituiu engenharia. Ela amplificou engenharia.
O que mais mudou em 2026, comparando com minha experiência em 2025, foi a qualidade da colaboração.
Em 2025, eu já tinha desenvolvido uma solução semelhante para acompanhar a Copa do Mundo FIFA de Clubes. Na época, a IA ajudava bastante, mas ainda exigia muito mais correção manual, retrabalho, revisão de estrutura e explicações repetidas.
Em 2026, a sensação é diferente.
A IA já consegue lidar melhor com contexto, manter consistência entre arquivos, entender regras de negócio com mais profundidade, sugerir componentes, ajustar layout, refatorar trechos, criar testes e corrigir problemas de forma mais próxima de um fluxo real de engenharia.
Mesmo assim, o papel humano continua sendo decisivo.
Eu defini o produto.
Eu defini o fluxo de navegação.
Eu defini as regras de negócio.
Eu revisei a experiência de uso.
Eu conduzi as decisões técnicas.
Eu validei se o resultado fazia sentido.
Eu pedi ajustes quando a IA seguia um caminho genérico demais.
Eu cobrei consistência, clareza e qualidade.
A IA executou muito, mas a direção foi humana.
O que eu precisei fazer além de “pedir código”
Uma coisa que ficou muito clara nesse projeto é que a qualidade do resultado depende diretamente da qualidade da condução.
Meu trabalho foi transformar uma ideia vaga — “uma central para acompanhar a Copa” — em decisões concretas de produto e engenharia.
Algumas decisões que precisei orientar:
- Como organizar as informações principais para o usuário não se perder;
- Como tratar jogos, fases, horários e transmissões;
- Como deixar a interface simples para consulta rápida;
- Como pensar a experiência mobile, já que muita gente acompanha esse tipo de informação pelo celular;
- Como evitar uma interface poluída, mesmo lidando com muitos dados;
- Como separar responsabilidades no código;
- Como validar regras e comportamentos esperados;
- Como revisar o que a IA entregava antes de aceitar como pronto.
Esse ponto é importante porque existe uma visão superficial de que usar IA para programar é “não programar”.
Na minha experiência, é o contrário.
Quanto mais capacidade a IA ganha, mais importante fica saber especificar, revisar, testar, priorizar e tomar decisão técnica.
A diferença é que, em vez de gastar a maior parte do tempo digitando cada linha de código, eu consigo gastar mais energia pensando no produto, na arquitetura, nos casos de uso e na qualidade final.
O ganho real não foi só velocidade
Velocidade foi um ganho óbvio.
Mas, para mim, o maior ganho foi conseguir iterar mais.
Eu conseguia testar uma ideia de interface, perceber que não estava boa, pedir uma variação, ajustar a hierarquia visual, mudar a abordagem, revisar o fluxo e seguir refinando.
Esse tipo de iteração normalmente custa caro em energia. Com IA, ficou mais barato experimentar.
Isso muda bastante a forma de construir produto.
Antes, muitas vezes eu evitava testar certas ideias porque sabia que teria um custo alto de implementação. Agora, consigo explorar alternativas com mais liberdade — desde que eu continue fazendo o papel de filtro técnico e de produto.
A IA acelera a criação, mas ainda cabe ao engenheiro decidir o que merece ficar.
Onde a IA ajudou mais
Neste projeto, a IA foi especialmente útil em algumas frentes:
- Estruturação inicial da aplicação;
- Criação de componentes;
- Ajustes de layout e responsividade;
- Organização de dados;
- Refatoração de trechos;
- Sugestão de melhorias de experiência;
- Criação e revisão de regras;
- Testes e validações;
- Correção de inconsistências;
- Polimento final.
Mas em todos esses pontos, a IA funcionou melhor quando recebeu instruções claras.
Quando eu era genérico, o resultado era genérico.
Quando eu especificava melhor o comportamento esperado, o contexto do usuário e as restrições do produto, o resultado melhorava muito.
Esse talvez seja um dos aprendizados mais importantes: IA boa não elimina a necessidade de clareza. Ela aumenta o retorno de quem sabe ser claro.
O que mudou de 2025 para 2026
Comparando com a solução que fiz em 2025 para a Copa do Mundo FIFA de Clubes, senti algumas diferenças bem fortes.
A IA de 2026 entende melhor tarefas maiores.
Mantém melhor o contexto do projeto.
Erra menos em mudanças espalhadas por múltiplos arquivos.
Consegue ajudar melhor com testes.
É mais útil para revisar código.
Lida melhor com refatorações.
Consegue colaborar de forma mais próxima de um fluxo real de desenvolvimento.
Em 2025, muitas vezes parecia que eu estava usando uma ferramenta de autocomplete muito avançada.
Em 2026, a sensação é mais próxima de trabalhar com agentes de desenvolvimento: eu descrevo uma intenção, defino restrições, reviso o plano, deixo executar, testo, corrijo a rota e sigo iterando.
Isso não torna o processo automático. Torna o processo mais produtivo.
O desenvolvedor continua sendo responsável
Um ponto que considero essencial: usar IA não tira a responsabilidade técnica de quem está construindo.
Se a regra de negócio está errada, a culpa não é da IA.
Se a experiência ficou confusa, a culpa não é da IA.
Se o código está frágil, a culpa não é da IA.
Se não houve teste, revisão ou critério, a culpa não é da IA.
A IA pode sugerir, escrever, adaptar e acelerar. Mas quem assina a decisão continua sendo o engenheiro.
Por isso, vejo cada vez menos sentido na pergunta “a IA vai substituir programadores?” e cada vez mais sentido na pergunta:
Que tipo de programador consegue extrair valor real da IA?
Na minha visão, quem mais ganha com IA não é necessariamente quem sabe pedir “faça uma tela bonita”.
É quem sabe decompor problema, definir regra, pensar fluxo, revisar arquitetura, testar comportamento, identificar inconsistência e transformar uma ideia em produto utilizável.
Conclusão
Criar a Central da Copa 2026 com IA foi uma experiência muito interessante porque mostrou, na prática, como o desenvolvimento de software está mudando.
Eu não deixei de ser engenheiro de software durante o processo. Pelo contrário: precisei usar ainda mais julgamento técnico.
A diferença é que a IA assumiu boa parte da execução operacional, enquanto eu fiquei mais focado em direção, produto, arquitetura, qualidade e validação.
Para mim, esse é o ponto mais forte da IA em desenvolvimento hoje.
Ela não transforma uma ideia ruim automaticamente em um bom produto.
Ela não substitui clareza de pensamento.
Ela não elimina regra de negócio.
Ela não dispensa testes.
Ela não remove a necessidade de revisão.
Mas, quando bem conduzida, ela permite que um engenheiro experiente construa mais rápido, teste mais ideias e chegue a um resultado melhor em menos tempo.
A Central da Copa 2026 foi um ótimo exemplo disso para mim.
Não foi “a IA fez sozinha”.
Foi engenharia guiada por humano, com execução acelerada por IA.