# Vibe coding: usos e limites

Taiga Learning · Planilha de exercício
https://taiga.training/pt-BR/lessons/vibe-coding/

Use informações fictícias ou aprovadas. Não coloque segredos nesta planilha.

## Objetivos de aprendizado
- Diferenciar a exploração de ideias de uma decisão de release.
- Identificar as responsabilidades que uma demonstração convincente não cobre.
- Definir limites seguros para um primeiro experimento.

## Exercício
Escolha uma funcionalidade de uma demonstração recente.
1. Registre um resultado que a demonstração comprovou.
2. Registre três questões que continuam em aberto.
3. Atribua um responsável a cada questão.
4. Defina uma verificação específica que possa detectar cada falha possível.
Não use “tornar seguro” no lugar de uma verificação específica.

## Sua resposta
- Cenário e escopo:
- Premissas e perguntas em aberto:
- Resposta ou decisão proposta, com motivos:

## Verifique sua resposta
| Afirmação ou critério | Evidência ou teste | Resultado ou lacuna | Responsável |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Próxima ação
- Ação, responsável e data:
- Quando você revisará esta resposta?

## Princípio a preservar
Dê às pessoas espaço para criar protótipos com dados sintéticos. Verifique a plataforma e a aplicação antes de conceder acesso a dados confidenciais ou APIs de sistemas reais.

## Fontes
- [NIST: Secure Software Development Framework 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Lovable: Security best practices](https://docs.lovable.dev/tips-tricks/security-best-practices)
- [OWASP: Broken Object Level Authorization](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)
- [Stripe: Idempotent requests](https://docs.stripe.com/api/idempotent_requests)

Esta planilha apoia o aprendizado. Preenchê-la não autoriza, por si só, uma alteração em produção.