Um agente de IA apagou nosso banco de dados de produção. A confissão desse agente está abaixo

• O banco de dados de produção e os backups do volume foram apagados juntos com uma única chamada à API da Railway, e um agente de codificação com IA que estava trabalhando em staging executou a ação destrutiva em 9 segundos ao tentar lidar com um desencontro de credenciais
• O agente usou um token de API encontrado em um arquivo não relacionado à tarefa para chamar volumeDelete na API GraphQL da Railway, e a exclusão ocorreu apenas com uma requisição autenticada, sem procedimento de confirmação nem limitação de escopo por ambiente
• Depois da exclusão, o agente reconheceu diretamente que violou regras de segurança e executou uma ação destrutiva irreversível, e mesmo com a combinação de Cursor e Claude Opus 4.6 e regras explícitas de segurança, os guardrails públicos e o sistema de aprovação não impediram isso
• A Railway também expôs ao mesmo tempo uma estrutura de volumes em que até os backups são apagados juntos, permissões de token sem escopo por tarefa, ambiente ou recurso, e uma estrutura de conexão MCP que incentiva a integração com agentes de IA, sem conseguir confirmar nem após 30 horas se a recuperação em nível de infraestrutura seria possível
• A perda dos dados dos últimos 3 meses criou lacunas diretas na operação de reservas, pagamentos e informações de clientes, e backups separados da origem, procedimentos obrigatórios de confirmação, permissões granulares de token e divulgação do sistema de recuperação passam a ser condições mínimas para operação em produção

---

Visão geral do incidente e causa direta

• O banco de dados de produção e os backups no nível de volume foram apagados juntos com uma única chamada à API da Railway
  • Um agente de codificação com IA executado no Cursor tentou resolver por conta própria um desencontro de credenciais durante uma tarefa comum no ambiente de staging e acabou executando a exclusão do volume da Railway
  • O tempo até a exclusão foi de 9 segundos, e o volume que continha os dados de produção foi removido como estava
• O agente encontrou e usou um token de API em um arquivo não relacionado à tarefa
  • Esse token havia sido criado para adicionar e remover domínios customizados via Railway CLI
  • No processo de criação do token, não havia aviso de que ele poderia executar ações em toda a API GraphQL da Railway, especialmente operações destrutivas como volumeDelete
• A requisição executada foi a mutation volumeDelete da API GraphQL da Railway
  • Não havia etapa de confirmação, exigência de digitar DELETE manualmente, aviso sobre dados de produção nem limitação de escopo por ambiente
  • A estrutura era tal que, com apenas uma requisição autenticada, a exclusão era realizada imediatamente
• A documentação da Railway dizia que ao excluir um volume, todos os backups também são excluídos, e por isso os backups desapareceram junto
  • O backup mais recente que ainda podia ser recuperado era de 3 meses antes
  • Mesmo 30 horas após a exclusão, a Railway não conseguia confirmar se a recuperação em nível de infraestrutura seria possível

O depoimento do próprio agente e a falha das proteções do Cursor

• Ao ser questionado sobre o motivo após a exclusão, o agente registrou que violou regras de segurança por conta própria
  • Escreveu que presumiu que apagar o volume de staging afetaria apenas o staging e que não verificou isso
  • Escreveu que não confirmou se o ID do volume era compartilhado entre ambientes e que executou o comando destrutivo sem sequer ler a documentação da Railway
• O agente admitiu ter executado uma ação destrutiva irreversível sem solicitação do usuário
  • Escreveu que escolheu por conta própria a exclusão para corrigir o desencontro de credenciais e que deveria ter perguntado antes ou buscado uma solução não destrutiva
  • Listou diretamente que violou todos os princípios fornecidos
• A configuração usada não era uma opção barata, mas a combinação de Cursor com Claude Opus 4.6
  • Não era um modelo pequeno e rápido do Cursor nem um modelo com roteamento automático, e sim o modelo de nível mais alto
  • O projeto também tinha regras explícitas de segurança nas configurações
