Sobre *minha* experiência criando algo 100% com IA
Nessa última semana (do dia 18/04 até hoje 25/04), dediquei meu tempo livre para desenvolver uma aplicação utilizando codificação agentica (Agentic Coding). A vontade surgiu depois de ver o Fábio Akita comentando sobre o assunto. Nossa área mudou e precisamos nos adaptar: a codificação com IA veio para ficar — e isso não é problema. Há quem diga que é o fim do mundo; eu discordo. Mas é o fim de algo. Não sei o quê, então não vou gastar energia especulando.
Enfim, vou deixar de lado qualquer capricho sobre um futuro incerto e ser pragmático. Codificação com IA é mais rápida do que a codificação tradicional — pelo menos no meu caso. Agora eu não preciso saber como, mas preciso saber muito claramente o quê eu quero. Importante ressaltar: essa é minha experiência, num projeto pessoal específico. Um experimento. Se fosse um projeto de produção com times envolvidos, tudo seria diferente — a velocidade inicial seria parcialmente absorvida por um code review mais rigoroso, ou talvez até mais rigoroso que o convencional, porque agora há incerteza adicional sobre a origem do código.
A aplicação que desenvolvi foi o Index: um TUI (Terminal User Interface) para gerenciar arquivos PDF que baixei da web. Alguns são do TabNews, outros do Dev.to, e eu queria centralizá-los em um único lugar. O Index usa o sistema de arquivos do computador para localizar artigos de uma pasta específica e extrai metadados do nome do arquivo: status de leitura (lido/não lido), origem do artigo, nome do autor e título.
A premissa era simples, e eu sabia exatamente o quê queria. Para garantir que essa visão estava clara, utilizei o Gemini (versão web) para gerar um PRD (Product Requirements Document). Apresentei minha ideia, pedi que estruturasse em um documento formal, e com algumas iterações, tínhamos um .md pronto para começar o desenvolvimento.
Durante esse processo, inclusive encontrei um artigo: "O único prompt que você precisa aprender", publicado no TabNews. A ideia central dele é pedir à IA que faça o escrutínio da sua ideia — o que garante que você pensará em muito mais detalhes do que se tivesse apenas a visão inicial sem contrapontos.
Com a especificação em mãos (um PRD de escopo bem específico), decidi dividir a implementação em etapas — algo comum no desenvolvimento tradicional. Pedi ao agente para gerar Milestones com base no PRD. No fim, o projeto foi dividido em 7 marcos, cada um implementando uma parte do sistema.
A intenção era dupla: não bombardear o modelo com o projeto inteiro, mas com pedaços dele. E aqui vou ser honesto — embora tenha feito para adicionar disciplina ao processo, tenho certeza de que os modelos atuais aguentariam facilmente um projeto do escopo do Index em uma única requisição. Talvez não em um único prompt, mas em termos de contexto, eles realmente aguentam. A divisão também me ajudou a manter contexto das alterações e saber em qual etapa eu estava a cada momento. Foi útil? Sim. É necessário? Provavelmente não, mas não posso garantir. Projetos maiores podem ser um problema, ou não. Honestamente, não sei. E ninguém realmente pode dar certeza.
Com os arquivos .md do PRD e de cada milestone em mãos, eu tinha confiança suficiente para começar a codificar. E aqui está o ponto: eu não fazia ideia de como o código seria estruturado, apenas de o quê deveria fazer. Foi isso que me lancei.
A partir disso, pedi que o modelo gerasse a M1 e em poucos segundos eu tinha uma implementação. É assustador como é rápido — tão rápido que nos faz questionar se não daria para substituir uma pessoa. Mas o que esquecemos é que nosso trabalho não é escrever código. Código é apenas o meio, e para alguns radicais é até "o gargalo". Agora o código é escrito em segundos, mas a disciplina de engenharia de software não é inferida pelo modelo, é responsabilidade do programador.
Aqui preciso ser honesto também: o modelo errou muito pouco. Ele fez exatamente o que eu pedi, e isso é consequência direta de quão específico eu fui na especificação. Os erros que descobri não eram bugs técnicos — eram decisões de design de UI que não faziam sentido para mim, mas foi porque eu não especifiquei bem aquele detalhe. Não é sobre o modelo ser perfeito; é sobre a qualidade do input determinar a qualidade do output. Você sabe o que quer? Consegue comunicar? Então o modelo entrega. Você não sabe? Então ele entrega algo que você vai precisar iterar — muito mais vezes que se fosse codificando manualmente.
Eu escolhi Python. Eu escolhi qual biblioteca de TUI usar. Eu escolhi a arquitetura de pastas, decidi usar Value Objects, implementei a arquitetura em 3 camadas (com a camada service adicionada e sem camada de banco de dados). Eu escolhi escrever testes, escolhi como organizá-los, defini as regras de negócio, o que era válido e o que não era. Minha responsabilidade migrou de escrever código — que historicamente consumia a maior parte do tempo — para tomar decisões: escolher o que passou e o que não passou, qual regra seria implementada, se os testes cobriam o necessário.
Nunca tomei tanta decisão em um projeto. E isso é realmente divertido.
Aqui está o ponto importante: o "como" não desapareceu. Ele ainda é absolutamente crucial. Se você não sabe o que o código faz, realmente há um problema — sua aplicação pode virar uma caixa-preta. Mas o "como" mudou de significado. Você não precisa mais se preocupar em escrever o "como"; você precisa se preocupar em compreender, validar e governar o "como" que foi escrito.
E aqui está um detalhe importante que merece clareza: quando eu digo "não preciso saber como", eu não estou dizendo que não preciso entender Python, arquitetura de software ou padrões de design. Eu sei essas coisas. O que eu não preciso é saber a integração prática específica desses conceitos. Eu não preciso saber se a biblioteca X será integrada de jeito A ou jeito B — a IA decide isso. O que eu preciso é validar que a integração funciona e entender por que tomou a forma que tomou. O conhecimento técnico continua indispensável — apenas a natureza do trabalho evoluiu.
E uma coisa que ficou clara durante o projeto: os testes automatizados foram fundamentais. O Index tem 100% de cobertura de testes, e foi através deles que consegui gerenciar a dívida cognitiva. No meu caso, como especifiquei cada função nos arquivos de especificação, eu tenho confiança em suas intenções e os testes ajudam nisso.
Agora, uma reflexão sobre responsabilidade. Se o código subiu para produção, isso foi uma decisão — uma decisão minha. Se eu não testei edge-cases, isso também foi uma decisão. E consequentemente, a culpa é minha. O artigo fala sobre migração de escrever código para tomar decisões, e essa é uma delas. Você é responsável pelo que valida e coloca em produção, independentemente de quem escreveu.
No fim, sim, é uma mudança de como fazemos as coisas. Mas definitivamente não é uma sentença de morte. Não sabemos como será o futuro. Em muitas empresas, a codificação ainda é manual. A adoção de IA é rápida — mas também é lenta, dependendo de onde você olha. Que é útil é inegável. E que desenvolver não é só escrever código deveria ser mais claro do que nunca.
Agora, sobre times, grandes projetos, contextos corporativos? Não faço ideia. Meu experimento foi solitário e em um escopo pequeno. Talvez isso escale, talvez não. Talvez para empresas do interior, como a maioria daqui, a adoção seja ainda mais lenta porque ninguém sabe a resposta e "tentar a sorte" não é uma estratégia válida. Talvez o armazém de requisitos imprecisos seja um problema real. Talvez times grandes sofram com alguém gerando código que ninguém sabe como revisar direito. São incógnitas.
Mas o que é certo é que muita gente ainda tem medo, e alguns fingem que a IA não existe, que ela não vai escrever código. É hora de abrir-se à experiência de escrever código usando IA, de aprender a fazer isso — porque é não convencional, é diferente, e vai exigir disciplina. Essa foi minha experiência com o agentic coding.
Se quiser conferir, o código do projeto está aqui. Abraço.