Instruções de entrega do IRPF 2026

O prazo de entrega da Declaração Anual do Imposto de Renda Pessoa Física (IRPF) 2026, ano-calendário 2025, começa nesta segunda-feira, 23 de março, e segue até o próximo dia 29 de maio, às 23h59. Pessoas físicas que receberam rendimentos tributáveis acima de R$ 35.584,00 assim como aquelas que obtiveram receita bruta da atividade rural acima de R$ 177.920,00, são obrigadas a declarar.

A declaração pré-preenchida já estará plenamente disponível no início do prazo de entrega da declaração, com novos dados incluídos em relação ao ano passado, informações do e-Social relativas aos empregados domésticos, dados do Imposto de Renda Retido na Fonte sobre a renda variável e recuperação das informações de pagamento (DARFs). Todas as regras estão presentes na Instrução Normativa RFB nº 2.312/2026 , publicada no Diário Oficial da União desta segunda-feira, 16/3.

A declaração pré-preenchida virá com as seguintes informações:

• Informações da declaração anterior do contribuinte: identificação, endereço
• Rendimentos e pagamentos da Dirf, Dimob, DMED e Carnê-Leão
• Rendimentos isentos em função de moléstia grave e códigos de juros
• Rendimentos de restituição recebidas no ano-calendário
• Contribuições de previdência privada
• Atualização do saldo de conta bancária e poupança
• Atualização do saldo de Fundos de investimento
• Imóveis adquiridos no ano-calendário
• Doações efetuadas no ano-calendário
• Informação de Criptoativos
• Conta bancária/poupança ainda não declarada
• Fundo de investimento ainda não declarado
• Contas bancárias no exterior

RENDIMENTOS NO EXTERIOR — A partir deste ano, os dados de contas bancárias no exterior foram incluídos na declaração pré-preenchida, após a legislação determinar a tributação de offshores (empresas de investimentos em outros países) e rendimentos no exterior. Por causa da lei que antecipou a cobrança de Imposto de Renda sobre Fundos Exclusivos e tributou as offshores, os rendimentos no exterior passaram a ser tributados de forma definitiva na declaração de ajuste anual, com alíquota de 15%. Até 2023, o pagamento era feito mensalmente, mas passou a ser feito anualmente. Na declaração, os bens que representem investimentos no exterior passam a permitir a informação do rendimento e do imposto pago, tanto no Brasil como no exterior.

OUTRAS MUDANÇAS — A declaração terá poucas mudanças em relação à do ano passado. As principais são as situações em que o contribuinte está obrigado a entregar o documento, por causa do reajuste da faixa de isenção no ano passado.

Em relação às obrigatoriedades, as mudanças foram as seguintes:

• Valor de rendimentos tributáveis anuais que obrigam a entrega da declaração subiu de R$ 33.888,00 para R$ 35.584,00
• Limite da receita bruta de obrigatoriedade para atividade rural subiu de R$ 169.440,00 para R$ 177.920,00
• Quem atualizou valor de bens imóveis e pagou ganho de capital diferenciado em dezembro de 2025 terá de preencher a declaração
• Quem apurou rendimentos no exterior de aplicações financeiras e de lucros e dividendos passou a declarar anualmente
• As demais obrigatoriedades foram mantidas.

Outra mudança é a maior prioridade para quem simultaneamente utilizou a declaração pré-preenchida e optou pelo recebimento da restituição via Pix. Até o ano passado, a prioridade era definida apenas com base na utilização de uma das duas ferramentas.

Estão, portanto, isentas da declaração as pessoas que receberam até dois salários-mínimos mensais durante 2025, salvo se se enquadrarem em outro critério de obrigatoriedade. Os demais critérios de obrigatoriedade mantiveram-se os mesmos. Dentre os principais, destacam-se aqueles aplicáveis aos contribuintes que:

• receberam rendimentos isentos, não tributáveis ou tributados exclusivamente na fonte superior a R$ 200 mil;
• alienaram em bolsas de valores, de mercadorias, de futuros e assemelhadas valores em soma superior a R$ 40 mil ou com ganhos líquidos sujeitas à incidência do imposto;
• tiveram, em 31 de dezembro de 2025, a posse ou a propriedade de bens ou direitos, inclusive terra nua, de valor total superior a R$ 800 mil;
• passaram à condição de residente no Brasil em qualquer mês e estava nesta condição no fim de 2025.

MULTA — Quem enviar a declaração fora do prazo deverá pagar multa de 1% sobre imposto devido, com valor mínimo de R$ 165,74, ou de 20% do valor devido, prevalecendo o maior valor.

Reinstituções

A Receita Federal pretende antecipar o pagamento da restituição do Imposto de Renda este ano. A previsão é que 80% dos contribuintes que tenham direito à restituição recebam os valores até o dia 30 de junho. A maior agilidade no processamento possibilitará a redução da quantidade de lotes este ano, que passarão de cinco para quatro. O primeiro lote será pago no dia 29 de maio, com os subsequentes ocorrendo nos dias 30/6, 31/7 e 31/8. Confira a ordem de prioridades nas restituições:

