De escrever código a escrever empresas

Antes de 2025, construir software significava escrever código. Você abria o editor, digitava funções, corrigia bugs, fazia commits. O ciclo de feedback era curto e o trabalho, profundamente manual. Se você queria algo construído, ou construía por conta própria ou explicava para outro engenheiro, que então escrevia o código por você.

Esse mundo acabou. Não do jeito que as pessoas previam, com a IA corroendo aos poucos as bordas da produtividade. Acabou no sentido de que toda a definição do que significa “construir” está sendo reconstruída do zero, uma camada de abstração por vez, em um ritmo difícil de acompanhar.

Pensando em camadas de abstração, eu conto cinco:

1. Escrever código: o humano escreve cada linha
2. Descrever mudanças: o humano diz ao agente o que mudar e revisa o resultado
3. Harness Programming: os agentes escrevem 100% do código
4. A organização: metas, papéis, intenção. O código é invisível. Os humanos são o conselho
5. Metaorganizações: construir muitas empresas, empresas que constroem empresas

Cada camada faz a mesma coisa: afasta os humanos da implementação e os aproxima da intenção. Cada uma parece radical quando você a encontra pela primeira vez e óbvia em retrospecto.

Vou percorrer cada uma delas.

Camada 1: escrever código

Foi aqui que a maioria de nós começou. Você pensa no que precisa acontecer, traduz isso em código, executa, depura e entrega. Todo o peso criativo e mecânico fica nas suas costas.

Você é ao mesmo tempo o arquiteto e o pedreiro.

Grande parte da história da engenharia de software está aqui. Décadas de ferramentas, linguagens, frameworks e práticas, todos criados para tornar esse ciclo mais rápido. Controle de versão, linters, sistemas de tipos, CI/CD. Tudo construído para ajudar os humanos a escrever código melhor.

Achávamos isso divertido.

Camada 2: descrever mudanças

Então chegaram o Claude Code, o Codex e ferramentas parecidas. De repente, você podia descrever o que queria mudar e um agente escrevia o código por você. Não com perfeição, mas bem o bastante para que seu trabalho passasse de escrever para revisar.

É aqui que está a maioria dos engenheiros hoje. Você abre um ticket no Linear ou uma thread no Slack, descreve o que quer, e o agente produz um diff. Você revisa. Você questiona. Você conduz. Talvez diga “não, use este padrão” ou “o tratamento de erros deveria funcionar de outro jeito aqui”. O agente itera e, por fim, você aprova.

Antes

“Vou escrever o middleware de autenticação, tratar os casos extremos, adicionar testes e abrir um PR.”

Agora

“Adicione um middleware de autenticação que valide tokens JWT. Trate tokens expirados com elegância. Cubra os casos extremos nos testes.”

Você escreve código mais rápido do que nunca. Mas ainda está profundamente envolvido no nível do código. Ainda revisa diffs, ainda se importa com padrões de arquitetura, ainda aplica julgamento e bom gosto.

Você sente, com razão, que essas coisas importam para o sucesso do seu produto.

A mudança-chave aqui é sutil: você passou de escrever código para definir o trabalho.

Mas você ainda olha para o código.

Camada 3: Harness Programming

Algumas equipes foram além. O objetivo é deixar os agentes escreverem 100% do código. Não 80%, não “a maior parte”. Tudo. Essa abordagem foi chamada de Harness Programming ou Harness Engineering, termo consolidado pela OpenAI em seu relato detalhado sobre a construção de uma base de código de um milhão de linhas sem nenhum código digitado manualmente.

Em um experimento interno de cinco meses, uma pequena equipe de engenheiros guiou agentes do Codex por pull requests e fluxos de CI. Os agentes escreveram tudo: lógica de aplicação, testes, configuração de CI, documentação, observabilidade e ferramentas. Os humanos não escreveram nenhuma linha de código. A principal função deles passou a ser permitir que os agentes fizessem um trabalho útil: projetar as restrições, codificar “princípios de ouro” no repositório e construir os ciclos de feedback que mantinham os agentes no caminho certo.

Nesse modelo, você não olha mais para arquivos e diffs individuais. Você usa o Claude Code ou o Codex como interface principal. Você conduz o agente por instruções de nível mais alto. Você está no ciclo e pode intervir, mas sua relação com o código em si está se tornando indireta.

A pergunta natural seguinte: se os agentes fazem todo o trabalho, por que você ainda o distribui manualmente? Por que continua no Claude Code, passando tarefas uma a uma?

