Forjando Jinki: ferramentas personalíssimas na era dos agentes

O insight

A melhor ferramenta que eu tenho hoje não existe em nenhuma loja: fui eu que forjei, para mim, para um trabalho que só eu faço desse jeito.

Percebi isso no meio de um projeto. Eu estava montando uma esteira completa de IA para desenvolvimento autônomo, com agentes que planejam, escrevem código, testam e entregam. A cada etapa, faltava alguma coisa. Um cliente de API que entendesse o meu jeito de organizar requisições. Um painel que mostrasse exatamente o que a esteira estava fazendo. Um utilitário que só fazia sentido dentro daquele fluxo.

Então eu fui construindo. E em algum momento olhei para aquilo tudo e pensei: isso não é um conjunto de ferramentas genéricas. São ferramentas personalíssimas. E me lembrei de um anime.

O Jinki

Em Gachiakuta, o poder não vem de magia ou de sangue nobre. Vem de objetos comuns que alguém valorizou tanto que eles ganharam vida.

Esses objetos se chamam Jinki (instrumentos vitais). Quem consegue usá-los é chamado de Giver. Um guarda-chuva, uma tesoura, um par de luvas: qualquer coisa pode virar Jinki, desde que carregue o vínculo do dono. A força do instrumento é proporcional ao valor que a pessoa atribui a ele.

O protagonista, Rudo, vive num mundo onde as pessoas descartam tudo sem pensar. As luvas dele, herdadas do pai adotivo, deixam que ele extraia o valor escondido de qualquer coisa que toca, inclusive lixo. O tema do anime inteiro é esse: o que o mundo joga fora ainda tem valor para quem sabe enxergar.

Três ideias do Jinki me parecem traduzir muito bem o que está acontecendo com software:

1. O poder vem do vínculo, não da sofisticação. Um guarda-chuva não é uma arma melhor que uma espada. Mas nas mãos certas, é.
2. O instrumento reflete quem o usa. Cada Jinki é diferente porque cada dono é diferente.
3. O que é lixo para o mercado pode ser tesouro para uma pessoa. Uma ferramenta que só serve para mim nunca seria produto. Para mim, é a mais valiosa que eu tenho.

Por que "personalíssima"

Personalíssima é a ferramenta que perde o sentido quando muda de dono. A palavra vem do direito.

No direito brasileiro, um direito ou uma obrigação personalíssima é aquela ligada à pessoa, que não pode ser transferida. Os juristas usam a expressão intuitu personae: "em consideração à pessoa". Se eu contrato um pintor específico para fazer meu retrato, ele não pode mandar outro no lugar. A obrigação é dele.

Uma ferramenta pessoal é diferente de uma ferramenta personalíssima. Pessoal é a que eu configurei: meu tema no editor, meus atalhos. Personalíssima é a que foi construída a partir de mim. Ela carrega minhas decisões, meus nomes para as coisas, a ordem em que eu penso. Se eu der para outra pessoa, ela funciona, mas não serve.

É exatamente como um Jinki. No anime, um Jinki até pode passar de mão em mão, mas quem herda precisa criar o próprio vínculo com ele. Sem isso, é só um objeto.

O fim do "já existe uma ferramenta pra isso"

A IA mudou a pergunta. Antes era "existe uma ferramenta para isso?". Agora é "como essa ferramenta deveria ser para mim?".

Durante décadas, construir software custou caro demais para valer a pena fazer algo para uma pessoa só. A resposta racional era aceitar a ferramenta genérica e se adaptar a ela. O Postman foi feito para milhões de desenvolvedores, então ele resolve o problema médio de milhões de desenvolvedores. Eu me encaixava nele.

Com agentes escrevendo boa parte do código, o custo de forjar uma ferramenta caiu para horas, às vezes minutos. Isso inverte a lógica. A ferramenta genérica deixa de ser o padrão e vira a opção de quem não quer construir.

Isso não quer dizer que todo mundo vai reescrever tudo. Quer dizer que o limite mudou de lugar. A barreira já não é saber construir. É saber o que você quer, com clareza suficiente para descrever.

Essa ideia não é só minha

Depois do insight, fui procurar se alguém já tinha dado nome a isso. Tinha, várias vezes, em pelo menos vinte anos de conversa.