1º) Idade igual ou superior a 80 anos;

2º) Idade igual ou superior a 60 anos, deficientes e portadores de moléstia grave;

3º) Pessoa que tenha maior fonte de renda vinda do magistério;

4º) Quem utilizou conjuntamente a declaração pré-preenchida e optou pela restituição no Pix;

5º) Quem utilizou exclusivamente a declaração pré-preenchida ou optou pela restituição no Pix; e

6º) Demais contribuintes

Restituição Automática – ano-calendário 2024

Outra novidade anunciada na coletiva foi o pagamento de um lote especial de restituição para os contribuintes que não entregaram a declaração de Imposto de Renda em 2025 por não estarem obrigados, mas tinham direito à restituição por fatos ocorridos em 2024. Esta situação pode acontecer, por exemplo, com um empregado que teve imposto de renda retido na fonte por ter recebido salário no primeiro trimestre de 2024, mas ficou desempregado posteriormente e não obteve renda no restante do ano para se encaixar nos critérios de obrigatoriedade de entrega da declaração. A parcela de imposto que foi retida dá a ele direito à restituição, que será realizada através de uma declaração automática elaborada pela própria Receita Federal a partir de 15 de junho deste ano, com o crédito a partir de 15 de julho.

Segundo a Receita Federal, cerca de 4 milhões de contribuintes se encaixam nesta situação, com um valor médio de R$ 125 em restituições devidas, totalizando um montante de R$ 500 milhões.

A declaração automática será elaborada para contribuintes que tem direito à restituição de até R$ 1 mil, com CPF regular e chave Pix vinculada ao CPF. O pagamento será feito de maneira automática. A partir do dia 15 de junho, o contribuinte poderá verificar se teve sua declaração automaticamente gerada na página da Receita Federal, e poderá realizar retificações na declaração se assim o desejar.

"Este é um importante mecanismo de Justiça Fiscal, no qual a Receita Federal passa a devolver valores que o cidadão tem direito, mas não pleiteou, ou por falta de conhecimento ou por falta de recursos para fazer a sua declaração", explicou o responsável pelo programa do Imposto de Renda 2026, José Carlos da Fonseca.

A Receita Federal recomenda que os declarantes utilizem a pré-preenchida, que insere automaticamente dados como rendimentos recebidos e despesas médicas efetuadas. Ao minimizar a possibilidade de erros, a declaração pré-preenchida evita que o contribuinte seja retido na malha fiscal, popularmente conhecida como “malha fina”. É importante destacar, porém, que os dados da declaração são enviados por terceiros como empresas e planos de saúde, e é responsabilidade do contribuinte ver se eles estão corretos.

Além do Programa Gerador da Declaração, o contribuinte também pode utilizar o sistema "Meu Imposto de Renda", solução online para celulares e tablets. O acesso ao Meu Imposto de Renda exige autenticação via Plataforma GOV.BR (níveis ouro ou prata), com acesso por meio da página gov.br/receitafederal, pelo centro virtual de atendimento ao contribuinte (Portal e-Cac) ou pelo aplicativo da Receita Federal.

O sistema "Meu Imposto de Renda" recebeu várias melhorias em relação ao ano passado. A interface de ajuda está mais amigável e o sistema agora emite alertas para erros comuns, tais como pagamentos para dependentes sem a declaração de rendimentos e despesas médicas elevadas. "Outro alerta é quando o contribuinte informa uma chave PIX vinculada ao CPF que não existe. O objetivo é evitar erros e estabelecer um diálogo com o cidadão através do próprio programa", explicou José Carlos da Fonseca. O sistema também foi otimizado para recuperar automaticamente informações de dependentes que estejam cadastrados regularmente no sistema CPF e tenham sido declarados como tal nas declarações dos últimos três anos, sem necessidade de autorização específica para a recuperação de dados.

Referência

Gov.BR

Feito!

O Linux foi banido no Brasil?

O texto da Lei nº 15.211/2025 (ECA Digital), o decreto regulamentador de março de 2026 e a repercussão técnica que gerou esse pânico digital.

Vou direto ao ponto: Dizer que o Linux foi "banido" no Brasil é Fake News. Não existe qualquer artigo na lei que proíba o uso, a distribuição ou a posse do sistema operacional Linux. O que existe é um desafio de conformidade técnica que foi interpretado de forma sensacionalista.

Abaixo, apresento o parecer jurídico e técnico sobre a situação:

1. O que a Lei realmente diz?

O ECA Digital (Lei 15.211/2025) foca na proteção de menores contra conteúdos inadequados e coleta predatória de dados. No seu Artigo 12, ela estabelece obrigações para:

Provedores de redes sociais;

