DEV Community: Marcos Filipe

Concluí o Volume 1 da Stackovia Learning Series: 13 capítulos gratuitos + projeto integrador

Marcos Filipe — Fri, 29 May 2026 21:22:23 +0000

Há pouco tempo eu publiquei o início de um projeto open source que comecei a construir: a Stackovia Learning Series.

A ideia era simples, mas ambiciosa: criar uma série gratuita de estudos em desenvolvimento moderno, começando pelos fundamentos e evoluindo, aos poucos, para frontend, backend, full stack, DevOps, arquitetura, IA, agentes e segurança.

Agora tenho um marco importante para compartilhar:

o Volume 1 está completo em preview.

São 13 capítulos publicados e um projeto integrador completo para download, para o aluno desenvolver ao longo do curso.

Hub da série:
https://mffdeo.github.io/stackovia-learning/

Volume 1:
https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/

Projeto integrador:
https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/projeto-integrador.html

Por que esse projeto existe?

Nem sempre as pessoas têm dinheiro para pagar cursos.

Muita gente quer aprender tecnologia, construir projetos e evoluir profissionalmente, mas encontra alguns obstáculos comuns:

conteúdo espalhado;
excesso de teoria sem prática;
projetos que não geram portfólio;
falta de progressão;
falta de clareza sobre o que estudar primeiro;
pouca explicação sobre como transformar estudo em evidência real.

A Stackovia nasceu para tentar atacar esse problema de forma aberta.

Não como uma promessa milagrosa, nem como “o curso definitivo”, mas como uma trilha prática, gratuita e em construção pública.

A ideia é que cada volume ajude o aluno a aprender um conjunto de fundamentos, construir algo concreto e sair com evidências no GitHub, no LinkedIn e no próprio portfólio.

O que é a Stackovia Learning Series?

A Stackovia Learning Series é uma série open source organizada em volumes.

A proposta geral é sair dos fundamentos e evoluir para temas modernos de desenvolvimento de software:

Fundamentos do Desenvolvedor Moderno
Frontend Profissional com React e Next.js
Backend Profissional com FastAPI
Full Stack: Produto Real de Ponta a Ponta
System Design, Software Architecture e Aplicações Robustas
Docker, AWS e DevOps Foundation
Kubernetes e Platform Engineering
Prompt Engineering e Fundamentos de LLMs
AI Engineer: Embeddings, Vector DB, RAG e Multimodal
AI Agents em Produção
AI Red Teaming, Governança e Tech Lead Capstone

O Volume 1 é a base dessa jornada.

O que tem no Volume 1?

O Volume 1 se chama:

Fundamentos do Desenvolvedor Moderno

Ele foi pensado para quem está começando ou quer reorganizar a base.

Não é um volume sobre frameworks. Não começa com React, Next.js, FastAPI, Docker ou IA.

Ele começa antes disso.

Começa com o que muita gente pula:

como a internet funciona na prática;
terminal, pastas e arquivos;
Git;
GitHub;
README;
Pull Request;
HTML semântico;
CSS responsivo;
JavaScript básico;
HTTP e fetch;
formulários;
segurança básica;
publicação estática;
portfólio;
release e divulgação honesta.

O objetivo é criar uma base profissional antes de acelerar para ferramentas mais avançadas.

Os 13 capítulos publicados

O Volume 1 está organizado em 13 capítulos:

Entrada na Stackovia e setup da jornada
Como a internet funciona na prática
Terminal, pastas, arquivos e ambiente
Git como memória do aprendizado
GitHub, README e Pull Request
HTML semântico para a primeira página
CSS moderno e layout responsivo
JavaScript básico aplicado ao IntraStack
HTTP, request/response e dados mockados
Formulário, validação simples e erros comuns
Segurança básica desde cedo
Publicação estática e checklist de portfólio
Fechamento: release, LinkedIn e próximos passos

Todos estão publicados no site do Volume 1:

https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/

O projeto integrador: IntraStack Básico

Além dos capítulos, o Volume 1 tem um projeto integrador completo:

IntraStack Básico

Ele é um portal interno fictício da Stackovia, criado com:

HTML;
CSS;
JavaScript;
dados mockados;
documentação;
checklist;
runbook;
smoke-check;
estrutura de projeto;
README;
assets;
páginas estáticas.

A proposta é que o aluno desenvolva esse projeto ao longo do volume, capítulo por capítulo.

A página do projeto integrador tem instruções para baixar, rodar localmente e explorar a estrutura:

https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/projeto-integrador.html

O aluno pode baixar via Git ou ZIP, rodar localmente e estudar o projeto como referência.

Por que chamar de “preview completo”?

Porque o Volume 1 já está completo em conteúdo navegável, mas ainda pode evoluir.

Ainda pretendo melhorar:

revisão editorial fina;
diagramação futura em PDF;
exemplos adicionais;
correções sugeridas pela comunidade;
pequenos ajustes de clareza;
melhorias no projeto integrador.

Então prefiro chamar de preview completo.

Isso comunica melhor o estado real do projeto: já dá para estudar, ler e usar, mas ainda está aberto a melhoria.

O que eu aprendi construindo esse volume?

Aprendi que criar material didático exige muito mais do que escrever texto.

Foi necessário pensar em:

progressão pedagógica;
escopo;
ordem de aprendizagem;
exemplos antes da teoria;
projeto integrador;
consistência entre capítulos;
revisão;
publicação;
GitHub Pages;
VitePress;
open source;
documentação;
licença;
portfólio;
segurança básica;
feedback público.

Também aprendi que ensinar, mesmo enquanto ainda estou aprendendo, força uma postura diferente.

Quando você escreve para outra pessoa entender, você percebe rapidamente onde seu próprio entendimento ainda está frágil.

O papel da IA no processo

Tenho estudado bastante o uso de IA no desenvolvimento de software.

Neste projeto, a IA foi usada como apoio para organizar ideias, revisar estrutura, sugerir melhorias, validar consistência e acelerar algumas etapas do fluxo.

Mas a Stackovia não é “texto jogado por IA”.

O projeto tem revisão humana, controle de escopo, decisões registradas, preocupação com segurança, progressão e qualidade.

Meu interesse em IA no desenvolvimento não é substituir fundamentos. É entender como ela pode ajudar em fluxos reais:

documentação;
revisão;
organização de contexto;
planejamento;
testes;
avaliação;
produtividade;
rastreabilidade;
segurança.

IA ajuda bastante, mas não elimina responsabilidade técnica.

Para quem esse Volume 1 pode ajudar?

Acredito que pode ser útil para:

quem está começando em desenvolvimento web;
quem quer revisar fundamentos;
quem quer organizar melhor o próprio aprendizado;
quem quer transformar estudo em portfólio;
quem quer aprender Git/GitHub com contexto;
quem sente que pulou etapas importantes;
quem quer material gratuito em português.

Não é um atalho. É uma trilha.

Links do projeto

Hub da Stackovia Learning Series:
https://mffdeo.github.io/stackovia-learning/

Volume 1 — Fundamentos do Desenvolvedor Moderno:
https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/

Projeto integrador — IntraStack Básico:
https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/projeto-integrador.html

Repositório hub:
https://github.com/mffdeo/stackovia-learning

Repositório do Volume 1:
https://github.com/mffdeo/stackovia-vol01-fundamentos-dev-moderno

Como você pode ajudar

Se você puder acessar, ler algum capítulo e mandar feedback, já vai ajudar muito.

Alguns tipos de feedback que seriam muito úteis:

explicação confusa;
erro de digitação;
capítulo longo demais;
capítulo raso demais;
sugestão de exemplo;
melhoria no projeto integrador;
problema no site;
sugestão para próximos volumes.

Se a proposta fizer sentido, também agradeço quem puder dar uma estrela no GitHub e compartilhar com alguém que esteja estudando tecnologia.

A Stackovia é um projeto em construção, mas agora o primeiro volume já existe de verdade.

E isso, para mim, é um marco importante.

Design de sistemas não é sobre parecer sofisticado: é sobre resolver o problema certo

Marcos Filipe — Fri, 29 May 2026 02:58:03 +0000

Recentemente assisti a uma entrevista com Bassem Dghaidi, engenheiro de software sênior no GitHub, falando sobre design de sistemas. O tema me chamou muita atenção porque, quanto mais estudo engenharia de software, arquitetura, backend e IA aplicada ao desenvolvimento, mais percebo uma coisa: a parte difícil não é apenas conhecer tecnologias. A parte difícil é saber quando usar, por que usar e qual problema real aquela decisão resolve.

Muita gente olha para empresas como GitHub, Google, Netflix, Uber ou Amazon e pensa: “se eles usam arquitetura distribuída, Kubernetes, filas, cache, NoSQL, sharding, feature flags e observabilidade avançada, então eu também preciso usar tudo isso no meu projeto”.

Mas talvez essa seja uma das maiores armadilhas do aprendizado em tecnologia.

