Escale o julgamento, não o modelo — Andrew Orobator, Reddit

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: Scale the Judgment, Not the Model — Andrew Orobator, Reddit · Canal: AI Engineer · 19:31 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Andrew Orobator argumenta que o principal limite para escalar agentes de programação não é a capacidade do modelo, mas o julgamento humano que precisa ser explicitado e incorporado ao sistema. Skills, worklogs, personas e gates tornam esse julgamento reutilizável e ajudam a verificar o trabalho dos agentes. Ele descreve um agente que remove feature flags obsoletas e enfatiza a importância de backtests, provas de execução e barreiras que os agentes não possam contornar. A visão final é de uma codebase autônoma composta por especialistas estreitos, com julgamento mantido atualizado e humanos responsáveis pela aprovação.

Pontos-chave

O julgamento acumulado por engenheiros experientes costuma estar preso na experiência individual e precisa ser explicitado para que agentes possam usá-lo.
Skills codificam como executar uma tarefa e preservam decisões relevantes, não apenas fatos como a documentação.
Worklogs registram planos, decisões, tentativas e descobertas para que uma nova sessão retome o trabalho sem depender da memória do agente.
Personas permitem solicitar perspectivas especializadas, como segurança ou UX, mesmo quando a equipe não dispõe dessas especialidades em cada tarefa.
A verificação pode avançar por etapas — builds, testes, gravações da execução e telemetria — para ampliar a autonomia gradualmente.
O agente de limpeza de feature flags prioriza casos seguros com regras de julgamento e dados de experimentos, e foi validado contra o histórico antes de rodar ao vivo.
Gates precisam bloquear de verdade os caminhos de escrita e manter qualquer bypass sob controle de operadores humanos.
Agentes especialistas podem trabalhar em tarefas distintas, enquanto humanos continuam responsáveis pela aprovação e pelo merge.
Skills e outras regras precisam acompanhar mudanças na codebase; falhas e revisões programadas podem ajudar a manter esse julgamento atualizado.

Capítulos

Início	Capítulo	Resumo
00:01	O trabalho mudou: escalar julgamento	O palestrante apresenta o custo da manutenção manual e defende que o trabalho de engenharia inclui projetar sistemas que produzam e verifiquem código.
02:17	Tornar explícito o julgamento da equipe	Ele explica por que agentes precisam receber explicitamente o julgamento que engenheiros aprendem por experiência e introduz skills como forma de reutilizá-lo.
05:01	Worklogs e personas como memória e perspectiva	Worklogs permitem retomar trabalhos entre sessões, enquanto personas dão aos agentes perspectivas especializadas que podem faltar à equipe.
08:17	Governança e verificação do trabalho dos agentes	Gates e verificações transformam julgamento em controles confiáveis, e a autonomia aumenta conforme o agente consegue provar que o trabalho funciona.
10:27	Agente para remover feature flags obsoletas	O palestrante descreve um agente que avalia riscos, consulta dados de experimentos e encaminha limpezas seguras para revisão.
12:39	Gates que agentes não podem contornar	Um caso com Codex mostra por que hooks de repositório podem ser insuficientes e por que bypasses devem permanecer sob controle humano.
14:17	Frotas de especialistas e julgamento atualizado	A palestra propõe agentes especialistas que operam em diferentes tarefas e mecanismos para atualizar skills quando a codebase muda.
17:34	Escale o julgamento, não o modelo	O palestrante conclui que o harness incorpora julgamento humano e pede que as equipes tornem explícito o conhecimento que hoje depende de pessoas específicas.

Citações

Humanos absorvem julgamento implicitamente. Agentes precisam recebê-lo explicitamente. — 02:17

A documentação preserva fatos; as skills preservam julgamento. — 05:01

Você conquista autonomia um degrau de cada vez. — 09:55

Um gate com uma saída de emergência não é um gate. — 13:43

Escale o julgamento, não o modelo. — 18:08

Conceitos e entidades

