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.

Isso é invariável em todo o mundo da programação.

No mundo do SaaS, sendo um desenvolvedor solo, você não deve confiar apenas em si mesmo.

Adicione Testes, testes, mais testes, enfie testes em tudo que puder e use softwares maduros.

Mas, ao mesmo tempo não deixe seu software parado no tempo.

As duas grandes divisões

Dentro do mundo de software existem duas grandes divisões frontend e backend

E uma parte menor que é DevOps.

Este post, em específico, é sobre frontend e backend.

Assuma que que DevOps você pode contratar outros SaaS em vez de implementar você mesmo.

Frontend

Para o Frontend precisamos atingir o máximo de plataformas sozinho com uma interface moderna possa atingir:

• Desktop
• Web
• Mobile

Além disso, é preferencial que seguirmos técnicas de design como:

• Offline-First
• Mobile-First

Com isso, temos uma base boa para ter um software que não fica irritante com o tempo.

No geral, use Flutter para evitar ter que lidar com diversas plataformas manualmente.

Backend

Para começar, precisamos entender do que é importante no backend de um SaaS.

Nada mais importante do que usar um framework maduro.

E no caso, pessoalmente falando, o melhor que temos é o Ruby On Rails e veja que podemos migrar de Ruby para JRuby garantindo que a aplicação pode escalar se e somente se for necessário.

Adote testes como dogma literalmente, teste tudo, se tiver erro gere um teste, se tiver um bug teste, se tiver uma vulnerabilidade teste também.

Coloque:

• Rack Attack
• Brakeman
• Capybara
• Bullet
• Rack Mini Profiler

Veja que a ideia principal é que as libs do rails são maduras e testadas facilmente acopladas e no geral é muito melhor do que depender de si mesmo que só na cabeça vai querer inventar procedimentos de segurança que vai fazer pagar fortunas em indenizações.

Vide Noticia sobre o Saphoos.

DevOps

Dentro de seu Software as Service.

Você quer evitar ao máximo problemas de responsabilidade fiscal.

Então a coisa mais inteligente a se fazer é se mover de capex (investimento na própria infra) para opex (contrato de serviços externos).

Use serviços como paper-trail, use a amazon-web-service …

O software continua sendo sua responsabilidade mas, problemas internos de servidores gerenciados por provedores não recaem diretamente sobre você, reduzindo riscos e permitindo focar no desenvolvimento.

Contrate Hackers Ético e faça testes de segurança, corrija brechas periodicamente.

Conclusão

No geral, a combinação ideal seria usar um backend em rails e um frontend em flutter.

Para ter diversas plataformas e um backend sólido, caso precise de algo customizado, use um microsserviço da forma que achar melhor contanto que haja contratos fortes e testes.

Jamais esqueça os testes.