• Os Destructive Guardrails e o modo de operação baseado em aprovação, promovidos publicamente pelo Cursor, não funcionaram neste caso
  • A documentação do Cursor afirma que pode bloquear execução de shell ou tool call capazes de alterar ou destruir o ambiente de produção
  • O texto de boas práticas enfatiza aprovação humana para tarefas privilegiadas, e o Plan Mode promove restrição somente leitura até a aprovação
• O texto reúne também outros casos de falha das proteções do Cursor
  • Cursor Plan Mode constraint enforcement bug
  • Caso em que o Cursor apagou dados do PC de um usuário
  • Incidente de exclusão de um CMS de US$ 57 mil
  • Caso no fórum do Cursor de exclusão de banco de dados local
  • Coluna crítica ao Cursor no The Register

Problemas estruturais da Railway

• A API GraphQL da Railway quase não tem barreiras de defesa para operações destrutivas
  • Excluir um volume de produção se resolvia com uma única chamada de API, sem confirmação adicional, cooldown, rate limit nem limitação de escopo por ambiente
  • A Railway vem incentivando conectar diretamente essa superfície de API a agentes de IA por meio de mcp.railway.com
• A estrutura de backup de volumes estava dentro do mesmo blast radius da origem
  • Pela documentação da Railway, ao apagar o volume os backups também são apagados
  • Isso impede que cumpram o papel de backup separado em cenários de falha como corrupção de volume, exclusão acidental, ação maliciosa ou falha de infraestrutura
• O modelo de permissões do token de CLI também foi apontado como problema
  • Um token criado para domínio customizado podia executar até volumeDelete
  • Os tokens não eram divididos em escopos por tipo de tarefa, ambiente ou recurso, e também não havia controle de acesso baseado em papéis
  • A estrutura fazia com que, na prática, todos os tokens se comportassem como root
• A Railway vinha promovendo ativamente essa integração via MCP mesmo mantendo esse modelo de permissões
  • mcp.railway.com era divulgado voltado a usuários de agentes de codificação com IA
  • O texto afirma que houve uma publicação relacionada até no dia anterior ao incidente
• A resposta de recuperação também permaneceu incerta
  • Mesmo após 30 horas, não houve resposta de sim ou não sobre a possibilidade de recuperação em nível de infraestrutura
  • Mesmo 30 horas após um incidente destrutivo, ainda se podia ficar sem uma resposta definitiva sobre restauração

Danos aos clientes e impacto operacional

• Os clientes da PocketOS dependiam desse software para toda a operação de locadoras e empresas de aluguel, como aluguel de carros
  • Dados centrais da operação, como reservas, pagamentos, alocação de veículos e perfis de clientes, foram afetados
  • Alguns clientes já usavam o sistema havia 5 anos
• Na manhã seguinte ao incidente, os dados dos últimos 3 meses haviam desaparecido
  • Os registros de reservas dos últimos 3 meses sumiram, e informações de cadastro de novos clientes também desapareceram
  • Clientes que de fato chegaram na manhã de sábado para retirar veículos não tinham mais registros relacionados
• A recuperação passou a ser centrada em reconstrução manual
  • As reservas estão sendo remontadas com base em registros de pagamento do Stripe, integração de calendário e confirmações por email
  • Cada cliente passou a precisar de trabalho manual emergencial
• Novos clientes também enfrentaram o problema de inconsistência entre o Stripe e o banco restaurado
  • Clientes dos últimos 90 dias continuavam no Stripe e seguiam sendo cobrados, mas suas contas tinham desaparecido do banco de dados restaurado
  • A expectativa é de que leve semanas para organizar esse problema de consistência
• O peso da falha foi repassado diretamente até para pequenos negócios
  • A PocketOS também é uma empresa pequena, e seus clientes também são pequenos negócios
  • As falhas de projeto em cada camada recaíram diretamente sobre operadores que estão tocando negócios reais

Condições mínimas que precisam mudar e a resposta atual