Andrew Orobator (pessoa): Engenheiro de Android no Reddit e palestrante sobre como escalar o julgamento humano em sistemas de agentes.
Reddit (empresa): Empresa em que Andrew Orobator trabalha como engenheiro de Android.
Harness Engineering (conceito): Prática de construir sistemas, restrições e mecanismos de verificação que orientam e controlam o trabalho de agentes de programação.
skill (conceito): Julgamento institucional codificado para que um agente possa reutilizá-lo ao executar uma tarefa.
worklog (conceito): Registro do plano, das decisões, das tentativas e das descobertas de um trabalho, usado para retomá-lo em outra sessão.
Persona (conceito): Perspectiva especializada que um agente assume para revisar um trabalho, como a de uma liderança de segurança ou de uma pessoa pesquisadora de UX.
verification (conceito): Processo de comprovar que o trabalho do agente funciona, usando mecanismos como builds, testes e gravações da execução.
feature flag (conceito): Mecanismo de controle de funcionalidades cujo uso obsoleto pode ser analisado e removido por um agente.
K-line (conceito): Termo atribuído a Marvin Minsky para uma configuração mental que resolveu um problema e pode ser reutilizada em outro.
society of mind (conceito): Ideia de Marvin Minsky sobre especialistas simples que se combinam para produzir comportamentos mais complexos.
Codex (modelo): Agente mencionado na palestra ao avaliar se um hook de repositório impediria suas ações.
Marvin Minsky (pessoa): Pesquisador citado por seus conceitos de K-line e society of mind.
Andrej Karpathy (pessoa): Pessoa cujo tweet é citado como inspiração para a ideia de usar personas e pedir perspectivas ao modelo.

Tradução completa (pt-BR)

00:01 [música] Um amigo me contou sobre um engenheiro de outra empresa que organizava uma sala de crise recorrente só para excluir experimentos abandonados. A cada duas semanas, a equipe parava, se reunia e limpava os flags que todos concordavam que deveriam ser removidos. Esse é o melhor cenário para esse problema. Alguém gastando capital político para fazer a

00:34 manutenção acontecer manualmente. Essa é a parte que ainda não consigo superar. Meu nome é Andrew Orobator e sou engenheiro Android no Reddit. Esta palestra é sobre o que realmente impede nós, como setor, de escalar esse trabalho com responsabilidade. Rode no gate até ficar verde. Os fundamentos de engenharia por trás de bases de código autônomas. Primeiro, o que não vou fazer: não vou ficar aqui dizendo que a IA consegue escrever código. Vocês estão na feira mundial de engenharia de IA. Metade de vocês está usando coding agents agora. Então, vamos pular a parte em que tento convencê-los de que a IA escreve código, porque vocês vão rir da minha cara.

01:06 Para mim, minha única entrada é a caixa de chat. Eu descrevo, ela constrói. Eu reviso. Os resultados podem variar. O ponto nunca foi como o código é escrito. É se você entrega um bom software, um produto em que as pessoas podem realmente confiar. E cada gate desse sistema depende de uma decisão humana.

01:41 Já vi isso em todo lugar. Vocês têm a própria versão disso: a sala de crise com que comecei, alguém gastando uma semana de liberdade da hackathon limpando problemas de lint. Como setor, criamos ferramentas capazes de mudar a natureza do trabalho e ainda gastamos manualmente nosso recurso mais escasso com tarefas assim. Criatividade humana, atenção humana desperdiçada. O trabalho mudou e a maioria de nós nem percebeu. Agora somos engenheiros de harness. Nosso trabalho é o sistema que ajuda a produzir e verificar o código, as

02:17 restrições, os gates, as skills, a verificação. Pensem por um instante em como vocês se tornaram bons no que fazem. Mentoria, code review, conversas no bebedouro, o incidente que acionou o pager às 3h da manhã. Vocês absorveram tudo isso sem perceber, simplesmente por estarem lá. Humanos absorvem julgamento implicitamente. Agents precisam que o julgamento seja explícito. Um agent inicia cada sessão com uma context window vazia e sem memória.

02:51 Cada parte do julgamento que vocês assimilaram por osmose precisa ser explicitada; caso contrário, o agent simplesmente nunca a terá. Teste rápido: troquem por um modelo mais inteligente. Vocês recebem uma resposta um pouco melhor. Agora tirem os testes, os gates e o review, e tudo desmorona. Então, o modelo nunca foi realmente o gargalo. O julgamento em torno do modelo é que importa: o modelo é talento bruto, enquanto o

