Gerar é barato, revisar é caro: como parar de entregar slop de IA — Gabriel Martinez, G2i

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i · Canal: AI Engineer · 16:48 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA

Resumo

Gabriel Martinez define slop como trabalho que parece concluído antes que o raciocínio esteja completo: a geração supera o julgamento, e decisões importantes ficam escondidas. Embora agentes acelerem a produção, o custo de entender, testar e manter o software continua recaindo sobre as pessoas. Para evitar sistemas incoerentes e PRs difíceis de revisar, ele defende trabalho de escopo menor, convenções claras, diagramas e responsabilidade explícita. ORC incorpora essas práticas a um workflow que mantém o julgamento humano no centro.

Pontos-chave

Slop não é simplesmente código gerado por IA; é resultado sem julgamento, entendimento ou responsabilidade suficientes.
O custo de gerar código está caindo, mas o custo de compreender e manter sistemas não.
Protótipos rápidos podem levar stakeholders a subestimar o trabalho de integração, esclarecimento de requisitos, testes e revisão.
A pressão por velocidade e métricas inadequadas pode incentivar PRs grandes e código mesclado sem entendimento ou testes suficientes.
A produtividade não deve ser medida por linhas de código ou tokens produzidos, mas pelo valor e pela qualidade do software.
Decompor tarefas em partes pequenas e revisáveis ajuda a preservar entendimento e controlar a complexidade.
Diagramas, convenções, padrões e limites claros tornam sistemas e mudanças mais fáceis de avaliar por humanos.
Frameworks com convenções consistentes reduzem decisões repetitivas e facilitam o trabalho de agentes e engenheiros.
ORC organiza práticas de planejamento, revisão, checagens adversariais e gestão de contexto sem remover a responsabilidade humana.

Capítulos

Início	Capítulo	Resumo
00:01	O que é slop	Gabriel define slop como resultado que parece concluído antes do raciocínio e do julgamento necessários.
02:18	Código gerado e custo da complexidade	A geração acelerada não substitui decisões humanas e pode ampliar sistemas confusos e produtos inchados.
04:53	Protótipos, responsabilidade e revisão	A aparência de rapidez dos protótipos esconde o trabalho de integração, testes e responsabilidade de longo prazo.
07:40	Pressão por velocidade e PRs difíceis de avaliar	Incentivos focados em rapidez podem levar engenheiros a mesclar mudanças sem revisá-las com o devido cuidado.
10:22	A geração é barata, a avaliação é cara	A palestra contesta métricas baseadas em produção e defende práticas de engenharia, decomposição e revisão humana.
12:31	Tornar sistemas legíveis para humanos	Diagramas, convenções e limites claros ajudam a reduzir a carga cognitiva e a revisar o trabalho de agentes.
15:46	ORC e a orquestração com julgamento	ORC incorpora práticas de planejamento e revisão para que agentes produzam software coerente sem eliminar a responsabilidade humana.

Citações

Slop é o que acontece quando a geração ultrapassa o julgamento. — 00:34

O custo de criar código está caindo, mas o custo de entender um programa de software não. — 03:20

Gerar é barato, mas avaliar é caro. — 10:22

O objetivo não é entregar mais código gerado. É entregar software que continue coerente, testado, sustentável e sob responsabilidade de alguém. — 16:16

O futuro é orquestração com julgamento. — 16:16

Conceitos e entidades

slop (conceito): Trabalho que parece pronto, mas foi produzido sem resolver ambiguidades nem demonstrar entendimento e julgamento suficientes.
judgment (conceito): Capacidade humana de decidir o que construir, avaliar trade-offs e reconhecer restrições e casos de borda.
PR (conceito): Mudança proposta para revisão, cuja manutenção e consequências também precisam ser consideradas.
review (conceito): Avaliação do código e de seu comportamento para verificar se a mudança é compreensível, adequada e segura para integrar.
Harness (conceito): Estrutura usada para testar e avaliar resultados, mencionada como parte de práticas de engenharia que devem ser claras.
Rails (ferramenta): Framework citado como exemplo de convenções que reduzem decisões repetitivas e facilitam a compreensão de código.
ORC (ferramenta): Workflow criado para incorporar planejamento, revisão, checagens adversariais e gestão de contexto ao uso de IA.
Gabriel Martinez (pessoa): Palestrante, também conhecido como Gabo, que se apresenta como engineering manager e responsável por combater slop na G2i.
G2i (empresa): Empresa onde Gabriel Martinez trabalha e que é associada ao desenvolvimento de ORC na palestra.

