Bem, eu venho pensando bastante sobre o uso de LLMs. Não vou fazer um guia de prompts, dizer que a inteligência artificial vai acabar com a programação ou defender que todo mundo precisa usar essas ferramentas.

Também não é um texto anti-IA. Eu uso LLMs e, para ser sincero, uso bastante.

LLMs são coisas boas e ruins ao mesmo tempo. Eu sei que isso parece uma resposta meio covarde, de quem não quer escolher um lado, mas é literalmente o que eu penso. A mesma coisa que torna uma LLM útil também pode tornar ela perigosa.

Ela diminui o atrito entre ter uma ideia e ver alguma coisa funcionando. Só que também diminui o esforço entre não saber direito o que está fazendo e produzir um resultado que parece correto.

Esse é o meu ponto principal: o custo de fazer algo errado caiu, o custo de fazer algo funcional caiu, mas o esforço mental do processo também está caindo.

Essa discussão não começou agora

Na verdade, essa discussão é bem antiga. Se não me engano, até Edsger W. Dijkstra entrou nessa pira ao falar sobre ferramentas, linguagens e o trabalho de programar.

Digo “se não me engano” porque é bom conferir antes de atribuir qualquer coisa a alguém que já morreu e não pode aparecer no X para me chamar de burro. O texto linkado é The Humble Programmer, uma palestra de 1972.

Dijkstra não estava falando de LLMs e nem fazendo uma crítica específica ao BASIC. O ponto era mais amplo: computadores mais poderosos não eliminam a dificuldade da programação. Pelo contrário, eles permitem que a gente tente resolver problemas maiores e mais ambiciosos.

Ele também falava sobre como ferramentas e linguagens influenciam os hábitos de pensamento de quem usa elas. É aí que a comparação fica interessante. Uma ferramenta não apenas executa uma tarefa. Ela também muda a forma como a gente pensa sobre essa tarefa.

O custo de fazer errado caiu

Antes de usar uma LLM, se eu quisesse criar uma coisa qualquer, precisava pelo menos pesquisar como começar. Isso não quer dizer que eu entendia tudo, mas existia uma fricção mínima: procurar a documentação, abrir um exemplo, descobrir o nome de uma propriedade, compilar, quebrar e tentar entender por que quebrou.

Agora posso escrever:

Crie um tema para o Hugo com foco em SEO e qualidade de leitura, usando tons em preto e laranja inspirados em abelhas.

Em poucos segundos existe alguma coisa para abrir e olhar. Talvez seja uma porcaria. Talvez nem compile. Talvez seja uma porcaria que compila, que é uma categoria especialmente perigosa. Mas existe alguma coisa.

Isso é ótimo para experimentar. Uma ideia que antes morreria porque parecia trabalhosa demais agora pode virar um protótipo. O custo de testar uma hipótese ficou bem menor.

O problema é quando eu confundo um protótipo funcionando com uma solução que eu entendi.

Uma LLM consegue criar um tema que renderiza, tem uma aparência razoável e até segue algumas boas práticas de SEO. Só que isso não quer dizer que eu saiba explicar o HTML, o CSS, a acessibilidade, o sistema de templates ou as decisões de responsividade daquele tema.

Pode funcionar muito bem até o dia em que alguma coisa sair do caminho feliz. Aí a pergunta deixa de ser “a LLM consegue criar?” e passa a ser “eu consigo manter o que ela criou?”.

Fazer funcionar e entender são coisas diferentes

E aqui vem a parte chata: é possível produzir mais usando uma LLM e aprender menos no processo.

Não vejo contradição nisso. Posso terminar uma tarefa, entregar um resultado e ainda assim sair dela sem um modelo mental melhor do que eu tinha antes.

Enquanto tudo funciona, qualquer implementação parece inteligente. O problema aparece quando preciso alterar alguma coisa sem pedir para a LLM refazer tudo, localizar um erro ou tomar uma decisão que não apareceu na resposta dela.

Aprender costuma exigir um pouco de resistência. Ler uma documentação confusa, testar uma hipótese ruim, escrever um exemplo pequeno e descobrir que a primeira ideia estava errada fazem parte do processo. Se eu removo toda essa resistência, talvez esteja removendo também o exercício que fazia a informação ficar na minha cabeça.

Não estou dizendo que toda dificuldade é boa. Repetir código burocrático por horas não me torna um programador melhor. Mas existe uma diferença entre remover trabalho repetitivo e remover a necessidade de pensar.