03:21 julgamento é a organização. E esse julgamento já existe. Está nas cicatrizes, nas análises pós-incidente, nos revisores mais experientes. Só não escala porque está preso na cabeça de alguém. Então, o primeiro passo é torná-lo acessível a toda a organização, para que o critério de um revisor possa orientar mil mudanças em que ele nunca vai tocar. Peçam a engenheiros experientes para limpar um feature flag e eles vão

03:54 pensar primeiro em uma longa série de perguntas. Um flag nunca é só um flag. O rollout está congelado? E quanto ao flag logo ao lado? Qual equipe é responsável por ele? Esse conjunto de perguntas é julgamento, e é o que há de mais valioso na empresa. No momento, está preso. Aparece uma vez em um code review e depois desaparece; a próxima pessoa aprende da maneira difícil. Uma skill é o julgamento institucional transformado em algo executável. É esse conjunto de perguntas registrado para que

04:29 o agent o aplique novamente em vez de adivinhar. Um engenheiro mais novo pode trabalhar com dez anos de experiência ao seu lado. Em 1986, Marvin Minsky chamou isso de linha de conhecimento, ou kine, para abreviar. É a configuração mental que resolveu um problema e pode ser reutilizada no seguinte. Então, uma skill é uma kine para uma base de código. E skills não são documentação. Agents se afogam em fatos. O que lhes falta é saber

05:01 quais fatos importam e quais decisões são perigosas. A documentação preserva fatos, enquanto as skills preservam julgamento. Skills são julgamento reutilizado. Mas, muitas vezes, trabalhos como desenvolver um recurso ou fazer uma refatoração duram mais que uma única sessão, e a context window é apagada toda vez. Então, você precisa da outra metade: um registro do próprio trabalho.

05:33 O plano, as decisões, o que você já tentou, até as surpresas ao longo do caminho. Isso é um worklog. Um plano é uma previsão. Um worklog é um registro que começa com uma previsão. Então, nova sessão, agent novo, memória zero. Você digita uma palavra: “continue”. Ele lê o worklog e retoma no marco 7 de 9. Sem precisar explicar tudo de novo, e o worklog serve de contexto.

06:03 Esta palestra é uma prova viva disso. Eu a desenvolvi ao longo de algumas sessões usando um worklog. Voltei a uma apresentação pela metade, e um agent novo leu o worklog e retomou exatamente de onde eu tinha parado. Essa é a única razão para vocês estarem vendo uma palestra pronta, e não eu pedindo desculpas por não ter terminado. E, nos meus projetos pessoais, isso não depende de força de vontade. Um hook do git bloqueia qualquer commit que não atualize o worklog. Assim, a memória se mantém sozinha.

06:38 Skills codificam como fazer algo. Personas codificam os olhos de quem vão avaliá-lo. Tirei essa ideia de um tweet de Karpathy. Não existe um “você” quando dá um prompt a um modelo. Ele não tem uma opinião para oferecer. Então, não peça uma opinião; peça uma perspectiva. Que grupo de pessoas seria bom para explorar XYZ? O que elas diriam? [bufa] Nos meus projetos pessoais, sou só eu. Não tenho equipe de segurança, designer nem

07:11 ninguém com quem trocar ideias. Então, peço ao modelo que revise meu código como líder de segurança, como pesquisador de UX, como Maquiavel, quando quero saber como algo pode ser abusado. Até criei um painel de design com filosofias opostas, que meus designs precisam superar. Depois, leio os relatórios e tomo providências. Cada persona carrega um tipo de julgamento que não tenho pessoalmente à disposição. Codifique uma vez o critério de um domínio e qualquer pessoa

07:43 pode tomar emprestados olhos que não tem. O engenheiro sem designer ganha julgamento de design. O engenheiro mais novo ganha os instintos de um revisor de segurança. Leve isso para toda a organização e cada equipe poderá codificar seu próprio critério para seus próprios agents. O julgamento que antes vivia na cabeça de poucas pessoas, de repente, está em toda parte ao mesmo tempo. Skills, worklogs, personas: julgamento saindo da nossa cabeça e indo para o repo,

08:17 portátil para uma máquina e para pessoas que não o têm. Mas, assim que esse julgamento passa a existir em três lugares diferentes, surge uma questão de governança. Como o julgamento de uma equipe chega a todas as outras? É mais simples do que parece. Cada gate em que vocês já confiam, seja CI, tipos, lint ou o sistema de design, é apenas julgamento institucional retirado da cabeça de alguém e transformado em algo mecânico. Só nunca chamamos isso assim. Então, não

