Osdev: Programação assistida por ai, usando ralph wiggum pra acelerar o desenvolvimento
Introdução
No mundo moderno, não existe nada pior do que se defasar e pior ainda ficar travado por causa de opinião sem embasamento, obviamente eu dou opinião, pelo menos o suficiente para produzir os posts como:
E alguns outros que ainda pretendo postar.
Porém, entretanto, todavia uma coisa que tenho pensado é no hype das AI e no novo modelo de desenvolvimento baseado em Ralph Willgum
Para contextualizar, eu estava em um dia normal assistindo alguns vídeos no Freetube (o melhor frontend para youtuber que eu conheço) e encontrei ou melhor reencontrei um vídeo falando deste modelo de desenvolvimento e como já tinha instalado o Omarchy do DHH e testado o OpenCode que possui ferramentas gratuitas decidi testar no meu projeto de osdev, o FKernel.
Em questão o vídeo que eu assisti foi
O que é o metodo Ralph Wiggum
Basicamente é assumir que LLM é uma porra e usar força bruta + memória longa + pequenas tarefas para conseguir um resultado melhor, ambas as memórias são mantidas no sistema operacional do agente na forma de tasks em json e um prompt.
Após isso colocamos um for-loop que deve infinitamente rodar lendo o prompt e atualizando as tasks.
Para tarefas longas, tudo vira tarefas curtas que são infinitamente mais supportaveis de se fazer me um problema longo.
Dividir e conquistar é a meta da programação
E o que eu pretendo com isso?
O FKernel em seu modelo é essencialmente lindo, mas, é mantido por uma pessoa só “eu”.
E o geral a programação tende a ter muito débito técnico quando não se sabe como atingir o que quer e meu processo de desenvolvimento é saber o que quero fazer em A mas não saber que preciso integrar a B.
Então é necessário fazer uma reescrita ou uma refatoração, mesmo uma nova feature que seja maior que o projeto fica mais fácil de desenvolve - lo a longo prazo.
Mesmo recursos ou práticas avançadas do FKernel.
Porém é um projeto BSD-3-Clause
Sendo um projeto aberto é normal se esperar contribuições, eu mesmo não tive, porém seria bom normalizar o processo para ficar automático para todos os desenvolvedores que quiserem contribuir usando obviamente 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 a parte qualquer script de gerenciamento é normalizado em scripts no diretório /Meta e podemos dividir em pequenas libs em /Meta/Lib reusáveis.
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 > Ter o mínimo de dependencia externa > Gerar o binário
Funciona?
Não é exatamente o claude-code então não consegui replicar perfeitamente o comportamento esperado, fora que os logs em si não contribuem muito ainda.
Ou seja precisa de muito trabalho para ser 100% funcional da forma esperada, tirando isso.
Acredito que o progresso e o resultado em si devam ser proveitosos no dia a dia quando estiver num ponto agradavel de uso.
Bom em especial quando eu tiver grandes e chatas tasks de refatoração em especifico ou de implementação.
O futuro é pica
Com tudo isso dito, a única coisa que posso aguardar é um melhor futuro no desenvolvimento do meu kernel já que agora tarefas incrivelmente custosas em tempo pode ser executada não em menos tempo, mas em menos iteração manual. Rodou esqueceu e ele que se ajuste.
Fora na subdivisão em tarefas menoras e o monitoramente continuo de como continuar a progressão