Tradução completa (pt-BR)

00:01 [música] Oi, pessoal. Meu nome é Gabriel Martinez. Podem me chamar de Gabo. Sou gerente de engenharia e fiscal residente da porcaria na G2I. E estou aqui para falar sobre porcaria. Estou aqui para falar sobre isso porque sou bastante apaixonado pelo tema. E, por apaixonado, quero dizer irritado. O termo “slop” já foi usado até perder o sentido, mas aquilo a que ele se refere existe há muito tempo.

00:34 Só que agora isso acontece em velocidade de dobra. Certo. Slop é o que acontece quando a geração ultrapassa o julgamento. Slop não é código gerado por IA. Não estou tentando defini-lo como algo concreto e objetivo que possa ser facilmente detectado, embora existam sinais. Slop é uma entrega que parece concluída antes de o pensamento estar concluído. É um produto de trabalho em que as ambiguidades foram eliminadas com suposições, em que as concessões foram deixadas ao acaso, em que ninguém assumiu a responsabilidade. O resultado foi produzido, sim, mas

01:11 não houve compreensão. E o verdadeiro perigo não é simplesmente a máquina ter feito uma escolha ruim. O perigo é o engenheiro nem sequer ter percebido que havia uma escolha a fazer. Ele nunca se deparou com a ambiguidade. Nunca sentiu a restrição. Nunca descobriu o caso extremo que teria mudado o design. O trabalho chegou já alisado e, com ele, as incógnitas desconhecidas continuaram desconhecidas. Mas o software é um registro de escolhas: escolhas técnicas, de produto, operacionais e voltadas ao usuário.

01:43 Se não enxergamos essas escolhas, não podemos assumir a responsabilidade por elas. E, se não assumimos essa responsabilidade, não estamos realmente fazendo engenharia. Estamos apenas aceitando resultados. Somos apenas macacos de código apertando o botão de merge. Não sou um purista que veio aqui dizer que a IA é ruim. Ela não é ruim, certo? Estou aqui para descrever alguns dos padrões que nos levaram à nossa embriaguez de IA. É totalmente compreensível, considerando os avanços desde dezembro de 2025, como chegamos a esse ponto. Mas precisamos ajustar o rumo. Precisamos desacelerar. Precisamos ficar sóbrios. Os agents podem parecer capazes de

02:18 fazer mágica. E a internet faria você acreditar nisso. Eles podem escrever código, criar a estrutura inicial de telas e, com o ajuste certo, construir funcionalidades ou sistemas inteiros. Mas não podem substituir o trabalho humano de decidir o que importa, entender o que está sendo construído, interpretar ambiguidades, assumir a responsabilidade pelo sistema a longo prazo, exercer julgamento e contenção no nível da arquitetura do sistema e, talvez o mais importante, saber o que não construir. SLOP não é sobre a IA como ferramenta. Em vez disso,

02:49 é sobre a ausência de julgamento. Então, vamos falar um pouco sobre o que nos trouxe até aqui. Num mundo em que tudo é possível, decidir o que construir é mais importante do que nunca. As pessoas ficaram empolgadas demais e construíram monstruosidades de produtos sem sentido, feitos de código espaguete. É quase como se tivessem esquecido que cada linha de código que você escreve é um passivo, e que o melhor código é nenhum código. O custo de criar código está caindo, mas o custo de entender um programa de software não. E quero deixar isso claro. Não estou

03:20 dizendo que cada linha de código precisa ser lida pessoalmente, aprovada e entendida isoladamente. Esse nunca foi bem o padrão. Sistemas grandes sempre contiveram mais detalhes do que uma só pessoa consegue guardar na cabeça. Mas é preciso entender a lógica. É preciso entender os fluxos principais, os limites, o modelo de dados e os comportamentos do produto. Um bom software tem uma espécie de harmonia. Não num sentido estético preciosista, mas num sentido prático. O código deve refletir a forma do domínio. A IA pode gerar código, mas

03:50 não pode dar coerência mágica a um sistema desorganizado. Um agent consegue operar com muito mais eficácia numa base de código que tenha estrutura, padrões, limites claros e justificativas. Mas, se o sistema já é uma grande bola de lama, o agent não vai tirar você da lama. Só vai aumentar a bola mais rápido. O fato de você poder gerar outro componente não significa que o produto precise de mais um componente. Dijkstra disse uma frase ótima: se pudéssemos contar linhas de código, não deveríamos pensar nelas como linhas produzidas, mas como linhas gastas. Esse é o custo de construir. A IA facilita