O ponto mais forte da entrevista, para mim, foi este: design de sistemas não é uma competição para ver quem desenha a arquitetura mais sofisticada. É uma disciplina para tomar decisões técnicas compatíveis com o problema, a escala, o risco e o momento do negócio.

A armadilha da arquitetura por status

Uma parte da conversa fala sobre empresas que migram para Kubernetes, microsserviços ou arquiteturas cloud native não porque realmente precisam, mas porque aquilo parece moderno, bonito ou valorizado no mercado.

Isso acontece muito.

Às vezes a empresa ainda não tem escala. Às vezes o produto ainda nem validou mercado. Às vezes o time é pequeno. Às vezes o problema caberia muito bem em uma aplicação monolítica bem organizada, rodando em uma VM simples, com um banco relacional bem configurado.

Mesmo assim, a equipe decide montar uma arquitetura complexa demais.

O resultado pode ser perigoso: aumento de custo, mais pontos de falha, mais dificuldade de deploy, mais carga cognitiva para o time, mais tempo gasto mantendo infraestrutura e menos tempo entregando valor.

Existe uma frase que ficou forte para mim: o simples já é complicado o suficiente, especialmente em escala.

Essa frase resume muita coisa.

Simplicidade não é falta de conhecimento. Muitas vezes, simplicidade é justamente o resultado de maturidade. É saber que uma decisão técnica não deve ser tomada apenas porque “todo mundo está falando disso”, mas porque existe uma necessidade concreta.

Escalar antes da hora também é uma forma de desperdício

Um dos aprendizados mais importantes da entrevista foi a ideia de não projetar para uma escala imaginária de 10 anos no futuro.

É claro que precisamos pensar em evolução. Ninguém está defendendo código bagunçado, gambiarra sem critério ou ausência de arquitetura. Mas existe uma diferença enorme entre preparar um sistema para evoluir e construir hoje uma arquitetura para uma escala que talvez nunca chegue.

Muitas vezes, uma aplicação simples pode ir muito mais longe do que imaginamos. Escala vertical, uma boa modelagem de dados, bons índices, cache apenas quando necessário, observabilidade mínima e deploy bem feito já resolvem muitos problemas reais.

Antes de falar em sharding, múltiplos bancos, event streaming, microsserviços e infraestrutura distribuída, talvez a pergunta deveria ser:

qual é o gargalo real que temos hoje?

Se não existe métrica, talvez ainda não exista justificativa.

E isso muda completamente a conversa.

Em vez de “acho que precisamos de Kafka”, a discussão madura seria:

qual problema de negócio estamos tentando resolver?
qual volume atual?
qual volume esperado?
qual limite da arquitetura atual?
qual o custo de manter a solução atual?
qual o custo de migrar?
qual risco operacional estamos aceitando?
qual métrica prova que chegou a hora de mudar?

Sem esse tipo de pergunta, a arquitetura vira opinião. E opinião técnica sem contexto pode custar caro.

Software não é construído uma vez; software evolui

Outro ponto muito forte é a ideia de que software não é algo que você compra, entrega uma vez e esquece.

Muitas empresas ainda tratam software como obra fechada: paga-se uma vez, entrega-se o sistema e espera-se que ele dure anos sem investimento relevante. Mas software vive em um ambiente que muda: usuários mudam, regras mudam, mercado muda, infraestrutura muda, ameaças de segurança mudam, volume muda, dependências mudam.

Por isso, arquitetura precisa ser pensada como evolução contínua.

Não significa reescrever tudo a cada ano. Também não significa aceitar complexidade infinita. Significa revisar decisões, observar sinais, medir limites e planejar a próxima ordem de magnitude.

Essa ideia me marcou bastante: talvez a pergunta não seja “como faço uma arquitetura para durar 10 anos?”, mas sim:

qual arquitetura me leva com segurança até o próximo estágio?

Quando esse próximo estágio chegar, fazemos uma nova rodada de decisões com mais dados, mais aprendizado e mais clareza.

Resolver problema específico antes de criar solução genérica

Também gostei muito da crítica contra soluções genéricas demais.

Como desenvolvedores, é tentador criar abstrações, frameworks internos e componentes flexíveis para cenários que talvez nunca aconteçam. A intenção geralmente é boa: queremos deixar o sistema preparado para o futuro.

Mas existe um risco: quanto mais genérica uma solução fica, mais difícil pode ser entendê-la, testá-la, mantê-la e explicar suas decisões.

Resolver um problema específico primeiro tem uma vantagem enorme: você conhece melhor as restrições.

Você sabe o que importa.
Você sabe o que pode ser sacrificado.
Você sabe quais trade-offs está fazendo.
Você sabe quem é o usuário real.
Você sabe qual dor está resolvendo.

Depois, se padrões reais começarem a aparecer, aí sim pode fazer sentido extrair uma abstração.

Mas abstrair cedo demais pode virar apenas complexidade disfarçada de elegância.

Impacto de negócio importa

Outro aprendizado importante: engenharia de software profissional não é hobby.

Isso não significa abandonar o cuidado técnico. Pelo contrário. Significa entender que qualidade técnica precisa conversar com impacto real.

Não basta dizer:

“Melhorei a arquitetura.”
“Deixei o código mais limpo.”
“Criei uma infraestrutura moderna.”
“Implantei Kubernetes.”
“Adicionei cache.”
“Migrei para microsserviços.”

A pergunta mais madura é:

qual impacto isso teve?

Reduziu custo?
Aumentou confiabilidade?
Diminuiu tempo de resposta?
Reduziu incidentes?
Melhorou a experiência do usuário?
Acelerou entrega?
Reduziu risco?
Ajudou o negócio a operar melhor?

Essa parte me conecta muito com minha própria trajetória. Venho de uma área operacional, de ambiente crítico, onde decisão errada pode custar caro. Em uma operação real, não adianta ter o equipamento mais sofisticado se ele não resolve o problema no momento certo. Tecnologia, no fim, precisa servir à missão.

Na engenharia de software é parecido.

A solução mais bonita nem sempre é a solução mais adequada. Às vezes, o melhor sistema é aquele que resolve bem o problema de hoje, com segurança, clareza e espaço para evoluir.

E onde entra a IA nisso?

Esse ponto ficou ainda mais importante para mim por causa do momento atual da IA.

Com agentes de código, copilots e ferramentas cada vez mais poderosas, ficou mais fácil produzir código em grande volume. Mas isso também aumenta o risco de produzir complexidade em grande volume.

Se antes um desenvolvedor podia criar um sistema confuso em semanas, agora talvez consiga criar em horas.

Por isso, design de sistemas tende a ficar ainda mais importante. A habilidade principal não será apenas escrever código. Será saber orientar a construção, revisar decisões, entender requisitos, avaliar riscos, medir impacto e impedir que a velocidade da IA gere uma dívida técnica que ninguém consegue sustentar depois.

A IA pode acelerar muito a implementação. Mas ela não substitui responsabilidade arquitetural.

Meu principal aprendizado

Depois de assistir a essa entrevista, fiquei com uma reflexão:

um bom engenheiro não é aquele que usa a arquitetura mais avançada. É aquele que entende o problema o suficiente para escolher a solução mais apropriada.

Às vezes isso será um monólito.
Às vezes será uma VM.
Às vezes será um banco relacional.
Às vezes será cache.
Às vezes será fila.
Às vezes será microsserviço.
Às vezes será Kubernetes.
Às vezes será uma arquitetura distribuída complexa.

Mas a ordem importa.

Primeiro vem o problema.
Depois vêm as restrições.
Depois vêm as métricas.
Depois vêm os trade-offs.
Só então vem a tecnologia.

Esse é um aprendizado que quero carregar nos meus estudos e projetos: buscar fundamentos, entender contexto, evitar modismo e lembrar que software bom não é necessariamente o mais sofisticado.

Software bom é aquele que resolve o problema certo, no momento certo, com o nível certo de complexidade.

Tentei criar uma CLI para governar código gerado por IA — e descobri que o problema era outro

Marcos Filipe — Sat, 23 May 2026 20:43:24 +0000

Nos últimos tempos eu venho estudando bastante desenvolvimento assistido por IA, agentes de código, SPECs, policy gates, revisão humana, evidências e fluxos de trabalho mais seguros antes de abrir um pull request.

Como parte desse estudo, criei um projeto pessoal chamado DevForge CLI.

A ideia inicial era ambiciosa:

E se existisse uma CLI local-first capaz de ajudar a governar mudanças feitas com IA antes do merge?

O fluxo que eu queria era mais ou menos este:

init -> scan -> specify -> plan -> implement -> policy check -> review -> evidence -> pr-ready

Ou seja:

inicializar uma estrutura local de governança;
escanear o projeto;
transformar uma ideia em SPEC;
gerar um plano;
entregar um briefing para um agente de IA implementar;
rodar um policy check no diff;
registrar revisão humana quando necessário;
gerar um pacote de evidências;
preparar orientação de commit e pull request.

