Em defesa do software pequeno
Software pequeno pode ser lido em uma tarde, movido sem cerimônia e consertado por quem depende dele. Sua escala modesta não é falta de ambição; é um convite à posse.
vladymir@home: ~/writing/
·2026-08-24-vibe-coding.md·2026-08-23-computer-became-a-place-again.md·2026-08-20-freebsd.md·2026-08-17-knowledge-belief.md·2026-08-12-small-software.md·2026-08-04-computer-son.md·2026-07-29-simplicity-complexity.md
7 articles — select one to read
Tenho uma pequena confissão a fazer.
Eu vibe codei este site.
Isso é um pouco constrangedor para alguém como eu.
Passei décadas usando Unix, escrevendo código, configurando máquinas, quebrando sistemas, lendo man pages e acreditando — talvez com um certo orgulho — que entender as coisas importava.
Ainda acredito nisso.
a computer used to feel closer
Eu não programei este site do jeito antigo
Eu conversei sobre ele.
Descrevi o que queria.
Pedi mudanças.
Rejeitei ideias.
Comparei referências.
Muito moderno.
Muito cyberpunk.
Pouco Unix.
Parecido demais com um sistema operacional de brinquedo.
Fui ajustando até reconhecer alguma coisa minha na tela.
Boa parte do código foi escrita por uma IA.
E isso me incomoda um pouco.
Não porque eu ache que exista alguma virtude especial em digitar CSS à mão.
Mas porque programar, para mim, sempre esteve ligado a uma forma particular de intimidade com a máquina.
Você pensa.
Você escreve.
A máquina faz outra coisa.
Você descobre por quê.
Existe conhecimento nesse atrito.
PLACEHOLDER — somewhere underneath
Com vibe coding, parte desse atrito desaparece.
A intenção não chega mais diretamente ao código.
Agora existe alguma coisa no meio.
Antes eu expressava intenção em código.
Agora também posso expressar intenção sobre código.
Essa diferença parece pequena até você começar a trabalhar assim.
Em algum momento, percebi que já não estava dizendo exatamente como implementar as coisas.
Eu estava dizendo o que deveria existir.
quero que isso pareça uma workstation Unix antiga.
menos cyberpunk.
Plan 9 deveria ser mais seco.
esse texto não pertence ao Lab.
o tema precisa mudar a identidade
sem mudar o site inteiro.
Isso se parece menos com programar uma máquina e mais com conversar com outro programador.
Ideias que ficavam na gaveta
Talvez seja por isso que tenho produzido tanta coisa ultimamente.
Sempre tive mais ideias do que tempo para implementá-las.
Algumas viravam notas.
Outras, pequenos toy projects.
Muitas morriam antes mesmo de chegar ao editor.
Nem sempre por falta de interesse.
Às vezes eu simplesmente sabia o tamanho do trabalho que vinha depois da ideia.
E a vida tem outras coisas.
Trabalho.
Casa.
Família.
Uma quantidade finita de noites e fins de semana.
Existe um tipo particular de projeto que você adia não porque não quer fazê-lo, mas porque conhece bem demais o custo de fazê-lo direito.
IA reduziu esse custo de início.
Não tornou as ideias automaticamente boas.
Não eliminou decisões.
Não criou mais horas no dia.
Mas diminuiu bastante a distância entre:
isso seria interessante
e
existe alguma coisa funcionando na minha frente.
Isso mudou meu comportamento.
Tenho conseguido colocar para fora ideias que provavelmente continuariam como arquivos de texto, diagramas ou pensamentos soltos.
Algumas vão morrer depois.
Outras vão virar projetos reais.
Mas agora elas têm a chance de existir por tempo suficiente para que eu descubra qual das duas coisas são.
Talvez essa seja, para mim, a parte mais sedutora do vibe coding.
Não escrever software mais rápido.
Dar uma forma inicial a ideias que antes não sobreviveriam ao custo de começar.
Então quem fez o site?
A pergunta aparece cedo ou tarde.
Eu fiz este site?
Não sei se existe uma resposta simples.
Eu não saberia apontar todas as linhas que foram escritas pelo modelo.
Mas sei por que existem quatro temas.
Sei por que um deles se chama Workstation.
Sei por que não quero neon demais.
Sei por que existe um Lab.
Sei por que uma TV box quebrada merece uma página.
Sei por que certas coisas pertencem a Writing e outras a Notes.
Sei por que estou escrevendo este texto.
vladymir.info, 2026
A intenção continua sendo minha.
Mas a tradução dessa intenção para código mudou de lugar.
Talvez a autoria também tenha mudado de lugar.
Mais uma abstração
Existe uma maneira fácil de discutir vibe coding:
perguntar se ainda é programação.
Não sei se essa é a pergunta mais interessante.
Abstrações sempre mudaram a distância entre intenção e máquina.
machine code
↓
assembly
↓
C
↓
libraries
↓
frameworks
↓
...
Cada camada permitiu dizer menos sobre como e mais sobre o quê.
IA parece continuar esse movimento.
Mas há uma diferença estranha.
Essa abstração responde.
Você pode argumentar com ela.
Pode dizer que uma solução está errada sem saber exatamente onde.
Pode pedir outra.
Pode dizer:
não é isso.
mais simples.
menos bonito.
mais estranho.
agora ficou pior.
volta.
E alguma coisa acontece.
intent
↓
language
↓
model
↓
code
↓
machine
A parte perigosa
Um modelo preenche lacunas.
É exatamente isso que o torna útil.
Mas essas lacunas também são decisões.
Estrutura.
Nomes.
Dependências.
Comportamento.
Estética.
Suposições.
Quanto menos código eu escrevo diretamente, mais preciso perceber quando alguma decisão deixou de ser minha.
É fácil aceitar uma abstração.
É mais difícil perceber quando a abstração começou a escolher por você.
Talvez essa seja a parte do vibe coding que mais me interessa.
Não a possibilidade de gerar código rapidamente.
Mas a necessidade de manter intenção enquanto outra coisa implementa partes dela.
O trabalho muda de forma
Você escreve menos instruções para a máquina.
Passa mais tempo descrevendo limites.
Dizendo não.
Reconhecendo quando algo está quase certo, mas ainda não é seu.
E, curiosamente, isso também permite experimentar mais.
Ideias baratas de testar podem continuar pequenas.
Toy projects podem continuar toy projects.
Nem toda curiosidade precisa justificar semanas de implementação antes de mostrar se havia alguma coisa ali.
Isso, para mim, é uma mudança importante.
Talvez programação tenha sempre sido um pouco disso.
Só ficou mais visível agora.
Este site foi vibe coded.
Eu não sei apontar todas as linhas que foram escritas pelo modelo.
Mas sei por que existem quatro temas.
Sei por que um deles se chama Workstation.
Sei por que não quero neon demais.
Sei por que existe um Lab.
Sei por que uma TV box quebrada merece uma página.
Sei por que estou escrevendo este texto.
O código talvez não seja inteiramente meu.
O site é.
Por enquanto, quase tudo ainda está pela metade. A workstation ainda espera o gabinete. A TV box virou experimento antes de virar alguma coisa útil. A rede local continua mudando. O rack já existe, mas ainda está sendo organizado. A infraestrutura na nuvem cresce em paralelo. Nada está realmente pronto. E talvez essa seja a parte mais interessante.
Por muito tempo, meu computador foi ficando menos importante. O navegador virou a interface. Os servidores foram para a nuvem. O software virou serviço. A máquina na mesa virou principalmente uma forma de acessar computadores que estavam em outro lugar.
Ultimamente tenho feito o caminho contrário. Quero rodar meus próprios modelos localmente. Quero construir agentes do zero. Entender o loop. Entender a memória. Entender como ferramentas são escolhidas. Entender o que um agente sabe, o que inferiu e o que apenas supôs. Quero que essas coisas rodem em máquinas que eu controlo.
Foi daí que começaram a aparecer a rede, os servidores, FreeBSD, OpenBSD, jails, WireGuard, o rack, peças usadas, uma TV box que resolvi tentar transformar em Linux, ESP32s espalhados pela mesa e planos demais para poucas tomadas.
Em algum ponto disso apareceu a workstation. Ainda nem terminou de ser montada. Mas o papel dela já está claro.
Não quero apenas um computador mais rápido. Quero uma máquina que possa entender, modificar, quebrar, consertar e transformar conforme o próximo experimento. Uma máquina onde eu possa compilar software, subir uma VM, rodar um modelo, escrever um agente, testar uma rede e depois desmontar metade disso porque surgiu uma ideia melhor.
Ao redor dela, outras coisas também vão tomando forma. Infraestrutura local. Infraestrutura na nuvem. Máquinas reaproveitadas. Rede. Eletrônica. Modelos. Agentes. Software. Algumas dessas coisas vão funcionar. Outras provavelmente serão desmontadas. Algumas talvez nunca passem de experimento.
Tenho documentado parte desse processo aqui. Não como projetos terminados. Mais como rastros de coisas sendo construídas.
A workstation ainda não está pronta. O laboratório também não. Os agentes muito menos. Ótimo.
Há vinte e cinco anos, aos dezesseis, experimentei o FreeBSD pela primeira vez. Eu vinha do Slackware, onde a simplicidade era o ponto, e o FreeBSD passava a mesma sensação: um sistema só, montado em conjunto, nada extra entre você e a máquina. Gostei na hora e nunca cheguei a desaprender isso.
Durante anos trabalhei com outras coisas. Então, de propósito, decidi voltar às origens — a filosofia Unix e os fundamentos. Comecei a ler as internals do FreeBSD, a camada VFS e o vnode, como um arquivo realmente funciona. Entender como as peças se encaixam tornou a máquina legível de novo.
Duas razões práticas fecharam a decisão. ZFS, porque um sistema de arquivos deve ter memória — snapshots, checksums, um erro que dá para desfazer. E jails, porque isolamento não deveria significar rodar um segundo sistema operacional para cada serviço.
Então o plano é simples: hospedar o máximo que puder dentro de jails, sobre ZFS, e seguir essa filosofia. Pequeno, legível, montado de peças que eu ainda consigo enxergar.
Crença pode ser teimosa; conhecimento precisa continuar respondendo à evidência. A parte interessante não é parecer certo, mas construir hábitos que nos deixam perceber quando a realidade discorda.
Software pequeno pode ser lido em uma tarde, movido sem cerimônia e consertado por quem depende dele. Sua escala modesta não é falta de ambição; é um convite à posse.
Montamos o computador devagar o suficiente para perguntar o que cada peça fazia. Quando ele ligou, o resultado não era apenas uma máquina funcionando, mas um mapa de perguntas que podíamos continuar explorando juntos.
Sistemas complexos não se tornam simples porque escondemos seus controles. A simplicidade útil expõe os limites certos, nomeia as peças importantes e deixa um caminho para uma compreensão mais profunda.