8 anos de desejo, 3 meses para concluir — a fórmula dos side projects transformada pela IA

• Uma ferramenta de desenvolvimento de alta qualidade para SQLite, que fazia falta há muito tempo, foi concluída em pouco tempo com a ajuda da IA
• A maior dificuldade foi construir o parser, devido à ausência de uma especificação gramatical oficial e a um codebase complexo em C
• Com agentes de codificação por IA, como o Claude Code, a implementação inicial avançou rapidamente, mas o problema de código espaguete levou a uma reescrita baseada em Rust
• A IA mostrou grande eficiência em geração de código, refatoração, apoio ao aprendizado e melhoria de UX, mas também trouxe efeitos colaterais como atraso de design, desconexão do código e vício em dependência
• Em conclusão, a IA é apenas uma ferramenta para acelerar a implementação; o design e a direção do software continuam sendo responsabilidade humana

---

Registro de 3 meses construindo ferramentas de desenvolvimento para SQLite com IA

• Havia, há muito tempo, o desejo por ferramentas de desenvolvimento de alta qualidade para SQLite, mas as ferramentas open source existentes deixavam a desejar em confiabilidade, velocidade e flexibilidade
  • Durante a manutenção do PerfettoSQL, havia demanda por recursos como formatter, linter e extensão de editor, mas não existia uma ferramenta adequada
  • Havia a intenção de criar uma nova ferramenta como projeto pessoal, mas a dificuldade e o peso do trabalho repetitivo fizeram isso ser adiado por anos

Dificuldades do projeto

• O SQLite não tem especificação gramatical oficial nem uma API de parser estável
  • Como ele não gera internamente uma parse tree, foi necessário extrair diretamente a lógica do parser a partir do código-fonte
  • Era preciso mapear manualmente mais de 400 regras gramaticais, e escrever testes e depurar era um trabalho extremamente repetitivo e cansativo
• O codebase em C do SQLite é complexo e denso, o que dificulta sua compreensão
  • A estrutura era tão difícil que só para entender a API de virtual tables e sua implementação foram necessários vários dias

Processo de desenvolvimento com IA

• A partir do fim de 2025, passou-se a usar de forma séria agentes de codificação por IA, como o Claude Code
  • No início, a maior parte do design e da implementação foi delegada à IA, em um estilo de “vibe-coding”
  • O resultado funcionava, mas o codebase virou um emaranhado de código espaguete, a ponto de se tornar impossível de manter
• Depois disso, tudo foi reescrito em Rust, reorganizando a estrutura
  • O uso de Rust em vez de C facilitou o desenvolvimento de componentes de nível superior, como validador e language server
  • A IA foi limitada a uma função de “ferramenta de autocomplete reforçada”, enquanto design, revisão e testes passaram a ser conduzidos diretamente pela pessoa autora
  • Foi criado um scaffolding para validar a saída da IA, incluindo linting, validação e automação de testes

O que a IA tornou possível

• Superar a inércia

  • A IA quebra o trabalho em problemas concretos menores, facilitando começar
  • Em vez de “preciso entender parsing de SQLite”, a dinâmica mudou para “vou revisar a abordagem proposta pela IA”, acelerando a execução

• Velocidade na geração de código e refatoração

  • Quando os requisitos são claros, a IA escreve rapidamente código padronizado e consistente
  • Em designs não padronizados, como a estrutura do parser, ela mais atrapalha do que ajuda, exigindo implementação manual
  • Após gerar grandes volumes de código, a refatoração contínua é indispensável para manter a qualidade

• Papel de assistente de aprendizado

  • A IA explica em tempo real novos conceitos, como o algoritmo de formatação Wadler-Lindig
  • Também permite entrar rapidamente em áreas menos familiares, como Rust e extensões do VS Code
  • Quando o contexto do projeto se perde, perguntas como “explique este componente” ajudam na recuperação imediata do contexto

• Aumento do nível de acabamento

  • Reduziu o custo de desenvolver recursos complementares, como extensão de editor, binding para Python, playground em WASM e site de documentação
  • Com menos peso na implementação, foi possível focar mais em melhorias de UX, reforçando a experiência do usuário em mensagens de erro, design de CLI etc.

Efeitos colaterais do uso de IA

• Dependência viciante

  • Existe uma estrutura de recompensa tipo caça-níquel de “só mais um prompt”
  • Quanto maior o cansaço, pior a qualidade dos prompts; os resultados pioram e isso cria um ciclo vicioso

• Desconexão com o codebase

  • Quanto mais código gerado por IA se acumula, maior a perda de sensibilidade para a estrutura detalhada
  • Quando o contexto se perde, até a conversa com a IA fica longa e ineficiente
  • Como solução, adotou-se o hábito de ler o código diretamente logo após a geração e verificar “onde eu teria escrito diferente”