Na minha cabeça, isso parecia um fluxo bem lógico.

Mas, testando na prática, descobri que o problema real era mais difícil.

A ideia original

O DevForge CLI nasceu como uma tentativa de organizar o caos do desenvolvimento assistido por IA.

Hoje é muito fácil pedir para uma IA implementar uma feature. O problema começa depois:

O que exatamente ela deveria implementar?
Qual era o escopo?
Ela tocou arquivos sensíveis?
Ela inventou coisa fora da SPEC?
Existe evidência de teste?
Alguém revisou?
O pull request está minimamente explicável?
O que deve ou não entrar no commit?

Eu queria uma CLI que criasse uma trilha local, simples e auditável.

A ideia não era substituir Cursor, Copilot, Codex, Claude Code ou qualquer agente de código. A ideia era criar um “cinto de segurança” ao redor deles.

Algo como:

Agentes executam. DevForge governa.

Pelo menos essa era a ideia inicial.

O que funcionou bem

Algumas partes funcionaram melhor do que eu esperava.

1. SPECs e briefs ajudam muito

Uma das melhores descobertas foi que o valor não estava apenas no comando em si, mas nos artefatos gerados.

Por exemplo:

Specification Brief;
SPEC;
Plan Pack;
Context Pack;
Implementation Brief;
Agent Instructions;
Policy Decision;
Human Review;
Evidence Pack;
PR Ready guidance.

Esses arquivos em Markdown e JSON ajudam a tornar o processo mais explícito.

Em vez de simplesmente dizer para a IA:

implemente essa feature

o fluxo passa a gerar algo mais estruturado:

implemente a feature usando este briefing, dentro deste escopo, respeitando estas restrições, e depois rode policy check.

Isso já melhora bastante a qualidade do handoff entre humano e agente.

2. O Evidence Pack foi útil

Outra parte que fez sentido foi o pacote de evidências.

A ideia era simples: antes de abrir ou mergear um PR, gerar um resumo local com:

diff analisado;
policy decision;
test report;
revisão humana, se exigida;
rollback plan, se exigido;
audit log;
decisão final.

Isso não prova que a mudança está perfeita, mas ajuda a responder:

O que foi feito, quais riscos foram identificados e quais evidências existem?

Para um projeto pessoal, isso já foi um aprendizado importante.

3. O PR Ready também fez sentido

Outra parte útil foi o comando que prepara orientação para commit e pull request.

Em vez de simplesmente mandar o usuário fazer:

git add .
git commit -m "..."

o DevForge passou a sugerir quais arquivos deveriam entrar e quais deveriam ficar fora.

Por exemplo:

Required files to commit:
- app.py
- db_create.py
- templates/index.html
- specs/SPEC-...
- docs/rollback/...
- .devforge/evidence/...

Do not commit:
- .venv/
- *.db
- *.sqlite
- __pycache__/

Isso parece pequeno, mas ajuda muito quando agentes de IA geram vários arquivos e artefatos.

Onde começou a quebrar

O problema apareceu quando tentei fazer o DevForge entender projetos diferentes de forma determinística.

No primeiro teste, usei um Todo App com Flask e SQLite.

A feature era simples:

Adicionar prioridade às tarefas: Baixa, Média e Alta.

Nesse caso, o DevForge até fazia sentido. A feature tocava formulário, template, código Python e banco SQLite. Então fazia sentido falar de schema, rollback plan, test report e revisão humana.

Mas depois testei em outro projeto: uma calculadora CLI simples em Python.

A nova feature era:

Adicionar histórico de cálculos durante a sessão.

Esse projeto não tinha:

banco;
autenticação;
cloud;
dados pessoais;
schema;
login;
permissões.

Era apenas uma CLI local.

E aí os problemas apareceram.

O problema das heurísticas

O scanner e o planner começaram a confundir palavras.

Por exemplo:

input() parecia dado de usuário;
user parecia dado pessoal;
session parecia autenticação;
“no database” ainda continha a palavra database;
“sem banco” ainda continha a palavra banco.

Ou seja: o código estava tentando interpretar intenção usando heurísticas simples.

E isso é frágil.

A palavra “session” pode significar uma sessão autenticada em um sistema web, mas também pode significar apenas “sessão local de uso” em uma calculadora CLI.

A palavra “user” pode significar um usuário cadastrado, com dados pessoais e permissões, mas também pode significar apenas “a pessoa usando o terminal”.

A frase “no database” fala justamente que não tem banco, mas um scanner ingênuo pode ver a palavra “database” e classificar risco errado.

Esse foi o ponto em que ficou claro:

O problema não era só corrigir keywords. O problema era arquitetural.

A grande descoberta

A principal descoberta foi esta:

O DevForge não deveria tentar ser um scanner universal que entende qualquer projeto sozinho.

Ele deveria ser um harness de governança.

Ou seja, em vez de fingir que sabe tudo, ele deveria:

coletar sinais determinísticos;
gerar um Project Profile preliminar;
expor assumptions e gray areas;
permitir revisão ou refinamento por IA externa;
exigir aprovação humana do perfil;
gerar SPECs e planos como drafts revisáveis;
registrar evidências e decisões.

A diferença é sutil, mas importante.

Antes eu pensava:

DevForge entende o projeto -> decide o risco -> gera o plano

Depois dos testes, passei a enxergar melhor assim:

DevForge coleta sinais -> gera artefatos revisáveis -> guia IA e humano -> registra decisões

Isso é muito mais realista.

O scanner não deve decidir sozinho

Um scanner determinístico é útil para coisas como:

listar extensões;
detectar arquivos .py, package.json, pyproject.toml, go.mod;
encontrar migrations;
detectar arquivos .env;
detectar bancos locais;
calcular diff;
identificar arquivos gerados;
registrar audit trail.

Mas ele não deveria concluir sozinho:

este projeto lida com dados pessoais

ou:

esta feature é autenticação

ou:

essa mudança exige aprovação humana

sem considerar contexto, SPEC e revisão.

A melhor função do scanner é gerar um draft.

Um draft pode estar errado.

E tudo bem — desde que o fluxo deixe isso claro.

O papel da IA nesse fluxo

Curiosamente, eu comecei tentando criar uma ferramenta para governar IA, mas acabei percebendo que a própria IA também pode ajudar no processo de governança.

Só que não como mágica escondida.

O uso mais interessante da IA aqui seria:

revisar um Project Profile;
identificar gray areas;
melhorar uma SPEC;
revisar um Implementation Brief;
apontar riscos em um diff;
sugerir evidências necessárias.

Mas sempre com uma regra:

A IA pode ajudar a raciocinar, mas a decisão importante precisa ser explícita, revisável e aprovada por humano.

No DevForge, isso levou à ideia de separar:

deterministic signals
agent-assisted reasoning
human-confirmed governance

Esse modelo é muito mais forte do que tentar fazer tudo com regras fixas.

O que eu aprendi com o projeto

Algumas lições ficaram bem claras.

1. Heurísticas são boas para sinais, não para verdade final

O scan pode dizer:

encontrei arquivos Python
encontrei SQLite
encontrei migrations
encontrei arquivos alterados

Mas não deveria dizer com confiança absoluta:

essa feature é de alto risco

sem contexto suficiente.

2. SPEC é mais importante do que parece

A SPEC virou o contrato da mudança.

Quando a SPEC era fraca, o plano ficava ruim.

Quando a SPEC tinha objetivo, fora de escopo, riscos, critérios de aceite e gray areas, o fluxo melhorava.

Isso me fez perceber que, em desenvolvimento com IA, especificar bem é quase tão importante quanto codar.

3. “Handoff” é uma palavra-chave

O maior valor do DevForge não foi automatizar tudo.

Foi criar handoffs melhores:

da ideia para a SPEC;
da SPEC para o plano;
do plano para o agente;
da implementação para o policy check;
do policy check para a revisão;
da revisão para o Evidence Pack;
do Evidence Pack para o PR.

Esses handoffs tornam o processo mais rastreável.

4. Governança não é bloquear tudo

No começo, o fluxo tendia a exigir revisão humana e rollback plan em excesso.

Mas isso também é ruim.

Uma mudança local, simples, sem banco, sem auth e sem dados pessoais não deveria ter o mesmo peso de uma mudança em login, pagamento ou dados sensíveis.

Governança boa precisa ser proporcional.

5. Projeto experimental precisa dizer que é experimental

Esse talvez seja o ponto mais importante para um projeto público.

Depois dos testes, reposicionei o DevForge CLI como:

A local-first experiment for AI-assisted software governance.

E deixei claro:

não é ferramenta de compliance;
não é produto de produção;
não é scanner universal;
não garante segurança;
outputs são drafts revisáveis.

Isso é mais honesto e, para mim, mais útil como projeto de aprendizado.