Lojas de aplicativos (como Play Store ou Apple Store);

Sistemas operacionais de terminais.

A lei exige que esses entes ofereçam mecanismos de verificação de idade (proibindo a autodeclaração simples) e ferramentas de controle parental.

2. Por que surgiu o rumor do "Banimento"?

O problema não é uma proibição, mas a responsabilidade civil e financeira.

Projetos de software livre, como o Arch Linux 32 ou o MidnightBSD, são mantidos por voluntários e não possuem CNPJ ou recursos para implementar APIs caras de verificação de identidade (como as que exigem biometria ou checagem de documentos).

Temendo multas que podem chegar a R$ 50 milhões por infração, alguns projetos menores decidiram, por conta própria, bloquear o acesso de IPs brasileiros aos seus sites de download como medida preventiva de "segurança jurídica". Foi uma decisão dos desenvolvedores estrangeiros, e não uma ordem do governo brasileiro.

3. O Linux vai parar de funcionar?

Absolutamente não.

Grandes Distribuições: Empresas como a Canonical (Ubuntu) e a Red Hat possuem corpo jurídico e financeiro para se adequar ou negociar termos com a ANPD (Autoridade Nacional de Proteção de Dados).

Infraestrutura Nacional: O próprio Governo Brasileiro é um dos maiores usuários de Linux (em servidores, urnas eletrônicas e datacenters). Banir o Linux seria paralisar o Estado brasileiro e a internet nacional, o que é juridicamente e logicamente impossível.

Uso Pessoal: Você pode continuar usando a sua distro Linux preferida normalmente. A lei regula o fornecedor do serviço, não pune o usuário final por ter o sistema instalado.

Títulos Sensacionalistas no YouTube

Os títulos "Linux banido" são exemplos clássicos de clickbait. Eles pegam um fato real (a dificuldade técnica de pequenos projetos de código aberto em cumprir uma lei de verificação de idade) e o transformam em uma catástrofe inexistente para gerar visualizações.

Resumo do Parecer

Aspecto Analisado	Realidade Jurídica (Pós-Regulamentação 2026)
O Linux foi proibido?	Não. O sistema continua legal. A lei foca em mecanismos de proteção de menores, não na proibição de kernels ou arquiteturas de software livre.
Por que há bloqueios?	Auto-bloqueio preventivo. Alguns projetos internacionais (sem representação no Brasil) bloquearam IPs brasileiros para evitar multas de até R$ 50 milhões, por não possuírem infraestrutura de verificação de idade.
Uso em Servidores e Urnas	Garantido. O Linux é a base da infraestrutura crítica do Estado Brasileiro. Bani-lo seria tecnicamente impossível e juridicamente nulo por ferir a continuidade do serviço público.
Risco ao Usuário Final	Zero. As sanções do ECA Digital são administrativas e direcionadas aos fornecedores e distribuidores que não implementarem controle parental, nunca ao cidadão que utiliza o sistema.
Veredito sobre os Rumores	Fake News / Clickbait. Títulos que afirmam "Linux Banido" distorcem um desafio de compliance técnico transformando-o em uma proibição estatal inexistente.

Considerações finais

Não há motivo para pânico. O Linux continua sendo legal e amplamente utilizado no Brasil. O que estamos presenciando é o "atrito" entre uma legislação nova e o modelo de desenvolvimento descentralizado do software livre, algo que será ajustado via regulamentação administrativa nos próximos meses.

Para quem deseja se aprofundar e evitar cair em armadilhas de engajamento, a recomendação é uma só: leia o texto da regulamentação na íntegra. Ao analisar o documento oficial, fica evidente que os vídeos no YouTube com títulos como "Linux banido no Brasil" ou similares são puramente sensacionalistas e clickbait. Eles exploram o medo da comunidade técnica para gerar visualizações, distorcendo um desafio de conformidade em uma proibição que nunca existiu.

Referência

Governo do Brasil

Guia Offical

Feito!

Maven vs Gradle em projetos Java: Qual escolher?

No ecossistema Java, ferramentas de build automation são fundamentais para compilar código, gerenciar dependências, executar testes e gerar artefatos como JAR ou WAR. As duas ferramentas mais utilizadas são Apache Maven e Gradle.

Ambas resolvem o mesmo problema, automatizar o ciclo de build de aplicações Java, porém utilizam abordagens diferentes.

No presente artigo vamos analisar:

• O que são Maven e Gradle
• Como cada um funciona
• Prós e contras
• Quando usar cada ferramenta em projetos Java

O que é Maven?

Apache Maven é uma ferramenta de build criada pela Apache Software Foundation e lançada em 2004.

Seu principal objetivo é padronizar o processo de build em projetos Java.

Ele utiliza um arquivo chamado pom.xml (Project Object Model) onde são declarados:

• dependências
• plugins
• versão do projeto
• configuração de build
• repositórios