Como eu tento usar LLMs na programação

Minha regra, pelo menos por enquanto, é simples:

Escreva para a LLM aquilo que você já sabe, em passos bem curtos. O que você não sabe, procure na documentação e escreva com suas próprias mãos — pelo menos até entender o que está fazendo.

Não é uma regra universal e provavelmente vai mudar. É só uma forma de impedir que a ferramenta pule justamente a parte que eu queria aprender.

Quando já conheço o problema, uma LLM ajuda bastante. Posso pedir um esqueleto de código, uma refatoração mecânica, testes para casos que já defini, uma conversão entre formatos ou uma explicação de um trecho específico. Nesses casos, pelo menos tenho algum mapa para perceber quando a resposta está indo para o mato.

O cenário muda quando não conheço o assunto. Se eu não sei como uma API funciona, qual é a garantia de uma biblioteca ou quais são as limitações de um formato, a resposta mais bonita do mundo ainda pode estar errada.

Nesse caso, começo pela documentação, pelos exemplos oficiais e pelo código-fonte quando for necessário. Depois posso usar a LLM para resumir um trecho, comparar duas alternativas ou explicar palavras que não conheço. A documentação é a fonte; a LLM entra como alguém que me ajuda a ler.

Um exemplo: pedir um tema para o Hugo

O exemplo do tema mostra bem essa diferença. Posso fazer um pedido amplo:

Crie um tema para o Hugo com foco em SEO e qualidade de leitura, usando tons em preto e laranja inspirados em abelhas.

Ou posso descrever algumas restrições técnicas:

Crie um tema para o Hugo. Use media queries para responsividade em desktops e telas pequenas, use unidades rem para tipografia e espaçamento, limite a largura do texto a uma medida confortável e mantenha a direção de leitura adequada para o português.

O segundo pedido é melhor porque comunica mais decisões. Também corrige um problema do meu exemplo original: o recurso usado para adaptar um layout a diferentes tamanhos de tela é, em geral, uma media query, não simplesmente um media type.

Parece um detalhe pequeno, mas ele mostra uma coisa importante: usar palavras técnicas não é a mesma coisa que entender a técnica.

Se eu não sei a diferença, posso escrever um prompt cheio de termos corretos pela metade e receber um resultado que parece profissional. A LLM não vai necessariamente me impedir de fazer uma pergunta ruim. Ela pode simplesmente preencher as lacunas com alguma coisa plausível.

Além disso, “foco em SEO” é uma instrução muito vaga. SEO não é só colocar uma palavra-chave no título. Tem estrutura semântica, títulos hierárquicos, descrição, links internos, URLs, desempenho, acessibilidade e outras decisões que dependem do contexto.

Uma LLM pode ajudar a levantar esses pontos. O que ela não deveria fazer é me convencer de que eu já entendi tudo só porque produziu um arquivo grande e bonito.

Ainda vale a pena usar

Apesar de tudo isso, eu não quero parar de usar LLMs.

Quando usadas com algum critério, elas reduzem o tempo gasto com código repetitivo, ajudam a transformar uma ideia em um primeiro experimento e tornam menos assustador abrir um projeto desconhecido. Também são úteis para conversar sobre alternativas, encontrar casos de teste e perceber que eu esqueci alguma condição óbvia.

Para quem trabalha sozinho, isso pesa ainda mais. Nem sempre tenho alguém para perguntar como uma biblioteca funciona ou para revisar cada decisão pequena. Uma LLM pode ser uma interlocutora inicial, mesmo sem substituir uma revisão de verdade.

Às vezes o maior ganho não é terminar mais rápido, é conseguir começar. Um protótipo ruim ainda pode ensinar alguma coisa, desde que eu trate ele como protótipo e não como produto pronto.

Mas a conveniência começa a dar ruim quando vira dependência.

Existe uma falsa sensação de conhecimento. A resposta vem organizada, cheia de exemplos e com uma confiança irritante. É fácil aceitar uma afirmação sem conferir a documentação ou copiar um código sem entender suas consequências.

Também dá para terceirizar todas as decisões. Se eu peço para a LLM escolher a arquitetura, a biblioteca, o modelo de dados e a estrutura dos diretórios, talvez receba um projeto coerente. Só que a coerência da resposta não significa que as escolhas sejam boas para o meu problema.