O estado atual do DevForge CLI

Hoje eu vejo o DevForge CLI como um laboratório pessoal.

Ele ainda tem comandos funcionais como:

devforge init
devforge scan
devforge profile approve
devforge specify --idea "Describe your feature idea"
devforge plan --spec specs/SPEC-ID.md
devforge implement --spec specs/SPEC-ID.md --agent custom --command "echo" --dry-run
devforge policy check --diff
devforge review --issue SPEC-ID
devforge evidence --issue SPEC-ID
devforge pr-ready --issue SPEC-ID

Mas tudo isso deve ser tratado como experimento.

Não é para confiar cegamente.

É para estudar o fluxo.

O que eu faria diferente se começasse de novo

Se eu fosse recomeçar do zero, eu faria diferente:

começaria pelo modelo de artefatos, não pelo scanner;
trataria todo scan como evidência bruta;
colocaria Project Profile como etapa aprovada pelo usuário;
usaria IA externa para refinar briefs e gray areas;
manteria as decisões importantes sempre editáveis e auditáveis;
evitaria qualquer promessa de produto antes de testar em muitos projetos reais.

Em resumo:

Eu não tentaria construir um scanner mágico. Eu construiria primeiro um sistema de handoffs.

Conclusão

O DevForge CLI não provou que uma CLI consegue governar automaticamente qualquer repositório.

Mas ele mostrou algo mais útil:

Desenvolvimento assistido por IA precisa de contexto, contratos, evidências, revisão humana e handoffs estruturados.

No fim, o valor não estava em fazer a ferramenta “entender tudo”.

O valor estava em organizar melhor a conversa entre humano, projeto, agente de IA e pull request.

E, para mim, isso já fez o projeto valer a pena.

Repositório: https://github.com/mffdeo/devforge-ai-cli

Landing page: https://mffdeo.github.io/devforge-ai-cli/

O fim do “modelo que faz tudo”? Conheça o Conductor, a IA que orquestra outras IAs

Marcos Filipe — Fri, 22 May 2026 16:03:08 +0000

OpenClaw, Hermes e Conductor mostram que o futuro da IA pode estar menos em chatbots isolados e mais em sistemas de agentes coordenados.

Sabe quando você usa um LLM para uma tarefa complexa e percebe que ele vai bem em uma parte, mas tropeça em outra?

Ele entende a ideia geral, mas erra o cálculo.

Gera código razoável, mas falha na arquitetura.

Explica bem, mas não sabe executar.

Tem bom raciocínio, mas não conhece o seu contexto.

Durante muito tempo, a solução mais comum foi tentar encontrar “o melhor modelo para tudo”.

Mas talvez a pergunta certa não seja:

Qual é o melhor modelo?

Talvez a pergunta mais importante seja:

Quem deve coordenar vários modelos, ferramentas e agentes para resolver uma tarefa complexa?

É nesse ponto que entra o Conductor, apresentado no artigo “Learning to Orchestrate Agents in Natural Language with the Conductor”, da Sakana AI.

Link do artigo:

https://arxiv.org/abs/2512.04388

E a ideia é muito interessante: em vez de criar mais um modelo gigante para tentar fazer tudo sozinho, os pesquisadores treinaram um modelo menor, de 7B parâmetros, para atuar como um maestro de outros LLMs.

Ele não é apenas mais um agente.

Ele é um orquestrador.

O que é o Conductor?

O Conductor é um modelo treinado com aprendizado por reforço, ou Reinforcement Learning, para coordenar outros modelos de linguagem.

Na prática, ele recebe uma tarefa complexa e decide como distribuir o trabalho entre diferentes “agentes trabalhadores”.

Esses trabalhadores podem ser modelos com capacidades diferentes: um melhor em código, outro melhor em raciocínio, outro melhor em análise, outro melhor em linguagem natural, e assim por diante.

O Conductor faz principalmente quatro coisas:

Decompõe o problema em partes menores.
Decide qual agente ou modelo deve resolver cada parte.
Escreve instruções específicas para cada trabalhador.
Define como esses trabalhadores podem trocar informações entre si.

Esse último ponto é muito importante.

O Conductor não apenas envia uma pergunta para vários modelos e escolhe a melhor resposta. Ele aprende a montar uma topologia de comunicação.

Ou seja: ele decide quem conversa com quem, em que ordem, com qual contexto e com qual objetivo.

Uma metáfora simples: o maestro e a orquestra

Imagine uma orquestra.

O violinista toca muito bem violino.

O pianista toca muito bem piano.

O percussionista entende ritmo.

O maestro talvez nem toque todos os instrumentos melhor do que cada músico.

Mas ele sabe algo essencial:

como coordenar todos eles para produzir uma música melhor do que qualquer músico sozinho conseguiria produzir.

Essa é a ideia do Conductor.

Ele não precisa ser o melhor modelo em tudo.

Ele precisa saber:

qual modelo chamar;
quando chamar;
com qual instrução;
com qual contexto;
e como combinar as respostas.

Em vez de pensar em IA como “um grande cérebro único”, começamos a pensar em IA como uma sinfonia de inteligências especializadas.

Diagrama conceitual

O ponto central não é apenas chamar vários modelos.

O ponto central é aprender a coordená-los.

Por que isso é diferente de um roteador simples?

Um roteador simples poderia fazer algo assim:

Se for tarefa de código -> mande para o modelo X
Se for tarefa de texto -> mande para o modelo Y
Se for tarefa matemática -> mande para o modelo Z

Isso é útil, mas ainda é limitado.

O Conductor vai além porque aprende estratégias mais dinâmicas.

Ele pode perceber que uma tarefa de código exige:

um agente planejador;
um agente implementador;
um agente revisor;
um agente verificador;
e talvez uma nova rodada de correção.

Ou seja, ele não apenas escolhe um modelo.

Ele monta um pequeno fluxo de trabalho.

E o mais interessante: segundo o artigo, o Conductor também pode ser chamado como um dos trabalhadores, criando estruturas recursivas. Em outras palavras, o maestro pode, em certos momentos, participar da própria execução.

Isso aponta para algo muito importante no futuro dos agentes:

a inteligência pode emergir não apenas do tamanho do modelo, mas da qualidade da coordenação entre modelos.

E onde entram OpenClaw e Hermes Agent?

Quando li sobre o Conductor, uma pergunta veio naturalmente:

Ele competiria com ferramentas como OpenClaw e Hermes Agent?

Depois de analisar melhor, a resposta mais honesta é:

sim, mas não diretamente.

A resposta mais completa é:

eles atuam em camadas diferentes de um mesmo futuro.

O Conductor está mais próximo da camada de orquestração cognitiva.

OpenClaw e Hermes Agent estão mais próximos da camada de execução, autonomia, memória e operação prática.

Não é exatamente uma competição “ferramenta contra ferramenta”.

É mais uma convergência de funções.

Comparando as camadas

Dimensão	Conductor	OpenClaw	Hermes Agent
Papel principal	Orquestrar modelos/agentes	Executar tarefas no ambiente do usuário	Aprender com o uso e manter continuidade
Analogia	Maestro	Assistente operacional / canivete suíço	Assistente persistente com memória
Foco	Delegação inteligente	Automação real de tarefas	Aprendizado contínuo e personalização
Pergunta que responde	“Quem deve resolver cada parte?”	“Como executar essa tarefa no mundo real?”	“Como melhorar com base no histórico?”
Camada	Coordenação	Execução	Memória + evolução
Melhor uso	Problemas complexos com múltiplas etapas	Tarefas práticas com ferramentas, arquivos, web e sistema	Assistente de longo prazo que aprende com você

Uma analogia de escritório

Imagine uma equipe trabalhando em um projeto complexo.

O OpenClaw seria aquele profissional operacional que consegue mexer em várias ferramentas: navegador, arquivos, terminal, automações, APIs e integrações. Ele tem “mãos”.

O Hermes Agent seria aquele assistente que vai aprendendo com o tempo. Ele lembra preferências, cria habilidades, evolui com base nas experiências anteriores e tenta se tornar mais útil a cada interação. Ele tem “memória”.

O Conductor seria o coordenador técnico que olha para o problema e diz:

“Essa parte vai para o agente de pesquisa.

Essa outra vai para o agente de código.

Depois o revisor confere.

Em seguida o verificador testa.

Só então eu combino tudo em uma resposta final.”

Ele tem “coordenação”.

Essas três capacidades são diferentes, mas complementares:

mãos;
memória;
coordenação.

E talvez o futuro da IA esteja justamente na fusão dessas três camadas.

A competição real ainda está se formando

Hoje, eu não vejo o Conductor como um substituto direto de OpenClaw ou Hermes.

Vejo como uma peça de uma camada superior.

Um sistema como OpenClaw pode ganhar muito se tiver um orquestrador melhor decidindo quais habilidades usar, em qual ordem e com quais permissões.

