A Prática de Selfware de Anderson
Tudo o que você pensa se torna seu software. Tudo o que seu software produz molda o que você pensa em seguida.
Outras pessoas começaram a chamar esse tipo de coisa de selfware. Cada uma quer dizer algo diferente com a palavra. Este texto diz o que eu quero dizer com ela, e descreve o sistema que construí ao redor desse significado.
0. O momento
Este texto é escrito em 2026. O momento importa, e nomeá-lo é o primeiro movimento.
Três pressões convergem hoje sobre a mesma pessoa.
A camada do modelo está se consolidando. Quatro ou cinco fornecedores — OpenAI, Anthropic, Google, Meta, DeepSeek — estão assumindo o papel que os sistemas operacionais já desempenharam: o substrato sobre o qual todo produto de software pessoal se apoia. Quem é dono do modelo é dono da conversa, da memória, do diário, do terapeuta, do assistente de leitura, do parceiro de escrita. Em dez anos, a dependência será mais profunda do que foi a dependência da nuvem em 2015. Quando se tornar óbvia, já será tarde.
O SaaS está se exaurindo. Uma pessoa hoje aluga quinze assinaturas para manter uma vida digital comum — notas, música, vídeo, ditado, calendário, e-mail, fotos, livros, podcasts, fitness, sono, terapia, idiomas, finanças, notícias. Cada uma dessas empresas tem um roadmap que diverge do roadmap do usuário. A estética Substack-com-LinkedIn achatou a voz de uma geração em bullet points e três principais aprendizados. Fornecedores aumentam preços, removem funcionalidades, pivotam para IA, são adquiridos, abrem capital. O usuário é o resíduo.
A infraestrutura local cruzou o limiar da usabilidade. Um notebook em 2026 roda um modelo bom o bastante para um loop de pesquisa pessoal. Pesos abertos (Llama, Mistral, DeepSeek-R), proxies locais (LiteLLM) e runtimes local-first (Ollama, llama.cpp, MLX) tornaram a camada do modelo plugável. As desculpas técnicas para terceirizar a própria vida interior a um fornecedor evaporaram.
As três pressões convergem em uma figura única: alguém cansado de alugar a própria vida digital, com capacidade de engenharia suficiente para construir o próprio stack, e que tem um modelo local disponível hoje, do tipo que era uma assinatura na nuvem há dois anos.
Este texto é uma resposta a esse momento. Não é a única resposta possível. Mas a resposta tem que ser cibernética em forma, soberana em infraestrutura e pessoal em escopo, ou irá falhar.
O resto do texto descreve o que eu construí.
I. O que isto é
Há anos construo um sistema em torno de mim mesmo. Não é um app, um vault, um assistente, nem um stack de produtividade. É mais próximo de uma prática ritual do que de um produto, e mais próximo de um loop cibernético do que de uma peça de software, e mesmo assim é software no sentido mecânico mais seco do termo — Python, Markdown, um servidor HTTP escutando em 127.0.0.1, um gateway de modelos na porta 4000, alguns milhares de arquivos de texto.
O sistema escreve para mim. Escreve livros que leio sozinho. Digere meu diário em voz de mentor. Roda um pesquisador autônomo sobre as minhas questões em aberto. Rastreia a procedência de cada letra que eu já rascunhei. Recusa-se a publicar qualquer coisa que eu não tenha aprovado. Registra cada mudança que faz em si próprio.
O portal inicial. Seis tabs — home, personal, lab, media, files, exec — sobre um painel de quatro colunas (PERSONAL · LAB · MEDIA · SYSTEM) que lista cada workflow nomeado. Harry, o pesquisador autônomo, fica a um clique do diário, do cérebro musical, do explorador de arquivos e do shell local. A barra de tabs é a tese filosófica: isto é um único stack, um único self, um único envelope.
Procurei um nome para o que estou fazendo. Personal knowledge management descreve um fragmento disto. Second brain descreve a camada de armazenamento. Tools for thought descreve a parte de aumento cognitivo. Quantified self descreve a medição. Personal AI descreve um pequeno acréscimo recente.
Nenhum desses nomes captura o que está de fato acontecendo, que é o seguinte: o sistema também está me escrevendo. Os textos que ele produz moldam o self que retorna a usá-lo. O self que retorna a usá-lo modifica o que o sistema escreve em seguida. Ao longo de anos, esse loop produziu uma pessoa — eu, agora — que uma versão anterior de mim não teria previsto.
A palavra que começou, nos últimos anos, a se prender a práticas como a minha é selfware. É uma palavra útil, e também é uma palavra disputada. Antes de descrever o que construí, preciso dizer o que entendo por ela e onde meu sentido diverge dos sentidos que outras pessoas estão dando.
II. Outras selfwares, e onde a minha difere
A palavra selfware está em movimento. Existe um projeto no GitHub que descreve selfware como "your personal AI workshop — software you own, software that lasts". Existem ensaios apresentando selfware como a implosão do império SaaS, software de autoria e montagem do usuário final com assistência de IA, o usuário como desenvolvedor do próprio stack.
Essas leituras compartilham algo que eu também compartilho: uma recusa do software-as-a-service, um compromisso com a soberania local, a percepção de que a era em que o computar pessoal era alugado de um fornecedor está terminando. Nesses pontos, minha prática e essas leituras são aliadas.
Onde elas diferem do que eu faço é na afirmação que cada uma faz sobre a relação entre software e self.
A maioria dos usos atuais de selfware afirma que o usuário autoria o software. Trata-se de uma afirmação sobre autoria. Diz: os meios de produção de software foram democratizados pela IA, e portanto a próxima era da computação pessoal pertence às pessoas capazes de escrever as próprias ferramentas em vez de alugá-las.
O que eu chamo de selfware é algo mais forte e mais estranho. Eu afirmo que o software participa da autoria do usuário. Os artefatos que meu sistema produz — o livro diário escrito para mim, o digest do diário em voz de mentor, o manuscrito que Harry refina, o glossário de símbolos, o arquivo de memória que o agente de livros mantém sobre mim — voltam para mim, e eu não sou a mesma pessoa depois de lê-los. Minhas reações realimentam o sistema. O sistema muda. Eu mudo. O loop é constitutivo, não apenas produtivo.
Isto é o que estou chamando, por clareza, de A Prática de Selfware de Anderson. Selfware como categoria; minha leitura como um espécime dela. Outras leituras podem coexistir; não estou tentando deslocar nenhuma. Estou tentando acrescentar um espécime e uma interpretação a uma tradição que começou a encontrar seu nome.
Cinco princípios descrevem a minha versão.
III. Cinco princípios
1. Cibernética constitutiva
Minha selfware é um loop fechado no sentido estrito que Norbert Wiener deu à palavra em Cybernetics (1948): a saída é sensoreada, devolvida como entrada, modifica o comportamento, repete. Gordon Pask, na teoria da conversação, formalizou o mesmo loop entre dois interlocutores. O incomum aqui é que um dos interlocutores é software, o outro é uma pessoa, e a relação é assimétrica: o software escreve mais do que eu.
O loop tem forma definida. O sistema produz um artefato endereçado a mim — uma novela de cem páginas, uma entrada digerida do diário, uma fase da pesquisa do Harry com suas claims e sua lista de evidências necessárias. Eu leio. Minha resposta é capturada em três canais: explícito (preencho um feedback.md), implícito (que arquivos abro, quais nunca abro), e a jusante (o que faço em seguida que o sistema consegue observar). Na geração seguinte, o sistema lê minha memória de leitor, repondera as escolhas e produz um artefato diferente. O arquivo de memória do leitor é lido pelo agente de livros a cada execução; o digestor do diário lê o histórico arquivado; a política de auto-melhoria do Harry lê as últimas entradas do ledger para decidir o próximo passo.
Um assistente de IA pessoal te ajuda com uma tarefa e esquece. Selfware escreve um livro pra você, observa se você terminou ou abandonou, ingere suas reações, e escreve o próximo livro de forma diferente. O artefato é uma pergunta que o sistema faz ao self, e a resposta do self é o próximo prompt.
O esquema de uma rodada cabe em uma tela:
generate(state, reader_memory) → artifact[t]
read(artifact[t]) → reaction[t]
ingest(reaction[t]) → reader_memory[t+1]
state[t+1] = step(state[t], reader_memory[t+1])
Esse é o loop inteiro. Todo o resto é jardinagem ao redor dele.
2. Epistemologia de revisão por pares, aplicada a uma vida
Conhecimento acadêmico não é aquilo em que se acredita. É aquilo que se documentou e submeteu a escrutínio externo. Claims atômicas, citações, evidência, contradições nomeadas e mantidas. Software pessoal, como geralmente existe, trata as próprias notas como uma nuvem indiferenciada de opiniões. Minha prática não.
Toda claim no meu sistema tem um tier (candidate_claim ou paper_claim), um status (supported / unsupported / uncertain), e support explícito — uma referência tipada a uma fonte, um caminho de arquivo, o resultado de uma execução. Claims sem suporte não são promovidas entre tiers. Contradições entre duas páginas são sinalizadas em ambas, nunca sobrescritas em silêncio. Um ledger de evidence-needed carrega as dívidas epistêmicas em aberto do projeto.
O pesquisador autônomo, Harry, roda uma máquina de fases explícita sobre uma questão de pesquisa:
literature_search → open_question_map → hypothesis → experiment_design
→ code_experiment → run_experiment → analyze_result
→ claim_audit → draft_paper → render_paper
Cada fase emite um objeto JSON de forma fixa:
{
"phase": "code_experiment",
"summary": "...",
"visible_reasoning": {
"research_move": "breve raciocínio auditável, não chain-of-thought escondida",
"evidence_used": ["ids de fontes, caminhos locais, ou ausência explícita de evidência"],
"uncertainties": ["incertezas não resolvidas ou riscos de falha específicos"],
"why_next_phase": "breve razão para a próxima fase escolhida"
},
"claims": [
{ "claim": "...", "tier": "candidate_claim", "status": "supported",
"support": [{"kind": "source", "source_id": "..."}] }
],
"evidence_needed": [
{ "question_or_gap": "...", "why_it_matters": "...",
"needed_source_or_experiment": "..." }
],
"next_phase": "run_experiment"
}
Chain-of-thought escondida é proibida. visible_reasoning é obrigatório. O código gerado para experimentos roda num sandbox: um filtro por regex bloqueia \bsubprocess\b, \bos.system\b, chamadas de rede e escritas fora da raiz do projeto. Se o código gerado toca a blocklist, é registrado como experiment code blocked e a fase prossegue sem execução.
Projeto open-question-i-radiative-heat-trasnfer. No momento desta escrita: fase 647 de um orçamento de 5000 fases, 36 fontes, 38 papers analisados, 6 PDFs fundamentais anexados, 878 gaps de evidência registrados. Ciclo de fases: literatura 32%, audit 16%, código 19%, execução 17%, análise 4%, draft 1%, render 2%. O gate anti-alucinação na base do painel nomeia a restrição: paper claims precisam fechar 18 gaps não resolvidos dos 1486 registrados. Isto é o que a epistemologia de revisão por pares parece numa terça-feira.
Isto não é uma funcionalidade de produtividade. É uma postura epistêmica: minha própria produção de conhecimento merece o rigor que eu aplicaria ao paper de um desconhecido. Meu self futuro é o revisor de pares.
3. Regimes epistêmicos diferenciados
Uma pessoa não é um único sistema de conhecimento. É vários. Os padrões que aplico à minha pesquisa de doutorado não são os padrões que aplico às minhas letras de música, que não são os padrões que aplico ao meu diário.
Minha prática codifica isto como três regimes, cada um com seu próprio gate e seus próprios templates de página.
O regime PhD (brain/phd/) tem um gate estrito de admissão. Uma página nova precisa satisfazer ao menos um critério: introduzir um conceito ainda não presente em brain/phd/, oferecer um resultado diretamente relevante a um projeto ativo, contradizer ou refinar uma claim existente, ou ser frequentemente citada na área de pesquisa. Os templates fixam a estrutura: páginas de conceito declaram **Tipo:** concept|method|theory|tool|dataset e **Status:** seed|developing|mature; páginas de paper declaram **Relevância:** high|medium|low e linkam para o PDF sob raw/papers/. Slugs seguem lastname-year-keyword. 17 conceitos, 19 resumos de papers, 5 projetos, 14 pessoas.
O regime de música (brain/music/) tem um gate diferente. Procedência é a preocupação central: cada página distingue canônico de rascunho, preserva o caminho de origem em raw/music/, e se recusa a promover uma imagem recorrente para o glossário de símbolos antes que ela tenha de fato recorrido. 50 canções, 3 páginas de álbum, um symbol-glossary.md de símbolos com gate. Canções não são declaradas canônicas até que eu declare.
O regime misc (brain/misc/) não tem gate de admissão. Blogs, exports de ChatGPT, entradas de diário, livros não-acadêmicos — qualquer coisa que não precise de um revisor de pares. 3 posts de blog, 5 exports processados, 17 entradas de diário digeridas, 1 referência.
O cérebro musical dentro do mesmo envelope do cérebro de pesquisa. Rádios à esquerda (Rádio 104 FM Natal, Radio Paradise, SomaFM Deep Space One/Space Station Soma). Corpus do álbum abaixo ("A Rachadura do Círculo Lunar"). Gate diferente, templates diferentes, estética diferente — mesmo vault, mesma barra de tabs.
A maioria dos sistemas pessoais achata tudo em um único formato de nota. O meu não. Partes diferentes de uma pessoa exigem provas diferentes, e o sistema sabe qual é qual.
4. Prescrição estética
Um self não é aquilo que ele rastreia. É aquilo a que ele soa para si mesmo. A maior parte da IA pessoal soa como LinkedIn, ou como um classificador de sentimento, ou como um script de atendimento ao cliente. A maior parte das anotações pessoais achata a prosa em bullets.
Minha prática legisla a forma. O digestor do diário transforma as notas brutas do dia em uma entrada em voz de mentor, por extenso, em exatamente três parágrafos de prosa sem subtítulo, terminando com ## Estrofe — uma estrofe curta que condensa a entrada em algo que pode ser lembrado. Não há cabeçalhos chamados Introdução, Desenvolvimento ou Conclusão. Não há fábula. Não há conselho. O mentor fala. Depois a estrofe chega.
O lado bruto do loop é igualmente prescritivo. A inbox é um único template que o sistema sobrescreve a cada dia:
date · energy · mood · tags #diary/raw
Agora — o que está mais presente na cabeça/corpo agora
Aconteceu Hoje — fatos, cenas, conversas, lugares, leituras, músicas, código, trabalho
Corpo E Energia — sono, alimentação, cansaço, ansiedade, foco, dor, movimento, respiração
Emoções — nomear sem explicar demais; o que ficou, o que passou, o que pede atenção
Pensamentos Recorrentes — ideias que voltaram mais de uma vez
Criação — música, letras, imagens, escrita, wiki, programação
Relações — quem apareceu, quem não, o que foi sentido
A inbox bruta antes do digest rodar. Data, slider de energia, mood, tags e sete prompts em português. O digestor lê isso, arquiva em raw/misc/personal-diary/archive/YYYY-MM-DD-HHMM-slug.md, escreve a entrada de três parágrafos em voz de mentor sob brain/misc/diary/, e zera o template. O bruto permanece bruto para sempre. A forma é a filosofia.
Isto é uma recusa da estética dominante do auto-rastreamento. O registro terapêutico, o registro de produtividade, o registro de chatbot — nenhum deles pertence a um sistema que está tentando constituir um self digno de ser. A estética é parte da filosofia. Um diário em bullets é uma pessoa diferente de um diário em três parágrafos e uma estrofe.
5. Soberania local sobre a camada do modelo
Minha selfware roda em hardware que eu possuo, em software que eu posso ler, com fornecedores de modelo que eu posso trocar. Isto não é apenas uma feature de privacidade. É a precondição para que o loop seja fechado e o self seja quem está dentro dele.
A camada do modelo é a questão de carga. Se seu digestor de diário pertence a um fornecedor, o fornecedor lê seu diário, o roadmap do fornecedor molda no que seu diário se torna, e o fornecedor pode revogar o acesso. O loop não é seu; você está dentro do loop do fornecedor.
Minha prática abstrai a camada do modelo atrás de um proxy LiteLLM local atendendo em 127.0.0.1:4000. Toda chamada de modelo — agente de livros, digestor de diário, Harry, OCR de foto-para-LaTeX, squad de personas em debate — fala a mesma API compatível com OpenAI. O proxy mapeia aliases voltados ao usuário (deepseek-pro, deepseek-flash, gpt-5.5, gpt-5.4, gpt-5.4-mini) para rotas específicas de cada fornecedor. No dia em que um fornecedor aumentar preços, revogar acesso ou for adquirido, eu edito uma linha de YAML, reinicio o proxy, e o stack segue. O stack precisa sobreviver ao próximo pivô, à próxima aquisição, à próxima onda de monetização.
Isto coloca minha prática numa linhagem mais antiga do que o software: o manifesto GNU de Stallman (1985), os princípios da IndieWeb de Tantek Çelik (anos 2000) e o paper Local-first software: You own your data, in spite of the cloud de Martin Kleppmann (2019). O que a selfware constitutiva acrescenta a essa linhagem é a alegação de que isto não é apenas soberania sobre dados. É soberania sobre o sistema que participa de produzir quem você é.
IV. O exemplar canônico
Rodo um stack que chamo de anderson-second-brain. É o exemplar canônico da minha prática de selfware. O código não é open source. Os dados internos são privados. O que estou oferecendo em público é a prática, os princípios e a arquitetura — não a implementação. A selfware de outra pessoa não vai parecer com a minha; o trabalho é construir a sua, não copiar a minha.
Topologia
anderson-second-brain/ ← raiz do brain
├── raw/ 195 MB · 111 arquivos ← fonte da verdade imutável
│ ├── papers/ 21 PDFs ← literatura de pesquisa
│ ├── books/ ← PDFs de referência e escrita-craft
│ ├── music/ 14 arquivos de áudio ← corpus de letras + áudio
│ ├── notes/ ← entradas brutas do dia
│ ├── misc/ blogs · chatgpt-exports · personal-diary
│ └── writing/ ← rascunhos criativos
│
├── brain/ 1.3 MB · 164 páginas Markdown · 3 regimes epistêmicos
│ ├── index.md ← portal global
│ ├── log.md 1.147 entradas append-only
│ ├── phd/ regime PhD — gate estrito
│ │ ├── concepts/ 17 páginas
│ │ ├── papers/ 19 resumos de papers
│ │ ├── projects/ 5 threads de pesquisa
│ │ ├── people/ 14 pesquisadores
│ │ ├── books/ 1 referência
│ │ └── glossary.md
│ ├── music/ regime de música — gate de procedência
│ │ ├── songs/ 50 páginas
│ │ ├── albums/ 3 páginas
│ │ ├── symbol-glossary.md símbolos recorrentes, com gate por recorrência
│ │ └── music-tags.md
│ └── misc/ regime sem gate
│ ├── blogs/ 3 posts processados
│ ├── diary/ 17 entradas digeridas
│ ├── chatgpt/ 5 exports processados
│ └── books/ 1 referência não-PhD
│
├── synthetics/ 99 MB · automação + artefatos gerados + runtime
│ ├── phd-lab/
│ │ └── harry-projects/ 6 projetos · 740 fases · 123 experimentos gerados
│ ├── writing/
│ │ ├── daily-books/ 2 novelas geradas (formato de 100 páginas)
│ │ └── daily-tales/ 8 contos curtos gerados
│ ├── brain-input-ui/ runtime da UI · run logs · estado de sessão
│ ├── squad/ configuração do proxy LiteLLM · litellm.env
│ └── scripts/
│ ├── brain_input_ui.py 23.182 LOC · servidor HTTP single-file + HTML/JS vanilla
│ ├── harry_researcher.py loop de pesquisa autônoma
│ ├── daily_book_litellm.py o agente de livros constitutivo
│ ├── litellm_client.py gateway de modelos compartilhado
│ └── … ingestão, sync calibre, digest do diário, hábitos, blog
│
├── AGENTS.md 40,2 KiB ← regulamento de agentes (ler antes de qualquer refactor LLM)
├── CLAUDE.md 21,5 KiB ← constituição operacional para mantedores IA
├── SKILLS.md 5,0 KiB ← lista canônica de skills
└── README.md 4,2 KiB
Três observações tornam esta topologia carga-portante.
Primeira: raw/ é imutável. Nenhum script escreve em raw/ exceto pelo caminho explícito de ingestão. Isto equivale ao source of truth em sistemas event-sourced: o brain é uma projeção, e uma projeção que pode ser reconstruída a partir do raw sem perda de fidelidade. Se o brain corromper, o raw permanece íntegro.
Segunda: brain/log.md é append-only, com 1.147 entradas no momento desta escrita. Registra cada página criada, atualizada, linkada ou sinalizada, em seções datadas. Entradas passadas nunca são editadas. O log é a autobiografia do próprio brain.
Terceira: AGENTS.md e CLAUDE.md juntos (≈61,7 KiB de regras operacionais) funcionam como uma constituição para qualquer LLM que toque o vault. Todo refactor começa com um Canonical Rule Pass: o agente lê os dois arquivos, marca cada regra aplicável como aplicada / não aplicável / bloqueada, e só então prossegue. Isto é governança sobre a camada do modelo no nível do prompt, antes de qualquer mudança de código.
Os componentes
Cada workflow no sistema é uma skill nomeada, invocada por uma única paleta de comandos em português. >ingerir <fonte> ingere uma fonte bruta no brain; >consultar <pergunta> consulta; >auditar reporta órfãos e contradições; >gerar-livro escreve a novela diária; >processar-diario digere a inbox; >sincronizar-calibre sincroniza livros com uma biblioteca local do Calibre. O vocabulário é o contrato. Nada no sistema é invocado a não ser por uma skill nomeada.
O lab de análise de papers. 38 papers de doutorado no workspace, 0 atualmente selecionados, teto de 30 anexos. O brief de análise é fixo: "problema central, método, premissas, equações, perguntas não resolvidas, próximos experimentos." Os PDFs brutos são extraídos a texto localmente com pdftotext; o LLM nunca vê o arquivo diretamente. Sessões são arquivadas (session-20260505-101002), revisáveis, replicáveis.
O code lab roda Python, Fortran e notebooks como instrumentos de pesquisa. Scripts gerados por IA vivem em synthetics/phd-lab/code/; figuras, tabelas e logs vão para synthetics/phd-lab/results/. Cada ação do lab é registrada: panel_selected, harry_run_started, harry_project_recovered com a rota LiteLLM usada. O lab é um sistema, não um freestyle.
Componentes por função
Harry — pesquisador autônomo. Máquina de estados sobre dez fases (busca de literatura até render do paper). Schema JSON por fase com visible_reasoning, claims atômicas e evidence_needed. Orçamento de fases por projeto: mínimo 1000, máximo 5000. Execução de código sandboxed. A política de auto-melhoria lê entradas recentes do ledger para detectar travamentos (ex.: "4 fases recentes não produziram delta durável → avança para analyze_result"). Um projeto (open-question-i-radiative-heat-trasnfer) atualmente na fase 647/5000.
Agente de livros diários — cibernética generativa. Escreve uma novela de cem páginas por solicitação, lê reader-profile.md, reader-memory.md, o snapshot atual do brain e as mudanças recentes do brain. Produz book.md, book.epub, feedback.md, soundtrack.md, um outline, arquivos de capítulo e os prompts usados. O feedback.md é o slot de resposta do usuário; ingerir o arquivo atualiza reader-memory.md e feedback-log.md para o próximo livro.
Agente de contos diários — mesmo formato, em forma mais curta (leitura em uma sentada).
Digestor de diário — >processar-diario. Lê raw/misc/personal-diary/YYYY-MM-DD-diary-template.md, arquiva o template preenchido sob archive/YYYY-MM-DD-HHMM-slug.md, escreve a entrada digerida sob brain/misc/diary/ (três parágrafos em voz de mentor, terminando em ## Estrofe), e zera o template.
Squad — debate multi-persona. Um elenco configurável de personas baseadas em LLM discute um brief, cada uma lendo documentos compartilhados e produzindo críticas. Armazenado em synthetics/squad/runs/.
Brain input UI — arquivo Python único, 23.182 linhas, HTML/JavaScript vanilla, sem build step, sem React, sem Electron. Instalável como PWA. Seis tabs no topo, seis sub-painéis no lab, sete sub-painéis no personal, cinco sub-painéis em media. App lock é uma senha numérica comparada contra BRAINPUT_APP_PASSWORD; o token de sessão é regenerado a cada start do servidor.
Proxy LiteLLM — gateway OpenAI-compatível local em 127.0.0.1:4000. Aliases (deepseek-pro → deepseek/deepseek-reasoner, etc.) carregam chaves de API de variáveis de ambiente. Auto-inicia com a UI; auto-encerra ao sair da UI; sobrevive a mudanças de fornecedor com a edição de um YAML.
A arquitetura é replicável. A instância não é. Quem tentar copiar meu stack exato vai falhar; o que se deve copiar são os princípios, e moldar uma instância à própria vida.
V. A objeção que mais escuto
A primeira objeção é solipsismo. Um sistema afinado a um único leitor, escrevendo livros para esse leitor, ingerindo o feedback desse leitor, vai cada vez mais dizer a esse leitor o que esse leitor já é. O loop fechado é um loop de conforto. O self produzido é um self num salão de espelhos.
Esta é a objeção mais forte. Qualquer prática de selfware precisa respondê-la. Três respostas, em ordem crescente de importância.
Primeiro, minha selfware não é o único loop em que estou. Ela vive ao lado de leitura pública, escrita pública, revisão pública, orientadores, amigos, editores e desconhecidos — loops que eu não controlo. Um self que ingerisse apenas a própria selfware seria um self fechado. Nenhum praticante de selfware em quem eu confiaria vive assim. Selfware é uma prática privada, e uma prática privada é perigosa sem contrapesos públicos.
Segundo, a disciplina epistêmica dentro da minha prática combate o loop de conforto diretamente. Claims atômicas com suporte. Contradições nomeadas. Raciocínio visível. Registros de evidência. O ponto de tratar minha própria produção de conhecimento com rigor de revisão por pares é precisamente manter o loop honesto. Um diário que apenas conforta não é selfware; é um app de journaling. Um loop de pesquisa que apenas confirma não é selfware; é uma máquina de alucinação. Os princípios que nomeei não são ornamentos opcionais. São o que torna o loop sobrevivível.
Terceiro, e mais importante, selfware é uma prática, não um produto. O praticante precisa querer ser mudado pela prática. Se você adota selfware para confirmar o que você já é, a prática vai falhar com você, e a falha vai ser visível — seu diário vai encolher, seu pesquisador não vai produzir claims que consiga sustentar, seus livros vão deixar de surpreendê-lo. A prática expõe o próprio colapso. Esse é o design.
VI. Aquilo contra o que esta prática se opõe
Toda prática que vale a pena ter é contra alguma coisa. O primeiro ensaio da minha selfware deve nomear o que ela recusa.
É contra software-as-a-service que aluga sua vida interior para você. Seu diário, sua lista de leitura, seus rascunhos de música, sua sessão de terapia por chat, suas sessões de leitura-com-IA: esses não são serviços que devem ser alugados de um fornecedor cujo roadmap é moldado por uma chamada trimestral de resultados. Os artefatos de um self devem viver em hardware que esse self possui.
É contra a IA terapêutica em bullets que achata uma pessoa em uma nuvem de tags e um plano de ação. Um self não é uma sequência de bullets. A voz que se dirige a um self deve ser uma voz digna de confiança. Se você não consegue suportar ler o que seu sistema escreve sobre você, o sistema não é seu.
É contra o enquadramento de produtividade da computação pessoal. Um self não é um backlog para otimizar. Um second brain que existe para fazer de você um trabalhador mais eficiente entendeu mal para que um second brain serve. O ponto não é fazer mais. O ponto é tornar-se.
É contra chain-of-thought escondida como a epistemologia dominante da IA pessoal. Um raciocínio que seu sistema não te mostra é um raciocínio que você não pode avaliar. Minha prática toma a posição de que o que o sistema faz em seu nome deve ser auditável. Raciocínio visível não é uma feature de transparência. É o preço da confiança.
VII. Um chamado
Selfware já é uma palavra disputada. As pessoas vão brigar sobre o que ela significa. Não vou vencer essa briga, e não quero. O que eu quero é ver outros espécimes.
Se você leu o que escrevi aqui e reconheceu o que eu faço, construa o seu. Documente. Nomeie como seu — A Prática de Selfware da Maria, A Prática de Selfware do João, A Prática de Selfware da Beatriz, qualquer que seja seu nome em qualquer língua que seja sua. Publique a arquitetura. Mantenha os dados. Faça sua selfware identificável como sua e de mais ninguém.
Uma categoria com uma única definição é uma marca. Uma categoria com muitas instâncias nomeadas é uma tradição.
Quero a tradição. Se três de nós fizermos isto, começamos uma. Se trinta fizermos, temos um movimento pequeno mas legível. Se trezentos fizermos, a próxima geração da computação pessoal vai parecer diferente da que os fornecedores estão vendendo — e a diferença não é quem construiu nossas ferramentas, mas o que nossas ferramentas construíram dentro de nós.
Esta é A Prática de Selfware de Anderson. Qual é a sua?
Um relatório de campo sobre uma prática de selfware. O artefato é anderson-second-brain — um stack privado: 195 MB de fonte bruta, 1,3 MB de brain processado em 164 páginas, 99 MB de artefatos sintéticos, 23.182 linhas de código de UI, 1.147 entradas no log, 740 fases do Harry, 123 experimentos gerados, 50 canções, 17 conceitos, 19 resumos de papers, 17 entradas de diário digeridas. O argumento e a arquitetura são oferecidos para teste de estresse; a implementação e os dados ficam comigo. O convite é para outros praticantes nomearem e documentarem a sua.
Linhagem
- Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine (1948) — o loop fechado como objeto de estudo.
- Gordon Pask, teoria da conversação (anos 1970) — o loop entre dois interlocutores.
- Paul Ricoeur, Soi-même comme un autre (1990; ed. brasileira: O si-mesmo como um outro) — a identidade-ipse como selfhood através da mudança.
- Pierre Bourdieu, Esquisse d'une théorie de la pratique (1972; ed. brasileira: Esboço de uma teoria da prática) — o habitus como disposições incorporadas que moldam e são moldadas pela prática.
- Michel Foucault, Le souci de soi (1984; ed. brasileira: O cuidado de si) — hupomnemata, técnicas do self, a prática da auto-escrita na filosofia helenística.
- Richard Stallman, GNU Manifesto (1985) — a afirmação política do software livre.
- Tantek Çelik et al., IndieWeb principles (anos 2000) — own your data, own your URL.
- Martin Kleppmann et al., Local-first software: You own your data, in spite of the cloud (2019) — o caso técnico.
Texto escrito pelo Selfware de Anderson