• Situated software (2004). Clay Shirky observou seus alunos na NYU criando programas para um grupo social específico, não para "usuários" genéricos. A provocação dele: escala, generalidade e completude não são virtudes absolutas.
• Home-cooked software (2020). Robin Sloan, escritor que programa um pouco, fez um app de mensagens só para a família dele. A metáfora pegou: programador profissional é chef de restaurante; quem faz software para os seus é cozinheiro de casa.
• Barefoot developers (2024). Maggie Appleton chamou assim as pessoas que ficam entre usuário e programador profissional e resolvem problemas locais com a ajuda de modelos de linguagem. O nome vem dos "médicos descalços" da China dos anos 1960.
• Malleable software (2025). O laboratório Ink & Switch propôs um ecossistema em que qualquer pessoa adapta suas ferramentas com pouca fricção. Logo no começo, o texto usa a imagem da oficina de um luthier, com cada ferramenta arrumada do jeito dele.

O que eu acrescentaria a essa linhagem é o recorte do Jinki. Os quatro falam de quem constrói e para quem. O Jinki fala do vínculo: a ferramenta fica poderosa porque carrega a pessoa dentro dela. E, com agentes, esse vínculo deixa de servir só a mim e passa a orientar o trabalho de quem age em meu nome.

Forjando Jinki para os agentes

Na esteira autônoma, as ferramentas não eram só minhas. Eram as mãos dos agentes. E isso tornou a ideia ainda mais forte.

Um agente é tão bom quanto as ferramentas que ele tem. Com ferramentas genéricas, ele tropeça nas mesmas fricções que eu tropeçaria: saídas verbosas, conceitos que não batem com o projeto, passos que exigem contexto que ele não tem. Com ferramentas feitas sob medida, ele trabalha dentro do meu jeito de pensar.

Foi aí que entendi o que eu estava fazendo de verdade. Eu não estava só automatizando. Estava codificando meu critério em instrumentos. Cada ferramenta que eu forjava carregava uma decisão minha: o que importa checar, em que ordem, o que conta como pronto. Os agentes herdavam isso.

Volta a imagem do Jinki que passa de mão. O agente não tem vínculo próprio com a ferramenta. Ele usa o meu. A ferramenta personalíssima vira o meio pelo qual eu estou presente no trabalho mesmo quando não estou olhando.

A cópia nunca é igual

A IA consegue copiar o resultado, mas não o caminho. E é no caminho que mora a diferença.

Muita gente acredita no contrário. A ideia é que, com IA, qualquer pessoa chega ao mesmo lugar que uma empresa levou décadas para alcançar, ou copia a ideia de alguém numa tarde. Eu acredito no oposto.

Uma ferramenta é a soma de milhares de decisões pequenas: o que entra, o que fica de fora, em que ordem as coisas acontecem, como um erro é tratado, que nome cada coisa recebe. Cada decisão sozinha parece irrelevante. Juntas, viram uma assinatura. Quem copia o resultado herda a superfície, não os motivos. Na primeira vez que precisar mudar algo, não vai saber por que as coisas são como são.

Com agentes, isso se amplifica. O harness de cada pessoa — as ferramentas que o agente tem, o contexto que recebe, as instruções, os gates, a arquitetura do repositório — muda a forma como o agente trabalha. E isso muda a qualidade e o resultado. Duas pessoas com o mesmo modelo e a mesma ideia chegam a lugares diferentes. O modelo virou commodity. O harness, não.

Conheci essa ideia na faculdade, com o professor Valdinei Castelan, no artigo IT Doesn't Matter (Nicholas Carr, 2003): quando uma tecnologia fica acessível a todos, ela deixa de diferenciar quem a usa. Com os modelos de IA é igual. A vantagem está no que cada um constrói em volta.

E isso não é só opinião: eu medi. Quando troquei a arquitetura de um backend de camadas para vertical slices, o modelo e a tarefa continuaram os mesmos, e a sessão do agente passou a gastar de 57% a 62% menos tokens de entrada. Nada mudou no modelo. Mudou o que estava em volta dele. Os detalhes estão mais adiante, na seção sobre padrões de projeto.

É a lógica do Jinki de novo. Dois Givers podem carregar um guarda-chuva, e mesmo assim não vão lutar do mesmo jeito. O objeto se copia. O vínculo, não.

A dedicação não desaparece quando a IA escreve o código. Ela só muda de lugar: sai das linhas e vai para as decisões.