Um sistema como Hermes pode ganhar muito se tiver uma camada de coordenação mais sofisticada para organizar múltiplos perfis, subtarefas e agentes especializados.

E um Conductor, sozinho, também precisaria de ferramentas de execução, memória, permissões, ambiente, segurança e interface para virar um produto completo.

Então a pergunta não é:

Qual deles vence?

A pergunta mais interessante é:

Como essas capacidades vão se juntar?

O que isso ensina para quem desenvolve software?

Para mim, esse artigo reforça uma mudança importante no desenvolvimento com IA.

A primeira fase foi usar chatbots.

A segunda fase foi usar copilotos.

A terceira fase foi criar agentes com ferramentas.

Agora estamos entrando em uma fase em que a habilidade principal passa a ser orquestrar sistemas de agentes.

Isso muda o papel do desenvolvedor.

O desenvolvedor deixa de apenas pedir código para uma IA e passa a pensar em:

decomposição de tarefas;
escolha de modelos;
roteamento de contexto;
memória;
permissões;
segurança;
avaliação;
logs;
custo;
qualidade;
revisão humana;
e governança.

Ou seja, o problema deixa de ser apenas “gerar código”.

O problema passa a ser construir um sistema confiável de trabalho assistido por IA.

O risco: autonomia sem governança

Existe também um lado perigoso nessa evolução.

Quanto mais agentes ganham ferramentas, memória e capacidade de agir, maior fica a superfície de risco.

Um agente com acesso a arquivos, e-mail, terminal, navegador, banco de dados e APIs não é apenas um chatbot.

Ele é uma entidade operacional.

Se esse agente for mal instruído, mal isolado ou mal monitorado, ele pode:

executar comandos errados;
vazar informações;
acessar dados sensíveis;
tomar decisões sem aprovação;
criar automações perigosas;
ou simplesmente gerar caos em escala.

Por isso, a próxima geração de IA não pode ser apenas mais poderosa.

Ela precisa ser mais governável.

O futuro não será apenas sobre agentes autônomos.

Será sobre agentes autônomos com:

limites claros;
permissões explícitas;
trilhas de auditoria;
revisão humana;
avaliação contínua;
e mecanismos de segurança.

Para onde estamos convergindo?

Na minha visão, estamos convergindo para uma arquitetura com três grandes camadas.

1. Camada de orquestração

É onde entra algo como o Conductor.

Essa camada decide:

qual agente chamar;
qual modelo usar;
qual contexto enviar;
qual subtarefa executar;
qual resposta revisar;
e quando pedir intervenção humana.

Ela é o cérebro coordenador.

2. Camada de execução

É onde entram ferramentas como OpenClaw e outros agentes operacionais.

Essa camada executa ações:

abrir arquivos;
consultar APIs;
navegar na web;
escrever código;
rodar scripts;
criar documentos;
enviar mensagens;
interagir com sistemas.

Ela é o corpo operacional.

3. Camada de memória e aprendizado

É onde entram sistemas como Hermes Agent e arquiteturas com memória persistente.

Essa camada registra:

preferências;
decisões anteriores;
erros recorrentes;
habilidades aprendidas;
contexto de projetos;
padrões de trabalho;
e histórico de interações.

Ela é a continuidade.

A plataforma de IA do futuro

A plataforma de IA do futuro provavelmente não será apenas um chatbot bonito.

Também não será apenas um agente que executa comandos.

Ela será uma combinação de:

orquestração;
execução;
memória;
avaliação;
segurança;
governança;
e experiência de usuário.

Algo mais ou menos assim:

O grande diferencial não será apenas “ter IA”.

Será saber construir sistemas em que a IA consiga trabalhar com segurança, contexto e responsabilidade.

Conclusão

O Conductor é importante porque aponta para uma mudança de mentalidade.

A pergunta deixa de ser:

“Qual modelo é mais inteligente?”

E passa a ser:

“Qual sistema consegue coordenar melhor várias inteligências?”

OpenClaw, Hermes Agent e Conductor representam peças diferentes desse quebra-cabeça.

OpenClaw aponta para a execução.

Hermes aponta para memória e aprendizado contínuo.

Conductor aponta para orquestração.

Separados, eles já são interessantes.

Juntos, eles mostram para onde estamos indo.

Estamos saindo da era do modelo único e entrando na era dos sistemas de agentes coordenados.

Uma era em que a inteligência não estará apenas no modelo, mas na arquitetura ao redor dele.

A IA do futuro não será apenas um cérebro gigante.

Será uma orquestra.

E o grande desafio será construir o maestro, os instrumentos, as regras de segurança e a partitura certa.

Referências

Artigo do Conductor no arXiv:

https://arxiv.org/abs/2512.04388
Página da Sakana AI sobre o Conductor:

https://sakana.ai/learning-to-orchestrate/
OpenClaw no GitHub:

https://github.com/openclaw
Hermes Agent — documentação oficial:

https://hermes-agent.nousresearch.com/docs/
Hermes Agent no GitHub:

https://github.com/NousResearch/hermes-agent

Eu parei de rodar agentes de IA direto no meu WSL: usando Dev Containers + gVisor com Claude Code e Codex

Marcos Filipe — Wed, 20 May 2026 17:28:28 +0000

Nos últimos tempos, comecei a usar cada vez mais agentes de IA no terminal para desenvolvimento de software: Claude Code, Codex, OpenCode e outras ferramentas parecidas.

O fluxo parece simples:

cd meu-projeto
code .

Depois, dentro do terminal integrado do VS Code:

claude

ou:

codex

Só que aí veio uma dúvida importante:

Eu estou rodando esses agentes dentro de um ambiente seguro ou eles estão diretamente no meu sistema operacional?

A resposta, na maioria dos casos, é: se você só abriu o terminal do Ubuntu/WSL e digitou claude ou codex, provavelmente o agente está rodando direto no seu ambiente real.

E isso muda bastante o nível de risco.

Por que isso importa?

Agentes de IA para programação não são apenas chats que respondem perguntas.

Eles podem:

ler arquivos do projeto;
editar código;
criar arquivos;
apagar arquivos;
executar comandos de terminal;
instalar dependências;
rodar testes;
subir servidores locais;
acessar a internet, dependendo das permissões;
interagir com ferramentas do seu ambiente.

Isso é poderoso.

Mas também cria uma superfície de risco.

Imagine alguns cenários:

o agente entende errado uma instrução e executa um comando destrutivo;
você aprova um comando sem ler com atenção;
um arquivo do projeto contém uma instrução maliciosa para induzir o agente a agir fora do esperado;
o agente acessa arquivos que não deveria;
alguma dependência ou script executado pelo agente faz mais do que você imaginava.

Não é questão de demonizar as ferramentas. Pelo contrário: elas são extremamente úteis.

A questão é simples:

Se vamos dar autonomia para agentes executarem comandos, precisamos criar limites claros para onde eles podem atuar.

O problema do terminal “normal”

Meu fluxo antes era algo assim:

cd ~/projetos/meu-projeto
code .

Depois, no terminal integrado do VS Code:

claude

ou:

codex

O problema é que esse terminal estava apontando para algo como:

/home/meu-usuario/projetos/meu-projeto

Ou seja: eu estava no ambiente real do meu Ubuntu/WSL.

Nesse caso, o agente não está automaticamente dentro de um container só porque estou usando VS Code.

Ele está rodando no mesmo ambiente em que ficam minhas ferramentas, configurações, chaves, arquivos, histórico e dependências.

A ideia: colocar o ambiente de trabalho dentro de um Dev Container

O primeiro passo para melhorar isso é usar Dev Containers.

Com Dev Containers, o VS Code abre o projeto dentro de um container Docker. O editor continua confortável, mas o terminal, as extensões e as ferramentas de desenvolvimento passam a rodar dentro do container.

Na prática, o caminho muda de:

/home/meu-usuario/projetos/meu-projeto

para algo como:

/workspaces/meu-projeto

Esse detalhe é importante.

Quando o terminal mostra /workspaces/..., significa que você está dentro do Dev Container.

O fluxo passa a ser:

VS Code
→ Dev Container
→ ambiente isolado
→ agente de IA
→ projeto montado em /workspaces

A documentação oficial do VS Code explica que Dev Containers permitem abrir uma pasta dentro de um container e usar esse container como ambiente completo de desenvolvimento.

Referência: https://code.visualstudio.com/docs/devcontainers/containers

Mas Docker puro é suficiente?

Docker já ajuda bastante, mas container tradicional não é uma barreira perfeita.

Containers compartilham o kernel do host. Isso significa que eles isolam processos, filesystem, rede e permissões, mas não são a mesma coisa que uma máquina virtual completa.

Por isso existem camadas extras de isolamento, como:

permissões do próprio agente;
sandbox nativo da ferramenta;
seccomp;
gVisor;
microVMs.

Aqui é onde a confusão começa.