04:23 gastar linhas. Facilita gastar com arquivos, abstrações e complexidade. Mas, no fim das contas, a conta é sua. E ela aparece como confusão, fluxos frágeis e funcionalidades que ninguém quer tocar porque não as entende por completo. Aparece como interfaces de produto que tecnicamente fazem tudo, mas parecem um labirinto. Pense naquele tipo especial de software B2B inchado, em que toda tarefa exige treinamento, toda tela tem 12 saídas de emergência e ninguém consegue explicar se a complexidade

04:53 está ali porque os usuários precisavam dela ou porque as equipes simplesmente continuaram adicionando coisas. As equipes devem ser responsabilizadas pelo trabalho que produzem. Responsabilização é a palavra-chave aqui. Assumir a responsabilidade pelo produto que você está construindo e ter uma forma de vincular isso a incentivos positivos ou negativos. Só o fato de saber que outra pessoa vai revisar seu trabalho já leva os engenheiros a prestar um pouco mais de atenção aos detalhes e a ser um pouco mais meticulosos, especialmente se houver métricas de responsabilização visíveis para cada parte do trabalho produzido. Estamos entrando na era dos produtos inchados,

05:25 produtos inchados com uma UX espaguete, no nível dos piores ERPs B2B que você talvez já tenha recebido treinamento para usar. Hoje, qualquer pessoa pode fazer vibe coding de uma aplicação em uma hora e terminar com um protótipo clicável funcional. E isso mudou as expectativas, porque, quando as pessoas veem software surgir tão rápido, começam a acreditar que dá para construir software com essa mesma rapidez. Elas veem alguns prompts se transformarem em telas. Veem uma sessão no terminal produzir algo que parece real. E, para ser justo, às vezes é real o bastante para ser útil. Às vezes, esse protótipo é uma ótima maneira de explorar uma ideia. Mas o

05:59 problema é que os stakeholders que não vivem na base de código muitas vezes veem esse protótipo como prova de que a parte difícil já passou. Eles não estão pensando nas partes em que engenheiros experientes, calejados pela batalha, fazem valer seu trabalho. É o que acontece fora do caminho feliz: descobrir como integrar de forma coerente um novo conjunto de funcionalidades. O trabalho envolvido em esclarecer os requisitos. O trabalho de testar manualmente um conjunto de funcionalidades para garantir que funcione como uma pessoa esperaria e que a UX não seja uma porcaria completa.

06:32 Eles não estão pensando nem um pouco nas partes mais demoradas, nas partes humanas, na última etapa, onde o julgamento entra em jogo. É aqui que alguém precisa ler o código, testar o comportamento, assumir a responsabilidade pelas concessões, perceber os requisitos ausentes e decidir se aquilo merece fazer parte do sistema. Aqui está um tuíte que enfatiza o ponto que estou tentando defender. Ele cita o criador do SQLite, que, sobre pull requests, diz: “Você diz: ‘Ah, é de graça’. Não, não é de graça. O que você está fazendo é me pedir para manter isso para você, documentar isso para você, testar isso para você e manter isso para você pelos

07:06 próximos 25 anos. Isso não é de graça.” E isso realmente me tocou. Eu não poderia ter dito melhor. É fácil mandar um PR de qualquer jeito, mas quem vai assumir a responsabilidade por aquilo? Quem é responsável pelas consequências do que isso significa? Então, as pressões externas dos stakeholders, somadas à pressão de competir com quem produz slop, geram muito slop. Tenho certeza de que a maioria de vocês já viu isso na prática: os engenheiros ruins, aqueles que não revisam os detalhes, não refinam a especificação e não são atentos aos detalhes, acabam produzindo mais e mais rápido.

07:40 As pessoas que prestam atenção aos detalhes e fazem um esforço extra são as que podem parecer estar fazendo menos e avançando mais devagar. Isso se propaga e gera ansiedade de desempenho. Em equipes, essa ansiedade pode pressionar os engenheiros a fazer merge de PRs mais rápido do que conseguem julgar, levando à integração de código sem compreensão completa. O pensamento de curto prazo — fazer o PR entrar — vence a saúde do código a longo prazo. Eu senti essa ansiedade pessoalmente: os engenheiros ao meu redor estavam fazendo merge num ritmo incrível, e eu sentia uma ansiedade constante por não estar avançando rápido o bastante. E posso admitir que isso me levou