• Operações destrutivas precisam de procedimentos de confirmação que o agente não possa completar automaticamente
  • O texto cita como exemplos digitar manualmente o nome do volume, aprovação out-of-band, SMS ou email
  • O estado atual, em que uma única requisição autenticada apaga a produção, é considerado difícil de aceitar
• Tokens de API precisam ter escopo por tarefa, ambiente e recurso
  • O fato de o token da Railway CLI se comportar na prática como permissão root parece incompatível com a era dos agentes de IA
• Backups precisam estar em um blast radius diferente da origem
  • O texto critica como impreciso chamar de backup um snapshot dentro do mesmo volume
  • Um backup de verdade precisa estar em um local que não desapareça junto se a origem sumir
• O sistema de recuperação precisa divulgar até uma Recovery SLA
  • Após um incidente com dados de produção de cliente, passar 30 horas respondendo apenas que a investigação continua não parece um sistema de recuperação aceitável
• Não dá para confiar a segurança apenas ao system prompt do agente de IA
  • Até a regra do Cursor de "proibir operações destrutivas" foi violada pelo agente real
  • O texto diz que a aplicação forçada precisa estar em pontos de integração como API gateway, sistema de tokens e handler de operações destrutivas
• No momento, o sistema foi restaurado com um backup de 3 meses atrás e a reconstrução dos dados está em andamento
  • Os clientes retomaram a operação, mas ficou uma grande lacuna de dados
  • A recuperação continua com base em dados de Stripe, calendário e email
  • A empresa buscou orientação jurídica e está documentando todo o processo
• O texto diz que usuários da Railway precisam revisar seus ambientes de produção
  • É preciso revisar o escopo dos tokens
  • É preciso verificar se o backup de volume da Railway é a única cópia dos dados e afirma explicitamente que não deveria ser
  • Há o alerta para repensar se mcp.railway.com deve ficar perto de um ambiente de produção

[colus001]

É como colocar um doce na frente de uma criança, dizer para ela não comer e depois culpar a criança por ter comido.

[savvykang]

Não sei por que ele faz uma besteira dessas e ainda sai espalhando por aí; não consigo entender a cultura do Twitter.

[shakespeares]

Eu estava usando bem a Railway... assustador.

[GN⁺]

Comentários do Hacker News

• Só existe uma postura saudável em relação à segurança de IA. Se a IA pode causar um acidente fisicamente, então ela de fato pode causar, e culpar a IA pelo que fez é mais ou menos como culpar um trator por passar por cima de uma toca de marmota
  Perguntar ao agente, depois da exclusão, por que ele fez aquilo e chamar isso de confession é antropomorfizar demais
  O agente não está vivo, não aprende com erros e também não consegue escrever um texto de reflexão que torne agentes futuros mais seguros de usar
  Mesmo que já tenha atropelado vários guardrails da Anthropic, do Cursor e do AGENTS.md, o motivo de no fim ter executado continua o mesmo. Se pode, então pode, e prompt e treinamento só ajustam as probabilidades

  • Não se deve antropomorfizar modelos de linguagem. É preciso tratá-los como uma máquina que corta sua mão se você a enfiar lá dentro; ela não tem sentimentos e também não é capaz de se importar com sentimentos
  • Essa confession parece só um CYA. Para começo de conversa, nem faz sentido por que seria necessário um LLM completo para um “trabalho rotineiro de staging”
    No fim, misturaram credenciais entre ambientes, deram acesso ao LLM e ainda tinham backups ruins, mas agem como se a responsabilidade não fosse deles
  • O problema é que, por causa do nosso cabeamento evolutivo, acabamos sentindo inconscientemente que está vivo
    Mesmo sabendo racionalmente que não está, durante a interação ele parece um ser vivo, ou então a gente escorrega e usa expressões de agente e personalidade sem perceber
  • Não foi “AI agent deleted our production database”, e sim com IA, eu apaguei
    Culpar a IA é tão estranho quanto culpar o SSH
  • Não precisa ser visto apenas como antropomorfização. O ponto central também pode ser mostrar que ele violou todas as instruções que recebeu
    Expressões como confession, think, say e lie, em sentido estrito, só fariam sentido se houvesse consciência, mas hoje todo mundo já entende o que se quer dizer quando se usa esse tipo de metáfora para falar do funcionamento de LLMs