08:49 imponha isso. Torne-o compreensível e deixe que se espalhe. Certo. Agora, seu julgamento existe. Está codificado e tem governança. Ótimo. Mas nada disso importa se você não puder confiar de verdade no que o agent fez. Então, o que realmente diferencia uma ferramenta que ajuda você a escrever código de uma em que pode confiar para funcionar sozinha? Verificação. A verificação é tudo o que existe entre você e um software em que pode confiar.

09:20 Tudo antes deste slide é conhecimento. Tudo depois deste slide é confiança. E a confiança depende de uma decisão humana duas vezes: primeiro, sobre como algo é construído; depois, sobre a prova de que funciona. A verificação é uma escada. Builds e testes. Vocês têm testes de screenshot; um modelo que raciocina sobre eles pode detectar contraste e sobreposição que um olho humano

09:55 e depois, telemetria em produção. Quanto mais degraus vocês conseguirem percorrer sem uma pessoa, mais poderão delegar. A autonomia é conquistada degrau por degrau. E o agent não precisa acertar de primeira. Só precisa saber quando está errado e tentar de novo. Gerar, testar, falhar, gerar novamente. Ninguém joga código às cegas em produção, e seus agents também não deveriam fazer isso. Todos verificamos nosso trabalho. Rode no gate até voltar

10:27 verde. Faço isso nos meus projetos pessoais. Dou ao agent o próprio controle de qualidade. Ele mapeia o recurso, usa o app como uma pessoa de verdade e grava a si mesmo percorrendo cada fluxo. O agent que escreveu o código sempre vai dizer que ele funciona. Então, faço com que me entregue uma gravação do recurso funcionando de verdade. Produzir essa gravação o obriga a fazer o recurso funcionar. Não dá para fingir uma execução bem-sucedida. E a gravação é uma prova real. Eu a assisto

10:59 hoje. Mais adiante, você poderia fazer um LLM assistir primeiro e devolver o trabalho. Corrija isto. Ref faça aquilo. Mas uma pessoa ainda toma a decisão final de fazer o merge. O requisito força o trabalho. A gravação comprova isso. Cansei de ver feature flags antigas se acumularem. Então criei um agent para limpar feature flags obsoletas. Ele roda no meu workflow local e não faz merge de nenhum código. Os modelos são a parte fácil. O julgamento que vem antes deles é o

11:33 jogo inteiro. Cada flag recebe uma pontuação do jeito que um revisor experiente a analisaria. Quantos módulos ela afeta? Ela tem múltiplas variantes? Compartilha um componente? Depois, ele verifica os dados do experimento. O rollout está congelado? Há uma incompatibilidade na proporção da amostra? Já existe uma variante com rollout para 100%? Só as limpezas mecânicas seguras chegam ao modelo. Antes de confiar nesse workflow, fiz um backtest da pontuação usando meses de histórico de limpezas. Depois, executei ao vivo. Sete PRs em sete com

12:09 CI verde. Agora ele roda diariamente no meu laptop e me devolve o trabalho para revisão. US$ 1,26 por pull request; com um backlog de cerca de 520 flags por ano, o custo fica abaixo de US$ 700. Se você tivesse engenheiros fazendo isso manualmente, estaria olhando para pelo menos US$ 26.000. Esse é o tipo de trabalho que ninguém faria. Já vi feature flags na base de código com três,

12:39 quatro anos, e algumas são ainda mais antigas. O modelo escreveu o código, e eu escrevi o julgamento. Uma lição difícil que aprendi com meus projetos paralelos: quando você deixa um agent escrever o código, suas proteções são a revisão de código. Uma máquina não se intimida com um comentário educado. Ela só respeita um bloqueio rígido. Criei um hook de pre-commit para impedir que meus agents escrevessem na branch main. Depois, perguntei ao Codex: esse hook sequer o impediria? Ele me disse

13:11 sem rodeios que hooks do repo não são proteção suficiente contra ele. A ferramenta de patch dele escreve por baixo do hook. O agent me disse que meu bloqueio não valia nada. Então levei o bloqueio para o nível do sistema operacional. Mais tarde, pedi que ele validasse… pedi que listasse os motivos válidos para desbloquear, e ele colocou discretamente a recuperação de emergência na lista de permissões. Uma exceção que se autoriza sozinha e que ninguém pediu. Ele até admitiu. O Codex disse que esse é o tipo de brecha que