08:13 mesclar código que eu não necessariamente revisei com o nível de detalhe que normalmente revisaria ou deveria revisar. Já ouvi histórias de horror sobre pessoas mesclando código que não entendem completamente ou que nem sequer testaram. No fim das contas, somos todos humanos. Somos movidos por incentivos. E, se os incentivos estiverem levando as pessoas a abrir PRs, vamos ter um despertar brusco. As recompensas devem estar centradas na produção de valor: design de sistemas elegante, bem estruturado e pragmático, e clareza nos harnesses de teste e avaliação.

08:44 Há algo que realmente me irrita em ver um PR com vários milhares de linhas. Não há a menor chance de um ser humano conseguir entender completamente todos os aspectos importantes de uma mudança tão grande. Nosso trabalho como engenheiros é nos adaptar a esse novo mundo, decompor as necessidades em partes tão simples quanto possível, o que favorece o entendimento de superfícies de código mais simples e o controle das nossas bases de código. A IA deveria estar eliminando empregos, e os engenheiros deveriam estar

09:17 se movendo no ritmo da produção de tokens. Então, há muita pressão para produzir mais e mais rápido. O que a IA realmente está fazendo é produzir mais e mais rápido: mais caracteres que consomem mais tempo humano. Já vi isso acontecer das formas mais banais. Você dá a alguém dez tópicos de escopo, algumas jornadas de usuário, algo intencionalmente leve, e a pessoa volta com um documento de 20 páginas. Talvez pareça bem-acabado, com uma prosa rebuscada. Mas agora preciso passar horas tentando descobrir se há algum pensamento de verdade ali dentro. Esse é o trabalho gerado por IA no

09:50 pior sentido. Ele não esclarece o problema. Ele o expande. Pegou uma ambiguidade que deveria ter sido resolvida por quem estava fazendo o trabalho e a devolveu como um artefato maior, para que outras partes interessadas resolvessem. No código, uma tarefa vaga vira um PR grande. Um recurso pequeno vira uma pilha de arquivos. A entrega chega com aparência de concluída, mas o trabalho de verdade acabou de ser transferido para quem revisa. E é sobre isso que precisamos ser honestos. A geração é barata, mas a avaliação é

10:22 cara. Se a IA produzir mais do que os humanos conseguem avaliar, ela não acelerou a equipe. Criou um gargalo. Uma coisa que acho particularmente irritante é o Twitter. Está cheio de especialistas autoproclamados e caça-cliques resumindo uma palestra ou promovendo verdades que sempre conhecemos como se fossem alguma ideia genial e inédita. O ciclo Ralph foi um desses casos. Fizeram parecer um avanço inédito em agentes, quando é só um loop while. De alguma forma, nós

10:54 esquecemos completamente que o número de linhas de código é uma métrica péssima de produtividade. Mas aí decidimos que era diferente de concluir que o engenheiro que consome mais tokens deve estar produzindo mais. Antes, dividíamos um recurso em pequenas partes atômicas sobre as quais conseguíamos raciocinar. Pequenas o bastante para manter na cabeça e realmente revisar. Agora digitamos duas frases e esperamos receber, de uma só vez, um conjunto de recursos que não foi totalmente pensado, sem entender de verdade o que estamos pedindo. O ponto principal que quero destacar aqui é que não

11:25 devemos esquecer as verdades fundamentais que sempre conhecemos. Sessenta anos de sabedoria em desenvolvimento de software não foram invalidados pela IA. Código componível, bons padrões e práticas sólidas continuam sendo essenciais. Recentemente, um amigo me questionou sobre por que passo tanto tempo pensando em barreiras de proteção para agents, convenções de código, estilos arquiteturais e restrições sobre como o sistema deve ser estruturado. A pergunta dele era basicamente: qual é o sentido, se o agent escreve o código? Por que deveríamos

11:57 nos importar com a aparência do código? Até certo ponto, concordo: eventualmente, haverá um mundo em que muitos detalhes de implementação estarão completamente abstraídos dos humanos. Essa tem sido a direção do software desde o começo. Passamos do código de máquina para assembly, que nos levou a mais um nível de abstração, depois chegamos a C, depois a Java e então a linguagens como Ruby, cujo principal objetivo de design era a felicidade do programador. Assim como nas linguagens, criamos abstrações para coleta de lixo e ponteiros manuais; a IA está abstraindo as partes imperativas. Isso não elimina