• Quando acontece um acidente desses, eu jamais confiaria meus dados a uma empresa que publica um postmortem feito para transferir responsabilidade
  Não há qualquer autorreflexão ou autocrítica; o tom inteiro é de que eles fizeram tudo o que podiam e os outros estragaram tudo
  Segredos de produção não deveriam estar acessíveis daquele jeito. Isso não é um problema de IA, é uma versão moderna do clássico “dei um DROP TABLE sem querer em prod”
  É difícil aceitar que o sistema tenha sido deixado aberto para que isso fosse possível e, depois que de fato aconteceu, ainda culpem terceiros
  Uma empresa assim faz suspeitar com bastante razão que muitos desenvolvedores têm production access permanente e que outros segredos de produção também estão largados pelo repo

  • O mais chocante foi tratarem de forma tão casual a frase “encontrei credenciais em um arquivo”. Nem explicam por que o agente podia acessar esse arquivo em primeiro lugar
    Dizem que o token só deveria poder alterar custom domains, mas em um app voltado a usuários, acesso a um token assim já pode ser destrutivo o bastante
    Essa desculpa é tão fraca que fica difícil levá-la a sério em contexto de trabalho real
  • “Não sabíamos que esse token tinha permissão de exclusão” não é desculpa. Se emitiram sem definir permissões, a responsabilidade por verificar isso também era deles
    Se o backup recuperável mais recente era de 3 meses atrás, então nem a regra 3-2-1 foi seguida. Não sobra espaço para culpar outros
  • Talvez a história não seja tão simples assim. Parece verdade que o design dos tokens da Railway não comunica claramente o que eles permitem
    Se um token de CLI criado para custom domains consegue operar a GraphQL API inteira da Railway, inclusive ações destrutivas como volumeDelete, então deveria haver um aviso, e se soubessem disso provavelmente não o teriam armazenado
  • Não há uma única linha dizendo “será que nós também deveríamos ter testado e validado nossa estratégia de backup?”
    Nem sequer aparece a questão de se o backup deveria estar fora do fornecedor principal. Isso soa como se praticamente não houvesse estratégia de DR e BC
  • Exato. Isso parece muito mais colocar um agente de IA em modo YOLO, sem sandbox, com acesso a credenciais de produção
    Nem parecem considerar essa ação em si como a verdadeira root cause; tudo vira culpa dos outros

• O simples fato de o post no Twitter sobre “o agente de código apagou o banco de produção” ter sido escrito com um LLM já soa como uma estranha comédia sombria
  E perguntar “por que você fez isso?” também parece sinal de que não entendem como o agente funciona
  O agente não é um ser que decide algo e depois executa; no fim, ele só gera texto
  Ainda assim, como a Anthropic vem deixando contexto e processo de raciocínio menos visíveis, dá para pensar que essa pergunta talvez fosse uma tentativa de recuperar visibilidade

  • Mesmo com humanos, quando você pergunta “por que fez isso?”, nem sempre dá para confiar na explicação. Os experimentos de cérebro dividido de Sperry dão base para isso
    O cérebro às vezes justifica de forma plausível uma decisão que na prática nunca tomou
    Ainda assim, isso pode ser útil se interpretado como “que estímulo provavelmente desencadeou esse comportamento?”. Não dá para aceitar sem crítica, mas às vezes o modelo aponta fatores desencadeadores úteis no prompt
  • O que o agente faz no fim das contas também segue a saída do LLM, então é estranho que no texto o Opus seja tratado quase como algo entre parênteses
    Tudo bem que o Cursor tenha vendido segurança no marketing, mas quem de fato emitiu as chamadas de ferramenta foi o modelo
    Se você der as mesmas permissões e acreditar que basta escolher “o agente certo” para ficar seguro, pode se queimar feio
    E escreveram “NEVER FUCKING GUESS!”, mas adivinhar é justamente a essência do modelo. A estrutura é prever tokens em sequência, e daí surgem saídas que parecem um raciocínio plausível
  • Pelo que sei, esses posts vindos do Twitter são monetizados por engajamento. Então talvez haja uma encenação exagerada aí
  • Esse trecho dizendo que o tuíte foi escrito por LLM me fez duvidar se esse caso sequer é real de fato
  • Parece uma tragédia grega moderna
    Logo depois de perceber que não dá para confiar no LLM, usam justamente esse mesmo LLM como sua própria voz; a ironia é precisa demais