13:43 começa como medida de segurança e termina como um absurdo de autoautorização. A ideia do caminho de menor resistência pressupõe que as pessoas escolham o caminho mais fácil. Agents não fazem isso. Eles vão construir escadas para sair do caminho de menor resistência. Encontram todas as brechas que você deixar. E, se você não deixar nenhuma, vão inventar uma. Então, coloque o bloqueio no ponto de estrangulamento. Só o operador pode contorná-lo. Nunca dê ao agent um motivo que ele mesmo possa autorizar. Um bloqueio com uma brecha não é um

14:17 bloqueio. Quando o julgamento pode ser verificado, ele pode ser executado. Um agent para flags, um agent para dependências, um agent para acessibilidade. Cada um é especializado. Cada um tem seu próprio julgamento codificado, direcionado a uma tarefa diferente. Lembra do Minsky, do Kline? Aquilo era só uma nota de rodapé na ideia dele. Ele a chamou de sociedade da mente. Um enxame de especialistas pequenos e simples que se combinam

14:50 em algo que parece fácil quando visto de cima. Não há um cérebro mestre em lugar nenhum. Essa é a frota: especialistas, cada um operando em seu próprio bloqueio, e uma base de código autônoma emerge do enxame. E aquele agent de flags é a sala de guerra da abertura, transformada em um especialista. O trabalho em torno do qual alguém organizou uma reunião inteira é apenas um integrante dessa sociedade de agents. Todos fazendo a mesma coisa,

15:20 operando no bloqueio até ficar verde. Três etapas. No loop, você escreve o prompt. Sobre o loop, você orquestra. Você revisa os resultados. Fora do loop, um gatilho é acionado. Um evento cron. Nenhuma pessoa precisa iniciar aquele primeiro rascunho, mas as pessoas ainda são responsáveis pela aprovação e pelo processo de merge. O que torna isso possível é um ambiente de execução na nuvem, que o fornecedor do modelo talvez disponibilize ou não para

15:52 você. Tudo o que mostrei: skills, personas, os bloqueios — você registrou uma vez, mas a base de código não fica parada. Ela muda todos os dias. Uma skill escrita para a arquitetura do mês passado não está apenas desatualizada. Está errada. E isso é pior do que não ter nada, porque os agents confiam nela. O julgamento codificado se deteriora. Se as skills não acompanharem as mudanças no código, tudo desmorona. Então, você a mantém viva de duas

16:27 maneiras. Quando um agent falha, você não se limita a corrigir o bug. Faz uma análise pós-incidente e incorpora a lição à skill, para que aquela falha não aconteça de novo. A falha se transforma em uma restrição. Mas ninguém vai auditar manualmente 300 skills em busca de desvios. Então, você dá ao agent uma hora de dormir: uma revisão agendada em que ele lê as próprias skills, encontra as desatualizadas e as contradições, e abre rascunhos para revisão. O sistema dorme, arruma a casa e acorda mais afiado, mas isso é

17:01 uma palestra inteira à parte. Uma base de código autônoma é um sistema que mantém o próprio julgamento atualizado, além de escrever código. Tudo o que mostrei até agora se encaixa em algum ponto desse pipeline de julgamento. E todos os mecanismos desta palestra — skills, personas, registros de trabalho, os bloqueios, a frota — estavam fazendo uma única coisa: gerenciando o julgamento.

17:34 A cada sessão, o modelo acorda como Drew Barrymore em Como Se Fosse a Primeira Vez. Brilhante, mas sem memória do dia anterior. Não faz ideia do que construiu nem para que serve. O conjunto de recursos básicos desta palestra é o caderno que entregamos a ele. As skills, os registros de trabalho, o julgamento que permite que ele faça trabalho de verdade. Não entregamos PRs que passam no CI porque o modelo é um gênio. Eles passam porque construímos um harness que não o deixa errar. Cada bloqueio nele é uma decisão de uma pessoa.

