Um ano depois: o que mudou no meu estilo de programação (e a tirinha que resume)

Há um ano eu publiquei Meu estilo de programação: PDF antes do código, PSR-12, Swagger, Jira, commits pequenos. Aquilo ainda vale. O que mudou não foi o manifesto, foi com quem e como eu construo.

Em 2025 eu escrevia sozinho e documentava para o Tiago do futuro. Em 2026 eu ainda escrevo sozinho… mas com um parceiro que digita rápido, não tem ego e estrela se o briefing for vago: a IA. E aí a tirinha acima deixa de ser só humor de escritório.

Contents

• O que ficou de 2025
• O que mudou de verdade
• Documentação viva (não só PDF)
• IA sem virar o júnior da tirinha
• Produto antes de “clever”
• Tiago’s Code Style 2026
• FAQ
• Conclusion

O que ficou de 2025

Não joguei fora o que funcionava:

• 📚 Pensar antes de abrir o terminal.
• 🧠 PHP limpo (PSR-12), nomes em inglês, camelCase.
• 🛡️ API e contratos claros quando o projeto pede.
• 📋 Rastreabilidade (Jira ou equivalente).
• 🌿 Git com commits pequenos e branches com intenção.

O artigo de 2025 era um antídoto para o “código perfeito” da tirinha: aquele que só o autor entende, cheio de aviso vermelho e zero empatia pelo próximo. Isso continua sendo o inimigo.

O que mudou de verdade

2025	2026
PDF único no início	Docs vivos no repo (.docs/, .planning/, CONTEXT/PLAN)
Figma + ERD e depois código	Mesmo, + UI-SPEC e decisões travadas por fase
Eu + editor	Eu + Cursor/IA com regras e escopo explícitos
CSS modular / Bootstrap / Vuetify	Tailwind 4, tokens, mobile-first de verdade
“Funciona na minha máquina”	Print, WP-CLI, health check, prova no ar
Arquitetura bonita no slides	Restrições de produto (cota, cron, SEO, ads)

Documentação viva (não só PDF)

O PDF ainda serve para alinhar cliente. No dia a dia, o que salva o projeto é documentação versionada, perto do código:

• 📝 Visão, restrições e stack no mesmo repositório.
• 🗺️ Fases com objetivo, plano e verificação, não só board no Jira.
• 🔎 Pesquisa antes de inventar (docs oficiais, contratos de API).
• 🧾 Runbooks do que já quebrou (cota de API, cron, cutover).

Quando a documentação vive no Git, o “eu do futuro” e a IA leem a mesma verdade. Menos “obra-prima da lógica” escondida na cabeça de alguém.

IA sem virar o júnior da tirinha

A tirinha é o anti-padrão do sênior que joga código ilegível no colo do júnior e some. Com IA o risco é o inverso e o mesmo: você vira o sênior arrogante se mandar “faz aí” sem contexto, e a ferramenta vira o júnior chorando no teclado.

O que eu aprendi a fazer:

• 🎯 Escopo fechado: o quê, por quê, o que não fazer.
• 📐 Padrões no projeto (idioma, nomenclatura, stack) como regra, não como preferência.
• 🧪 Aceitar só com prova: tela no ar, print, endpoint, data certa.
• 🧹 Revisar como sênior de time, não como fã do autocomplete.

Na prática: eu leio tudo que a IA gera, de cabo a rabo. Diff, arquivo, fluxo, edge case. Se estiver errado, torto ou “quase certo”, eu não negoceio com o autocomplete: abro o editor e codifico na mão, no modo raiz, até ficar do jeito que eu assumo em produção.

IA acelera quem já sabe o destino e quem ainda manda no teclado. Sem destino (e sem revisão), ela só produz o inferno mais rápido.

Produto antes de “clever”

O que mudou no estilo não foi “aprendi a fazer portal” ou “integrei uma API”. Foi parar de tratar projeto como demo de stack e passar a tratar como produto com restrição real: cliente, prazo, hospedagem, dinheiro, operação do dia seguinte.

Isso vale em site de casamento com lista em cotas, migração HTML→WordPress, tema full stack, CRM, automação com Python, integração pesada, portfólio, o que for. A pergunta deixou de ser “qual arquitetura fica bonita no slide?” e passou a ser:

• 🎯 Resolve o problema de quem paga / quem usa?
• 📱 Aguenta o jeito real de uso (quase sempre mobile)?
• 🧱 Sobrevive ao próximo dev (ou a mim daqui a seis meses)?
• 💸 Respeita limite de API, servidor, ads, SEO e go-live?
• 🚫 Evita cleverness que impressiona no PR e quebra na sexta à noite?

Código clever que ignora o negócio não é estilo. É dívida. Entrega de verdade é a que o cliente opera sem me ligar em pânico.

Tiago’s Code Style 2026

• 📚 Documentação inicial e docs vivos no repo.
• 🧠 Código PSR-12 / SOLID, legível para humano e para IA.
• 🐫 Inglês + camelCase (PHP/JS) sem drama.
• 🛡️ Contratos claros (API, REST, schema) quando o dado importa.
• 🏛️ Banco e domínio com integridade, sem gambiarra de prazo.
• 🎨 Front modular: tokens, Tailwind 4, mobile-first.
• 📋 Gestão com rastreio (Jira e/ou planos no Git).
• 🤖 IA com briefing, revisão de cabo a rabo e correção na mão quando falha.
• 🧪 Entrega com evidência: print, deploy, URL no ar.
• 🌿 Git pequeno, mensagem clara, branch com intenção.

“Código não é só para rodar. Código é para o próximo, humano ou agente, continuar sem surtar.”

FAQ

O artigo de 2025 ficou obsoleto?

Não. Ele é a base. Este é o patch de um ano: mesmas boas práticas, mais processo, mais produto, mais parceria com IA.

Você abandonou o Figma / Swagger / Jira?

Não. Use o que o projeto pede. O que mudou é não depender de um PDF solto nem de board sem decisão escrita perto do código.

IA substitui o estilo de programação?

Substitui digitação. Não substitui critério. Sem estilo, a tirinha vira o seu dia a dia, só que em loop infinito.

Conclusion

De 2025 para 2026 meu estilo não ficou mais “esperto”. Ficou mais hospitaleiro: para o colega, para o cliente, para o eu do futuro e para a IA que só funciona bem quando o sênior não é o vilão da tirinha.

Artigo de 2025: Meu estilo de programação. E você, o que mudou no seu jeito de construir software neste último ano?