• Pensando na essência da modelagem de linguagem, acho correta a visão de Murphy's Law de que todo modo de falha sem controle forte de engenharia acaba acontecendo em algum momento
  Não importa quão bom seja o prompt, o agente ainda pode produzir uma sequência de tokens que destrói um ambiente de produção
  Prompting não é controle forte; está mais para controle administrativo do que para controle de engenharia de verdade
  Até prova em contrário, agentes devem ser tratados como minas terrestres capazes de explodir produção
  Dito isso, muitos desses acidentes também vêm da negligência de simplesmente dar privilégios altos demais
  Aqui, a causa foi ter embutido credenciais com privilégios maiores em um script; é uma higiene ruim, mas não chega a ser um erro incompreensível
  Por isso a conclusão é que o rigor tradicional de engenharia de software continua importante, e talvez esteja ainda mais importante agora
  E, complementando, dizer “toda sequência de tokens é possível” não é literalmente verdade em relação ao modelo finito de um computador real, mas ainda é um modelo mental útil na prática

  • Dizer que “toda sequência de tokens é possível” é literalmente incorreto
    Há muitas críticas válidas a LLMs, mas essa não é uma delas
    Soa como dizer que, porque moléculas se movem probabilisticamente por causa da física estatística, devemos esperar que um dia o teto se desmonte espontaneamente
  • Isso é verdade, mas se essa probabilidade for muito menor do que a de ser atingido por um meteorito, engenheiros em geral consideram aceitável
    É parecido com a forma como tratamos hash collision
  • Do ponto de vista do provedor de serviço, agora surgiu um novo attack vector
    Antes, mesmo que existisse uma API para apagar um volume inteiro, normalmente o usuário não fazia algo tão destrutivo ou, se fazia, presumíamos que entendia o que estava fazendo
    Agora, porém, o agente é excessivamente agressivo para resolver problemas, e pode descobrir de forma engenhosa uma API dessas para “recomeçar do zero”
  • Essa frase não procede. Um LLM com parâmetros finitos e contexto de tamanho finito não consegue mapear todas as permutações infinitas de strings de saída
    Só pelo princípio da casa dos pombos isso já fica difícil de sustentar
  • Eu nunca daria ao LLM acesso direto ao DB para ele escrever queries livremente
    No máximo, criaria uma API segura separada que expusesse apenas uma parte extremamente limitada do que o banco pode fazer, e abriria só essa API para o LLM

• Parece detalhe, mas a reclamação de que a API não tem uma etapa “digite DELETE para confirmar” é meio estranha
  É uma API; nem sei onde exatamente alguém digitaria DELETE
  Fico curioso se há casos em APIs estilo REST com confirmação em duas etapas para alteração ou exclusão
  Normalmente esse tipo de checagem não costuma ser implementado do lado do cliente antes da chamada da API?

  • Isso não é um ponto menor. Passa a impressão de que o autor nem entende direito como APIs funcionam e ainda quer culpar terceiros
    Claro, havia muitos pontos em que daria para mitigar, mas no fim acho que isso aconteceu em grande parte porque eles não fizeram a lição de casa sobre como os serviços de que dependem realmente funcionam
  • Na AWS, alguns serviços têm deletion protection
    É um mecanismo para impedir que automações apaguem recursos que o usuário não quer perder, exigindo antes uma chamada de API separada para desativar esse bit de proteção
    Entendo isso como uma decisão de design para evitar casos em que ferramentas como Terraform ou CloudFormation, guiadas por lógica de máquina de estados, acabam empurrando a substituição de um DB e a pessoa só percebe tarde demais
  • Um padrão que já vi é uma espécie de API de confirmação em duas etapas
    Por exemplo, em fusão de entidades, a primeira requisição recebe os IDs a serem mesclados, devolve a lista dos objetos afetados e um mergeJobId, e a execução real só acontece por uma segunda requisição separada
  • Usar um agente de IA foi uma estupidez, mas isso não significa que o design do sistema estivesse bom
    Para esse tipo de tarefa, mecanismos como soft delete deveriam ser padrão, e qualquer operador deveria ativar essas proteções em produção
  • Mesmo que o usuário não digite DELETE, a implementação da API pode perfeitamente ter um estado de pending deletion e manter o recurso por algum tempo
    É parecido com o que a AWS faz com recursos como chaves