E tem a homogeneização. Se todo mundo pede para a LLM “seguir as melhores práticas”, muita coisa começa a parecer igual. Às vezes isso é bom, já que padrões existem por algum motivo. Mas também podemos parar de perguntar se o padrão resolve o problema real ou só parece familiar.

Por fim, a LLM pode simplesmente estar errada. Pode inventar uma função, misturar versões de uma biblioteca, esquecer uma restrição de segurança ou afirmar que algo é impossível quando não é. A responsabilidade pelo código continua sendo minha, mesmo quando a primeira versão veio de outra coisa.

Conclusão

O que estou tentando fazer é escrever primeiro o objetivo e as restrições com minhas próprias palavras, quebrar o trabalho em partes pequenas, pedir ajuda para uma parte específica, conferir a documentação, testar e ler o diff.

Se existe alguma mudança que eu não consigo explicar, não considero que terminei. Tenho um artefato, não necessariamente conhecimento.

No geral, LLMs são boas e ruins ao mesmo tempo porque diminuem o custo de quase tudo. Isso inclui experimentar, prototipar e automatizar tarefas chatas. Também inclui pular etapas, aceitar respostas erradas e produzir algo que eu não sei manter.

Não quero parar de usar LLMs. Seria uma decisão meio estúpida fingir que uma ferramenta útil deixou de existir só porque pode ser usada de maneira ruim. Também não quero entregar meu processo inteiro para um modelo e chamar isso de produtividade.

Meu objetivo é usar a LLM onde eu já tenho algum mapa. Quando estou entrando em um assunto desconhecido, prefiro abrir a documentação, ler devagar e escrever uma parte na mão. Depois posso voltar para a ferramenta com perguntas melhores.

Então fica a regra por enquanto: escreva para a LLM aquilo que você já sabe, em passos curtos; o que você não sabe, procure na documentação e tente entender antes de terceirizar.

Fui!

Em primeiro lugar, consegui meu primeiro emprego com carteira assinada. Nada muito glamouroso.

Fui contratado para ser auxiliar de desossa (na área de controle de estoque) numa empresa pequena da região.

É pouco até você perceber que eles lidam em torno de 700 porcos por dia em média.

No geral, é um emprego digno e interessante por ser bastante manual.

É uma preferência pessoal, mas gosto de serviço braçal porque ele faz minha mente pensar — ou parar de pensar — por algum tempo.

Isso não significa que deixei a programação e os estudos de lado. Na verdade, meu Obsidian e meu AppFlowy — uma alternativa de código aberto ao Notion — estão mais lotados do que nunca de roteiros sobre programação e outros assuntos.

Além disso, a empresa possui um banco de talentos, inclusive para a área de TI, então vale a pena permanecer nela.

Voltando ao Obsidian: mudei totalmente o estilo do vault para algo parecido com um despejo direto do meu cérebro.

.
├── Assets
│   ├── CheckList
│   │   ├── Checklist de viagem de carro.jpg
│   │   ├── Checklist de viagem.jpg
│   │   └── Kit de Primeiros Socorros.jpg
│   ├── Design
│   │   ├── Linguagem visual Dark Mode FoxBSD.png
│   │   └── Linguagem visual FoxBSD.png
│   ├── Learning
│   │   ├── Etiqueta de Roupas.jpg
│   │   └── Pendurar ou Dobrar.jpg
│   └── Specifications
│       └── OpenStep Specification.pdf
├── Learning
│   └── Investimentos
│       ├── Fundamentos de Investimentos.md
│       └── Organização Financeira.md
├── Notes
│   └── Stack de Programação.md
├── Projects
│   ├── FoxBSD
│   │   └── What IS - FoxBSD.md
│   ├── Jarvis
│   │   └── What IS - Jarvis.md
│   ├── KitsuneBot
│   │   └── What IS - KitsuneBot.md
│   └── NeoStep
│       └── What IS - NeoStep.md
└── Studying
    ├── Knowledge
    │   ├── Checklists.md
    │   └── Manuais.md
    ├── Limpeza
    │   ├── Limpeza de Roupa Branca.md
    │   └── Limpeza de Tênis Branco.md
    └── Receitas
        ├── Caldos
        │   └── Caldo de Ossos.md
        ├── Cortes
        │   └── Compras de Carnes.md
        ├── Erros e Truques de Cozinha
        │   ├── Erros e truques de Cozinha.md
        │   └── Truque da tampa - Quando usar e Quando não usar.md
        ├── Guia
        │   ├── Guia Prático dos  Pimentões.md
        │   ├── Guia Prático dos tipos de panela.md
        │   └── Guia sobre quando adicionar alimentos à água.md
        ├── Marinar
        │   ├── Formas de marinar carne bovina.md
        │   ├── Formas de marinar frango marinado.md
        │   └── Formas de temperar manteiga.md
        └── Molhos
            └── Molhos Clássicos para Massas.md