Muita gente fala “use Docker com Claude Code” ou “use sandbox com agente de IA”, mas isso pode significar coisas diferentes.

Pode significar:

rodar o agente dentro de um container;
fazer o código gerado aparecer no host por volume montado;
usar o sandbox nativo do agente;
usar gVisor como runtime do Docker;
usar microVMs.

No meu caso, eu queria um equilíbrio entre:

continuar usando VS Code normalmente;
manter o terminal integrado funcionando;
usar Claude Code e Codex dentro do projeto;
não rodar tudo direto no WSL;
adicionar uma camada extra além do Docker padrão.

A solução foi:

VS Code
→ Dev Container
→ Docker
→ gVisor / runsc-ptrace
→ Claude Code ou Codex

O que é gVisor?

gVisor é uma camada de isolamento criada para rodar containers com uma barreira adicional entre o container e o kernel do host.

Em vez de deixar as chamadas de sistema do container irem diretamente para o kernel do sistema, o gVisor intercepta e implementa parte desse comportamento em um kernel de usuário.

Na prática, ele fica entre o container e o sistema operacional.

Referência oficial: https://gvisor.dev/

No Docker, usamos o runtime runsc para executar containers com gVisor.

Exemplo:

docker run --runtime=runsc --rm hello-world

Referência: https://gvisor.dev/docs/user_guide/quick_start/docker/

O detalhe no WSL2: `systrap` falhou, `ptrace` funcionou

Durante a configuração, um detalhe importante apareceu.

O runtime padrão do gVisor usando runsc falhou no meu ambiente WSL2 com um erro parecido com este:

OCI runtime start failed: starting container: starting root container: urpc method "containerManager.StartRoot" failed: EOF

Depois de investigar, o problema estava na plataforma padrão usada pelo gVisor, chamada systrap.

A solução foi registrar um runtime alternativo usando ptrace:

sudo runsc install --runtime runsc-ptrace -- --platform=ptrace
sudo systemctl restart docker || sudo service docker restart

Depois testei:

docker run --runtime=runsc-ptrace --rm hello-world

E funcionou.

Então, no meu ambiente, o caminho funcional ficou:

Docker + gVisor usando runsc-ptrace

ptrace pode ser mais lento que systrap, mas tende a ser mais compatível em ambientes como WSL2.

Referência sobre plataformas do gVisor: https://gvisor.dev/docs/user_guide/platforms/

O template `.devcontainer`

Depois disso, criei um template simples para reaproveitar em qualquer projeto.

O arquivo principal é:

.devcontainer/devcontainer.json

Com esta ideia central:

{
  "name": "Agent Dev Container - gVisor ptrace",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",

  "runArgs": [
    "--runtime=runsc-ptrace"
  ],

  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "22"
    },
    "ghcr.io/devcontainers/features/python:1": {
      "version": "3.12"
    }
  },

  "postCreateCommand": "corepack enable && corepack prepare pnpm@10.0.0 --activate",

  "customizations": {
    "vscode": {
      "extensions": [
        "ms-azuretools.vscode-docker",
        "ms-python.python",
        "bradlc.vscode-tailwindcss",
        "esbenp.prettier-vscode"
      ]
    }
  },

  "remoteUser": "vscode"
}

A parte mais importante é esta:

"runArgs": [
  "--runtime=runsc-ptrace"
]

Isso força o Dev Container a subir usando o runtime do gVisor que funcionou no WSL2.

Como usar em qualquer projeto

Depois de ter Docker, gVisor e runsc-ptrace configurados no sistema, não preciso repetir tudo em cada projeto.

Para um projeto novo, basta copiar a pasta .devcontainer para a raiz do projeto.

Exemplo:

cp -r caminho/para/agent-devcontainer-gvisor-template/.devcontainer meu-projeto/

Depois:

cd meu-projeto
code .

No VS Code:

Ctrl + Shift + P
Dev Containers: Reopen in Container

Quando abrir o terminal integrado, verifico:

pwd

Se aparecer:

/workspaces/meu-projeto

então estou dentro do Dev Container.

Como confirmar se está usando gVisor

Em outro terminal, fora do Dev Container, posso rodar:

docker ps

Depois:

docker inspect $(docker ps -q | head -n 1) --format '{{.HostConfig.Runtime}}'

O esperado é:

runsc-ptrace

Se aparecer isso, o Dev Container está rodando com o runtime configurado.

E o Claude Code?

O Claude Code possui sandbox nativo.

No Linux/WSL2, a documentação oficial fala sobre o uso de bubblewrap e socat para o sandbox.

Referência: https://code.claude.com/docs/en/sandboxing

Dentro do Claude Code, posso rodar:

/sandbox

E escolher:

Sandbox BashTool, with regular permissions

Esse modo mantém o BashTool sandboxado, mas ainda usa o fluxo normal de permissões.

Para mim, é um bom equilíbrio entre segurança e controle.

Com isso, o fluxo fica:

Dev Container
→ gVisor / runsc-ptrace
→ Claude Code
→ sandbox nativo do Claude

E o Codex?

O Codex também trabalha com a ideia de permissões e sandbox.

No menu de permissões, o modo que escolhi foi:

Default

Esse modo permite que o Codex leia, edite arquivos e execute comandos dentro do workspace, mas exige aprovação para acessar a internet ou editar arquivos fora do projeto.

Referência: https://developers.openai.com/codex/agent-approvals-security

Na prática, isso combina bem com o Dev Container:

Dev Container
→ gVisor / runsc-ptrace
→ Codex
→ permissões Default

O que não fazer

Eu evitaria usar agentes direto em:

/home/meu-usuario/projetos/meu-projeto

principalmente com permissões amplas.

Também evitaria começar usando modos como:

Full Access
danger-full-access
--dangerously-skip-permissions

Esses modos podem fazer sentido em ambientes descartáveis e controlados, mas não são uma boa escolha inicial para o dia a dia.

Para uso normal, prefiro:

workspace limitado
aprovação manual
rede controlada
ambiente isolado

Isso resolve 100% da segurança?

Não.

Esse setup não é uma promessa de segurança perfeita.

Ele é uma melhoria prática.

A ideia é reduzir o risco de rodar agentes de IA diretamente no sistema principal.

Ainda é importante:

revisar comandos antes de aprovar;
não expor credenciais desnecessárias;
não montar pastas sensíveis no container;
não usar Full Access sem necessidade;
revisar o diff antes de commitar;
manter dependências e imagens atualizadas;
tratar agentes como ferramentas poderosas, não como usuários totalmente confiáveis.

O template no GitHub

Para facilitar, deixei um template simples no GitHub:

https://github.com/mffdeo/agent-devcontainer-gvisor-template

A ideia é copiar a pasta .devcontainer para qualquer projeto e abrir com:

Dev Containers: Reopen in Container

O template assume que você já configurou Docker, gVisor e runsc-ptrace no ambiente.

Conclusão

Usar agentes de IA no terminal está ficando cada vez mais comum.

Mas existe uma diferença enorme entre:

rodar um agente direto no seu sistema

rodar um agente dentro de um ambiente isolado, com permissões controladas

Para mim, o caminho que fez sentido foi:

VS Code
→ Dev Container
→ Docker
→ gVisor / runsc-ptrace
→ Claude Code ou Codex

Não é o único caminho possível.

Mas é um caminho prático, reproduzível e mais seguro para quem quer usar agentes de IA no desenvolvimento local sem entregar o sistema inteiro de bandeja.

Se você usa Claude Code, Codex ou outros agentes no terminal, vale a pena parar alguns minutos e perguntar:

Esse agente está rodando onde exatamente?

Essa pergunta muda tudo.

Comecei a construir a Stackovia Learning Series: uma trilha open source gratuita para aprender desenvolvimento moderno

Marcos Filipe — Tue, 19 May 2026 03:41:06 +0000

Nos últimos meses eu venho estudando desenvolvimento de software com mais intensidade, tentando organizar melhor minha evolução e transformar estudo em algo mais concreto.

Não queria apenas assistir aulas, fazer anotações soltas ou acumular links. Queria construir uma trilha que me obrigasse a praticar, documentar, revisar e publicar evidências reais do aprendizado.

Foi assim que nasceu a Stackovia Learning Series.

A Stackovia é uma série open source e gratuita de estudos em desenvolvimento moderno. A proposta é começar pelos fundamentos e evoluir, volume por volume, até temas mais avançados como full stack, DevOps, arquitetura, IA, agentes e segurança.

O hub já está no ar:

https://mffdeo.github.io/stackovia-learning/

Por que criar mais um projeto de estudos?

Porque nem sempre as pessoas têm dinheiro para pagar cursos.

Muita gente quer aprender tecnologia, melhorar de vida, migrar de área ou simplesmente construir algo melhor para si mesma, mas esbarra em material caro, trilhas confusas, excesso de conteúdo solto ou falta de direção.

Ao mesmo tempo, eu também estou aprendendo.