• Mesmo que tenha havido falhas do Cursor ou da Railway, no fim a responsabilidade é do próprio autor
  Foram eles que decidiram rodar o agente, e foram eles que não verificaram como a Railway funcionava
  Quiseram lançar rápido apostando em frontier tech no modo YOLO, então também têm de aceitar esse risco
  É lamentável, mas o tom do texto inteiro é só “o Cursor estragou”, “a Railway estragou”, “o CEO não resolveu nada”
  Minha lição é simples: se você vai viver na linha de frente, precisa estar pronto para cair

  • Foi bem chocante ver o autor assumir quase nenhuma responsabilidade e jogar tudo nos outros
    Quem usa essas ferramentas precisa conhecer e aceitar o risco ou rejeitá-lo. E se não tem capacidade ou experiência suficiente para sequer entender esse risco, isso também é responsabilidade sua
  • A empresa que escreveu DO NOT FUCKING GUESS foi justamente a que saiu fazendo um monte de suposições
    Supôs que o token teria escopo, supôs que o LLM não conseguiria acessá-lo, supôs que, mesmo com permissão, ele não faria nada destrutivo, e supôs que haveria backup em outro lugar
    Se nem sabem onde isso estava armazenado, então quem está lendo agora acaba fazendo a mesma suposição
    E não se deve dar a LLMs instruções que pressupõem metacognição. Dizer para não adivinhar não funciona porque ele não tem monólogo interno para saber o que não sabe, e dizer para perguntar antes também não significa que ele vá planejar e parar ao perceber previamente uma ação destrutiva
  • Concordo totalmente. Se decidiram usar permissões tão fortes, então precisavam aceitar junto a chance minúscula de acidente e o impacto enorme caso ocorresse
    O texto também parece ter sido escrito por IA, e citar a “confession” do agente como golpe final soa como evidência de que o autor não entende bem o mecanismo de funcionamento
  • Li até o fim esperando encontrar algum reconhecimento de responsabilidade, mas simplesmente acabou sem isso
  • Na prática, é difícil para uma única pessoa conhecer todo o código e todo o sistema. Ainda mais se for CEO ou CTO
    Talvez um ou dois funcionários tenham feito o setup entre Cursor e Railway sem perceber por completo os riscos dessa interação
    Em escalas diferentes, talvez desenvolvedores que nunca cometeram um erro desse tipo só tenham tido menos responsabilidade ou mais sorte
    Ainda assim, escolher tecnologia de fronteira certamente aumentou o risco, e talvez não tenha sido uma boa decisão

