Dados de usuário continuam sendo a parte crítica na era de código por agente

A velocidade do código por agente tem uma exceção

Mattias Geniar descreve como o desenvolvimento assistido por agentes acelerou drasticamente seu trabalho: funcionalidades saem em dias, designs são implementados em horas e ajustes de layout ou fluxo acontecem a uma velocidade impensável um ano antes. Grande parte desse trabalho ele já faz do celular, falando com um ambiente de código remoto, porque a iteração ficou barata: tudo tem um "botão de desfazer". Um layout confuso, um bug, uma tradução errada ou um redesign que piorou a usabilidade - tudo se resolve com um novo deploy. Ele mantém disciplina (suite de testes e leitura do diff antes do merge), mas o custo de uma decisão errada caiu a poucos minutos.

A camada de dados não tem volta

O mesmo não vale para os dados. Sempre que precisa tocar na camada de dados, Geniar para e exige outro contexto: mesa, laptop, sem distrações. Ali, o erro não é desfeito pelo próximo deploy. Padrões como soft delete, migrações com down() e backups noturnos amenizam o problema, mas desfazem mudanças no código, não a perda em si: se uma migração truncou uma coluna, o down() recria a coluna vazia.

O event sourcing é o que chega mais perto de um desfazer real: em vez de armazenar o estado atual, guarda-se cada mudança como evento (como OrderPlaced ou AddressChanged) e as tabelas são construídas a partir deles. Com o pacote da Spatie, um comando de replay permite reconstruir uma tabela destruída por migração ruim. Mas a porta de sentido único continua existindo - apenas se moveu para o log de eventos, que é append-only: um evento mal desenhado fica lá para sempre, um evento nunca gravado não pode ser reproduzido, e um registro permanente de tudo que um usuário fez é problemático justamente quando ele pede exclusão da conta. Como ele resume com um app próprio de reconhecimento de alimentos: dá para reconstruir a tela que fez a pergunta em uma tarde, mas não a resposta - só quem comeu sabe, e disse ao app uma única vez.

Portas de sentido único na era dos agentes

Geniar recorre à carta de 2015 de Jeff Bezos aos acionistas da Amazon, que divide decisões em "portas de dois sentidos" (reversíveis) e "portas de sentido único" (quase irreversíveis, que exigem deliberação). Bezos alertava contra tratar portas de dois sentidos com cuidado excessivo, o que torna empresas lentas. Com agentes, Geniar teme o erro oposto: atravessar uma porta de sentido único em velocidade de porta de dois sentidos, porque tudo ao redor corre nesse ritmo.

As portas de sentido único estão na camada de dados: migrações, o que armazenar e em qual formato, estruturas de dados, backups e recuperação. É ali que concentra seu tempo e raciocínio hoje - não em UI, UX ou roadmap, que podem permanecer fluidos. Uma mudança de layout é um deploy; uma mudança de dados é um plano, com destino de cada linha existente, verificação e caminho de retorno. Guardar um campo cria deveres de proteção, backup e eventual exclusão; não guardar significa que ele se perde para sempre.

Privacidade, retenção e a conclusão

Privacidade e retenção também não se apressam: por quanto tempo guardar, quem vê, o que acontece na exclusão de conta e se isso cobre os backups. Essas perguntas não têm resposta rápida, e o fato de um agente escrever a migração em 30 segundos não as simplifica - escrever a migração nunca foi a parte lenta; pensar no efeito sobre dados já existentes é.

A conclusão é a tese do título: tire de um aplicativo a interface, o site, os servidores e a infraestrutura, e tudo pode ser reconstruído, hoje mais rápido do que nunca. Perca os dados dos usuários, e o que sobrar é uma casca vazia com tela de login. Por isso ele itera em layout do celular, mas a migração espera até estar na mesa.