Exemplo do arquivo pom.xml para o projeto Spring Framework 7 com Java 21 + JUnit + cobertura mínima de 80%

pom.xml

O Maven segue o princípio Convention over Configuration, ou seja, ele já possui uma estrutura padrão:

src/main/java
src/main/resources
src/test/java
src/test/resources

Essa padronização facilita a colaboração entre equipes.

O que é Gradle?

Gradle surgiu em 2012 como uma alternativa mais flexível e performática ao Maven.

Ele utiliza uma DSL baseada em Groovy ou Kotlin para definir o build.

Exemplo de arquivo build.gradle para o projeto Spring Framework 7 e Java 21 + JUnit + cobertura mínima de 80%:

build.gradle

O Gradle foi projetado para:

• builds mais rápidos
• maior flexibilidade
• melhor suporte a projetos complexos

Hoje ele é amplamente usado em projetos modernos, incluindo o build padrão do Android Studio.

Diferenças conceituais

Característica	Maven	Gradle
Configuração	XML (pom.xml)	DSL baseada em Groovy ou Kotlin
Filosofia	Convention over Configuration	Alta flexibilidade e customização
Performance	Mais lento em builds grandes	Mais rápido com incremental build e cache
Curva de aprendizado	Mais simples para iniciantes	Maior devido à DSL programável
Customização	Limitada via plugins	Muito alta, com scripts programáveis

Prós do Maven

1. Padronização

O Maven impõe uma estrutura padrão para projetos.

Isso facilita:

onboarding de novos desenvolvedores

manutenção de projetos

integração entre equipes

2. Ecossistema maduro

O Maven possui milhares de plugins prontos.

Exemplos:

compilação

geração de documentação

análise de código

empacotamento

3. Simplicidade conceitual

Apesar do XML ser verboso, o modelo é simples:

clean
compile
test
package
install
deploy

Esse ciclo é chamado de build lifecycle.

4. Alta adoção corporativa

Muitas empresas utilizam Maven em aplicações enterprise, especialmente em projetos baseados em:

• Spring Framework
• Spring Boot
• aplicações legadas Java

Contras do Maven

1. XML verboso

Configurações simples podem virar arquivos grandes.

Exemplo comum: pom.xml com centenas de linhas.

2. Customização limitada

Criar pipelines complexos pode ser difícil.

3. Performance menor

Comparado ao Gradle, o Maven:

• recompila mais coisas
• possui menos otimizações

Prós do Gradle

1. Build mais rápido

Gradle implementa várias otimizações:

• incremental build
• build cache
• execução paralela

Isso reduz bastante o tempo de build em projetos grandes.

2. DSL mais expressiva

A configuração é escrita em Groovy ou Kotlin, permitindo:

• lógica condicional
• loops
• funções
• scripts reutilizáveis
3. Melhor para projetos grandes

Gradle funciona muito bem com:

• monorepos
• microservices
• builds multi-módulo
4. Flexibilidade extrema

É possível construir praticamente qualquer pipeline de build.

Contras do Gradle

1. Curva de aprendizado maior

Desenvolvedores precisam entender:

• Groovy ou Kotlin
• conceitos de tasks
• lifecycle do Gradle
2. Menos padronização

Como tudo pode ser customizado, projetos podem ficar inconsistentes entre equipes.

3. Debug de build mais complexo

Scripts muito dinâmicos podem dificultar troubleshooting.

Maven vs Gradle em projetos reais

Na prática, a escolha depende do tipo de projeto.

Use Maven quando:

• o projeto é corporativo tradicional
• a equipe prefere padronização
• builds não são extremamente complexos
• onboarding rápido é importante

Use Gradle quando:

• o projeto é grande ou modular
• erformance de build é crítica
• pipelines precisam de customização
• o projeto envolve Android

Tendências do ecossistema Java

Nos últimos anos, Gradle tem crescido bastante, especialmente em projetos modernos.

Entretanto, Maven ainda domina grande parte do mercado corporativo devido à sua estabilidade e padronização.

Ou seja:

• Maven -> estabilidade e padrão
• Gradle -> flexibilidade e performance

Considerações finais

Tanto Apache Maven quanto Gradle são excelentes ferramentas de build para projetos Java.

A escolha correta depende de fatores como:

• complexidade do projeto
• tamanho da equipe
• necessidade de customização
• tempo de build

Em termos simples:

• Maven é previsível e padronizado
• Gradle é poderoso e flexível

Um engenheiro de software moderno deve conhecer ambos, pois cada um continua sendo amplamente utilizado nas empresas.

Feito!

Entendendo o git worktree na prática

No dia a dia de engenharia de software, especialmente em projetos com múltiplas features, hotfixes e revisões paralelas, é comum enfrentar um problema recorrente: alternar entre branches sem quebrar o estado do workspace. Tradicionalmente, isso envolve stash, commits temporários ou até múltiplos clones do mesmo repositório. O git worktree resolve esse problema de forma elegante e eficiente.