12:31 a necessidade de entender como um sistema se integra de forma coesa. É por isso que diagramas são tão importantes: não como documentação decorativa feita depois do fato, mas como uma forma de tornar os sistemas compreensíveis. Quando agents conseguem gerar milhares de linhas de detalhes de implementação, os humanos precisam de uma superfície de revisão condensada: limites entre serviços, fluxos de dados, transições de estado e modos de falha. Um bom diagrama nos permite ver a estrutura do sistema de uma forma que o código muitas vezes obscurece. Podemos deixar o processo principal ou o workflow como a superfície passível de revisão, com

13:03 os detalhes de implementação relegados às folhas. É por isso que defendo código declarativo e padrões de arquitetura que criam camadas sobre as quais os humanos conseguem realmente raciocinar. O objetivo não é apenas gerar código. O objetivo é o conhecimento humano, o entendimento humano e a revisão humana. Precisamos otimizar para essa camada humana. A sobrecarga cognitiva é um imposto que todo engenheiro precisa pagar antes de fazer uma mudança significativa. É o tempo gasto tentando descobrir onde o código deve ficar, qual padrão seguir e o que uma implementação adequada realmente

13:36 significa. A IA não elimina esse imposto. Se não for controlada, ela o agrava. Um agent pode gerar cinco padrões plausíveis em cinco estilos diferentes. E agora quem revisa precisa fazer engenharia reversa não só do código, mas também da intenção por trás dele. Com convenções adequadas, é mais fácil entender a intenção. A resposta para isso são convenções, padrões, fluxos documentados, superfícies pequenas e passíveis de revisão, limites claros de responsabilidade e definições de pronto. Quanto mais óbvio for o caminho, menos espaço

14:09 haverá para o trabalho de baixa qualidade se esconder. Quero fazer aqui um reconhecimento especial ao Rails, que tem um lugar especial no meu coração. O Rails importa nesse contexto porque mostra o que acontece quando um framework reduz agressivamente o espaço de decisões. Quando as convenções reduzem sua sobrecarga, em vez de você acabar com dez maneiras diferentes de estruturar o mesmo conceito, fica com uma só. Talvez ela não seja perfeita na opinião subjetiva de todos, mas é compreendida e funciona. Na minha carreira, entre meu

14:40 primeiro e segundo 4A com Rails, houve um intervalo de quatro anos. Foi maravilhoso voltar depois desse intervalo e ver que os mesmos padrões nas bibliotecas de fato continuavam sendo os mesmos padrões nas bibliotecas de fato. Consegui voltar direto a uma base de código e entender imediatamente a intenção, sem precisar analisar a arquitetura. Isso permite que engenheiros mudem facilmente de projeto, de forma lateral, com um período mínimo de adaptação. Não se pode dizer o mesmo de outros ecossistemas de linguagens. Ambientes JavaScript com uma única maneira correta

15:15 de fazer as coisas são superiores para o desenvolvimento com agents, porque os agents não ficam confusos com dezenas de abordagens concorrentes. Isso é bem respaldado pela doutrina oficial do Rails. Ela menciona explicitamente “otimizar para a felicidade do programador” e “convenção em vez de configuração” como pilares fundamentais, e descreve a convenção como uma maneira de eliminar decisões recorrentes e reduzir a barreira de entrada. Trata-se de reduzir a sobrecarga cognitiva. Tudo de que falei hoje é

15:46 o que nos levou a criar ORC. Não apenas porque achamos que a resposta são mais agents — e definitivamente não porque achamos que o julgamento de engenharia possa ser automatizado. Criamos ORC porque continuávamos vendo o mesmo padrão de falha. A IA conseguia gerar código, mas ainda faltava a disciplina ao redor: o planejamento, a revisão, as verificações adversariais, o gerenciamento de contexto. Com o tempo, percebemos que repetíamos os mesmos processos humanos para combater trabalho de baixa qualidade: dividir o trabalho, gerenciar o contexto,