Os novos padrões de projeto

Quando eu quase não leio mais o código, o que define uma boa arquitetura muda. Factory, Strategy e companhia continuam sendo boas ideias, mas deixaram de ser a primeira pergunta.

Nós, desenvolvedores backend, estudávamos esses padrões para entrevistas e aplicávamos nos projetos. Eles resolviam problemas de humanos que leem e mantêm código: reuso, extensibilidade, baixo acoplamento. O código ainda precisa ser legível por humanos. Não acho que vamos chegar a código que ninguém consegue ler. Mas o leitor principal agora é o agente, e ele tem outras limitações.

Preocupação	Pergunta de antes	Pergunta de agora
Leitura	Um humano entende isso?	O agente encontra o que precisa sem carregar o repositório inteiro?
Custo	Quanto tempo leva para escrever?	Quantos tokens custa cada mudança?
Qualidade	Passou no code review?	Passou nos gates automáticos?
Evolução	O padrão permite estender?	As métricas mostram que melhorou?

No lugar dos padrões clássicos como premissa, eu penso em três coisas:

• Eficiência de token. Cada arquivo que o agente precisa abrir para entender uma mudança é custo, latência e mais chance de se perder. Arquitetura boa é a que reduz o contexto necessário.
• Gates de qualidade. Testes, tipos, lint, checagem de contrato, revisão por outro agente. Se eu não leio o código, são os gates que leem por mim. Eles precisam barrar o problema antes de ele chegar até mim.
• Métricas bem definidas. Por exemplo: taxa de acerto na primeira tentativa, retrabalho, custo e tempo por tarefa. Sem métrica, "melhorou" é só impressão.

Juntas, essas três viram um ciclo de melhoria contínua:

1. Defino a métrica que importa para aquele tipo de tarefa.
2. O agente executa dentro da arquitetura e do harness atuais.
3. Os gates aprovam ou barram o resultado.
4. Meço custo, acerto e retrabalho.
5. Ajusto o harness, as ferramentas ou a arquitetura onde a métrica mostrou atrito, e volto ao passo 2.

Por que vertical slices

Migrei um backend real de Clean Architecture com DDD para vertical slices e medi o efeito no trabalho dos agentes de código. As fatias ganharam das camadas, mas não do jeito que eu esperava.

Em camadas, uma funcionalidade se espalha por controllers, services, repositórios e DTOs em pastas diferentes. Para mudar uma coisa, o agente precisa achar e carregar todas essas peças. Numa vertical slice, tudo o que uma funcionalidade precisa fica junto: entrada, regra, acesso a dados, testes.

Para um agente, isso significa:

• Menos contexto. Ele abre uma pasta, não o projeto inteiro.
• Mudança local. O raio de impacto de um erro fica dentro da slice.
• Gate por slice. Cada fatia tem seus próprios testes, então dá para verificar só o que mudou.
• Trabalho em paralelo. Agentes diferentes podem mexer em slices diferentes sem pisar um no outro.

O que a medição mostrou

Comparei o backend antigo (7 projetos em camadas) com o novo (um projeto só, .NET 10 com Minimal API, organizado por funcionalidade) em três tarefas que existem nos dois:

Tarefa	Arquivos (antigo → novo)	Tokens lidos
Campo novo num recurso existente	12 → 1	−27%
Login	14 → 3	−32%
Regra de alerta de uma medição	18 → 3	+38%

O número de arquivos caiu de 79% a 92%. Os tokens lidos, nem sempre. Na regra de alerta o agente leu mais, porque uma mudança de três linhas mora num arquivo de 28 KB, e toda rota passa por um arquivo de permissões de 15 KB.

O ganho grande aparece na sessão inteira, não na leitura. Cada leitura ou edição é uma volta, e cada volta reenvia todo o contexto acumulado. No antigo, o agente descobre o caminho aos poucos: o controller aponta a interface, a interface o serviço, o serviço a entidade. Para o campo novo, foram 15 voltas no antigo contra 7 no novo, com 57% a 62% menos tokens de entrada num modelo simples dessa conta.

O código também ficou mais enxuto: cada endpoint caiu de cerca de 2.100 para 750 tokens.

A lição é que a economia vem de cortar indireção e voltas, não de ter arquivos menores. E eu só descobri isso porque medi.

