Três sistemas construídos em 11 dias, 2 semanas e cerca de 3 semanas, cada um tirando um trabalho manual do caminho. A IA escreveu a maior parte do código. O que encurtou o prazo foi o método em volta dela.
Anderson Silveira · 1 de outubro de 2026
Em setembro de 2026, uma distribuidora de lubrificantes tinha um processo que qualquer operação pequena conhece: o pedido chegava como foto de papel no WhatsApp, e alguém redigitava tudo. O sistema de pedidos e estoque que construí para ela foi do primeiro commit à versão atual em 11 dias, já rodando no servidor do cliente. Em junho, o Glint, uma plataforma de eventos que vai da página de vendas ao reembolso, levou cerca de três semanas. Em agosto, a primeira versão completa do Kitnets, uma plataforma de locação e gestão de kitnets, saiu em duas semanas.
Nos três, agentes de IA escreveram a maior parte do código. Mas, se eu tivesse de apontar o que encurtou o prazo, não seria a IA. Seria entender o trabalho manual antes de automatizá-lo, e o método em volta da IA.
O momento em que isso ficou claro foi no Glint. A primeira versão dos setores travava a lotação no checkout. Funcionava. Só que o painel mostrava lotes com vagas num setor que já não tinha espaço. A correção não pediu tela nova: a trava mudou de lugar e passou para a configuração. A soma dos lotes de um setor não pode passar da capacidade dele. Um agente escreve qualquer uma das duas versões em minutos. Decidir qual é a certa é trabalho de produto, e é esse trabalho que define se o sistema fica pronto em semanas ou vira um ciclo sem fim de retrabalho.
O método, em cinco partes
- 01Discovery curto
Problema, público, regras de negócio e o que fica fora.
- 02Modelo antes da tela
Entidades, relações e onde cada regra mora.
- 03Fatias que vão ao ar
Ondas pequenas, cada uma utilizável.
- 04IA com revisão humana
Agentes escrevem; pessoas aprovam plano e entrega.
- 05Testes como trava
A suíte barra a entrega, e o fluxo é visto rodando.
1. Discovery curto, mas com prova
Curto não quer dizer raso. No Kitnets, antes de qualquer tela, fiz uma descoberta de mercado com verificação cruzada: 36 afirmações sobre concorrentes, preços e regras técnicas, todas confirmadas. Dela saíram um documento de requisitos com 12 blocos de funcionalidade e 60 critérios de aceite, e um roteiro de 29 épicos em três ondas.
Três achados mudaram o produto. A vitrine pública era o diferencial, porque nenhum concorrente voltado à pessoa física tinha uma funcionando. O aluguel precisava de um meio de pagamento brasileiro, com Pix e boleto, diferente do que cobra a assinatura do software. E a postura jurídica virou regra de produto: a plataforma é software e meio de pagamento, nunca intermediária. Nenhum desses achados viria de pedir “faça um sistema de aluguel” a uma IA.
No sistema de pedidos, o discovery coube numa decisão: não pedir para ninguém mudar de hábito antes de ganhar alguma coisa com isso. O comprador já mandava foto da anotação no WhatsApp. Então o sistema aceita a foto, a IA lê, e uma pessoa confere linha por linha antes de confirmar.
2. Modelo de dados antes da tela
É a etapa que mais economiza tempo depois. No Glint, separei o evento em camadas antes de desenhar: Evento → Setor → Tipo de ingresso → Lote. Setor é a área física, com capacidade. Tipo é a condição comercial. Lote é a escada de preço.
- Evento
- SetorÁrea física, com capacidade
- Tipo de ingressoInteira, meia, passe de um dia
- LoteVira por data, por percentual vendido ou por esgotamento
Com o modelo certo, a pergunta “onde mora a trava de capacidade?” tem resposta: no setor. A tela só obedece.
O sistema de pedidos mostrou o mesmo princípio por outro lado. No meio do projeto, o cliente pediu para tirar o preço de todas as telas, porque cada comprador tem a sua negociação. Parecia uma mudança grande. Saiu barata, porque a decisão já morava num lugar só e as telas apenas a obedeciam. Quando uma regra de negócio tem um endereço só, mudar de ideia custa pouco.
3. Fatias que vão ao ar
Em vez de um grande lançamento, o trabalho anda em ondas pequenas, e cada onda entrega algo que alguém consegue usar. No sistema de pedidos, a primeira versão entrou no ar em poucos dias, e depois vieram ajustes quase diários a partir do que o cliente pedia: venda por caixa, preço oculto, agenda de retirada. O Kitnets seguiu o roteiro de três ondas do discovery. No Glint, cada funcionalidade virou uma ficha no repositório, com objetivo, critérios de aceite, cenários felizes e não felizes e riscos; o catálogo tem um documento mestre e 21 fichas, e serviu de contrato entre design, código e teste.
Fatia que vai ao ar tem uma vantagem que nenhuma reunião substitui: o cliente reage a algo real, e a próxima onda nasce dessa reação.
4. IA no desenvolvimento, com humano revisando
No Kitnets, o código foi escrito 100% por agentes de IA, num processo que eu desenhei: cada demanda vira uma tarefa com etapas, um agente “contestador” ataca o plano antes do código, e documento de requisitos, plano técnico e melhorias passam por aprovação humana. No Glint, as entregas grandes foram divididas em ondas executadas por vários agentes em paralelo, com revisões adversariais nas partes que mexem com dinheiro e segurança.
Uma dessas revisões achou o risco de estorno duplicado com dois cliques simultâneos no reembolso. A correção garante que o item é cancelado primeiro, de forma atômica, e só então o dinheiro volta. Esse é o tipo de falha que o caminho feliz não mostra.
O papel humano não diminui. Ele muda de lugar: sai de digitar código e vai para decidir o que entra, o que fica fora e onde um humano precisa estar no meio. No sistema de pedidos, a regra virou princípio de produto: a IA propõe, o humano confirma. Errar a embalagem de um tambor de 200 litros não é um erro barato.
5. Testes que travam a entrega
No Kitnets, uma suíte que tenta acessar dados de outro proprietário cresceu a cada épico e trava a entrega se falhar. A suíte do Glint passou de mil testes, incluindo o isolamento entre organizadores.
Mas teste verde não é sistema funcionando. No sistema de pedidos, a suíte passou inteira enquanto a API, rodando de verdade, respondia erro no catálogo: os testes liam uma versão do código e o servidor lia outra. Por isso, depois do verde, alguém passa o fluxo no sistema em pé, olhando a tela. Escrevi mais sobre isso em Validar antes de construir.
Os três projetos lado a lado
| Glint | Kitnets | Sistema de pedidos | |
|---|---|---|---|
| O que é | Plataforma de eventos e ingressos | Locação e gestão de kitnets | Pedidos B2B e estoque |
| O trabalho manual atacado | Reembolso por e-mail e certificado montado à mão | Lembrete no WhatsApp pessoal e Pix conferido no extrato | Redigitar a foto do pedido e conferir o estoque de cabeça |
| Prazo | Cerca de 3 semanas | 2 semanas (primeira versão completa) | 11 dias (do primeiro commit à versão atual) |
| Decisão de modelo | Trava de capacidade no setor | Cobrar pela plataforma é opcional | Saldo de estoque é um extrato, não um campo |
| Onde o humano fica | Revisão adversarial de dinheiro e segurança | Aprovação de requisitos, plano e melhorias | Confirmação de cada linha lida pela IA |
| Trava de qualidade | Mais de mil testes | Suíte de isolamento a cada épico | Fluxo visto no sistema rodando |
O prazo curto não veio de cortar etapa. Veio de cada etapa ser curta, e de nenhuma ser pulada.
Quando NÃO automatizar sob medida
Automação sob medida não é a resposta padrão. Eu recomendaria não fazer quando:
- Uma ferramenta pronta resolve quase tudo. Contabilidade, folha de pagamento, e-mail marketing: se o seu processo é igual ao de todo mundo, pague a assinatura. Sob medida vale quando o processo é o que diferencia o negócio, como a foto do pedido que o comprador já mandava ou a lotação amarrada ao espaço físico do evento.
- O processo ainda não existe. Se a operação muda toda semana, comece numa planilha. Sistema cristaliza regras; regra que ninguém definiu vira retrabalho.
- Ninguém do lado de vocês é dono do produto. Alguém precisa responder rápido “isso entra ou não entra?”. No sistema de pedidos, as mudanças de regra vieram do cliente, e foi isso que manteve os ajustes quase diários no rumo certo.
- Não há quem cuide do sistema depois. Sistema no ar pede atualização, monitoramento e alguém que responda quando algo falha. Se isso não tem dono, o sistema envelhece mal.
- A expectativa é “a IA faz tudo”. A IA acelera o código. Ela não decide onde mora a trava de capacidade, nem se a leitura da foto pode virar pedido sem conferência.
O que eu faria diferente
- Pôr usuários reais na frente mais cedo. No Kitnets e no sistema de pedidos, as dores vieram do discovery de mercado e do processo descrito, não de entrevistas. Fatias curtas tornam essa rodada barata; vale fazê-la antes de ligar as partes mais caras.
- Conferir a mudança de regra em todas as telas, no sistema rodando. Quando o preço saiu das telas do sistema de pedidos, dois lugares ainda imprimiam um valor zerado. Nenhum teste reclamou; eu só vi passando o fluxo inteiro.
Checklist antes de automatizar sob medida
- O processo que o sistema vai apoiar é um diferencial do negócio, e não algo que uma ferramenta pronta resolve?
- O discovery deixou escrito o problema, o público, as regras de negócio e o que fica fora?
- O modelo de dados foi desenhado antes das telas, com cada regra num lugar só?
- O trabalho está dividido em fatias pequenas que vão ao ar?
- Está claro onde a IA propõe e onde uma pessoa decide?
- Planos e entregas passam por revisão humana, com atenção redobrada em dinheiro e segurança?
- Os testes travam a entrega, e alguém passa o fluxo no sistema rodando?
- Existe um dono do produto do lado da empresa?
- Já está definido quem cuida do sistema depois que ele entra no ar?
Como posso ajudar
O que a sua equipe faz na mão, dá para automatizar. Se existe um trabalho repetitivo na sua operação, um pedido redigitado, um documento lido um a um, uma planilha conferida à mão, eu posso conduzir do mapeamento do processo à primeira versão no ar, ou ajudar a decidir se automatizar sob medida é mesmo o caminho. Os cases do Glint, do Kitnets e do sistema de pedidos mostram o processo em detalhe. Fale comigo.