Então a ideia da Stackovia é unir as duas coisas:

estudar com mais profundidade;
escrever para organizar o pensamento;
construir projetos práticos;
transformar cada etapa em evidência pública;
compartilhar gratuitamente com quem também estiver aprendendo.

Eu não estou criando a Stackovia como alguém que “já sabe tudo”. Estou criando como alguém em evolução, documentando a caminhada com honestidade.

A proposta da série

A Stackovia será organizada em 11 volumes:

Fundamentos do Desenvolvedor Moderno
Frontend Profissional com React e Next.js
Backend Profissional com FastAPI
Full Stack: Produto Real de Ponta a Ponta
System Design, Software Architecture e Aplicações Robustas
Docker, AWS e DevOps Foundation
Kubernetes e Platform Engineering
Prompt Engineering e Fundamentos de LLMs
AI Engineer: Embeddings, Vector DB, RAG e Multimodal
AI Agents em Produção
AI Red Teaming, Governança e Tech Lead Capstone

A ideia não é fazer uma lista infinita de tópicos. Cada volume terá capítulos, projeto integrador, entregas práticas e evidências de portfólio.

O que já está no ar

O hub da série já está publicado:

https://mffdeo.github.io/stackovia-learning/

E o Volume 1 também já começou:

https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/

Neste primeiro momento, o Volume 1 está focado em fundamentos:

terminal;
organização de pastas;
Git e GitHub;
HTML;
CSS;
JavaScript básico;
HTTP;
segurança inicial;
construção de portfólio.

Os primeiros capítulos já estão publicados em modo preview.

A ideia central: não é só estudo, é evidência

Um dos princípios da Stackovia é que estudar precisa gerar algum tipo de evidência.

Isso pode ser:

um README bem escrito;
um commit bem explicado;
um diagrama;
um checklist;
um pequeno projeto;
um post técnico;
uma release;
uma explicação clara do que foi feito e do que ainda não foi feito.

A ideia é evitar aquela sensação de “estudei muita coisa, mas não consigo mostrar nada”.

O papel da IA nesse processo

Também tenho muito interesse em IA aplicada ao desenvolvimento de software.

Mas não vejo IA apenas como “ferramenta para gerar código”. O que mais me interessa é entender como ela pode ajudar em fluxos reais:

organizar contexto;
apoiar documentação;
revisar decisões;
sugerir testes;
ajudar no aprendizado;
estruturar trilhas;
avaliar qualidade;
apoiar agentes;
aumentar produtividade sem remover responsabilidade humana.

A Stackovia também serve como laboratório para isso: construir com IA, mas com revisão, rastreabilidade, controle de escopo e preocupação com qualidade.

Um projeto open source em construção

A Stackovia ainda está no começo.

O hub está online, o Volume 1 começou e os primeiros capítulos estão publicados. Ainda há muito trabalho pela frente: escrever, revisar, melhorar o site, evoluir os projetos, gerar PDFs e organizar contribuições.

Mas decidi publicar cedo porque acredito que construir em público ajuda a melhorar o projeto.

Feedbacks, críticas, sugestões e correções são muito bem-vindos.

Links

Hub da série:
https://mffdeo.github.io/stackovia-learning/

Volume 1:
https://mffdeo.github.io/stackovia-vol01-fundamentos-dev-moderno/

Repositório hub:
https://github.com/mffdeo/stackovia-learning

Repositório do Volume 1:
https://github.com/mffdeo/stackovia-vol01-fundamentos-dev-moderno

Se a ideia fizer sentido para você, fique à vontade para acompanhar, sugerir melhorias, abrir issue, compartilhar ou deixar uma estrela no GitHub.

A Stackovia é, ao mesmo tempo, meu projeto de aprendizado, meu laboratório de escrita técnica e minha forma de contribuir com quem também está estudando tecnologia.

Eu achava que Node.js era o “Django do JavaScript”… até entender isso

Marcos Filipe — Fri, 03 Apr 2026 23:25:52 +0000

Se você está começando no desenvolvimento web, deixa eu tentar adivinhar:

Em algum momento você pensou algo como:

“Se Django é o principal framework do Python… então Node.js deve ser tipo isso pro JavaScript, né?”

Eu também pensei assim.

E foi aí que começou a confusão.

🤯 O momento em que tudo não fez sentido

Eu comecei a pesquisar sobre backend e vi coisas como:

Node.js
Express
NestJS
Django
Flask

E aí veio a dúvida:

“Por que Python tem um nome forte (Django)… mas JavaScript tem vários?”

Parecia que eu estava comparando coisas… que não eram comparáveis.

💡 A virada de chave

Depois de um tempo, caiu a ficha:

Eu estava comparando um ambiente com um framework.

E isso muda tudo.

🧱 A base vs a construção

Vamos simplificar ao máximo:

🔹 Node.js

Não é um framework.

É um ambiente que permite rodar JavaScript fora do navegador.

👉 Ele é o terreno onde você vai construir.

🔹 Django

É um framework completo para aplicações web em Python.

👉 Ele já é praticamente a casa pronta.

⚖️ A comparação correta (agora sim faz sentido)

Quando você ajusta a lente, fica claro:

Python + Django ≈ Node.js + (Express | NestJS | AdonisJS)

Ou seja:

Node.js sozinho não compete com Django
Você precisa de um framework junto

🏗️ Duas filosofias totalmente diferentes

Aqui é onde a escolha realmente importa 👇

🟦 Django — “já vem com tudo”

Django segue a ideia de:

“Não perca tempo decidindo, só construa.”

Você já ganha:

Sistema de autenticação
ORM
Painel admin
Segurança pronta

👉 Sensação: produtividade imediata

🟨 Node.js — “monte do seu jeito”

No mundo Node:

Você escolhe tudo:

Framework (Express, NestJS…)
Banco (Mongo, PostgreSQL…)
ORM (Prisma, Sequelize…)
Auth (JWT, OAuth…)

👉 Sensação: liberdade total (e um pouco de caos no começo)

🧠 O erro mais comum de iniciantes

Achar que:

“Node.js é um framework igual ao Django”

Quando na verdade:

Node.js é só o começo da stack

🚀 Então… qual é melhor?

Resposta honesta:

Depende do tipo de dor que você quer ter 😂

Vá de Django se você quer:

Começar rápido
Menos decisões técnicas
Estrutura pronta

Vá de Node.js se você quer:

Flexibilidade
Trabalhar com JavaScript em tudo
Entender melhor como as peças se conectam

🔥 Conclusão (a versão que eu gostaria de ter ouvido antes)

Django é um pacote completo. Node.js é uma caixa de ferramentas.

Um te dá tudo pronto.
O outro te dá liberdade pra montar.

Nenhum é melhor universalmente — só são diferentes.

💬 Agora me conta

Você também já confundiu isso no começo?

Ou ainda tá tentando decidir qual caminho seguir?

Comenta aí — sempre tem alguém passando pela mesma dúvida que você 👇

Construindo minha primeira CLI com Node.js (consumindo a API do GitHub)

Marcos Filipe — Mon, 30 Mar 2026 17:57:19 +0000

Recentemente, desenvolvi uma CLI simples em Node.js para visualizar a atividade recente de usuários do GitHub direto pelo terminal.

O objetivo foi praticar fundamentos de backend na prática, sem depender de bibliotecas externas, focando em entender cada etapa do processo.

💡 O que a aplicação faz

A ferramenta permite executar:

github-activity <username>

E retorna algo como:

Pushed commits to user/repo
Opened a new issue in user/repo
Starred user/repo

Os dados são obtidos através da API pública do GitHub:

GET /users/:username/events

⚠️ Desafio encontrado: dados incompletos da API

Inicialmente, a ideia era exibir a quantidade exata de commits em cada push:

Pushed 3 commits to user/repo

Porém, durante os testes, observei que a API de eventos do GitHub nem sempre retorna os dados completos.

Em vários PushEvent, o payload vinha assim:

{
  "ref": "refs/heads/main",
  "head": "commit_hash",
  "before": "commit_hash"
}

Sem os campos:

"commits": []
"size": number

Ou seja:

Não há lista de commits
Não há quantidade (size)
Apenas o intervalo (before → head)

🧠 Análise técnica

Isso mostra que a API de eventos:

Funciona como um feed resumido de atividades
Não garante consistência nos dados
Pode omitir informações dependendo do contexto

Uma alternativa mais precisa seria usar:

GET /repos/:owner/:repo/compare/:before...:head

Que retorna o número real de commits. Porém, isso exigiria:

múltiplas requisições por evento
controle de rate limit
maior complexidade

Para este projeto, optei por manter a simplicidade.

✅ Solução adotada

Implementei um fallback:

Pushed commits to user/repo

Quando a quantidade de commits não está disponível.

Isso evita exibir dados incorretos e mantém a saída consistente.

🧠 Aprendizados principais