16:16 avaliar as opções e garantir que a entrega entre na base de código de uma forma que a equipe ainda consiga compreender. ORC está incorporando essas lições ao workflow. Não é uma caixa mágica que elimina a responsabilidade humana pela correção. É um sistema para preservar essa responsabilidade enquanto permite que os agents façam uma parte maior do trabalho. O objetivo não é entregar mais código gerado. O objetivo é entregar software que continue coerente, testado, sustentável e sob responsabilidade de alguém depois da geração. Porque o

16:48 futuro não é fazer vibe coding melhor e mais rápido. O futuro é orquestração com discernimento. Obrigado a todos pelo tempo, e lembrem-se: não façam trabalho de baixa qualidade. >> [música]

Transcrição original

[00:01] [music] Hi everyone, my name is Gabriel Martinez. I go by Gabo. I’m an engineering manager and resident slop warden at G2I. And I’m here to talk about slop. I’m here to talk about slop because I’m rather passionate about the topic. And by passionate, I mean angry. The term slop has been beaten to a pulp, but the thing it points at has long been around.

[00:34] Only now it happens at warp speed. All right. Slop is what happens when judgment when generation outruns judgment. Slop is not AI generated code. I don’t mean to define it as some concrete objective thing that can easily be sniffed out, although there are tells. Slop is output that looks finished before the thinking is finished. It is work product where ambigu ambiguity was cleared with guesses, where trade-offs were left to chance, where ownership was not taken. Output was produced, sure, but

[01:11] understanding was not. And the real danger is not simply that the machine made a bad choice. The danger is that the engineer never noticed that there was a choice to make. They never hit the ambiguity. They never felt the constraint. They never discovered the edge case that would have changed the design. The work arrived already smoothed over and with it the unknown unknowns stayed unknown. But software is a record of choices. Technical choices, product choices, operational choices, userfacing choices.

[01:43] If we do not see those choices, we cannot own them. And if we do not own them, we are not really engineering. We are just accepting output. We are just a code monkey hitting the merge button. I’m not the purist that’s come here to tell to tell you that AI is bad. It’s not bad, okay? I’m here to describe some of the patterns that have led to our drunken AI stuper. It’s absolutely understandable given the advancements made since December 25, how we got to where we are. But we need to dial it in. We need to slow down. We need to sober up. Agents can seem to

[02:18] make magic. And the internet would make you believe it is so. They can write code, scaffold screens, and with right tuning can build whole features or systems. But they cannot replace the human work of deciding what matters, understanding what is being built, interpreting ambiguity, owning the system for the long haul, exercising judgment and restraint at the system architecture level, and arguably the most important important knowing what not to build. SLOP is not about AI as a tool. Rather,

[02:49] it is about the absence of judgment. So, let’s talk a little bit about what got us here. In a world where anything is possible, deciding what to build is more important than ever. People have gotten overly excited and built behemoths of spaghetti product nonsense. It’s almost as if they’ve forgotten that any line of code you write is a liability, that the best code is no code at all. The cost of creating code is falling, but the cost of understanding a software program is not. And I want to be clear here. I’m

[03:20] not saying every line of code needs to be personally read, blessed, and understood in isolation. That has never really been the standard. Large systems have always contained more detail than any one person can hold in their head. But the logic has to be understood. The main flows, the boundaries, the data model and product behaviors have to be understood. Good software has a kind of harmony to it. Not in some precious aesthetic sense, in a practical sense. The code should reflect the shape of the domain. AI can generate code, but it

[03:50] cannot magically give a messy system coherence. An agent can operate with much more effectively inside a codebase that has structure, patterns, clear boundaries, and rationale. But if the system is already a big ball of mud, the agent does not rescue you from the mud. It just builds the ball bigger, faster. Just because you can generate another component does not mean the product needs another component. Dystra had this great line. If we could count lines of code, we would not think of them as lines produced, but as lines spent. It is the cost of building. AI makes it

[04:23] easier to spend lines. It makes it easier to spend on files, abstractions, and complexity. But at the end of the day, you own the bill. That bill shows up as confusion, brittle flows, features nobody wants to touch because they don’t fully understand. It shows up as product surfaces that technically do everything but feel like a maze. Think about that special kind of B to bloated B2B software where every task requires training where every screen has 12 escape hatches and nobody can explain whether the complexity is

[04:53] there because users needed it or because teams just kept adding things. Teams should be held accountable for work they are producing. Accountability is the key word here. Taking ownership over the product you’re building and having a way to tie that to positive or negative reinforcement. Just in the mere fact of knowing that someone else will review your work will force engineers to pay just a little bit more attention to the finer details and be a bit more meticulous, especially if there are accountability metrics that can be made visible for each chunk of work product. We’re entering the age of bloated