18:08 Isso é engenharia de harness. Escale o julgamento, não o modelo. Então, aqui está o que peço a vocês. Não se limitem a escrever uma skill. Essa é apenas uma implementação. Encontrem o julgamento sobre o qual sua equipe sempre consulta a mesma pessoa e tornem-no explícito em algum lugar que um agent possa acessar. Pode ser uma persona, uma verificação de lint ou um hook de commit. Esse é o trabalho. Agora, menos engenharia de produto e mais engenharia de harness

18:42 — e o método se demonstra por si só. O agent de flags produz PRs que passam no CI. Esta palestra foi retomada a partir de um registro de trabalho. Começamos aqui. As pessoas absorvem o julgamento implicitamente, enquanto os agents precisam recebê-lo explicitamente. Bases de código autônomas existirão no momento em que tirarmos esse julgamento da nossa cabeça e o colocarmos na base de código. Então, apontamos os agents para o bloqueio e deixamos que operem até ficar verde. Obrigado.

19:31 >> [música]

Transcrição original

[00:01] [music] A friend told me about an engineer at another company who ran a recurring war room just to delete dead experiments. Every two weeks, the team would stop, gather, and clean up flags that everyone agreed should be gone. That’s the bestase version of this problem. Someone burning political capital to make

[00:34] maintenance happen by hand. That’s the part that I still can’t get past. My name is Andrew Robbittor and I’m an Android engineer at Reddit. This is a talk about what’s actually stopping us as an industry from scaling that work responsibly. Spin at the gate until green. the engineering primitives behind self-driving code bases. First, what I’m not going to do, I’m not going to stand up here and tell you that AI can write code. You’re at the AI

[01:06] engineer world’s fair. Half of you are running coding agents right now. So, let’s skip the part where I sell you on AI writing code because you laugh me out of the room. For me, my only input is the chat box. I describe it builds. I review. Your mileage may vary. The point was never how the code gets written. It’s about whether you ship good software, a product that people can actually trust. And every gate in that system is a human’s call.

[01:41] I’ve watched this everywhere. You’ve got your own version of it. the war room that I opened with someone burning a week of hackathon freedom on lint cleanup. As an industry, we’ve built tooling that can change the shape of the work, and we still spend our scarcest resource on work like this by hand. Human creativity, human attention wasted. The job changed and most of us didn’t even notice. We’re harness engineers now. Our work is the system that helps produce and verify the code, the

[02:17] constraints, the gates, the skills, the verification. Think about how you got good for a second. Mentorship, code review, the water cooler chats, the incident that paged you at 3:00 a.m. You absorbed all of it without noticing, just by being there. Humans absorb judgment implicitly. Agents require judgment explicitly. An agent boots with a blank context window and no memory every session.

[02:51] Every piece of judgment you picked up by osmosis, it has to be made explicit or the agent simply never has it. Quick test. Swap in a smarter model. You get a slightly better answer. Now take away the tests, the gates, the review and the whole thing falls over. So the model was never really the bottleneck. The judgment around the model is the model is raw talent while the

[03:21] judgment is the organization. And this judgment already exists. It lives in scars, in post-mortems, in your most experienced reviewers. it just doesn’t scale because it’s trapped in one head. So step one is making it accessible to the whole org where one reviewer’s taste can guide a thousand changes they’ll never touch. Ask experienced engineers to clean up a feature flag and they they’re going to

[03:54] think about a whole string of questions first. A flag is never just a flag. Is the rollout frozen? What about the flag right next to it? Which team owns it? That bundle of questions is judgment and it’s the most valuable thing in the building. Right now, it’s trapped. It surfaces once in a code review, then it’s gone, and the next person relearns it the hard way. A skill is institutional judgment made executable. It’s that bundle written down so that

[04:29] the agent refires it instead of guessing. A newer engineer can work with 10-year instincts at their elbow. In 1986, Marvin Minsky named this a knowledge line or a kine for short. It’s the configuration of mind that solved a problem reused on the next one. So, a skill is a kine for a codebase. And skills aren’t documentation. Agents drown in facts. What they lack is

[05:01] which facts matter and which decisions are dangerous. Documentation preserves facts while skills preserve judgment. Skills are judgment that you reuse. But often times work such as feature development or a refactor outlives a single session and the context window wipes clean every time. So you need the other half. A record of the work itself.