24 directories, 30 files

Agora, com o tempo, dá para continuar alguns projetos e buscar formas diferentes de entretenimento.

Esta é uma pequena atualização do dia a dia. Por enquanto, está bacana.

Pois é: para alguém que disse que demoraria a publicar mais posts neste ano, cá estou eu de novo.

Desta vez, em complemento ao post Uma jornada de reforço nos estudos: planos para 2026, no qual prometi que o ano seria mais lento, mostrarei como estou configurando o Obsidian para estudar.

Antes de mais nada, estudar exige uma mistura de método e disciplina para memorizar conceitos e compreender os resultados de certas ações, fórmulas ou ocorrências.

Essa é, claro, uma definição bastante crua. Então, quando seu professor criticar você por memorizar a fórmula, diga:

Se eu não memorizar, como vou entender e, consequentemente, aprender?

Enfim, existem diversas técnicas e formas de aprender algo.

Meu Obsidian

Decidi adotar o Zettelkasten, que combina muito bem com o Obsidian.

Mas obviamente não de forma crua como está, então eu adicionei alguns plugins como:

• Advanced Canvas
• Dataview
• Iconize
• Tag Wrangler
• Templater
• Escalidraw
• Omnisearch

Esses plugins cobrem grande parte do que preciso e permitem ligar conteúdos de forma muito mais interessante.

E adicionei também alguns diretórios:

00 - Assets
01 - Referências
02 - Permanentes
03 - Map of Contents
xx - Excalidraw

xx representa um diretório sem valor numérico.

Mas a parte mais importante fica em Assets/_Templates.

Ali ficam os templates do projeto:

• Nota MOC → lê-se “nota de mapa de conteúdo”
• Nota Permanente
• Nota Referência

Aliás, dica importante

No Obsidian, abra as configurações do Templater e defina Template folder location como 00 - Assets/_Templates.

Isso evita que o plugin sugira outras notas como templates.

Bom, a ideia é simples:

Tudo o que eu ler e considerar útil virará uma Referência.

Depois que a referência for feita, ela não pode mais ser editada, somente para alguma revisão ou em nova versão v2.

Depois, lemos a referência e transformamos os insights em notas permanentes, que devem ter:

• Argumento central
• Resumo do que ocorreu
• Conexões com outras notas
• Link para as referências originais

Você pode usar o Dataview para verificar se já existe uma nota permanente desse tipo antes de criar duplicatas.

Por fim, atualizamos o MOC da área correspondente, listando ou vinculando todas as notas permanentes das respectivas áreas e subáreas.

Se houver alguma dúvida, ela pode ser registrada em Questões em aberto.

Agora, o mais importante é o processo de revisão, sempre releia as permanentes antigas e atualize o MOC se surgirem novas conexões.

Templates

Nota de referência

---
tipo: referencia
area:
fonte:
autor:
link:
created: <% tp.date.now("YYYY-MM-DD") %>
status:
tags:
  - nota-referencia
---

# <% tp.system.prompt() %>

## Resumo bruto

-

## Pontos Importantes

-

## Ideias Provocadas

-

## Possíveis Permanentes

-

É um template simples. O uso de <% tp.system.prompt() %> permite criar um título a partir do texto informado pelo usuário. Também podemos ter diversas referências para uma única nota permanente.

O template possui propriedades como:

area-> Categoria do conteúdo

fonte/autor/link -> informações da fonte original

resumo bruto → síntese direta da fonte

pontos importantes -> destaque de ideias que podem se tornar permanentes

ideias provocadas -> insights iniciais que surgem ao ler a fonte

possíveis permanentes → conceitos que poderão virar notas consolidadas

Nota Permanente

---
tipo: permanente
area:
status: rascunho
origin:
created: <% tp.date.now("YYYY-MM-DD") %>
updated:
conexões:
referencias:
tags:
  - nota-permanente
---

# #Title