[05:25] bloated products with spaghetti UX on the order of worst kinds of B2B ERPs you may have ever been trained to use. Today, anyone can buy code an application in an hour and end up with a working clickable prototype. And that has changed expectations because once people see software appear that quickly, they start to believe software can be built that quickly. They see a few prompts turn into screens. They see a terminal session produce something that looks real. And to be fair, sometimes it is real enough to be useful. Sometimes that prototype is a great way to explore an idea. But the

[05:59] problem is that stakeholders do not live in the codebase of off that stakeholders that do not live in the codebase often experience that prototype as evidence that the hard part is over. They’re not thinking about the parts where real battleh hardened engineers earn their keep. It’s outside the happy path. Figuring out co how to cohesively integrate a new feature set. The the work involved in clarifying requirements. the work of actually manually testing a feature set to ensure that it works as a human should expect and that the UX isn’t complete garbage.

[06:32] They’re not at all thinking about the most timeconuming bits, the human parts, the last mile where the judgment lives. This is where someone has to read the code, test the behavior, own the trade-offs, notice the missing requirements, and decide whether this thing deserves to be a part of the system. Here’s a tweet that emphasizes the point I’m trying to make here. It quotes the creator of SQLite who on the topic of pull request says, “You say, ’Oh, it’s free. No, it’s not free. What you’re doing is asking me to maintain it for you, to document it for you, to test it for you, to maintain it for you for

[07:06] the next 25 years. That is not free.” And this really struck a chord with me. I couldn’t have said it better. It’s easy to yeet a PR, but who has to own that thing? Who’s responsible for the repercussions of what that means? So external pressures from stakeholders coupled with pressures of competing with slot misters begets mucho slopp. I’m sure most of you have seen this in the wild where the bad engineers, the ones who don’t review the details, that don’t refine the spec, that aren’t detail oriented, end up producing more faster.

[07:40] The folks who pay attention to the detail and go above and beyond are the ones that might seem like they’re doing less and moving slower. How this propagates is it yields performance anxiety where in team environments can pressure engineers to merge PRs faster than they can judge leading to code being merged without full understanding. Short-term thinking getting that PR in wins over long-term code health. I’ve personally felt this anxiety where engineers around me were merging at an incredible pace and I felt constant anxiety that I was not moving fast enough. And I can admit that it led me

[08:13] to merge code that I didn’t necessarily review with a level of detail that I normally do or should have. I’ve seen horror stories of people merging code they don’t fully understand or haven’t even tested themselves. At the end of the day, we’re all human. We are driven by incentive. And if incentives are driving people to get PRs in, then we’re going to be in for a rude awakening. Rewards should be centered around producing value. elegant, well-factored, pragmatic system design and around clarity of test and evaluation

[08:44] harnesses. There’s just something that really grinds my gears about seeing a multi,000line PR. There’s no way in hell that a human can fully understand all the important bits of a change that big. It is our job as engineers to optimize for this new world, to decompose needs into its simplest chunks, which lends to understanding. understanding simpler code surfaces and controlling of our code bases. AI is supposed to have been eradicating jobs and engineers are supposed to be

[09:17] moving at the rate of token production. So there is a lot of pressure to be in producing more faster. What AI is really doing is producing more faster. More characters that eat more human time. I’ve seen this happen in the most mundane ways. You give someone 10 bullets of scope, a few user journeys, something intentionally lightweight, and they come back with a 20page document. Maybe it looks polished with fancy pros. But now I have to spend hours figuring out whether there’s any real thinking inside it. That is AI generated work in

[09:50] the worst sense. It does not clarify the problem. It expanded it. It took ambiguity that should have been resolved by the person doing the work and handed it back as a larger artifact for other stakeholders to do it. In code, a vague task becomes a large PR. A small feature becomes a pile of files. The output arrives with the shape of completion, but the real work has just moved to the reviewer. And that is the part that we need to be honest about. Generation is cheap, but evaluation is

[10:22] expensive. If AI produces more than humans can possibly evaluate, it has not accelerated the team. It has created a bottleneck. One thing that I find particularly annoying is Twitter. You’ve got all these self-proclaimed experts and clickbaiters summarizing some talk or promoting some truths that we’ve always known as if there’s some novel genius idea. The Ralph loop was one of those. It was made to sound like a novel agentic breakthrough when it’s just a while loop. Somehow we’ve