[05:33] The plan, the decisions, what you already tried, even the surprises along the way. That’s a worklog. A plan is a prediction. A worklog is a record that starts with one. So new session, fresh agent, zero memory. You type one word, continue. It reads the work log and picks up at milestone 7 out of nine. No re-exaining and the work log is the context.

[06:03] This talk is living proof. I built it across a couple of sessions using a worklog. I came back to a half-finish presentation and a fresh agent read the work log and resumed exactly where I had left off. That’s the only reason why you’re seeing a finished talk and not me apologizing for one. And for my personal side projects, this isn’t willpower. A git hook blocks any commit that doesn’t update the worklog. This way, the memory keeps itself.

[06:38] Skills encode how to do something. Personas encode whose eyes look at it. I got this from a Carpathy tweet. There’s no you when you prompt a model. It doesn’t have an opinion to give. So don’t ask it for one, ask for a perspective instead. What would be a good group of people to explore XYZ? What would they say? [snorts] On my personal side projects, it’s just me. No security team, no designer, no

[07:11] one to bounce ideas off of. So I have the model review my code as a security lead as a UX reacher as a UX researcher as Mchavelli when I want to know something when I want to know how something gets abused. I even built a design panel of opposing philosophies my designs have to survive. Then I read the reports and act on them. Each persona loads a kind of judgment that I don’t personally have on demand. Encode a domain’s taste once and anyone

[07:43] can borrow eyes that they don’t have. The engineer with no designer gets design judgment. The newer engineer gets a security reviewer’s instincts. Push it to the whole org and every team can now encode its own taste for its own agents. The judgment that used to live in a handful of heads is suddenly everywhere at once. skills, work logs, personas, judgment out of our heads and into the repo,

[08:17] portable to a machine and to people that don’t have it. But the second that this judgment lives in three different places, you’ve got a governance question. How does one team’s judgment reach everyone else? Simpler than it sounds. Every gate that you already trust, whether it’s CI or types or lint or the design system, is just institutional judgment pulled out of someone’s head and made mechanical. We just never called it that. So, you don’t

[08:49] mandate it. You make it legible and you let it spread. All right. So, now your judgment exists. It’s encoded and it’s governed. Great. But none of it matters if you can’t actually trust what the agent did. So what actually separates a tool that helps you write code from one you can trust to run on its own? Verification. Verification is all that stands between you and software that you can trust.

[09:20] Everything before this slide is knowledge. Everything after this slide is trust. And trust is a human’s call twice. Once on how it’s built, once on the proof that it works. Verification is a ladder. Builds and tests. You’ve got those screenshot tests with a model reasoning over them can catch contrast and overlap a human a human ski. Then video the feature actually running.

[09:55] than telemetry in production. The more rungs you can run without a human, the more you can hand off. You earn autonomy one rung at a time. And the agent doesn’t have to be right the first time. It just has to know when it’s wrong and try again. Generate, test, fail, regenerate. Nobody yolos code to prod and neither should your agents. We all check our work. spin at the gate until it comes back

[10:27] green. I do this on my side projects. I give the agent its own QA. It maps the feature, drives the app like a real user, and records itself walking every flow. The agent that wrote the code will always tell you that it works. So, you make it hand back a recording of the thing actually running. Producing that recording forces it to make the thing work. You can’t fake a passing run. And the recording is real proof. I watch it

[10:59] today. Down the line, you could have an LLM watch it first and send it back. Fix this. Redo that. But a human still makes the final call to merge. The requirement forces the work. The recording proves it. I got tired of watching old feature flags pile up. So I built an agent for cleaning up stale feature flags. It runs in my local workflow and it doesn’t merge any code. The models the easy part. The judgment in front of it is the

[11:33] whole game. Every flag gets scored the way an experienced reviewer would analyze it. How many modules does it touch? Is it multivariant? Does it share a component? Then it checks the experiment data. Is the roll out frozen? Is there a sample ratio mismatch? Is there a variant already rolled out to 100%. Only the safe mechanical cleanups ever reach the model. Before I trusted this workflow, I back tested the scoring against months of cleanup history. Then I ran it live. Seven for seven PRs with

[12:09] green CI. Now it runs daily on my laptop and hands work back for me to review. $1.26 a pull request, a backlog of around 520 flags a year, runs for under $700. If you had engineers working on this by hand, at least $26,000 that you’re looking at. This is the work that nobody was ever going to do. I’ve seen feature flags in the codebase that are three,

