Executando verificação de segurança...
4

IA no desenvolvimento sem cair no “vibe coding”

Como usar IA no VSCode com processo, testes e previsibilidade, adaptando o Pster’s AI Workflow sem depender do Cursor.


O problema do “vibe coding”

Ferramentas como Copilot, Claude, ChatGPT, Continue e Cline mudaram a forma de escrever software. O problema é que muita gente adotou a ferramenta sem adotar engenharia.

Nasceu então o vibe coding:

  • prompt grande
  • código gerado
  • copiar e colar
  • torcer para funcionar

Às vezes funciona. Muitas vezes vira:

  • regressão silenciosa
  • APIs inventadas
  • código plausível, mas errado
  • retrabalho
  • perda de confiança no sistema

IA acelera desenvolvimento.
Mas também acelera bagunça quando não existe processo.

O oposto de vibe coding não é parar de usar IA.
É usar IA dentro de um workflow disciplinado.


O Pster’s AI Workflow

O Pster’s AI Workflow é uma metodologia open‑source criada para reduzir alucinações e tornar o desenvolvimento assistido por IA previsível.

O fluxo é simples:

Brainstorm → Plano → Execução por fases → Review → Documentação → Commit

Cada etapa tem um papel.

Brainstorm

Antes de codar, a IA ajuda a explorar abordagens e riscos.

Plano

A tarefa é quebrada em fases pequenas.

Execução

Uma fase por vez.

Review

Segurança, performance e impacto.

Documentação

Contexto atualizado junto com o código.

Commit

Histórico claro e rastreável.

A ideia central:

IA não substitui engenharia.
Ela trabalha dentro da engenharia.


Cursor vs VSCode

O workflow nasceu no Cursor, que possui integração profunda com IA.

Mas o próprio repositório do projeto documenta como usar o método em outros editores (VSCode, terminal, etc.).

O importante não é o comando /pwf-plan.

O importante é existir uma etapa de planejamento antes de implementar.

No VSCode isso pode ser reproduzido com:

  • prompts estruturados
  • snippets
  • scripts
  • hooks de git
  • CI

Estrutura mínima de projeto

Uma organização simples já ajuda muito.

project/
├─ .ai/
│  ├─ prompts/
│  ├─ rules/
│  └─ context/
├─ docs/
│  ├─ planning/
│  ├─ architecture/
│  └─ runbooks/
├─ scripts/
│  ├─ regression-check.sh
│  └─ commit-validate.sh
├─ .github/workflows/
└─ .vscode/

Função de cada parte:

.ai → prompts e regras da IA
docs → memória do projeto
scripts → automação local
workflows → validação no CI


Ferramentas no VSCode

O workflow funciona com várias opções.

Continue.dev

Muito forte em contexto de projeto e checks versionados.

Pontos fortes:

  • lê o codebase
  • integra com múltiplos modelos
  • permite checks em PRs
  • open‑source

Cline

Focado em agentes multi‑step.

Pontos fortes:

  • navegação de arquivos
  • execução de comandos
  • aprovação humana a cada ação

Copilot Chat

Boa escolha quando o time já usa GitHub Enterprise.


Prompt base anti‑alucinação

Prompts estruturados fazem enorme diferença.

CONTEXTO
Projeto: X
Stack: Node + PostgreSQL
Arquivos relevantes: auth.ts, user.service.ts

TAREFA
Implementar validação de sessão.

REGRAS
- usar apenas APIs existentes
- não criar bibliotecas novas
- respeitar arquitetura atual

SAÍDA
1 confirmar entendimento
2 listar arquivos alterados
3 explicar abordagem
4 mostrar código

Isso reduz muito código inventado.


Fluxo de prompts

Brainstorm

Liste 3 abordagens técnicas possíveis.
Para cada uma:
- implementação
- prós
- contras
- riscos
Recomende a melhor.

Plano

Quebre a implementação em fases pequenas.
Para cada fase:
- objetivo
- arquivos envolvidos
- critérios de aceite

Execução

Implemente apenas a fase X.
Não avance para a próxima.
Liste alterações feitas.

Review

Checklist:

  • segurança
  • performance
  • consistência
  • impacto em outros módulos
  • documentação

Testes continuam sendo a prova real

IA pode gerar código elegante que não funciona.

Por isso testes são essenciais.

Fluxo clássico:

RED → GREEN → REFACTOR
  1. escrever teste
  2. teste falha
  3. implementar
  4. refatorar

Regra prática:

Código gerado por IA sem teste não entra no repositório.


Proteção contra regressão

O maior risco não é só gerar código errado.

É quebrar algo que já funcionava.

Proteção em camadas:

1 Pre‑commit

./scripts/regression-check.sh
./scripts/doc-check.sh

2 CI

npm test
npm run build
npm run lint

3 Branch protection

Sem merge com testes falhando.

4 Feature flags

Mudanças críticas ficam ativáveis/desativáveis.


Reduzindo alucinação

Alucinação nunca vai a zero.

Mas pode ser reduzida.

Principais causas:

  • falta de contexto
  • prompt vago
  • modelo fraco
  • pressa

Mitigações:

1 contexto rico
2 prompts claros
3 validação local
4 testes
5 review humano
6 CI
7 observabilidade

Objetivo: reduzir risco, não eliminar.


Vibe Coding vs Workflow

AspectoVibe codingWorkflow
velocidade inicialaltamédia
retrabalhoaltobaixo
regressãocomumrara
qualidadeinstávelprevisível
onboardingdifícilfácil

Adoção gradual

Não tente mudar tudo de uma vez.

Semana 1

  • criar estrutura .ai
  • definir prompts base

Semana 2

  • aplicar em uma feature piloto

Semana 3

  • adicionar hooks e CI

Semana 4

  • consolidar no time

Verdades duras

  • alucinação nunca desaparece
  • testes não pegam tudo
  • review humano falha
  • no começo o processo parece mais lento

Mas o ganho aparece quando o retrabalho cai.


Regras simples que funcionam

1 nunca peça código sem pedir abordagem
2 implemente em fases pequenas
3 peça testes
4 revise impacto
5 atualize documentação
6 valide antes do merge


Conclusão

IA é um amplificador.

Amplifica velocidade.
Amplifica produtividade.

Mas também amplifica erro.

A diferença está no processo.

O valor do Pster’s AI Workflow não está no Cursor.

Está em três ideias simples:

  • contexto
  • etapas pequenas
  • validação contínua

O oposto do vibe coding não é parar de usar IA.

É usar IA com método.


Referências:
Pster’s AI Workflow
https://github.com/J-Pster/Psters_AI_Workflow
Continue.dev
https://continue.dev
Cline
https://cline.bot

Carregando publicação patrocinada...
2

Parabéns pelo texto. Não sou programador, apenas um 'hobbista', e posso dizer a IA engana, faz coisas que a gente não pediu, cria textos gigantescos, erra e depois diz que o erro é seu, e pelo menos em c++, tenta acoplar tudo, alterar a cor de uma letra na tela involve alterar vários arquivo cpp e hpp em vários lugares do seu projeto, isso se vc não ficar atento. Agora só peço por modulos pequenos e monitoro para que não cresçam muito e evito acoplamento.