No presente artigo, vamos entender o conceito, os benefícios arquiteturais no fluxo de trabalho e um exemplo prático que conecta teoria e prática.

O que é git worktree

git worktree é um recurso do Git que permite ter múltiplos diretórios de trabalho (working directories) associados ao mesmo repositório local. Cada diretório pode estar ligado a uma branch diferente, compartilhando o mesmo histórico e objetos Git.

Em termos técnicos:

• Um único repositório .git
• Vários diretórios de trabalho independentes
• Cada diretório com sua própria branch ativa

Isso elimina a necessidade de:

• Fazer checkout constante
• Clonar o repositório várias vezes
• Usar stash com frequência

O problema que o worktree resolve

Imagine um cenário comum em equipes de desenvolvimento.

Você está trabalhando em:

• feature nova
• correção de bug urgente
• revisão de Pull Request

Sem worktree, o fluxo geralmente é:

1. Commit parcial ou stash
2. Checkout de outra branch
3. Resolver a tarefa
4. Voltar para a branch original
5. Aplicar stash
6. Resolver conflitos eventuais

Isso gera:

• perda de foco
• risco de conflitos
• overhead mental
• contexto misturado

Em projetos grandes (monorepos, microsserviços, projetos com CI/CD pesado), isso impacta diretamente a produtividade.

Benefícios do git worktree

1. Paralelismo no desenvolvimento

Você pode trabalhar em múltiplas branches ao mesmo tempo.

Exemplo:

repo/
 ├── main-workspace
 ├── feature-pagamentos
 ├── hotfix-producao
 

Cada diretório tem sua branch ativa.

2. Redução de conflitos e erros

Ao evitar stash frequente e mudanças de branch no mesmo diretório, diminui:

• arquivos modificados esquecidos
• conflitos inesperados
• commits acidentais
3. Ideal para revisão de código

Você pode abrir uma branch de PR sem interromper o trabalho atual.

4. Excelente para testes de versões

Muito útil quando você precisa rodar duas versões do sistema:

• versão atual
• nova feature

Exemplo típico em backend:

• API executando versão estável
• nova implementação em paralelo
5. Performance melhor que múltiplos clones

Porque:

• objetos Git são compartilhados
• apenas o workspace muda

Isso economiza:

• disco
• tempo de clone
• download de dependências

Estrutura interna (como o Git organiza isso)

Quando você cria um worktree, o Git registra internamente:

.git/worktrees/

Cada worktree tem:

• referência da branch
• HEAD independente
• index próprio

Mas todos compartilham:

• histórico
• objetos
• commits

Isso torna o mecanismo extremamente eficiente.

Quando usar git worktree na prática

Situações ideais:

Desenvolvimento paralelo de features

Quando duas tarefas estão em andamento ao mesmo tempo.

Hotfix urgente

Você não quer interromper sua feature atual.

Revisão de Pull Requests

Abrir o PR localmente sem bagunçar o ambiente atual.

Testes de refatoração grande

Manter uma branch estável rodando.

Monorepos grandes

Especialmente em projetos com build pesado.

Exemplo prático (teoria -> prática)

Vamos simular um cenário real de desenvolvimento.

Projeto:

API backend com duas tarefas:

• feature: sistema de notificações
• hotfix: correção de autenticação

Branch atual:

develop

Estrutura inicial:

finance-api/

Passo 1: Criar uma nova feature com worktree

Criando um diretório para a feature:

git worktree add ../feature-notificacoes -b feature/notificacoes

O que aconteceu aqui:

• Criou um novo diretório
• Criou uma nova branch
• Ligou a branch ao novo workspace

Agora temos:

finance-api/
feature-notificacoes/

Cada um com uma branch diferente.

Passo 2: Trabalhando em paralelo

Workspace 1:

finance-api
branch: develop

Workspace 2:

feature-notificacoes
branch: feature/notificacoes

Passo 3: Hotfix urgente

Bug em produção.

Criando outro worktree:

git worktree add ../hotfix-auth -b hotfix/auth

Estrutura final:

finance-api/
feature-notificacoes/
hotfix-auth/

Agora você tem três contextos isolados.

Passo 4: Fluxo real de desenvolvimento

No diretório hotfix

cd ../hotfix-auth

Corrige o problema:

git commit -m "fix: corrige validação do token"
git push origin hotfix/auth

Merge realizado.

Enquanto isso, a feature continua intacta

Sem stash.

Sem conflitos.

Sem troca de branch.

Listando worktrees existentes

git worktree list

Saída típica:

/home/reginaldo/projetos/finance-api develop
/home/reginaldo/projetos/feature-notificacoes feature/notificacoes
/home/reginaldo/projetos/hotfix-auth hotfix/auth


Isso ajuda muito em repositórios grandes.

Removendo um worktree

Após merge da feature:

git worktree remove ../feature-notificacoes

Ou manual:

