Em defesa ao Token Maxxing

O Token Maxxing, além de um termo engraçado, é a metodologia que muitas das empresas de tecnologia estão adotando para incentivar o uso de IA pelos seus desenvolvedores.

Ele surgiu primeiro em empresas do Silicon Valley, mas logo, com uns dois meses de atraso, foi adaptado e trazido para o Brasil.

Esse modelo institui a utilização de IA (ou melhor, de tokens) como um KPI (Key Performance Indicator) para os programadores, incentivando o gasto de tokens deliberadamente. Mesmo que essa aplicação não agregue ao produto final de seu trabalho.

Os desenvolvedores não só são incentivados a usar a IA ao máximo, mas são obrigados. Tudo dentro de uma pseudo-competição com seus próprios colegas.

Nesse artigo eu vou descrever o que o Token Maxxing realmente acerta, e como podemos usar ele para criar um modelo de trabalho realmente bom, que traga benefícios para todas as partes envolvidas.

Mas antes, precisamos definir exatamente o que ela não acerta.

Os problemas dessa abordagem

Não é difícil definir os pontos fracos dessa metodologia. Porém vou citar alguns deles para podermos deixar mais claro suas implicações:

O gasto de tokens não devia ser um KPI. Isso obriga bons desenvolvedores a irem na contramão de seus hábitos.
O custo de uma IA não deve ser ignorado. Escrever prompts que não levam isso em consideração, como a criação 5 protótipos em paralelo ao invés de 1 bem estruturado, vão apenas gerar um choque quando essa onda passar, principalmente nos desenvolvedores com menos experiência.
Cria prompts redundantes. Como disse no item anterior, a criação de 5 protótipos para uma mesma implementação é o equivalente a jogar um dado 5 vezes até cair no melhor número. Enquanto isso, a arquitetura de um sistema poderia ser pensada pelo desenvolvedor e realizada com a IA, em um único prompt bem-feito.
Simplesmente é muito caro para se manter. Entendo que o objetivo seja derrubar essa barreira na sua equipe, mas isso simplesmente não é sustentável por muito tempo. Nem empresas do Vale do Silício, que ganham em dólar e são gigantes, conseguiram. Quando a receita é em real e a despesa em dólar, isso se torna algo ainda mais inviável.

Esses são alguns dos pontos que eu consegui pensar, mas seguindo a sua experiência talvez você tenha até pensado em alguma coisa além dessa lista.

E, como você também pode ter pensado, muitos desses pontos são extremamente corrigíveis, o que mostra o potencial dessa abordagem.

Não é só de problemas que o Token Maxxing se sustenta, ainda existem pontos realmente bons dentro da sua implementação.

O que ela acerta

Mas antes de seguirmos para uma proposta nova, vamos conversar sobre o que esse modelo traz de bom para empresa e para seus desenvolvedores.

O principal benefício criado é a quebra do atrito mental que todos nós temos instintivamente: Gastar dinheiro.

Quando aplicamos um incentivo a usar uma ferramenta que cobra por uso, o desenvolvedor recebe a mensagem de que não só ele pode fazer, como deve. Isso corta qualquer relutância para usar essa ferramenta ao extremo, o que normalmente é percebido como "o caminho correto".

Somando a isso, essa metodologia acaba não só incentivando o desenvolvedor a usar a IA extensivamente, mas a torná-la um hábito. E a criação de um hábito sempre segue um fluxo definido:

Primeiro a pessoa vai demonstrar o interesse no assunto: Vai pesquisar o máximo sobre o assunto e entender como praticá-lo.
Depois de começar a colocar em prática, pode ser que tome gosto pela coisa ou que perceba uma simples desilusão.
Ao perceber que isso realmente é legal, ela vai ficar cada vez mais motivada, até atingir um pico. Vai praticar todos os dias, mais do que seria possível de sustentar por muito tempo. Vai abdicar de outros hábitos para poder exercer esse, e então sua vontade começa a cair.
Após atingir o pico de motivação, o único caminho é pra baixo. Vai começar a deixar de fazê-lo tão fervorosamente, talvez até parar completamente por um tempo.
E, por fim, vai retomar esse hábito. Em uma escala reduzida. Vai integrá-lo à sua rotina convencional, não torná-lo a sua rotina. É aqui que esse hábito vai se consolidar de fato.

Como citei antes, esse modelo foi primeiro aplicado no Silicon Valley, e as empresas de lá já estão chegando nesse nível de quebra de uso extremo, como no caso da Uber. O Brasil, por ter começado depois, ainda não chegou lá, mas esse momento vai nos alcançar ora ou outra.

Agora, considerando esses dois fatores juntos, a quebra da barreira mental com gastos e a consolidação natural de um hábito, as empresas estão sim agindo corretamente. Ao incentivar o uso extremo no início, elas resolvem os dois problemas de uma vez: eliminam a relutância de gastar e aceleram o ciclo até o platô estável.

Quanto antes essa fase de utilização excessiva for superada, antes a equipe chega num cenário com bom custo-benefício, previsível, e com uma vantagem real de experiência sobre quem começou depois.

O ciclo de um hábito, porém, depende de uma condição para funcionar.

As únicas exceções

Existe uma situação que anula os benefícios dessa dinâmica: Quando o desenvolvedor nunca esteve no primeiro passo.

Quando o desenvolvedor não despertou interesse pela ferramenta, ele nunca atingirá o pico e muito menos o platô do hábito. E quanto mais for forçado a entrar dentro dessa bolha, mais relutante ele vai ser para começar a ter esse interesse. E isso, eventualmente, vai resultar em uma grande rotatividade de desenvolvedores na empresa e um baixo nível de entregas.