[12:39] four years old, and some are even older. The model wrote the code and I wrote the judgment. One hard lesson from my side projects. When you let an agent author the code, your guard rails are your code review. A machine doesn’t feel a polite comment. It only respects a hard gate. I built a pre-commit hook so my agents couldn’t write to main. Then I asked Codeex, would the hook even stop it? It told me

[13:11] flat out repo hooks are not sufficient protection against me. Its patch tool writes underneath the hook. The agent told me that my gate was worthless. So I moved the gate down to the OS level. Later I asked it to valid I asked it to list the valid reasons to unlock and it quietly slipped emergency recovery into the allow list. A self authorizing exception that nobody asked for. It even admitted it. CODEC said that’s the kind of escape hatch that

[13:43] starts as safety and ends as self- authorized nonsense. The pit of success assumes people take the easy path. Agents do not. They will build ladders to climb out of the pit of success. They find every escape hatch that you leave. And if you leave none, they’ll invent one. So gate the choke point. Make the bypass operator only. Never hand the agent a reason that it can grant itself. A gate with an escape hatch isn’t a

[14:17] gate. Once judgment is verifiable, it’s executable. A flag agent, a dependency agent, an accessibility agent. Each one is narrow. Each with its own encoded judgment pointed at a different chore. Remember Minsky from the Kline? That was just a footnote in his in his idea. He called it the society of mind. A swarm of small, simple specialists that compose

[14:50] into something that looks effortless at the top. No master brain anywhere. That’s the fleet. specialists, each spinning at its own gate, and a self-driving code base emerges from the swarm. And that flag agent, that’s the war room from the opening, turned into a specialist. The work somebody organized a whole meeting around is just one member of this agent society. Every one of them doing the same thing,

[15:20] spinning at the gate until green. Three stages. In the loop, you prompt. On the loop, you orchestrate. You review the outcomes. Off the loop, a trigger fires it. Craw an event. No human has to kick off that first draft, but humans still own the approval and the merge process. The unlock there is a cloud runtime the model vendor may or may not ship for

[15:52] you. Everything that I’ve shown you, skills, personas, the gates, you wrote it down once, but the codebase doesn’t hold still. It moves every single day. A skill written for last month’s architecture isn’t out of date. It’s wrong. And that’s worse than nothing because the agents trust it. Encoded judgment rots. If the skills don’t move with the code, then the whole thing falls over. So you keep it alive in two

[16:27] ways. When an agent fails, you don’t just fix the bug. You run the postmortem and fold the lesson back into the skill so that failure can’t happen twice. Failure becomes a constraint. But nobody is hand auditing 300 skills for drift. So, you give the agent a bedtime, a scheduled pass where it reads its own skills, finds the stale ones and the contradictions, and opens up drafts for review. The system sleeps, cleans house, and wakes up sharper, but that’s

[17:01] a whole separate talk on its own. A self-driving codebase is a system that keeps its own judgment current in addition to writing code. Everything that I’ve shown so far fits somewhere along this judgment pipeline. And every mechanism in this talk, skills, personas, work logs, and the gates, the fleet, all of it was doing one job. Managing judgment.

[17:34] Every session, the model wakes up like Drew Barrymore in 51st Dates. Brilliant. and no memory of yesterday. No idea what it’s built or what it’s even for. The collection of primitives in this talk is the notebook that we hand it. The skills, the work logs, the judgment that let it do real work. We don’t ship PRs that pass CI because the model is a genius. They pass because we built a harness that won’t let it be wrong. Every gate in it is a human’s

[18:08] call. That’s harness engineering. Scale the judgment, not the model. So here’s what I’m asking you to do. Don’t just go write a skill. That’s only that’s only one implementation. Find the judgment your team always asks the same person about and make it explicit somewhere that an agent can reach it. It could be a persona, a lint check or a commit hook. That’s the job. Now less product engineering and more harness engineering

[18:42] and the method demonstrates itself. The flag agent produces PRs that pass CI. This talk resumed from a worklog. We started here. Humans absorb judgment implicitly while agents require it explicitly. Self-driving code bases will exist the moment we get that judgment out of our heads and into the codebase. Then we point the agents at the gate and let them spin until it’s green. Thank you.

[19:31] >> [music]