rm -rf ../feature-notificacoes
git worktree prune

Boas práticas usando git worktree

1. Criar um diretório padrão

Exemplo:

worktrees/

Estrutura recomendada:

repo/
worktrees/
   feature-x
   hotfix-y

2. Nomear worktrees por contexto

Evite nomes genéricos:

Errado:

test
dev2
branch2

Melhor:

feature-pagamentos
refactor-auth
hotfix-prod

3. Usar em conjunto com PR workflow

Fluxo eficiente:

1. Criar branch
2. Criar worktree
3. Desenvolver
4. Commit
5. Push
6. PR
7. Remover worktree
4. Automatizar com script

Exemplo simples:

new-feature.sh

#!/bin/bash

branch=$1

git worktree add ../wt-$branch -b $branch
cd ../wt-$branch

Uso:

./new-feature.sh feature/pix

Isso acelera bastante o fluxo de trabalho.

Comparação: workflow tradicional vs worktree

Sem worktree

Fluxo:

stash
checkout
pull
resolver conflito
stash pop

Problemas:

risco de erro

perda de contexto

lentidão

Com worktree

Fluxo:

novo diretório
nova branch isolada
desenvolver

Resultado:

workflow limpo

paralelismo

mais produtividade

Uso avançado em times experientes

Equipes maduras usam git worktree para:

QA paralelo

Ambiente para teste de PR local.

Refatoração grande

Manter branch estável rodando.

Testar migração de framework

Exemplo real:

Migrar:

• Spring Boot
• Angular
• React

Sem quebrar a base principal.

Integração com ferramentas modernas

Funciona muito bem com:

VSCode

Docker

Dev Containers

Monorepos

CI local

Exemplo prático com Docker:

Cada worktree pode subir um container diferente.

docker compose up

Com variáveis diferentes.

Quando não usar git worktree

Casos raros:

• projetos muito pequenos
• repositórios descartáveis
• scripts simples

Mas na maioria dos casos profissionais, vale a pena.

Considerações finais

git worktree é um recurso subestimado do Git, mas extremamente poderoso para engenheiros de software que trabalham com múltiplos contextos de desenvolvimento.

Ele melhora:

• organização
• foco
• produtividade
• segurança no workflow

E reduz drasticamente problemas comuns como:

• stash excessivo
• conflitos inesperados
• troca constante de branches

Em equipes que trabalham com:

• microserviços
• APIs
• sistemas corporativos
• projetos com CI/CD

O uso de git worktree pode se tornar um diferencial real no fluxo da engenharia de software.

Feito!

O lado obscuro do Vibe Coding

O movimento Vibe Coding transformou a maneira como criamos software. A promessa é sedutora: você descreve sua ideia em linguagem natural, e uma plataforma de IA (Bolt.new, Lovable, Abacus) que são ferramentas especializadas para gerar um aplicativo full-stack funcional em minutos.

No entanto, há um perigo silencioso nesse fluxo de trabalho. Muitas dessas ferramentas utilizam o Supabase como backend padrão. Se você não for específico no seu prompt, pode acabar com uma aplicação onde qualquer pessoa na internet consegue ler, alterar ou deletar os dados de todos os seus usuários.

O Contexto Histórico: Da Rebeldia de Karpathy ao Mainstream

O termo Vibe Coding não nasceu em um laboratório de engenharia tradicional, mas sim de uma observação provocativa de Andrej Karpathy (cofundador da OpenAI) em fevereiro de 2025. Ao descrever um fluxo de trabalho onde a sintaxe é irrelevante e a "vibe" (a intenção e o feedback visual) é tudo, Karpathy deu nome a um movimento que o lendário produtor Rick Rubin comparou ao "Punk Rock do Software".

Em 2025, o termo foi eleito a palavra do ano pelo dicionário Collins, consolidando a ideia de que qualquer pessoa com uma boa ideia e um prompt pode ser um desenvolvedor. No entanto, essa origem focada na velocidade e na expressão criativa trouxe um efeito colateral: a negligência com fundamentos invisíveis, como o RLS, que agora, em 2026, define a fronteira entre um protótipo amador e um app profissional seguro.

No presente artigo, vamos entender a vulnerabilidade de RLS (Row Level Security) desabilitado e como corrigi-la com uma simples mudança na sua instrução inicial.

O que é Vibe Coding e por que o Supabase?

Vibe Coding é o termo cunhado para descrever o desenvolvimento de software focado na intenção e na iteração rápida através de prompts de IA, onde o desenvolvedor atua mais como um "maestro" do que como um digitador de sintaxe.

Para que essa "mágica" aconteça, a IA precisa de um backend que seja fácil de configurar programaticamente. O Supabase é a escolha ideal por ser um "Firebase Open Source" baseado em PostgreSQL, oferecendo banco de dados, autenticação e armazenamento de forma instantânea.

O problema surge na configuração padrão.

O Perigo: A Chave Anon e o RLS Desabilitado