🔹 Entrada via CLI

Uso de process.argv para capturar argumentos do terminal.

🔹 Consumo de API

Utilização do fetch nativo do Node.js para requisições HTTP.

🔹 Manipulação de JSON

Filtragem e transformação de dados complexos em uma saída legível.

🔹 Tratamento de erros

usuário não encontrado
falhas de requisição
propriedades indefinidas

🔹 Limitações de sistemas externos

Nem sempre o problema está no código — às vezes está na fonte de dados.

⚙️ Decisões de implementação

Sem bibliotecas externas
Código simples e direto
Foco em aprendizado ao invés de abstrações

🚀 Próximos passos

Adicionar flags (--limit, --type)
Melhorar a formatação da saída
Adicionar cores no terminal
Publicar como pacote global (npm)

📌 Conclusão

Esse projeto mostrou, na prática, que:

APIs nem sempre entregam dados completos ou consistentes.

E mais importante:

Um bom software não depende de dados perfeitos — ele se adapta a eles.

🔗 Repositório

https://github.com/mffdeo/github-activity-cli

Memória Sob Demanda: Como o Engram Está Mudando a Forma como LLMs Pensam

Marcos Filipe — Thu, 26 Mar 2026 15:31:29 +0000

Você já parou para pensar que os Transformers, a arquitetura por trás de modelos como ChatGPT, Claude e DeepSeek, são ótimos em raciocínio, mas... péssimos em memória?

É isso que um novo paper da Peking University e DeepSeek-AI propõe resolver. Tentei trazer aqui os principais insights, que acredito serem um grande passo para a próxima geração de modelos de linguagem.

🔍 O Problema: Transformers Não Sabem "Lembrar"

Um Transformer não tem um mecanismo nativo para recuperar conhecimento. Toda vez que ele precisa de uma informação como "Diana, Princesa de Gales", ele gasta várias camadas computacionais para reconstruir essa informação a partir do contexto.

É como se, em vez de consultar uma enciclopédia, ele tentasse redescobrir a história inteira a cada pergunta.

No paper, os autores mostram que, em um modelo tradicional, são necessárias cerca de 6 camadas para formar uma representação completa dessa entidade. Isso é ineficiente: o modelo está usando raciocínio profundo para fazer algo que poderia ser resolvido com uma simples consulta a uma tabela de memória.

💡 A Solução: Engram (Memória Condicional)

O Engram introduz um novo tipo de "órgão" no modelo: um módulo de memória estática que funciona como um banco de dados de padrões linguísticos.

Como funciona na prática:

O modelo identifica um padrão local (ex: "Princesa de Gales")

Ele usa esse padrão como chave para buscar um vetor de memória pré-armazenado (via hashing)

Esse vetor é injetado diretamente nas camadas profundas do modelo

O resultado? O modelo não precisa mais gastar camadas iniciais reconstruindo informação. Ele já começa com um "atalho" para o conhecimento.

📊 O Resultado na Prática

Os pesquisadores treinaram um modelo chamado Engram-27B e compararam com um modelo tradicional de mesmo tamanho e mesmo custo computacional (MoE-27B). Os resultados:

Benchmark	Domínio	Ganho
MMLU	Conhecimento geral	+3,4%
BBH	Raciocínio complexo	+5,0%
HumanEval	Geração de código	+3,0%
MATH	Matemática	+2,4%

O mais interessante? O Engram melhorou até tarefas de raciocínio, não só de memorização.

Isso acontece porque, ao liberar as primeiras camadas do trabalho de reconstrução, o modelo pode usá-las para "pensar" mais profundamente. Os autores chamam isso de "aumento da profundidade efetiva" da rede.

🧠 Por Que Isso É uma "Nova Dimensão de Esparsidade"?

Até agora, a principal forma de escalar modelos sem aumentar custo computacional era o MoE (Mixture of Experts), que ativa apenas alguns "especialistas" por vez.

O Engram introduz uma segunda dimensão:

Abordagem	Função	Como funciona
MoE	Processa lógica dinâmica	Ativa especialistas (cálculo)
Engram	Recupera conhecimento	Ativa memórias (busca O(1))

Juntos, formam uma dupla poderosa. E o melhor: o Engram é tão eficiente que pode armazenar 100 bilhões de parâmetros na memória RAM do computador sem prejudicar a velocidade — algo impossível com MoE puro.

🔧 Detalhes Técnicos

Se você quer entender melhor a arquitetura:

Compressão do tokenizer: Redução de 23% no vocabulário via normalização (NFKC, lowercasing)
Multi-head hashing: 8 cabeças de hash para cada ordem de N-gram (2 e 3)
Gating contextual: O estado oculto atual decide quanto da memória recuperada deve ser integrada
Posicionamento estratégico: Inserido nas camadas 2 e 15 para equilibrar intervenção precoce com riqueza contextual

O código está disponível no GitHub:

👉 https://github.com/deepseek-ai/Engram

🧭 Conclusão

O Engram mostra que, assim como o cérebro humano, os modelos de IA podem se beneficiar de mecanismos especializados. Ter um sistema separado para memória de longo prazo e outro para raciocínio dinâmico não só torna os modelos mais eficientes, como libera capacidade computacional para o que realmente importa: pensar com profundidade.

Essa pode ser uma das direções mais importantes para os LLMs do futuro: modelos que sabem quando pensar e quando lembrar.

📚 Fonte e Créditos

Paper original: "Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models"
Autores: Xin Cheng, Wangding Zeng, Damai Dai, et al. (Peking University & DeepSeek-AI)

Usei ferramentas de IA para me auxiliar na consolidação e organização das ideias.

DEV Community: Marcos Filipe

Concluí o Volume 1 da Stackovia Learning Series: 13 capítulos gratuitos + projeto integrador

Por que esse projeto existe?

O que é a Stackovia Learning Series?

O que tem no Volume 1?

Os 13 capítulos publicados

O projeto integrador: IntraStack Básico

Por que chamar de “preview completo”?

O que eu aprendi construindo esse volume?

O papel da IA no processo

Para quem esse Volume 1 pode ajudar?

Links do projeto

Como você pode ajudar

Design de sistemas não é sobre parecer sofisticado: é sobre resolver o problema certo

A armadilha da arquitetura por status

Escalar antes da hora também é uma forma de desperdício

Software não é construído uma vez; software evolui

Resolver problema específico antes de criar solução genérica

Impacto de negócio importa

E onde entra a IA nisso?

Meu principal aprendizado

Tentei criar uma CLI para governar código gerado por IA — e descobri que o problema era outro

A ideia original

O que funcionou bem

1. SPECs e briefs ajudam muito

2. O Evidence Pack foi útil

3. O PR Ready também fez sentido

Onde começou a quebrar

O problema das heurísticas

A grande descoberta

O scanner não deve decidir sozinho

O papel da IA nesse fluxo

O que eu aprendi com o projeto

1. Heurísticas são boas para sinais, não para verdade final

2. SPEC é mais importante do que parece

3. “Handoff” é uma palavra-chave

4. Governança não é bloquear tudo

5. Projeto experimental precisa dizer que é experimental

O estado atual do DevForge CLI

O que eu faria diferente se começasse de novo

Conclusão

O fim do “modelo que faz tudo”? Conheça o Conductor, a IA que orquestra outras IAs

OpenClaw, Hermes e Conductor mostram que o futuro da IA pode estar menos em chatbots isolados e mais em sistemas de agentes coordenados.

O que é o Conductor?

Uma metáfora simples: o maestro e a orquestra

Diagrama conceitual

Por que isso é diferente de um roteador simples?

E onde entram OpenClaw e Hermes Agent?

Comparando as camadas

Uma analogia de escritório

A competição real ainda está se formando

O que isso ensina para quem desenvolve software?

O risco: autonomia sem governança

Para onde estamos convergindo?

1. Camada de orquestração

2. Camada de execução

3. Camada de memória e aprendizado

A plataforma de IA do futuro

Conclusão

Referências

Eu parei de rodar agentes de IA direto no meu WSL: usando Dev Containers + gVisor com Claude Code e Codex

Por que isso importa?

O problema do terminal “normal”

A ideia: colocar o ambiente de trabalho dentro de um Dev Container

Mas Docker puro é suficiente?

O que é gVisor?

O detalhe no WSL2: systrap falhou, ptrace funcionou

O template .devcontainer

Como usar em qualquer projeto

Como confirmar se está usando gVisor

E o Claude Code?

E o Codex?

O que não fazer

Isso resolve 100% da segurança?

O template no GitHub

Conclusão

Comecei a construir a Stackovia Learning Series: uma trilha open source gratuita para aprender desenvolvimento moderno

Eu achava que Node.js era o “Django do JavaScript”… até entender isso

🤯 O momento em que tudo não fez sentido

💡 A virada de chave

O detalhe no WSL2: `systrap` falhou, `ptrace` funcionou

O template `.devcontainer`