• Atraso e erosão do design

  • Como refatorar ficou fácil, surgiu a tendência de adiar decisões centrais de design
  • Mesmo com muitos testes, é difícil esconder erros fundamentais de design, e no fim uma reescrita completa pode se tornar necessária

• Ausência de noção de tempo

  • A IA não entende o contexto temporal nem o processo evolutivo do código
  • Isso leva à repetição de erros passados ou à reexploração ineficiente de problemas já resolvidos
  • Documentação ajuda a compensar isso, mas é difícil registrar completamente até a intenção do design

A relatividade do uso de IA

• Em áreas profundamente compreendidas, a IA é excelente, permitindo revisão rápida e repetição eficiente
  • Ex.: geração de regras de parser, onde há uma resposta claramente correta
• Em áreas parcialmente conhecidas, ela é útil como ferramenta de aprendizado, mas exige atenção constante
  • Ex.: aprendizado de algoritmos de formatter
• Na fase em que ainda não se sabe o que construir, ela pode ser prejudicial
  • Ex.: surgimento de loops improdutivos durante a etapa de design de arquitetura
• A IA é forte em problemas verificáveis (compilar, passar em testes), mas
  é fraca em questões sem resposta única, como design e qualidade de API

Conclusão

• Foi graças à IA que foi possível realizar em 3 meses a ferramenta para SQLite imaginada ao longo de 8 anos
  • Mas o processo não foi uma simples história de sucesso: ele veio acompanhado dos limites e custos da dependência de IA
• A IA é um acelerador da implementação, mas não substitui o design
  • Ela responde com precisão a perguntas técnicas, mas carece de história, gosto e sensibilidade de usuário
• A verdadeira lição é que, mesmo que a IA permita bater na parede mais rápido,
  cabe aos humanos assumir a direção do design e a “alma do software”
• O que será necessário daqui para frente é compartilhar casos de projetos capazes de resistir a usuários reais e à manutenção
  • Não apenas experimentos, mas o acúmulo de experiências de desenvolvimento com IA realistas e sustentáveis

[GN⁺]

Comentários do Hacker News

• Foi revigorante ver uma visão equilibrada sobre programação com IA
  É uma experiência com a qual a maioria dos desenvolvedores sérios provavelmente se identifica — no começo você se surpreende com o quão bem a IA escreve código, mas depois percebe que a base de código virou uma bagunça de código espaguete
  Alguns nem fazem code review e saem dizendo “agora a programação manual acabou”, enquanto outros decretam que “programar com IA não serve para nada”
  Mas a realidade está em algum ponto no meio. A IA pode ser um grande acelerador de produtividade, mas precisa ser integrada corretamente ao fluxo de trabalho e o ser humano deve continuar envolvido

  • Eu também usei o Claude como minha principal interface de programação nos últimos 3 meses
    No início era um protótipo, mas rapidamente evoluiu para um serviço real. Depois sofri para refatorar e limpar um monte de código inútil
    Ainda assim, é graças àquela prototipagem rápida que o produto atual existe. O Claude foi útil para organizar o código, quase como uma motosserra
    Recentemente adicionei um type checker com hooks de pre-commit e corrigi 90 erros em 2 horas.
    Programar com IA é impressionante, mas em código de produção revisão humana e julgamento continuam indispensáveis
  • Gostei especialmente deste texto por causa da perspectiva equilibrada
    Ainda assim, como este caso é um projeto greenfield individual, é difícil aplicá-lo diretamente ao desenvolvimento normal em equipe
    Mesmo assim, se o protótipo for feito com a premissa de ser descartado depois, acho que até código espaguete é aceitável.
    O problema foi o autor achar que poderia evoluir aquilo diretamente para um produto real.
    Mas acredito que esse fracasso deve ter ensinado um design melhor
  • Na verdade, acho que esse tipo de reação polarizada é uma fase pela qual passa todo mundo que experimenta programação com IA pela primeira vez
    Primeiro vem o deslumbramento, depois a decepção, e por fim se encontra um equilíbrio.
    Parece quase uma versão de IA do modelo de Kübler-Ross
  • Por outro lado, eu vejo a obsessão com qualidade de código como um ponto cego na era da IA
    Claro que qualidade importa, mas agora a qualidade do código em si está ficando menos importante
    Está aumentando a quantidade de código que não precisa de manutenção, como apps pessoais, e a capacidade de design da IA também está melhorando rapidamente
    No fim, a “verdade sobre programar com IA” continua mudando, e esse movimento não vai parar
  • Acho que existem dois motivos para textos realistas como este serem raros
    Primeiro, a maioria dos desenvolvedores simplesmente desfruta em silêncio de um ganho de produtividade de 2% a 50% e não vê motivo para fazer alarde
    Segundo, programação com IA de verdade é entediante e pouco visual.
    No fim, LLM é apenas uma ferramenta para “não precisar decorar boilerplate”, e a essência da programação continua a mesma

