No mundo moderno, não existe nada pior do que ficar defasado — e pior ainda é ficar travado por causa de opinião sem embasamento. Obviamente, eu também dou opiniões, pelo menos o suficiente para produzir posts como:

• Antes de ter filhos: reflexões sobre educação e responsabilidade
• Brasil, polarização política e tribalismo

E alguns outros que ainda pretendo postar.

Uma coisa em que tenho pensado é o hype da IA e o novo modelo de desenvolvimento baseado no método Ralph Wiggum.

Para contextualizar: eu assistia a alguns vídeos no FreeTube — o melhor frontend para YouTube que conheço — quando reencontrei um vídeo sobre esse modelo de desenvolvimento. Como já havia instalado o Omarchy, do DHH, e testado o OpenCode, que possui ferramentas gratuitas, decidi experimentar o método no meu projeto de OSDev, o FKernel.

O vídeo em questão foi:

O que é o método Ralph Wiggum?

Basicamente, é assumir que LLM é uma porra e combinar força bruta, memória longa e pequenas tarefas para obter um resultado melhor. As memórias são mantidas pelo agente na forma de tarefas em JSON e de um prompt.

Depois, colocamos um loop que roda continuamente, lendo o prompt e atualizando as tarefas.

Assim, um problema longo é dividido em tarefas curtas, muito mais suportáveis de executar e revisar.

Dividir e conquistar é a meta da programação

E o que eu pretendo com isso?

O modelo do FKernel é essencialmente lindo, mas o projeto é mantido por uma pessoa só: eu.

Em geral, a programação acumula muito débito técnico quando não sabemos como chegar ao resultado. Meu processo costuma ser saber o que quero fazer em A, mas não perceber de imediato que preciso integrá-lo a B.

Por isso, reescritas e refatorações tornam-se necessárias. Até uma nova funcionalidade maior que o projeto fica mais fácil de desenvolver no longo prazo quando é dividida corretamente.

Mesmo recursos ou práticas avançadas do FKernel.

Porém é um projeto BSD-3-Clause

Sendo um projeto aberto, é normal esperar contribuições. Ainda não recebi nenhuma, mas seria bom padronizar e automatizar o processo para desenvolvedores que queiram contribuir usando modelos gratuitos.

Particularmente neste kernel eu decidi fugir um pouco do mundo Unix Total e estou usando Lua como a única linguagem de script dentro do kernel.

Vantagens e desvantagens à parte, os scripts de gerenciamento ficam no diretório /Meta e podem ser divididos em pequenas bibliotecas reutilizáveis em /Meta/Lib.

Obviamente não dependendo de LuaRocks para gerenciar libs.

Não pretendo explicar muito além de dizer que é uma prática irrecomendável, porém facilita o pipeline de qualquer pessoa que quiser contribuir.

Baixar → usar o mínimo de dependências externas → gerar o binário.

Funciona?

Não é exatamente o Claude Code, então não consegui replicar perfeitamente o comportamento esperado. Os logs também ainda não ajudam muito.

Ou seja, ainda é preciso muito trabalho para que tudo funcione da forma esperada.

Acredito que o processo e o resultado serão proveitosos no dia a dia quando a ferramenta chegar a um ponto agradável de uso.

Isso será especialmente útil em tarefas grandes e repetitivas de refatoração ou implementação.

O futuro é pica

Com tudo isso dito, espero um futuro melhor no desenvolvimento do kernel. Tarefas muito custosas podem não terminar mais rápido, mas exigem menos intervenção manual: rodou, esqueceu e deixou o agente se ajustar.

Além disso, a divisão em tarefas menores facilita o monitoramento contínuo do progresso.