Quando uma plataforma (Bolt.new, Lovable, Abacus) cria um app Supabase para você, ela gera um arquivo de configuração (geralmente .env) contendo a SUPABASE_URL e a SUPABASE_ANON_KEY.

Diferente de backends tradicionais onde a chave do banco de dados fica escondida no servidor, no modelo de arquitetura moderna (PostgREST), a chave anon é pública e fica exposta no navegador do usuário.

O que é RLS (Row Level Security)?

RLS significa Row Level Security (Segurança em Nível de Linha). É um recurso do banco de dados PostgreSQL que permite definir regras granulares para quem pode ver ou modificar cada linha em uma tabela.

Sem RLS: Se você tem a chave anon, você tem acesso total às tabelas.

Com RLS: Mesmo com a chave anon, o banco de dados pergunta: "Quem é este usuário e ele tem permissão para ver esta linha específica?"

A Anatomia da Vulnerabilidade

Imagine que você pediu na plataforma (Bolt.new, Lovable, Abacus):

"Crie um app de gestão de clientes para minha agência".

A plataforma (Bolt.new, Lovable, Abacus) cria uma tabela chamada clientes. Por padrão, para facilitar o desenvolvimento e garantir que o app "funcione de primeira" (a famosa "vibe"), muitas ferramentas de geração de código criam as tabelas sem habilitar o RLS.

O Cenário de Desastre

1. O hacker acessa seu site.
2. Abre o console do desenvolvedor (F12) e encontra sua SUPABASE_ANON_KEY.
3. Utiliza uma ferramenta simples ou até o próprio terminal para fazer uma requisição à API do seu Supabase:
curl 'https://seu-projeto.supabase.co/rest/v1/clientes?select=*' \
-H "apikey: SUA_CHAVE_ANON" \
-H "Authorization: Bearer SUA_CHAVE_ANON"


O resultado? O invasor recebe um JSON com todos os dados de todos os clientes, e-mails, faturamentos e notas administrativas. Se o RLS estiver desabilitado, a chave "Anônima" tem poderes de administrador sobre os dados públicos.

A Solução: Ajustando o seu Prompt

A boa notícia é que a IA é obediente. O erro não está na tecnologia, mas na omissão da segurança no prompt inicial. Para garantir que seu app seja seguro desde o "dia zero", você deve incluir instruções explícitas de segurança.

O "Prompt Seguro"

Sempre que iniciar um projeto de Vibe Coding, adicione este parágrafo ao seu comando:

"Habilite o Row Level Security (RLS) em todas as tabelas criadas no Supabase. Crie políticas de segurança para que usuários autenticados possam ler e escrever apenas seus próprios dados, e garanta que dados administrativos não sejam acessíveis via chave anon sem as devidas permissões."

Ao fazer isso, a IA na plataforma (Bolt.new, Lovable, Abacus) gerará o SQL necessário para proteger seu banco, parecido com este:

-- Exemplo do que a IA deve gerar nos bastidores
ALTER TABLE clientes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Usuários só vêem seus próprios clientes"
ON clientes FOR SELECT

USING (auth.uid() = user_id);

Tabela Comparativa: Sem RLS vs. Com RLS

Recurso	Sem RLS (Padrão Vibe)	Com RLS (Prompt Seguro)
Visibilidade da Chave	Exposta no Browser (Normal)	Exposta no Browser (Normal)
Acesso a dados alheios	Livre (Risco Total)	Bloqueado pelo Banco
Privacidade	Inexistente	Garantida por UID
Escalabilidade	Perigosa	Segura para Produção

Considerações finais

O Vibe Coding é o futuro, mas a segurança não pode ser deixada para depois. Ao entender que o Supabase delega a segurança para o nível da linha (RLS), você assume o controle da integridade dos dados dos seus usuários.

Não deixe que a agilidade de um prompt comprometa a confiança dos seus clientes. Segurança também faz parte da "vibe".

Feito!

Executando o Ollama no ambiente Docker

Executar o Ollama no Docker é a maneira mais prática de executar modelos de linguagem (LLMs) localmente, garantindo isolamento do sistema operacional e fácil gerenciamento.

O presente howto explica passo a passo para configurar o Ollama com Docker e instalar modelos, tanto com CPU quanto com GPU.

1. Pré-requisitos

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

Nvidia Container Toolkit (Para GPU): Se você tem uma GPU Nvidia e quer aceleração, instale o Nvidia Container Toolkit para o Docker reconhecer sua placa.

2. Executar o Ollama no Docker

Abra o seu terminal e utilize os comandos abaixo:

A. Apenas CPU

-d: Roda o contêiner em segundo plano (detached mode).

-v ollama:/root/.ollama:

Cria um volume chamado ollama para garantir que seus modelos baixados não sejam apagados quando o contêiner for reiniciado.

-p 11434:11434:

Mapeia a porta padrão do Ollama.