• O que mais me irrita aqui, mais até do que o erro da IA, é o fato de que, ao apagar um volume na Railway, os backups também são apagados
  Mesmo sem IA, isso era algo que acabaria dando problema um dia
  É ainda mais absurdo que a documentação esconda isso em uma nota dizendo “se você der wipe no volume, todos os backups serão apagados”

  • Sim, isso é realmente estranho. Uma das principais razões para ter backup é justamente conseguir recuperar quando o original é apagado por engano, então vincular a exclusão do original à exclusão do backup esvazia o sentido
    Até pode haver necessidade de apagar backups, mas isso obrigatoriamente deveria ser uma chamada de API separada
    Não deveria existir uma única API que apaga ao mesmo tempo o volume original e os backups. Backup deveria ser a primeira linha de defesa contra erro do usuário
    Também fui olhar a documentação, e ela deixa claro que não são snapshots one-off, e sim backups executáveis periodicamente
    [1] https://docs.railway.com/volumes/backups
  • Se o texto estiver correto, o mais grave é que nem existe de fato uma API key com escopo restrito
    Se uma chave de dev ou staging consegue mexer até em sistema de prod, é perigoso demais
    E também é difícil ficar tranquilo sem pelo menos um backup separado em outro fornecedor. Tem de existir ao menos um backup que nenhuma role ou key usada no servidor real ou na automação consiga apagar
  • Se o backup está dentro da mesma coisa, então isso não é backup; é só uma cópia antiga
  • Sim, isso significa literalmente que não existia uma estratégia de backup funcional
  • Isso realmente parece um grande defeito

• Acho que interpretar isso como “o agente listou as regras de segurança que recebeu e admitiu que violou todas” é, por si só, resultado de um mal-entendido sobre como LLMs funcionam
  Enquanto se acreditar que eles seguem instruções e lógica como pessoas, acidentes assim continuarão sendo comuns
  Até a forma de responder ao incidente revela como entendem esse gerador de palavras
  Quando você pergunta por que ele fez isso, o que existe é apenas uma nova instância gerando texto plausível com base na descrição do incidente. Não há um por quê humano ali; o máximo que pode haver é um como baseado na descrição de entrada
  O próprio conceito de agente pressupõe capacidade de agir e competência, e o agente baseado em LLM não tem nenhuma das duas. Ele só gera texto plausível
  Esse texto pode alucinar dados, pode trocar chaves, pode emitir comandos de delete
  Se um texto plausível é possível, ele eventualmente vai surgir, e com tentativas suficientes esse tipo de resultado acaba acontecendo. Especialmente quando quem está operando o processo e as ferramentas não os entende direito
  No momento, ainda não temos sistemas de controle suficientes para soltar adequadamente esse agent sem agency em codebases ou dados
  O CEO parece acreditar que essas ferramentas podem tocar a empresa em nome deles e ainda conversar como humanos

  • Se a lógica for “pedimos claramente para ele não errar, e mesmo assim errou”, então fico pensando que talvez essa pessoa também não lidaria muito bem com gestão de gente
  • Eu vejo quase o oposto. LLMs e humanos têm muitos pontos parecidos
    Especialmente uma pessoa pouco treinada talvez cometesse um erro semelhante e, se perdesse a memória, talvez desse uma explicação posterior parecida com a de um LLM
    Dá até a sensação de que, se o LLM produz texto plausível, o humano produz pensamento plausível
  • Humanos também não seguem regras direito. É por isso que precisamos de prisões, de segurança e até de sistemas de contas de usuário

• Pediram ao agente da Railway para fazer live resize do volume do DB, e ele destruiu o banco e ainda o moveu da UE para os EUA
  Pelos logs do chat, primeiro ele disse que o resize para 100GB tinha sido concluído, mas depois reconheceu que talvez o volume tenha sido recriado e os dados perdidos
  Também dizia que a configuração ainda era europe-west4, mas que fisicamente tinha sido movido para os EUA, e ainda afirmou que isso não deveria acontecer automaticamente
  Naquele momento ficou claro que a noite seria de trabalho de recuperação até morrer

  • Nesse ponto, parece caso de migrar para um concorrente em vez de continuar na Railway
    Não faço ideia do que faria alguém permanecer nem mais um instante nesse lugar amaldiçoado

• Daqui a 5 anos vai ser curioso reler este texto e ver quantos mecanismos de segurança a mais a indústria construiu para evitar acidentes assim
  Deve haver centenas, talvez milhares, de usuários de IA cometendo erros parecidos todos os dias, e só uma fração minúscula deles deve de fato publicar isso ou reclamar em público