O Symphony, da OpenAI, é uma resposta a isso.

Ele se baseia nas mesmas ideias do loop Ralph Wiggum e é, basicamente, um serviço de longa duração que lê tickets do Linear, cria um workspace isolado para cada issue e executa um agente de código dentro dele. Você aponta o serviço para um projeto, dá a ele alguns agentes, e ele começa a processar o backlog. Os agentes abrem PRs, revisam o trabalho uns dos outros e fazem o merge quando o CI passa.

O Symphony continua sendo Harness Engineering em sua essência: é centrado no repositório, delimitado por ticket e focado em implementação. Mas ele automatiza a distribuição. Em vez de você acompanhar cada sessão de agente, o sistema pega o trabalho e segue com ele. O que chama atenção no repositório do Symphony é que ele quase não é uma implementação de código. É mais uma especificação, com forte incentivo para que você implemente a sua própria versão.

Eles não se importam com o código que o executa. Eles se importam com as ideias.

O insight decisivo aqui: as guardrails são tudo. Quanto mais rígido você for sobre o que os agentes podem fazer, quais padrões seguem e a quais regras de lint e de teste obedecem, melhor isso funciona. Sem limites estritos, os agentes se desviam. Fazem o que querem. Perdem o contato com a realidade. E aí você tem um projeto de refatoração nas mãos. Regras estritas de lint, formatação e testes, facilmente acessíveis a cada agente, são o que mantém todo o sistema com os pés no chão.

Isso também significa que é surpreendentemente difícil aplicar essa abordagem a um projeto brownfield, porque os agentes precisam dessas guardrails rígidas, e nós, humanos, temos a tendência de deixá-las de fora.

Camada 4: a organização

A Camada 4 é um grande salto.

Nas Camadas 1 a 3, os humanos ainda pensam em código, mesmo que não o escrevam nem o leiam mais. Os tickets são delimitados pela implementação. O trabalho é definido em termos de repositórios, endpoints e módulos. A abstração mudou, mas o modelo mental não.

Nesta camada, você para de pensar em código por completo. Não só deixa de lê-lo, mas deixa de delimitar o trabalho em torno dele. Em vez de descrever o que o código deve fazer, você descreve o que quer que seja verdade. Não “implemente um limitador de taxa na API”, mas “os usuários nunca devem conseguir sobrecarregar o sistema”. Não um ticket, mas uma intenção.

Thomas Dohmke, que foi CEO do GitHub até agosto de 2025, saiu para criar uma nova empresa chamada Entire, com US$ 60 milhões em capital semente. Sua tese: o GitHub foi criado para a colaboração entre humanos em torno do código, mas em um mundo em que as máquinas são as principais produtoras de código, o código em si deixa de ser o artefato mais importante. O que importa é o raciocínio, as especificações e a intenção que o produziram. Nas palavras dele, estamos caminhando para “uma abstração muito mais alta, que são especificações, raciocínio, logs de sessão, intenção, resultados”.

Nunca especificamos o código. Especificamos como gostaríamos que o mundo fosse. Se algo estiver fora do lugar, vemos no nível da aplicação e criamos novo trabalho. Nunca tocamos no código.

Mas capturar a intenção não é só uma mudança de ferramentas. É uma mudança organizacional. Quando você para de pensar em código, passa a pensar em papéis, responsabilidades, metas e responsabilização. Quem define o que o produto deve ser? Quem decide as prioridades? Quem revisa os resultados? São questões organizacionais, não de engenharia.

A estrutura natural que surge se parece com uma empresa. Você define um objetivo de alto nível: “construir o melhor boilerplate serverless open source de Python na AWS”. Você nomeia um agente CEO, dá a ele a missão e a visão, e deixa que execute. O CEO contrata um engenheiro fundador. O engenheiro contrata juniores. O CEO traz um gerente de produto e um profissional de marketing. Eles começam a construir em público, escrevendo posts de blog, entregando código, iterando a partir do feedback.

Ferramentas como o Paperclip tornam isso concreto: você define uma empresa com organograma, atribui papéis a agentes, estabelece metas e orçamentos, e deixa o organismo funcionar.

Você atua como o conselho: aprova contratações, revisa a estratégia e anula decisões quando necessário.

Essas organizações não são estáticas.