B. Com GPU NVIDIA (Aceleração) docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama --gpus=all:

Permite que o contêiner acesse a GPU.

3. Instalar e Rodar Modelos Abertos (Ollama Pull/Run)

Com o contêiner rodando, você pode "entrar" nele e baixar os modelos através da CLI (Interface de Linha de Comando).

Download de um modelo (ex: Llama 3.2):

docker exec -it ollama ollama pull llama3.2

Executar o modelo e interagir:

docker exec -it ollama ollama run llama3.2


Agora você pode conversar com o modelo diretamente no terminal.

Outros modelos populares:

docker exec -it ollama ollama run gemma2

docker exec -it ollama ollama run deepseek-r1

docker exec -it ollama ollama run qwen2.5
4. Como ver os modelos instalados e gerenciar

Para listar os modelos que você já baixou dentro do contêiner Docker, use:

docker exec -it ollama ollama list

Para remover um modelo:

docker exec -it ollama ollama rm nome_do_modelo
5. Dica Pro: Interface Web (Open WebUI)

Para ter uma experiência tipo "ChatGPT" com o Ollama no Docker, a melhor opção é o Open WebUI.

Use o docker-compose para rodar o Ollama e a interface gráfica juntos:

Crie um arquivo docker-compose.yml:

services:
  ollama:
    volumes:
      - ollama:/root/.ollama
    container_name: ollama
    image: ollama/ollama
    ports:
      - "11434:11434"
    networks:
      - ollama-net
    restart: always

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open-webui:/app/backend/data
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    networks:
      - ollama-net
    restart: always

networks:
  ollama-net:

volumes:
  ollama:
  open-webui:

Execute: docker-compose up -d

Acesse http://localhost:3000 no seu navegador.

Feito!

Fazendo o Deploy do site com GitHub Actions

Configurar um site com GitHub Actions para fazer o deploy automático via FTP transforma seu fluxo de trabalho: você faz o git push e o GitHub cuida do resto.

O presente howto explica como fazer o deploy do seu site com GitHub Actions via FTP, comum em hospedagem compartilhada.

Segue os procedimentos:

1. Salve suas credenciais com segurança

Nunca coloque senhas diretamente no código. No seu repositório no GitHub:

Vá em Settings > Secrets and variables > Actions.

Clique em New repository secret e adicione:

FTP_SERVER: O endereço ou nome de domínio do seu servidor.

FTP_USERNAME: Seu usuário de FTP.

FTP_PASSWORD: Sua senha de FTP.

2. Crie o arquivo de Workflow

No seu projeto local, crie a pasta .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Cole o conteúdo abaixo:

Se o site foi desenvolvido apenas com HTML, CSS e JS

No seu projeto local, crie o diretório .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Segue:

.github/workflows/main.yml

Se o site foi desenvolvido com React

Diferente de um site estático simples (HTML/CSS/JS), o navegador não entende diretamente seu código React (JSX). O GitHub Actions precisa rodar o comando de compilação para criar a pasta final com os arquivos otimizados.

No seu arquivo .github/workflows/main.yml, use esta estrutura

.github/workflows/main.yml

3. Suba as alterações

Agora basta commitar e enviar para o GitHub:

git add .

git commit -m "Configurando deploy automático"

git push origin main


Você pode acompanhar o progresso em tempo real na aba Actions do seu repositório. Se tudo estiver certo, seu site será atualizado em poucos segundos!

Pontos importantes para React:

Diretório Local (local-dir): Se você usa Vite (o padrão atual), a pasta de saída é a dist/. Se usa o antigo Create React App, é a build/.

Roteamento (SPA): Se o seu site usa react-router-dom, lembre-se de configurar um arquivo .htaccess no seu servidor para redirecionar todas as rotas para o index.html, caso contrário, você receberá erro 404 ao atualizar a página.

Variáveis de Ambiente: Se o seu React usa .env, você precisará cadastrar essas variáveis nos Secrets do GitHub e injetá-las no passo de build.

Caso criou o projeto React com Vite, precisa adicionar uma configuração.

O segredo aqui é que o GitHub Actions vai criar um "computador virtual", instalar o Node.js, baixar suas bibliotecas e transformar seu código JSX em arquivos que qualquer servidor entende.

Dica de Ouro: O arquivo .htaccess

Para sites React (Single Page Applications), se você não configurar o servidor, as rotas (ex: ://seusite.com) darão erro 404 ao atualizar a página. Crie um arquivo chamado .htaccess na sua pasta public do projeto com este conteúdo:

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]

ATENÇÃO

1. Verifique se o nome da pasta de saída no seu projeto é realmente dist (padrão do Vite) ou build.
2. Certifique-se de que as Secrets (FTP_SERVER, FTP_USERNAME, FTP_PASSWORD) foram adicionadas corretamente no GitHub.
3. Faça o git push e acompanhe a "mágica" na aba Actions.

Feito!