Explique a ideia com suas palavras.
Seja específico
Evite copiar a fonte.

---

## Argumento Central

---

Diferentemente da nota de referência, aqui usamos o título literal do arquivo, #Title, para gerar o título da nota permanente.

Ela também possui alguns campos:

area -> precisa ser a mesma da referência relacionada

origin -> referência de origem

argumento central -> explicação própria do conceito

conexões -> links para outras permanentes relacionadas

referências → referências utilizadas

status → pode ser rascunho, ativo ou revisado

Notas permanentes são a base do conhecimento consolidado, revisável e conectado pelo MOC.

Nota MOC

---
tags:
tipo: moc
area:
status: ativo
created: <% tp.date.now("YYYY-MM-DD") %>
---

# #Title

## Escopo

Descreva claramente o que este Map of Content cobre.

---

## Conceitos Fundamentais

```dataview
table area, status
from "02 - Permanentes"
where area = this.area
```dataview
---
## Subáreas

- ***

## Referências Base

```dataview
table fonte, autor
from "01 - Referencias"
where area = this.area
```dataview
---

## Questões em aberto

-

Eu acabei quebrando o dataview no exemplo acima para garantir que ficasse tudo em um único codeblock, assim caso copiem diretamente basta trocar ```dataview pela sua versão sem dataview usando regex.

A nota MOC funciona como um índice e oferece uma visão geral da área de estudo. Aqui também usamos #Title para gerar o título.

O MOC usa o Dataview para reunir as notas permanentes relacionadas à mesma área e organizá-las por área, subárea, cluster ou tópico.

Também há uma seção de questões em aberto: literalmente, uma lista do que ainda falta estudar.

Fluxo de estudo

1. Encontro algo novo e crio uma Referência.
2. Processo a informação e a transformo em uma nota Permanente, com minhas palavras e a origem citada.
3. Organizo o MOC, atualizando conceitos fundamentais, subáreas e questões em aberto.
4. Pratico. Este é o passo mais importante: conhecimento sem prática não adianta.
5. Reviso periodicamente, mantendo as notas permanentes e o MOC atualizados com novas conexões.

Este é meu Obsidian de estudos, chamado carinhosamente de Mind Order. Espero que tenham gostado. Fui!

Cá estamos nós em fevereiro, e eu realmente não consigo acreditar que faz pouco mais de seis anos que me tornei alguém ativo na web.

Não que eu seja famoso. Digo ativo no sentido de estar presente em diversas plataformas online: mantendo este blog, conversando no Discord, perdendo tempo no Vaporhole — uma rede social brasileira no estilo do tilde.club, como um computador Unix compartilhado via SSH —, vendo vídeos no YouTube e navegando no X e no Instagram.

Enfim, nada de muito revolucionário até aí.

Mas, sinceramente, desde a criação do ChatGPT, Claude, Gemini, Grok, DeepSeek e outros modelos, sinto que venho programando e exercitando cada vez menos meu intelecto como programador.

Não é como se eu cogitasse parar de usá-los. O ChatGPT conversa muito bem comigo, e eu o instruo a se comunicar da forma que entendo melhor:

Estilo e Tom básico: Franco Caracteristicas:

• Acolhedor: Menos
• Entusiasmado: Mais
• Lista e Cabeçalhos: Mais
• Emoji: Mais Instrução personalizada: Seja sarcástico, mas mantenha a educação; discorde com argumentos e questione minha lógica sempre que possível.

Não tenha floreios e aja com um homem adulto de 18 anos podendo explicitamente conversar sem preocupações como uma pessoa adulta faria com outra pessoa adulta.

Memória: O usuário prefere que eu nunca refaça as respostas que ele já escreveu e quer que isso seja respeitado permanentemente.

Então, a ideia para este ano é voltar a estudar algoritmos, estruturas de dados e ferramentas.

A segunda parte é começar com alguns projetos avulsos de prática.

Para quem não conhece: Yet Another Recreational Programming Session, do Tsoding.

Provavelmente este ano será lento, mas tentarei focar os próximos posts em assuntos menos comuns, como programação dinâmica, programação matemática, arquitetura e alguns padrões pouco discutidos.

A terceira parte é começar na criação de conteúdo.

A quarta parte e a mais importante é começar a sair do conforto e começar a fazer mais atividades físicas.

23 anos é muito tempo para ser feliz, hora de virar adulto.

Enfim, um bom ano para todos.

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.