Série: Aprendendo a Programar com IA

282 Commits, Primeiro Fim de Semana no Diário Público

282 commits do primeiro fim de semana: loop principal, rastreador de latência e a API C.

282 Commits, Primeiro Fim de Semana O loop: registrar, pegar, rascunhar, revisar, mesclar - depois reabastecer Registrar issuesdelimitadas com precisão Agente pegaabre PR de rascunho Revisãohumana, nos dois dias Mesclar / re-registrarrefinar se errado reabastecer a fila = o gargalo O que entrou: loop principal - rastreador de latência - API C - harness de teste - verificação de ABI 282 commits a maioria escrita por um agente de codificação autônomo
Os agentes não têm um emprego diurno - a produção é o que sobra de uma fila rodando continuamente.

A API C foi o commit que importou: o momento em que o runtime teve uma superfície pública estável, dois fluxos de trabalho escrito por agentes pararam de tropeçar um no outro. É assim que um runtime nativo de IA se parece quando o loop encaixa.

No sábado passado registrei uma pilha de issues e apontei um agente de codificação autônomo para a fila. Até o domingo à noite, sentado à mesa da cozinha com o laptop aberto uma última vez antes de segunda-feira, 282 commits tinham entrado no repositório do runtime. Fui o autor de uma pequena fração deles. Um agente de codificação autônomo foi o autor da maior parte do resto.

A razão de a contagem parecer uma semana inteira de sprint é que o trabalho vem acontecendo continuamente enquanto não estou no teclado. Eu fico no teclado nos fins de semana. Os agentes não têm um emprego diurno. A produção é o que sobra desse arranjo.

Como a fila funciona

Sábado de manhã é dia de registro. Sento com um café e escrevo issues no GitHub. Cada uma é um pedaço de trabalho delimitado com precisão que o motor precisa em seguida. O formato é aproximadamente:

  • Um subsistema ou uma funcionalidade por issue
  • Um critério de aceitação claro que o agente consegue autoverificar
  • Ponteiros para a documentação relevante, a especificação, e quaisquer arquivos existentes que o trabalho deveria tocar
  • Uma etiqueta explícita de “agent-queue”

Também há um workflow noturno (issue #37 no repositório do runtime neste fim de semana) que garante que a fila nunca caia abaixo de quinze issues abertas para agentes. Se cair, o workflow rascunha tarefas de placeholder a partir do roadmap. O agente lê a fila, pega a próxima que consegue fazer, abre um PR de rascunho, itera, e eventualmente se marca como pronto para revisão.

De sábado para domingo eu reviso e mesclo. Onde o agente errou algo, fecho o PR, refino a issue, e registro de novo. Onde o agente acertou, o PR entra e a issue fecha. O ritmo é registrar no início do fim de semana, revisar ao longo dos dois dias, e deixar uma fila fresca para trás quando o laptop fecha no domingo à noite. O agente mói a fila enquanto estou de volta ao meu emprego diurno.

Esse é o fluxo de trabalho. Não é sutil. A razão de valer a pena registrar é que funciona.

O que foi construído

Os destaques dos 282 commits:

  • Um loop principal de runtime de verdade, não só um esqueleto
  • Um rastreador de latência que mede o tempo ponta a ponta, da entrada do sensor até a renderização
  • Um monitor de uso de memória com limites configuráveis e relatórios periódicos
  • Um subsistema de logging com níveis INFO / WARNING / ERROR, saídas em console e arquivo
  • Tratamento de erros com signal handlers para desligamento gracioso
  • Uma API C expondo o runtime para que o SDK possa se conectar a ele
  • Um sistema de gerenciamento de módulo/agente na API C para integração com o SDK
  • O modelo de concorrência do runtime: filas de tarefas e threads de trabalho
  • Um harness de teste abrangente
  • Verificação de ABI e validação de conexão com o SDK
  • Especificação de óculos inteligentes AR1+ finalizada como o alvo do produto

Nada disso é glamouroso. Tudo isso é o que um runtime de RA precisa antes de qualquer coisa interessante poder ser construída em cima.

O commit mais importante, em retrospecto, é a exposição da API C. No momento em que o runtime teve uma superfície pública estável à qual o SDK podia se conectar, o trabalho do runtime e o trabalho do SDK pararam de tropeçar um no outro. Antes desse commit, toda mudança em um repositório tinha que ser cuidadosamente sincronizada com o outro. Depois dele, eles se desacoplaram. Dois fluxos de trabalho escritos por agentes puderam rodar em paralelo sem produzir conflito de merge.

O que me surpreendeu

Três coisas.

O agente é mais rápido em infraestrutura chata do que eu teria sido. Telemetria, logging, tratamento de erros, harnesses de teste. São o tipo de tarefa em que um humano se distrai porque o trabalho não é glamouroso. O agente não se distrai. Ele simplesmente entrega o diff.

O agente é conservador em arquitetura. Dê a ele uma issue que diz “implementar um rastreador de latência que mede o tempo do sensor até a renderização”, e ele constrói exatamente isso. Não inventa uma metafísica sobre o que latência significa nem propõe um formato diferente para a API. Isso é bom. Arquitetura é o meu trabalho. Implementação é o trabalho do agente.

Reabastecer a fila é o gargalo. Quando o agente entrega quinze PRs em um dia e a fila fica vazia até a noite, a vazão deixa de ser sobre quão rápido o agente trabalha. Passa a ser sobre quão rápido eu consigo articular o próximo conjunto de tarefas. Isso remodelou as manhãs de sábado. A primeira hora é registro de issues.

O que quebrou

Duas coisas, nenhuma fatal.

O build do CMake quebrou duas vezes quando o agente entregou código que compilava isoladamente mas não se conectava com o resto do runtime. Nas duas vezes a correção foi a mesma: o agente ainda não tem visibilidade total sobre o grafo de link-time do projeto. A correção está no enquadramento da issue. De agora em diante, toda issue que toca uma biblioteca diz explicitamente quais outras bibliotecas se conectam a ela.

O harness de teste foi adicionado tarde nessa leva e imediatamente revelou quatro bugs em PRs anteriores que tinham passado nos testes manuais de fumaça mas falhavam no novo harness. A lição ali é a nada glamourosa: escreva os testes como parte da funcionalidade, não como um follow-up. O agente faz isso quando a issue manda. Não faz quando a issue não manda. Faça sempre mandar.

O que eu quero que parceiros e construtores saibam

O formato deste motor está sendo construído agora mesmo. Até o fim do próximo mês a maioria das decisões fundamentais estará definida. Se você está em um lab de modelos e tem opiniões sobre como a camada de IA deveria se conectar, esta é a janela em que opiniões são baratas de incorporar. Se você é um desenvolvedor pensando em integração com Unity ou Unreal, o SDK está sendo moldado neste fim de semana e os bindings refletem o que o runtime consegue fazer. Prefiro ouvir de você na semana seis do que na semana sessenta.

O repositório do runtime está aberto. O repositório do SDK está aberto. A fila de issues abertas está aberta. Assistir isso acontecer em tempo real é o ponto todo.

282 commits, primeiro fim de semana no diário público. Domingo no bolso. Segunda-feira a seguir.

Molde o runtime enquanto opiniões são baratas

As decisões fundamentais estão acontecendo agora mesmo, abertamente - se você constrói modelos ou constrói óculos, esta é a janela para se conectar.

← Todos os posts