[Pitch] - Criei um app open-source, gratuito e local-first e coloquei o Codex para trabalhar nele todos os dias
Há alguns dias eu queria resolver um problema bastante pequeno.
Eu mantinha no Google Keep uma lista dos livros que li durante o ano. Queria algo um pouco melhor para isso, mas não queria outra rede social, conta obrigatória ou uma plataforma gigantesca.
Daí nasceu o Livro a Livro, um aplicativo gratuito e open source para registrar leituras.
O projeto começou pequeno.
Mas uma parte do processo acabou ficando tecnicamente mais interessante que o próprio aplicativo:
o Codex virou uma espécie de funcionário do projeto.
E não estou falando apenas de usar IA para gerar código enquanto eu programo.
Existem tarefas que acontecem independentemente de eu estar naquele momento trabalhando em uma feature.
Primeiro, sobre o app
O Livro a Livro é uma PWA feita em React + TypeScript + Vite.
A biblioteca do usuário vive em IndexedDB.
Não existe conta obrigatória e a arquitetura tenta manter uma fronteira bastante clara: livros, notas, avaliações, capas e backups não precisam passar pela API do projeto.
A API que existe é pequena e escrita em Rust/Axum, destinada aos serviços opcionais que realmente precisam de servidor.
Hoje já existem busca pela Open Library, capas, cadastro manual, estante por ano, avaliações e notas privadas, índice de autores, exportação JSON/CSV/Markdown, funcionamento offline e outros recursos.
Mas a parte mais curiosa para mim começou no processo de desenvolvimento.
O Codex não é apenas meu pair programmer
Eu comecei a experimentar uma ideia diferente:
em vez de abrir o Codex somente quando tenho uma tarefa, por que não dar a ele responsabilidades recorrentes sobre o projeto?
Hoje tenho rotinas com papéis diferentes.
Uma delas periodicamente olha o projeto procurando problemas.
A ideia não é simplesmente:
encontre um bug e faça deploy.
Ela pode investigar, propor uma correção e trabalhar na solução, mas mudanças que precisam ser validadas por usuários podem passar por feature gates e experimentos controlados.
Outra rotina olha o produto de uma perspectiva diferente:
use/inspecione o aplicativo e procure algo que poderia melhorar a experiência.
Nesse caso ela não recebe autorização para sair implementando qualquer ideia que tiver.
Ela me apresenta a sugestão.
Eu continuo sendo o gate de produto.
Se fizer sentido, aprovo e aquilo vira trabalho do projeto.
Comecei a perceber que isso se parece menos com autocomplete e mais com delegação.
O problema de deixar uma IA mexer no produto
Quando comecei a pensar nesse modelo, apareceu uma questão óbvia.
Mesmo que um agente consiga identificar um problema e escrever uma correção, como saber se a correção realmente melhora o produto?
Testes automatizados respondem:
o software continua funcionando?
Eles não necessariamente respondem:
isso ficou melhor para o usuário?
Foi daí que comecei a trabalhar numa infraestrutura de experimentos.
Feature gates, coortes e rollout percentual
A ideia é que uma mudança experimental não precise imediatamente existir para 100% dos usuários.
Um experimento pode ter variantes e uma porcentagem de exposição.
Algo conceitualmente parecido com:
experimento: nova_busca
status: ativo
controle: 90%
variante: 10%
Usuários elegíveis entram de forma estável em uma coorte.
Isso é importante: não quero que alguém receba a variante hoje, o controle amanhã e outra experiência depois simplesmente por atualizar a página.
A atribuição precisa ser determinística durante o experimento.
Se os primeiros sinais forem bons:
10%
↓
25%
↓
50%
↓
100%
Se alguma coisa der errado:
25%
↓
0%
A feature volta a ficar atrás do gate.
O objetivo não é criar um sistema gigantesco de A/B testing para um aplicativo pequeno.
É criar uma maneira segura de responder:
“essa mudança que o agente sugeriu realmente deveria virar comportamento padrão?”
Privacidade
O Livro a Livro é local-first.
Então seria bastante contraditório construir um aplicativo dizendo:
seus livros são seus
e depois enviar silenciosamente um monte de comportamento para um servidor de analytics.
Por isso experimentação e telemetria estão sendo tratadas como recursos opcionais e explícitos.
Inclusive, no momento em que escrevo isto, a infraestrutura de consentimento e os módulos de experimentos existem, mas o consumo das variantes e o envio de métricas ainda não estão ligados ao aplicativo em produção.
Prefiro dizer isso claramente porque issue fechada não significa feature entregue.
Essa distinção acabou virando uma regra importante no projeto.
O agente pode propor. Ele não decide o produto.
Essa talvez seja a parte que mais gostei desse experimento.
É muito tentador imaginar agentes autônomos como:
IA encontra problema
↓
IA escreve código
↓
IA faz deploy
↓
pronto
Eu estou chegando a um desenho diferente:
agente observa
↓
formula hipótese
↓
implementa quando autorizado
↓
testes automatizados
↓
feature gate
↓
coorte pequena
↓
evidência
↓
expandir / manter / reverter
E para mudanças de produto:
agente observa o app
↓
propõe uma melhoria
↓
humano avalia
↓
aprova ou rejeita
O agente ganha autonomia operacional.
Mas produto continua tendo um responsável humano.
Isso muda a forma como estou pensando software com IA
Até pouco tempo atrás, meu uso de IA para programação era essencialmente síncrono.
Eu queria alguma coisa.
Eu pedia.
A IA fazia.
Eu revisava.
Agora comecei a experimentar algo diferente.
Existem responsabilidades permanentes.
“Procure problemas.”
“Investigue regressões.”
“Olhe o produto e proponha uma melhoria.”
Eu não preciso necessariamente iniciar cada uma dessas interações. Se nao gostar simplismente ignoro. Todo dia tem novas ideias que posso ou não aceitar.
O Livro a Livro
O resultado desse experimento está acontecendo em um projeto real.
O Livro a Livro é gratuito, open source, sem anúncios e pode ser usado sem criar conta.
Aplicação:
Código:
https://github.com/ewflaviano/livro-a-livro
Sugestões, melhorias e contribuições são muito bem vindas.