Isso inverte uma intuição antiga. Um pouco de duplicação dentro de uma slice sai mais barato do que uma abstração compartilhada que o agente precisa rastrear por cinco arquivos. Localidade e clareza passaram a valer mais que reuso.

Onde as fatias cobram de volta

• Arquivos que crescem. A fatia junta tudo de uma área, e a área cresce. Como o agente lê o arquivo inteiro, uma fatia grande devolve o custo que a arquitetura tinha tirado. Foi o caso da regra de alerta. Minha regra agora é dividir fatias acima de uns 10 KB por subfuncionalidade.
• Pontos comuns. Permissões e acesso ao banco aparecem em quase toda fatia. Um resumo curto desses contratos no AGENTS.md evita que o agente leia os arquivos inteiros a cada rota.
• Menos fronteira no compilador. Sem interface de serviço nem repositório, o que impede uma fatia de mexer no banco de outra é a regra escrita e o teste de integração contra um banco real. Ou seja, os gates passam a fazer o trabalho que antes era da arquitetura.

Os padrões de projeto não morreram. Mudou o critério. Hoje um bom padrão é o que diminui o contexto necessário, deixa a verificação automática e torna a melhoria mensurável.

O lado sombrio do Jinki

No anime, Jinki também machuca. Nem todo vínculo é saudável, e às vezes a linha entre a ferramenta e quem a usa fica perigosamente borrada. Com ferramentas personalíssimas acontece algo parecido.

• Manutenção. Construir ficou barato. Manter, não tanto. Cada ferramenta forjada é uma coisa a mais que pode quebrar quando uma API muda. E não tem time de suporte: o suporte sou eu.
• Isolamento. Uma ferramenta que só serve para mim também não serve para mais ninguém. Se eu trabalho em equipe, preciso decidir o que é Jinki meu e o que precisa ser ferramenta compartilhada.
• Segurança. Um cliente de API próprio ou um painel de nuvem próprio lida com tokens e credenciais. Uma ferramenta caseira não ganha os anos de endurecimento que um produto maduro tem. Isso exige cuidado de verdade desde o início.

A regra que eu tento seguir: forjo onde sinto atrito todo dia. Onde a ferramenta genérica já serve, eu uso a genérica.

O valor vem do vínculo

O mundo de Gachiakuta é feito de gente que joga tudo fora. O Rudo é o personagem que olha para o lixo e enxerga valor.

Com software, passamos muito tempo do outro lado: aceitando ferramentas feitas para todo mundo e, por isso, para ninguém em particular. O que não tinha mercado nem era construído. Agora dá para construir. A pergunta deixa de ser "isso existe?" e vira "isso é meu?".

Talvez a próxima habilidade importante não seja só programar, nem só usar IA. Seja saber forjar os próprios instrumentos, e criar com eles um vínculo forte o bastante para que eles carreguem o seu jeito de trabalhar, até quando quem está usando é um agente.

E vínculo não é só apego. É conhecer a ferramenta bem o bastante para saber quando ela está falhando. Eu tinha certeza de que minha nova arquitetura economizava 80% dos tokens. Medi, e a realidade era outra: melhor em alguns pontos, pior em outros, e boa por motivos diferentes dos que eu imaginava. Descobrir isso não me afastou da ferramenta. Me aproximou dela. Um Jinki que você não entende é só um objeto que você gosta.

Eu sigo forjando os meus.

E sim, eu sei: este texto foi escrito com IA. As ideias e as decisões são minhas; a IA ajudou a organizar e escrever. Pensem nisso como um presente: vocês foram poupados do meu texto original, cheio dos erros de digitação de quem tem TDAH, kkk. E, no fim, ele é a prova do próprio argumento: o modelo escreveu, mas quem decidiu fui eu.

Referências

• Nicholas Carr, IT Doesn't Matter, Harvard Business Review (2003)
• Clay Shirky, Situated Software (2004)
• Robin Sloan, An app can be a home-cooked meal (2020)
• Maggie Appleton, Home-Cooked Software and Barefoot Developers (2024)
• Geoffrey Litt, Josh Horowitz, Peter van Hardenberg e Todd Matthews (Ink & Switch), Malleable software: Restoring user agency in a world of locked-down apps (2025)
• Kei Urana, com grafites de Hideyoshi Andou, Gachiakuta (mangá, Kodansha, desde 2022; anime, Studio Bones, 2025)