Quando li no Olhardigital.com.br que uma coalizão de estados americanos vai pedir US$ 193 bilhões da Meta num julgamento que começa dia 18, minha primeira reação não foi jurídica — foi técnica. A acusação central diz que a Meta projetou intencionalmente Facebook e Instagram para viciar crianças. E como dev, eu sei exatamente como isso é feito em código. Não é mágica. É arquitetura de produto deliberada.
O que realmente está em jogo no julgamento
O caso corre em Oakland, Califórnia, e tem duração prevista de seis semanas. A acusação sustenta que a Meta construiu mecanismos de dependência psicológica nos dois produtos. Se perderem, além da multa bilionária, os estados querem mudanças estruturais no funcionamento dos apps — não só dinheiro.
O valor pedido — R$ 1,05 trilhão — é menor que os US$ 1,4 trilhão ventilados antes. O advogado dos estados foi direto na audiência de quinta (13): “Não pedimos US$ 1,4 trilhão. A Meta calculou esse número para causar impacto.” Estratégia de comunicação da própria ré, ironicamente.
Por que isso interessa a você, dev
Não é caso de “problema dos outros”. Se você trabalha construindo produtos digitais — mesmo que não seja uma rede social —, esse julgamento redefine o que conta como responsabilidade técnica. Estamos entrando na era em que engagement metrics viram evidência judicial.
Na minha experiência, times de produto costumam tratar retenção e tempo de sessão como KPI unidimensional: quanto maior, melhor. Mas existe uma linha tênue entre “produto que retém” e “produto que vicia”. A diferença mora em três decisões arquiteturais:
- Como o algoritmo de recomendação lida com conteúdo emocionalmente carregado
- Se o infinite scroll é realmente infinito ou tem um fim proposital
- Se existe cooldown forçado após sessões longas
O coração técnico: variable reward schedules
A acusação contra a Meta tem base científica conhecida desde os anos 1950: Skinner demonstrou que recompensas variáveis e imprevisíveis geram comportamento compulsivo mais forte do que recompensas fixas. Caça-níqueis são o exemplo clássico. E é exatamente isso que um feed algorítmico faz.
Quando você scrolla no Instagram, nunca sabe se o próximo post vai ser uma foto da sua tia no almoço de domingo, um vídeo engraçado de gato, um conteúdo que te revolta ou algo de alguém que você nem lembrava que existia. A imprevisibilidade é o motor do vício. Tecnicamente, isso é um random sampler com distribuição de probabilidade ajustada por um modelo de ranking. Parece neutro? Não é.
Quando você combina reward variável com sinais de engajamento (likes, comentários, tempo de tela), você constrói um loop de reforço positivo que escala para bilhões de usuários. E o mais grave: o mesmo loop funciona ainda melhor em cérebros em desenvolvimento — adolescentes. Não é coincidência que o foco do julgamento seja em menores.
Na Prática: como NÃO construir um feed viciante
Vou mostrar duas arquiteturas de feed em Python. A primeira é o padrão “engagement-first” que a Meta é acusada de usar. A segunda é uma alternativa tecnicamente defensável. A diferença é estrutural, não cosmética.
Versão A — engagement-first (problemática)
class EngagementFirstFeed:
def __init__(self, user, content_pool):
self.user = user
self.pool = content_pool
self.session_start = time.now()
self.items_viewed = 0
def next_item(self):
# Sem limite de sessão
# Recompensa variável maximizada
candidates = []
for item in self.pool:
engagement_prob = self.predict_engagement(item)
emotional_intensity = item.sentiment_score
# Alta intensidade emocional + alta probabilidade de engajamento
score = engagement_prob * emotional_intensity
candidates.append((score, item))
candidates.sort(reverse=True)
return candidates[0][1] # sempre o mais "viciante"
def should_show_break_reminder(self):
return False # silenciosamente removido em 2019
def should_infinite_scroll(self):
return True # sem fim visívelVersão B — welfare-aware (defensável)
class WelfareAwareFeed:
SESSION_COOLDOWN_MINUTES = 30
MAX_ITEMS_PER_SESSION = 100
BREAK_REMINDER_EVERY = 20
def __init__(self, user, content_pool):
self.user = user
self.pool = content_pool
self.session_start = time.now()
self.items_viewed = 0
def next_item(self):
if self.items_viewed >= self.MAX_ITEMS_PER_SESSION:
self.enforce_cooldown()
return None
candidates = []
for item in self.pool:
engagement_prob = self.predict_engagement(item)
diversity_bonus = self.diversity_score(item)
wellbeing_penalty = self.wellbeing_impact(item)
# Diversidade e bem-estar entram no score
score = (engagement_prob * 0.5 +
diversity_bonus * 0.3 -
wellbeing_penalty * 0.2)
candidates.append((score, item))
candidates.sort(reverse=True)
return candidates[0][1]
def should_show_break_reminder(self):
return self.items_viewed % self.BREAK_REMINDER_EVERY == 0
def should_infinite_scroll(self):
return self.items_viewed < self.MAX_ITEMS_PER_SESSION
def enforce_cooldown(self):
self.user.lock_until = time.now() + timedelta(
minutes=self.SESSION_COOLDOWN_MINUTES
)Versão B limita sessão, força diversidade, penaliza conteúdo emocionalmente tóxico e mostra quando o feed acaba. Isso custa engajamento. Custa KPI. Mas talvez seja o que vai separar empresas que sobrevivem ao próximo ciclo regulatório das que vão pegar o mesmo tipo de processo.
Erros comuns que devs cometem (e que advogados vão explorar)
Quando você projeta features de retenção, três padrões aparecem repetidamente em depoimentos judiciais. Vou listar os que mais vejo em times com quem já trabalhei:
1. North Star metric errada
Time de produto define DAU ou time spent como objetivo principal. Aí todas as features são otimizadas para esse número. Se o produto é uma rede social com adolescentes, isso é literalmente projetar dependência. A Meta teve pesquisa interna vazada no Facebook Files com a frase "we have a compass that points to: make kids love Instagram". Documentos assim viram evidência direta.
2. Otimização A/B sem limites éticos
Times rodam testes A/B para descobrir qual versão retém mais. Ótimo na teoria. Na prática, você descobre que notificação às 3h da manhã aumenta abertura em 23% e implementa sem perguntar se isso causa danos. Esse tipo de decisão unilateral é exatamente o que promotores vão dissecar. Já vi feature ser aprovada em uma sprint e virar pergunta em deposition dois anos depois.
3. Remoção de friction sem justificativa
Cada fricção removida é +X% em alguma métrica. Auto-play de vídeo? +retention. Esconder contadores de likes? Pode reduzir ansiedade, mas também pode aumentar engajamento compulsivo. Não existe decisão neutra. Toda remoção de fricção tem trade-off documentável — e se não estiver documentado, será interpretado contra você.
4. Confundir viral com bom
Loop de compartilhamento é uma coisa. Loop de compulsão é outra. O primeiro resolve um problema real do usuário (quero mandar essa foto pra minha mãe). O segundo explora uma vulnerabilidade (não consigo parar de scrollar porque meu cérebro quer a próxima dose de dopamina). A arquitetura técnica parece idêntica. A diferença mora na intenção do designer.
FAQ — o que devs reais perguntam sobre isso
O julgamento da Meta vai criar precedente para outros produtos?
Provavelmente sim. Mesmo que o caso seja específico de menores, a tese jurídica de "design intencional para causar dependência" pode ser estendida para adultos. Apps de jogos, apostas, namoro, todos usam mecânicas similares.
Como dev, posso ser responsabilizado individualmente?
Direto: hoje, raramente. Indireto: sim — depoimentos viram evidência. Se você escreveu o algoritmo de recomendação e ele aparece em discovery como tendo "maximizado engajamento de menores sem safeguards", seu nome vai estar lá. Já aconteceu com ex-engenheiros do Facebook que viraram whistleblower e com gente que foi apenas testemunha.
Existe documentação técnica de "feed ético"?
Formal, não muito. Times de Responsible AI em empresas grandes publicam princípios internos, mas não são vinculantes. Como referência externa, vale ler as guidelines do Center for Humane Technology e alguns papers sobre value-sensitive design aplicados a sistemas de recomendação.
Vale a pena recusar uma feature request por motivos éticos no trabalho?
Na minha experiência, sim — e documentar por escrito. Cria registro defensável. No pior caso, se a empresa for processada, ter um e-mail seu dizendo "eu alertei sobre isso" é melhor que silêncio. Já vi gente perder o emprego por isso. Também já vi gente sobreviver a um deposition por causa disso.
O que muda na prática para mim, dev pleno/sênior?
Passei a incluir um campo "ethical risk" no design doc de qualquer feature de retenção. Leva 10 minutos. Se a feature mexer em loop de engajamento, notificações ou feed ranking, escrevo uma linha sobre potencial dano. Não é ciência — é hábito que cria cultura.
O ponto que ninguém fala
A Meta pode ganhar ou perder esse processo. O valor — R$ 1,05 trilhão — é grande, mas não existential para uma empresa que fatura US$ 160 bilhões por ano. O que importa para nós, devs, é o que vem depois: regulação. A União Europeia já avança nisso com o Digital Services Act. Brasil discute algo similar no PL 2630. Quando a régua baixar, o que vai diferenciar um dev "ok" de um dev "exposto" é se ele pensou sobre isso enquanto escrevia o código.
Não estou dizendo que você precisa virar filósofo antes de implementar um push notification. Estou dizendo que, na próxima vez que alguém pedir "maximizar tempo de sessão", vale 30 segundos pensando: isso ajuda o usuário ou só ajuda o KPI? A resposta vai parar no seu nome. Literalmente.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.