Invisible Work
Conversar

Como construímos

Por que cada projeto deveria melhorar o próximo

O que acontece quando um aprendizado técnico vira componente reutilizável — e o que não deve ser reutilizado nunca.

Invisible Work8 min de leitura

O problema de começar cada projeto do zero

Todo projeto de software com IA começa com um conjunto de problemas que não são do cliente: como avaliar se a resposta está boa, como tratar o caso que foge do padrão, como observar o custo, como descobrir que algo quebrou antes do usuário descobrir.

Esses problemas não aparecem no escopo. Eles aparecem no meio do caminho, quase sempre depois que a primeira versão já funcionou na demonstração. Resolvê-los do zero a cada projeto significa gastar, em todo contrato, uma parte do tempo naquilo que não é o problema do cliente — e cobrar por isso.

A alternativa não é ter um produto pronto que sirva para todos. É reconhecer quando um problema se repete e tratá-lo uma vez a mais do que o necessário: resolver para este projeto e deixar resolvido para o próximo.

Por que uma demo não é suficiente

Uma demonstração precisa funcionar uma vez, num caminho escolhido por quem está demonstrando. Um sistema em produção precisa funcionar todo dia, com entradas que ninguém previu, dentro de sistemas que já existem e com alguém responsável quando falhar.

A distância entre as duas coisas costuma estar em cinco frentes, e nenhuma delas é sobre o modelo:

  1. Avaliação

    Como saber se a resposta está certa, de forma repetível, em vez de conferir alguns exemplos à mão e concluir que está bom.

  2. Integração

    A solução precisa entrar nos sistemas que a operação já usa, com os dados no formato em que eles realmente estão — não no formato ideal.

  3. Monitoramento

    Quando a qualidade cai, alguém precisa perceber. Sem isso, a degradação aparece primeiro na reclamação do usuário.

  4. Custo

    O custo por execução importa quando o volume é real. O que é irrelevante em um teste pode inviabilizar a operação inteira.

  5. Manutenção

    Modelos, bibliotecas e integrações mudam. Alguém vai precisar mexer nisso daqui a seis meses, e o custo dessa manutenção é parte do projeto.

São desafios gerais de engenharia, não incidentes específicos de um cliente. Estão listados aqui porque é neles que o trabalho se concentra depois que a parte que impressiona já está pronta.

De onde veio o método

A prática de extrair aceleradores dos projetos começou em fevereiro de 2025. Não foi uma decisão de produto: foi a consequência de encontrar o mesmo tipo de problema técnico em contextos diferentes e perceber que estávamos resolvendo duas vezes o que podia ser resolvido uma vez e adaptado.

Esta seção diz o que foi verificado: a data em que a prática começou. Não afirmamos qual foi o primeiro componente extraído nem em que projeto, porque preferimos não reconstruir uma cronologia de memória.

O ciclo, em seis etapas

Não começamos todo projeto do zero. Quando encontramos um problema que se repete, transformamos o aprendizado em componentes, ferramentas e práticas reutilizáveis. Eles aceleram novos projetos, são colocados à prova e geram novos aprendizados.

  1. Projeto real

    Começamos em um problema concreto.

  2. Problema técnico

    Identificamos o que dificulta produção, escala ou qualidade.

  3. Solução construída

    Implementamos e avaliamos.

  4. Building block

    Extraímos o que pode ser reutilizado, quando fizer sentido.

  5. Próximo projeto

    Partimos de uma base mais madura e adaptamos ao novo contexto.

  6. Novo aprendizado

    Refinamos componentes e compartilhamos aprendizados publicáveis.

O ciclo recomeça.

O que cada etapa exige na prática

Projeto real. O ciclo só começa em trabalho pago, com restrição de verdade. Problema inventado gera solução que nunca foi testada contra a realidade.

Problema técnico. A pergunta é o que está impedindo este sistema de ir para produção, escalar ou manter a qualidade. Se a resposta for específica demais do cliente, o ciclo para aqui — e tudo bem.

Solução construída. Implementar e avaliar. Enquanto não houver como medir se funciona, não há o que reutilizar: copiar código que ninguém sabe avaliar é espalhar o risco, não reduzi-lo.

Building block. A etapa opcional. A extração só acontece quando compensa, pelos critérios da próxima seção.

Próximo projeto. O componente entra como ponto de partida e é adaptado ao novo contexto. Ele não chega pronto: chega maduro.

Novo aprendizado. O uso em outro contexto revela o que estava implícito. O componente melhora, e parte do que se aprendeu pode virar texto público — quando o contrato permitir.

O que merece virar building block