Não é culpa do desenvolvedor que ele não está entusiasmado com isso. Pode ser que daqui a um mês ele estaria tão entusiasmado quanto quem está impondo isso. Porém, naquele momento ele não está, e forçar isso fará ele nunca desenvolver essa empolgação naturalmente.

Quando a metodologia do Token Maxxing é aplicada com alguém não motivado, o efeito da cultivação do hábito não funciona mais. Ao invés do desenvolvedor evoluir, ele vai inconscientemente se estagnar com a utilização de IA, relutando a aprender boas práticas. Não vai ser mais incentivado a prototipar e experimentar, mas a realizar prompts redundantes.

Não é difícil encontrar histórias de desenvolvedores se recusando a se adequar a medidas impostas e, como nesse caso e nesse caso de funcionários da Amazon, burlando a exigência de gasto mínimo de tokens. E eles não necessariamente querem prejudicar quem implementou essa metodologia.

A nova abordagem

Mas então, se mesmo dentro dos pontos bons existem coisas questionáveis, esse modelo é inútil? Se formos considerar somente sua aplicação, com certeza.

Mesmo ele sendo um movimento exageradamente extremista sobre a aplicação de IA para desenvolvimento, podemos usá-lo como uma base para criar algo que realmente impulsione os desenvolvedores, os ganhos da empresa e que de quebra ainda diminua o gasto com IA.

Para começar, vamos solucionar o problema das pessoas não motivadas. Para isso a implementação dessa metodologia não deve ser algo obrigatório, mas opcional, e que parta da própria pessoa, tentando escapar da obrigação social e cultural dentro da empresa. Não pode ser o chefe mandando, mas sim um movimento com os colaboradores sugerindo.

Para quebrar a barreira de ser "ordenado a ter interesse no assunto", é preciso que a própria pessoa escolha se ela quer ter interesse naquilo, e com o tempo flexível. Aprendizado (e interesse) não é algo que se manifesta igualmente para todos, então essa flexibilidade é essencial para fazer uma transição adequada com toda a equipe.

Porém, antes de continuar, vamos recapitular o que o modelo erra, mas que tem potencial de melhora:

Incentivo ao desenvolvimento pessoal: IA ainda é uma boa ferramenta quando não usada ao extremo. O modelo original acabava incentivando os desenvolvedores a usar a ferramenta, porém acabava jogando fora:
- A experiência do desenvolvedor, que tinha que ignorar o seu workflow habitual;
- O apoio dos desenvolvedores desmotivados com a aplicação da IA, que eventualmente vão ter que ser remanejados para conseguir seguir a cultura que todos da empresa estavam seguindo.
Extremismo inicial: Usar exageradamente no começo vai inevitavelmente resultar em um cenário moderado e estável no futuro. Porém, manter isso por muito tempo só vai criar atrito no processo de criação.
Diminuição da barreira de gastos: E por fim, esse fluxo ajuda a quebrar o que segura os desenvolvedores de usar a IA como uma ferramenta que realmente se encaixa no seu workflow, o custo dela.

Para finalizar vamos também, ao invés de criar a competição entre colaboradores pelo uso de tokens, instituir um número mínimo e máximo de tokens mensais. Isso vai obrigar os desenvolvedores a usarem a IA para seu fluxo, mas também a usarem boas práticas, já que os tokens ainda precisam ser economizados.

Corrigindo os problemas citados junto com o modelo opcional de adoção, temos a seguinte proposta:

	Token Maxxing	Nova metodologia
Participação	Obrigatório	Opcional, partindo do próprio indivíduo
KPI	+ Tokens usados	+ Entregas de qualidade dentro do range de tokens definido
Foco	Entregas	Aprendizado e entregas
Objetivo final	Trabalho mais rápido	Experiência com IA e desenvolvimento

Isso vai transformar a forma que o modelo é visto. Ele não é mais um fluxo de trabalho necessariamente, mas sim um método para aprender a trabalhar com a IA.

A metodologia se torna um meio e não um objetivo final.

E, da mesma forma que fizemos uma tabela de mudanças que devem ser executadas, podemos montar uma hipótese de consequências das mudanças realizadas:

	Token Maxxing	Nova metodologia
Custo financeiro	Literalmente infinito	Controlado e previsível
Rotatividade	Alta	Igual a anteriormente
Transição	Rápida	Gradual

Com essa abordagem, depois de algum tempo, a equipe naturalmente vai transicionar para uma aplicação de IA mais avançada, sem uma curva brusca que acaba destruindo a cultura da empresa e nem interrompendo o fluxo de criação de boa arquitetura. E também mantendo a rotatividade de funcionários a mesma de antes.

Conclusão

Eu percebi, depois de escrever metade desse artigo, que o título "Em defesa do Token Maxxing" tinha ido bem contra esse o que eu acabei dizendo aqui. Mas escolhi mantê-lo como está, já que os pontos bons existem, mas precisam ser retrabalhados para serem úteis de verdade.

São poucas as abordagens que são completamente incorretas, mesmo as mais absurdas. As vezes só precisamos adaptar elas ao nosso contexto.

Nenhum modelo como esse é 100% imutável, e é dever de quem está no topo entender o que pode ser alterado para melhorá-lo para seu contexto.

A metodologia adaptada que descrevi na seção anterior não foi aplicada em nenhum lugar ainda, pelo menos não que eu saiba. Eu estou muito desempregado agora (aceitando oportunidades, aliás) para propor isso para minha empregadora. Mas, justamente por isso, convido todos que porventura leram isso aqui e concordaram ao menos em partes, a fazer críticas e pensar no modelo que mais vai encaixar dentro do seu ambiente de trabalho.

Tem alguma crítica, sugestão, ou simplesmente quer conversar comigo sobre algo? Fico feliz em trocar uma ideia.

Obrigado pela atenção.