[10:54] completely forgotten that lines of code is a garbage metric for productivity. But then we decided that it’s different than deciding the engineer who burns the most tokens must be producing the most. We used to break a feature into small atomic pieces we could reason about. Small enough to hold in your head and actually review. Now we type two sentences and expect a whole not fully thought out feature set back in one shot without really understanding it what it is we’re asking for. The key point I want to highlight here is that we do not

[11:25] forget the ground truths we’ve always known. 60 years of software wisdom hasn’t been invalidated by AI. Composable code, good patterns, and solid practices remain essential. A friend recently challenged me on why I spend so much time thinking about guard rails for agents, coding conventions, architectural styles, and and constraints around how the system should be shaped. His question was basically what’s the point if the agent writes the code why should

[11:57] we care about what the code looks like and to an extent I agree there will eventually be a world where much implementmentation detail is completely abstracted away from humans that has been the soft the direction of software from the beginning we went from machine code to assembly which another of level of abstraction up got us to C then Java then languages like Ruby where the primary design goal was programmer happiness. Just like in languages, we built abstractions for garbage collection and manual pointers, AI is abstracting away the imperative bits. It does not remove

[12:31] the need to understand how a system comes together cohesively. This is why diagrams matter so much, not as decorative documentation after the fact, but as a way of making systems legible. When a agents can generate thousands of lines of implementation detail, humans need a compressed review surface. service boundaries, data flows, state transitions, and failure modes. A good diagram lets us see the shape of the system in a way code often obscures. We can leave the main process or workflow as the reviewable surface with

[13:03] implementation details pushed to the leaves. That is why I vouch for declarative code and architecture patterns that create layers humans can actually reason about. The goal is not just code generation. The goal is human knowledge, human understanding, and human review. We need to optimize for that human layer. Cognitive overhead is a tax every engineer has to pay before they can make a meaningful change. It is the time spent figuring out where code belongs, which pattern to follow, and what proper implementation actually

[13:36] means. AI does not remove this tax. Unless tamed, it exacerbates it. An agent can generate five plausible patterns in five different styles. And now the human reviewer has to reverse engineer not just the code but the intent behind it with proper conventions intent is more easily gropped. The answer to this is conventions standards documented flows small reviewable surfaces and clear ownership boundaries and definitions of done. The more obvious the path, the less room

[14:09] there is for slop to hide. I want to give special recognition here to Rails and its place in my heart. Rails matters here because it shows what happens when a framework aggressively reduces decision surface. When conventions reduce your overhead rather than ending up with 10 different ways to structure the same concept, you end up with one. It may not be perfect in everyone’s subjective opinion, but it’s understood and it works. In my career, between my

[14:40] first and second 4A with Rails, I had a gap of four years. It was beautiful to come back after that gap to see that the same patterns in de facto libraries were still the same patterns and de facto libraries. I could hop right back into a codebase and immediately understand intent without needing to parse through architecture. It allows engineers to easily move between projects laterally with minimal ramp up. The same can’t be said about other language ecosystems. JavaScript environments with a single correct way

[15:15] of doing things are superior for agentic development because agents aren’t confused by dozens of competing approaches. This is well supported by the official Rails doctrine. It explicitly names optimize for programmer happiness and convention over configuration as core pillars and describes convention as a way to eliminate recurring decisions and lowering the barrier to getting started. It is the reduction of cognitive overhead. Everything I’ve talked about today is

[15:46] what led us to build ORC. Not only because we think the answer, not only because we think the answer is more agents and definitely not because we think engineering judgment can be automated away. We built ORC because we kept seeing the same failure pattern. AI could generate code but the surrounding discipline was still missing. The planning, the review, the adversarial checks, the context management. Over time, we found ourselves repeating the same human processes to fight slop. break down the work, manage context,

[16:16] weigh out your options, and make sure the output enters the codebase in the way the team can still reason about. ORC is taking those lessons and baking them into the workflow. It is not a magic box that makes correctness disappear as a human responsibility. It is a system for preserving that responsibility while letting agents do more of the lift. The goal is not to ship more generated code. The goal is to ship software that is still coherent, tested, maintainable, and owned after the generation happens. Because the

[16:48] future is not vibe coding better, faster. The future is orchestration with judgment. Thank you all for your time and remember, don’t get sloppy. >> [music]