A maior parte do que construímos não vira componente reutilizável, e essa é a decisão correta na maioria das vezes. Extrair cedo demais cria uma abstração que serve a um caso e atrapalha em todos os outros — com o custo de manutenção junto.

  1. O problema se repetiu de verdade

    Não a previsão de que vai se repetir. Enquanto aconteceu uma vez só, é solução de projeto.

  2. O custo de manter é menor que o de refazer

    Todo componente tem custo permanente: atualização, correção, documentação. Se refazer for mais barato, refazer é o certo.

  3. Não carrega nada confidencial

    Regra de negócio, dado e lógica específica do cliente ficam no cliente. O que sai é a forma de resolver, nunca o conteúdo.

  4. É robusto fora do caso que o originou

    Se só funciona com a forma exata dos dados de um projeto, ainda não é componente — é código daquele projeto.

  5. Dá para versionar e substituir

    Precisa ser possível atualizar sem quebrar quem já usa, e sair de cena quando deixar de fazer sentido.

Building block não é produto

Um building block é insumo de entrega, não item de catálogo. Ele existe para que o próximo projeto comece mais maduro — não para ser vendido separadamente.

A diferença é prática. Um produto precisa de preço, suporte, documentação pública, compatibilidade e um ciclo de vida próprio. Prometer isso para um componente interno significa passar a manter um produto em vez de resolver o problema do cliente. Nossa oferta é uma só: entender o problema e construir a solução até ela estar funcionando em produção. Os aceleradores tornam esse trabalho melhor e mais rápido; eles não são a coisa vendida.

Um exemplo concreto: o Process Recorder

O Process Recorder nasceu de um problema recorrente: antes de automatizar qualquer coisa, é preciso saber como o processo acontece de fato — não como ele está documentado. A diferença entre os dois costuma ser onde mora a oportunidade, e também o risco.

Hoje ele está sendo aplicado com um cliente que redesenha os processos de backoffice para ganhar eficiência operacional e melhorar a utilização do ERP. É um contexto em que a pergunta “onde exatamente o trabalho trava?” não tem resposta óbvia: o sistema está lá, as pessoas usam, e mesmo assim o processo real tem desvios, retrabalho e etapas que ninguém mediu.

Este é um trabalho em andamento. Não publicamos aqui nome de cliente, número, percentual de ganho nem afirmação de que o uso já está em produção: nada disso foi validado, e o nosso critério é não publicar resultado antes de poder descrevê-lo com período, base de comparação e autorização.

O que o exemplo ilustra é a etapa 4 do ciclo: um problema que apareceu em projeto real, foi resolvido para aquele contexto e se mostrou recorrente o bastante para virar componente — em vez de ser reconstruído do zero a cada vez que a pergunta reaparece.

Como pretendemos medir se isso funciona

Um método que promete acelerar precisa aceitar ser medido. Estes são os indicadores que fazem sentido para o flywheel:

  1. Tempo até a primeira versão avaliável

    Quanto se leva, num projeto novo, para ter algo que já dá para medir — não para demonstrar.

  2. Defeitos que chegam à produção

    Um componente exercitado em mais de um contexto deveria falhar menos que código escrito pela primeira vez.

  3. Custo de operação por execução

    O que o sistema custa para rodar no volume real, acompanhado ao longo do tempo.

  4. Custo de manutenção do próprio componente

    O lado da conta que costuma ser esquecido. Um acelerador que consome mais do que economiza deixou de ser acelerador.

Este é o método proposto, não um resultado já apurado. Não temos números publicáveis de aceleração, e não vamos apresentar estimativa como se fosse medição. Quando houver série suficiente e autorização para publicá-la, ela aparece aqui.

O que não reutilizamos

A lista do que fica de fora é tão definidora quanto a do que entra:

  1. Código e dados do cliente

    São dele. Não migram para outro projeto, em nenhuma forma.

  2. Regra de negócio proprietária

    A lógica que diferencia a operação de um cliente é justamente o que ele não quer ver replicado no concorrente.

  3. Integrações específicas

    A conexão com a instância de um sistema carrega decisões e credenciais daquele ambiente. O que pode ser reaproveitado é o padrão, nunca a configuração.

  4. Conclusões que não generalizam

    O que funcionou num contexto pode ser consequência daquele contexto. Transformar isso em regra geral é o jeito mais rápido de errar no projeto seguinte.

Onde isso aparece no trabalho

Este ciclo é o que sustenta a única oferta que temos: entender um problema relevante da operação e construir o software que o resolve, até ele estar funcionando em produção. Os cases mostram os problemas que enfrentamos; este artigo mostra por que o próximo tende a começar de um ponto melhor que o anterior.

Continue lendo