Elas aprendem. Descobrem o que funcionou e o que não funcionou. Se adaptam. Talvez em algum momento o CEO decida que a equipe precisa de mais gente, ou que alguém está com desempenho abaixo do esperado e deve ser substituído. É assim que as organizações reais funcionam. A estrutura é viva.

Como humanos, atuamos como o conselho. Ainda podemos conduzir. Há coisas que exigem nossa aprovação, e podemos orientar o CEO a qualquer momento.

“Acho que você deveria focar nesta oportunidade.”

“Demita esta pessoa.”

“A estratégia está errada; mude de rumo.”

O CEO recebe a instrução e delega ao restante da organização.

Nunca mais gerenciamos itens de trabalho individuais.

Camada 5: metaorganizações

E é aqui que a curva vira vertical.

Se você consegue construir uma organização e supervisioná-la como um conselho, consegue construir dez. Pode ter empresas que constroem empresas. Empresas que constroem modelos para outras empresas. Um portfólio de organizações autônomas, cada uma perseguindo sua própria missão, cada uma com seu próprio agente CEO, cada uma crescendo e se adaptando.

Um conselho pode supervisionar muitas empresas. Afinal, é isso que os conselhos fazem.

Esta é a camada que menos entendemos. Já temos as primitivas, e ferramentas como o Paperclip já suportam várias empresas em um único deploy, com isolamento completo de dados. O conceito de modelos de empresa para download, estruturas organizacionais prontas que você pode importar e executar, está no roadmap.

Mas o que acontece quando uma organização consegue criar novas organizações para resolver subproblemas? Quando uma empresa pode criar uma subsidiária, equipá-la com agentes, dar a ela um orçamento e uma missão, e deixar que funcione? Quando a própria metaorganização começa a tomar decisões sobre quais empresas financiar, quais encerrar e quais fundir?

Ainda não sabemos. Esta é a fronteira.

O ritmo

Entre 2010 e 2016, a comunidade JavaScript passou por um período às vezes chamado de guerra dos frameworks. React, Angular, Ember, Backbone, Vue, cada um ganhando popularidade, cada um disputando a hegemonia. Foi um período volátil. Era preciso aprender um novo framework por ano, às vezes a cada poucos meses. Meta, Google e equipes menores competiram para definir o futuro do desenvolvimento frontend.

Essa guerra durou cerca de seis anos.

O ritmo da mudança

Linha do tempo das camadas de IA:

• Jan 2026: o OpenClaw é lançado. Torna-se o padrão para executar agentes dedicados. O projeto de crescimento mais rápido da história do GitHub.
• Fev 2026: a OpenAI adquire o OpenClaw.
• Fev 2026: a OpenAI publica Harness Engineering. Um milhão de linhas de código, nenhuma digitada manualmente.
• Fev 2026: Entire é lançada. O ex-CEO do GitHub aposta US$ 60 milhões que a intenção, e não o código, é a nova primitiva.
• Mar 2026: Symphony é lançado. Distribuição automatizada de tickets para agentes via Linear.
• Mar 2026: Paperclip é lançado. Agentes CEO, organogramas, orçamentos, governança. Empresas como organismos.

Comparação

1. Guerra do JS: ~6 anos
2. Camadas de IA: ~semanas

Tudo o que descrevi, do OpenClaw ao Harness Engineering, ao Symphony e ao Paperclip, foi lançado em questão de poucas semanas.

E eis o que acontece com as camadas de abstração: quanto mais você sobe, maior a velocidade de iteração. Se os agentes agora conseguem construir empresas que, por sua vez, sobem a camada de abstração, o progresso se acumula. Cada camada acelera a descoberta da próxima.

Você pode acreditar na singularidade, na AGI ou em qualquer uma das grandes narrativas, mas é importante reconhecer que isso não está acontecendo em uma escala de anos.

Está acontecendo em semanas e meses.

O que isso significa para nós

Um pequeno grupo de pessoas vai se beneficiar primeiro. Isso vale para toda mudança tecnológica. Mas eu não acredito na subclasse permanente. Acredito que todos terão espaço para prosperar neste novo mundo, independentemente de quando ou onde escolheram participar, ou mesmo se escolherem não participar.

Minha esperança é que os humanos possam se concentrar no que nos torna humanos. O trabalho criativo. O tempo com amigos e família. As relações e experiências que realmente importam. Se os agentes fazem a maior parte da implementação, talvez o trabalho e o dinheiro deixem de ser os marcadores de status que sempre foram.

Seremos o conselho, não os pedreiros.

Vamos ver no que isso dá.