• Eu também enfrentei o mesmo problema com geração de testes por IA
  Ter muitos testes traz uma sensação de segurança, mas na prática eles muitas vezes não cobrem casos de borda
  Especialmente ao refatorar código legado sem testes, os testes criados pela IA apenas verificam se algo funciona, mas não garantem a consistência do comportamento
  Esse problema foi especialmente grave em apps React. Por isso estou pensando em combinar BDD + desenvolvimento orientado por especificação com IA

  • Tenho a sensação de que escrever bons testes é 10 vezes mais difícil do que programar de fato
    Em testes unitários, o essencial é projetar mocks de forma criativa; em testes de integração, manipular dados; e em testes e2e, a estabilidade dos seletores é o ponto-chave
    Esse tipo de julgamento criativo ainda é difícil para a IA acompanhar
  • Não se deve confiar cegamente em números de cobertura
    Mesmo com 97% de cobertura, ainda havia muitos buracos no espaço lógico de entradas.
    Recentemente automatizei técnicas clássicas como equivalence partitioning com agentes de IA e apliquei isso a 60 modelos
  • Recomendo uma abordagem de especificar o comportamento do sistema com TLA+ e conectar o código à especificação
    O essencial é separar ao máximo funções puras e testar completamente o mapeamento entre entradas e saídas

• No longo prazo, acho que o verdadeiro valor da IA está no papel de ferramenta de amplificação de entendimento
  Por exemplo, analisar as regras de um código C complexo e documentar sua estrutura
  Se essa extração de conhecimento se tornar possível, será possível automatizar documentação de API, mapeamento de regras, análise de bugs e até otimização de arquitetura
  No fim, a capacidade de estruturar contexto vai se tornar mais importante do que a de gerar código

  • As formas de usar IA variam radicalmente de pessoa para pessoa
    ① o tipo oráculo onisciente, que só joga os requisitos e manda gerar o app inteiro
    ② o tipo ferramenta auxiliar, que usa dentro da IDE revisando linha por linha
    Para criar um serviço sustentável, a opção ② é muito mais realista

• A frase “arquitetura surge quando partes locais interagem” me marcou bastante
  A IA é forte na execução local, mas fraca em etapas ambíguas de design
  Na verdade, isso também vale para desenvolvedores humanos. Design é uma sequência de trade-offs sem resposta única

  • Eu também já cheguei a conclusões de design após conversas longas com IA
    Ela ajudou bastante especialmente em design de SQL para ClickHouse
    Graças à abordagem de incluir SQL com base em templates sugerida pela IA, consegui reduzir duplicação e melhorar o desempenho
    Talvez essa abordagem já existisse, mas sem IA teria sido difícil encontrá-la

• Este texto passa confiança porque houve 250 horas de esforço real por trás dele
  Acho que um projeto desse porte é um modelo realista de programação de sistemas assistida por IA

• A expressão “programar com IA é como uma máquina caça-níquel” fez sentido demais
  Eu também recebi na empresa acesso ilimitado a agentes de IA, e quando você entra no “só mais um prompt”
  de repente já se passaram 12 horas. O poder de imersão viciante é forte

• Talvez este seja o momento mais difícil da programação com IA
  Coisas que eram inimagináveis 6 meses atrás agora já são possíveis
  Estou tocando projetos em várias linguagens, e a IA gera código tão rápido
  que agora o gargalo virou a velocidade de revisão
  Quando certo volume de testes passa, surge a dúvida: “isso já é suficiente?”
  Eu especifico no prompt atributos de qualidade como princípios SOLID, acoplamento e coesão
  Peço ideias de refatoração para a IA e, se parecerem boas, digo “ótimo, pode executar”
  No fim, o importante é a arte de projetar prompts
  Mas acho que em breve a IA passará a aplicar esses guardrails de qualidade por padrão

  • Também houve quem perguntasse por que fazer projetos em várias linguagens
    A linguagem em si não é o gargalo de desempenho, mas experimentar novas linguagens ajuda no aprendizado

• Isso me lembrou a filosofia do “construa um para jogar fora” de Fred Brooks
  A IA é ideal para criar rapidamente essa primeira versão descartável (throwaway)
  Esperar qualidade de produção logo de cara é uma abordagem tola
  O certo é construir rápido, aprender e depois refatorar
  Também concordo com a observação de que, quando estamos cansados, os prompts ficam vagos e os resultados pioram

  • Mas também é interessante notar que Brooks depois mudou sua posição em direção ao aperfeiçoamento iterativo (iterative refinement)

• Fiquei surpreso ao saber que o parser SQL do SQLite não é gerado por lemon
  Quando fiz um port do pikchr para Go, primeiro levei o lemon, mas o SQLite nem sequer constrói uma árvore de parsing
  Olhando a documentação do lemon, isso parece um caso de definição insuficiente do problema na fase de design

• Também concordo totalmente com a conclusão deste texto
  É um bom exemplo que mostra a realidade da programação com IA de forma honesta, sem exageros