 |
| Bellacosa Mainframe e a vibe coding sem misterios |
☕ Um Café no Bellacosa Mainframe
Vibe Coding sem Mistérios: da Ideia Nebulosa ao Aplicativo em Produção
O guia do Programador COBOL Padawan para comandar inteligências artificiais, construir software com disciplina e não transformar a nave em sucata espacial
Imagine a seguinte cena.
Você está sentado diante do terminal, com uma caneca de café ao lado, o cursor piscando na tela e uma ideia aparentemente genial atravessando sua mente:
“Vou pedir para a inteligência artificial criar um aplicativo completo.”
Você respira fundo, digita:
“Faça um aplicativo de controle financeiro.”
A IA responde com entusiasmo. Em poucos segundos aparecem telas modernas, botões elegantes, gráficos coloridos e uma estrutura de código que parece saída diretamente dos laboratórios de engenharia da Frota Estelar.
Você executa o projeto.
A tela inicial abre.
O botão “Salvar” não funciona.
O saldo aceita letras.
A senha aparece no código-fonte.
A aplicação perde todos os dados quando a página é atualizada.
O relatório mensal calcula fevereiro com 31 dias.
E, em algum lugar da galáxia, um velho programador COBOL fecha os olhos, segura a caneca de café e murmura:
“Foi por isso que inventamos análise de sistemas.”
Bem-vindo ao universo do Vibe Coding.
Não, Vibe Coding não é pedir “faça um aplicativo” e torcer para que tudo funcione. Também não é uma forma mágica de eliminar análise, testes, segurança, arquitetura ou responsabilidade.
Vibe Coding é uma nova maneira de construir software utilizando inteligência artificial como copiloto, desenvolvedor assistente, gerador de protótipos, revisor e acelerador de tarefas.
A palavra importante aqui é assistente.
A IA pode gerar o código. Pode desenhar a interface. Pode sugerir um banco de dados. Pode escrever testes. Pode até explicar por que determinada abordagem foi utilizada.
Mas alguém ainda precisa comandar a missão.
E esse alguém é você.
O que é Vibe Coding, afinal?
Vibe Coding é o desenvolvimento de software orientado por linguagem natural, contexto, exemplos visuais e ciclos rápidos de interação com inteligência artificial.
Em vez de escrever manualmente todas as linhas de código, o desenvolvedor descreve o que deseja construir.
A IA então transforma essa descrição em:
À primeira vista, parece que a programação desapareceu.
Mas ela não desapareceu.
Ela mudou de lugar.
Antes, boa parte do esforço estava em escrever instruções para a máquina utilizando uma linguagem formal.
Agora, parte do esforço passa a estar em descrever corretamente:
qual é o problema;
quem tem esse problema;
qual comportamento é esperado;
quais são os limites;
quais dados serão usados;
o que não deve ser criado;
como saberemos se o resultado está correto.
O programador deixa de ser apenas o tripulante que aperta os botões do console e passa a atuar também como:
analista;
arquiteto;
testador;
supervisor;
dono do produto;
comandante da ponte.
O Vibe Coding não elimina o raciocínio técnico. Ele pune, de maneira quase imediata, quem tenta evitá-lo.
Capítulo 1 — Não comece pela aplicação. Comece pelo problema.
Um dos maiores erros de quem entra no Vibe Coding é começar com a solução.
A pessoa diz:
“Quero criar uma rede social.”
Ou:
“Quero criar um aplicativo com inteligência artificial.”
Ou ainda:
“Quero construir o próximo Airbnb.”
Essas frases podem soar empolgantes, mas não descrevem um problema real. Elas descrevem categorias de produtos ou ambições gigantescas.
Uma boa missão começa com três elementos:
uma pessoa específica;
um problema concreto;
um resultado desejado.
Por exemplo:
Programadores COBOL iniciantes têm dificuldade para interpretar códigos de ABEND porque as informações estão espalhadas em manuais extensos e ambientes diferentes.
Agora temos uma situação clara.
A partir dela, poderíamos criar um pequeno aplicativo chamado:
ABEND Navigator
O usuário digitaria um código, como:
S0C7
E receberia:
Perceba a diferença.
“Criar uma plataforma de mainframe com IA” é nebuloso.
“Consultar causas e soluções iniciais de ABENDs” é concreto, testável e viável.
A fórmula Bellacosa para definir o problema
Use esta estrutura:
[Público] precisa de uma maneira de [ação] porque atualmente enfrenta [dificuldade].
Exemplos:
Analistas iniciantes precisam de uma maneira de organizar comandos JCL porque os exemplos estão dispersos em apostilas e anotações.
Estudantes de COBOL precisam de uma maneira de acompanhar o que estudaram porque esquecem quais assuntos precisam de revisão.
Pequenos comerciantes precisam de uma maneira simples de registrar vendas diárias porque utilizam cadernos e planilhas desorganizadas.
Essa frase funciona como as coordenadas da nave.
Sem coordenadas, até uma Enterprise equipada com os melhores computadores pode terminar dentro de um campo de asteroides.
Capítulo 2 — Escolha uma única funcionalidade inicial
Quando a ideia surge, o entusiasmo costuma assumir o controle.
O criador começa a listar:
cadastro de usuário;
painel;
chat;
notificações;
relatórios;
pagamento;
inteligência artificial;
integração com WhatsApp;
exportação para PDF;
modo escuro;
aplicativo para celular;
ranking;
gamificação;
rede social;
marketplace.
Em poucos minutos, aquele pequeno projeto se transforma em um sistema maior que o computador central da Federação.
Esse fenômeno recebe um nome conhecido na engenharia de software:
Scope creep
É o crescimento descontrolado do escopo.
O projeto começa com uma funcionalidade simples e, pouco a pouco, acumula tantas exigências que ninguém mais sabe qual problema ele deveria resolver.
A primeira versão precisa responder apenas uma pergunta:
A funcionalidade principal ajuda o usuário a resolver o problema?
No caso do ABEND Navigator, a primeira funcionalidade seria:
Digitar um código de ABEND e receber uma orientação estruturada.
Só isso.
Sem login.
Sem favoritos.
Sem assinatura premium.
Sem chatbot holográfico inspirado no computador da Enterprise.
Esses elementos podem ser adicionados depois, caso usuários reais demonstrem necessidade.
MVP não significa produto ruim
MVP é a sigla para Minimum Viable Product, ou Produto Mínimo Viável.
Existe uma confusão comum:
“Se é mínimo, pode ser malfeito.”
Não pode.
O MVP pode ter poucas funcionalidades, mas precisa ser confiável dentro do que promete.
Um sistema simples ainda deve:
validar dados;
exibir mensagens claras;
preservar informações;
evitar falhas óbvias;
proteger informações sensíveis;
funcionar no dispositivo esperado;
possuir um fluxo compreensível.
O MVP reduz a quantidade de recursos.
Ele não reduz a responsabilidade.
Um programa COBOL que possui apenas três rotinas ainda precisa calcular corretamente. Ninguém aceita um pagamento errado porque o programa era “uma primeira versão”.
Capítulo 3 — Escolha uma ferramenta e permaneça tempo suficiente para aprender
O ecossistema de Vibe Coding oferece diversas ferramentas.
Existem plataformas voltadas para:
O iniciante olha para todas elas e pensa:
“Preciso testar cada uma antes de começar.”
É assim que nasce o turismo de ferramentas.
Na segunda-feira, ele abre uma plataforma.
Na terça-feira, assiste a um vídeo sobre outra.
Na quarta-feira, migra o projeto.
Na quinta-feira, descobre uma terceira que promete ser dez vezes melhor.
Na sexta-feira, possui cinco contas, quatro projetos incompletos e nenhuma aplicação publicada.
Escolher a ferramenta perfeita é menos importante do que escolher uma ferramenta adequada e aprender seu fluxo.
Perguntas para escolher a ferramenta
Antes de decidir, avalie:
ela gera código exportável?
consigo executar o projeto fora da plataforma?
existe um plano gratuito para testes?
a publicação é simples?
há suporte ao banco de dados necessário?
consigo utilizar controle de versão?
os custos são previsíveis?
consigo recuperar versões anteriores?
a ferramenta atende ao nível de complexidade do projeto?
A melhor ferramenta não é necessariamente a mais famosa.
É aquela que permite construir, testar, entender e manter sua aplicação.
Capítulo 4 — O primeiro prompt é uma especificação disfarçada
Um prompt ruim gera um projeto baseado em adivinhações.
Considere:
“Faça um aplicativo de estudos.”
A IA precisará decidir sozinha:
quem é o usuário;
quais assuntos serão estudados;
quais telas existirão;
se haverá login;
como os dados serão armazenados;
quais relatórios serão exibidos;
qual tecnologia será usada.
Ela preencherá essas lacunas com hipóteses.
Algumas serão razoáveis.
Outras serão completamente incompatíveis com o que você imaginava.
Agora veja este prompt:
Crie uma aplicação web responsiva para estudantes de COBOL organizarem sessões de estudo. A primeira versão deve permitir cadastrar assunto, categoria, duração planejada e data. O usuário deve visualizar as sessões do dia e marcar cada sessão como concluída. Não implemente login, pagamentos, compartilhamento, notificações ou gamificação. Antes de gerar código, apresente a arquitetura proposta, a estrutura das telas, os dados necessários e os critérios de aceitação.
Aqui temos:
Quanto mais contexto fornecemos, menos a IA precisa inventar.
Os sete elementos de um bom prompt inicial
Um prompt sólido deve indicar:
Público — quem utilizará o sistema;
Problema — qual dificuldade será resolvida;
Objetivo — o que o usuário conseguirá fazer;
Escopo — o que entra na primeira versão;
Limites — o que não deve ser criado;
Critérios — como saber se funciona;
Processo — o que a IA deve apresentar antes de codificar.
Essa estrutura se aproxima muito de uma especificação funcional tradicional.
A diferença é que agora ela é escrita em linguagem natural e utilizada diretamente na construção.
Capítulo 5 — Antes do código, peça o plano de voo
Uma das práticas mais importantes no Vibe Coding é pedir um plano antes da implementação.
A tentação é grande.
Você descreve o projeto e quer ver imediatamente a tela funcionando.
Mas dez minutos analisando o plano podem economizar horas de correção.
Antes de gerar código, solicite:
arquitetura;
fluxo do usuário;
telas;
componentes;
estrutura dos dados;
validações;
riscos;
estratégia de testes;
processo de publicação.
Depois, questione.
Pergunte:
Por que essa arquitetura foi escolhida?
Existe uma alternativa mais simples?
O sistema realmente precisa de banco de dados?
Quais requisitos foram inferidos?
Quais são os principais riscos?
Que parte pode gerar custo futuro?
Existe alguma dependência que pode prender o projeto à plataforma?
Essa etapa é semelhante a revisar um fluxograma antes de escrever um programa COBOL de cinco mil linhas.
É muito mais barato corrigir uma seta no diagrama do que descobrir em produção que a rotina de fechamento contábil está executando antes da validação.
O poder da pergunta: “O que você presumiu?”
Essa é uma das perguntas mais poderosas para trabalhar com IA:
Quais decisões você tomou com base em suposições que eu não informei?
A IA pode responder que presumiu:
um único usuário;
idioma português;
armazenamento local;
ausência de dados sensíveis;
uso em desktop;
ausência de autenticação;
disponibilidade permanente da internet.
Agora você pode validar ou corrigir cada hipótese.
Uma inteligência artificial não distingue automaticamente uma regra real de uma lacuna preenchida por probabilidade.
Cabe ao comandante confirmar as coordenadas.
Capítulo 6 — Uma mudança por vez
Após gerar o protótipo, começa a fase de ajustes.
É comum enviar um pedido assim:
“Troque o menu, coloque login, corrija o formulário, mude as cores, adicione um gráfico, crie o banco, ajuste o celular e publique.”
Isso parece eficiente.
Na prática, aumenta brutalmente a chance de regressões.
A IA pode corrigir o formulário e quebrar a navegação.
Pode adicionar o banco e remover dados simulados ainda usados por outras telas.
Pode alterar o layout e destruir a responsividade.
A abordagem correta é trabalhar em mudanças pequenas.
Exemplo:
No formulário de cadastro, impeça que o campo “Assunto” seja enviado vazio. Não altere outros componentes.
Depois:
Mostre uma mensagem de erro abaixo do campo. Preserve o layout atual.
Depois:
Crie um teste para validar esse comportamento.
Uma alteração por vez oferece:
Programadores COBOL experientes conhecem esse princípio.
Quando um programa processa milhões de registros, você não altera vinte parágrafos sem necessidade porque encontrou uma condição incorreta em VALIDA-CLIENTE.
Na manutenção, precisão vale mais do que entusiasmo.
Capítulo 7 — Screenshots são telemetria visual
Uma das grandes vantagens das ferramentas modernas é a possibilidade de utilizar imagens durante a conversa.
Em vez de escrever:
“A tela está estranha.”
Você pode anexar uma captura e explicar:
No celular, o botão “Salvar” ultrapassa o limite do cartão. Ele deve ocupar toda a largura disponível abaixo dos campos. Não altere a versão desktop.
A imagem reduz ambiguidades.
Ela mostra:
Como enviar um bom pedido com screenshot
Inclua quatro elementos:
Localização
“No cartão superior direito...”
Problema atual
“O texto sobrepõe o botão...”
Resultado esperado
“O título deve quebrar em até duas linhas...”
Limite da mudança
“Não altere os demais cartões...”
A captura de tela é como um painel de diagnóstico.
Ela ajuda, mas ainda precisa de interpretação.
Um alerta no console da Enterprise não diz sozinho qual decisão o capitão deve tomar.
Capítulo 8 — Banco de dados apenas quando houver motivo
Muitos projetos de Vibe Coding começam com uma infraestrutura maior do que o próprio problema.
Antes de validar a funcionalidade, o criador já possui:
banco relacional;
autenticação;
funções serverless;
APIs;
triggers;
filas;
armazenamento;
regras de acesso;
painel administrativo.
Ele passa dias configurando tecnologia e quase nenhum tempo testando se alguém precisa da aplicação.
Para um protótipo, muitas vezes é suficiente utilizar:
O banco de dados passa a ser necessário quando precisamos:
persistir dados entre dispositivos;
trabalhar com vários usuários;
controlar permissões;
relacionar entidades;
processar volumes maiores;
manter histórico;
garantir consistência.
Exemplo prático
Considere um diário de estudos.
Na primeira versão, o navegador pode armazenar:
Assunto
Categoria
Data
Nível de confiança
Observação
Se o usuário utiliza somente um computador, isso pode ser suficiente para validar a ideia.
Mais tarde, ao precisar acessar pelo celular e pelo desktop, um banco remoto passa a fazer sentido.
A regra é simples:
Adicione complexidade quando ela resolver um problema real, não quando parecer tecnologicamente elegante.
Capítulo 9 — A IA também pode modelar dados errado
A inteligência artificial pode criar uma tabela em segundos.
Isso não significa que a estrutura esteja correta.
Imagine uma tabela:
TAREFAS
ID
USUARIO
CLIENTE
TITULO
STATUS
PRAZO
OBSERVACAO
Para uma demonstração, pode funcionar.
Mas, se vários clientes possuem muitas tarefas, provavelmente teremos entidades separadas:
USUARIOS
CLIENTES
TAREFAS
Agora surgem perguntas importantes:
qual é a chave de cada tabela?
uma tarefa pode existir sem cliente?
o que acontece quando um cliente é excluído?
precisamos guardar histórico?
o status possui valores controlados?
uma tarefa pertence a um ou mais usuários?
informações antigas podem ser alteradas?
Essas decisões continuam existindo.
Vibe Coding não revogou normalização, integridade referencial ou consistência transacional.
No mundo mainframe, ninguém trataria a estrutura de um arquivo VSAM ou uma tabela Db2 como detalhe decorativo.
Dados são o coração do sistema.
A interface pode mudar.
A tecnologia pode mudar.
Mas um dado mal modelado costuma assombrar o projeto por muitos anos.
Capítulo 10 — Segurança: o campo minado escondido
Aplicações geradas rapidamente podem conter vulnerabilidades sérias.
Entre os problemas mais frequentes estão:
chaves de API expostas;
senhas armazenadas de forma inadequada;
ausência de validação no servidor;
acesso aos dados de outros usuários;
permissões excessivas;
informações pessoais em logs;
upload de arquivos sem controle;
dependências vulneráveis;
consultas inseguras.
A interface pode parecer maravilhosa enquanto o sistema possui uma porta aberta no casco da nave.
Nunca aceite uma declaração genérica como:
“A aplicação está segura.”
Peça explicações concretas:
Onde os segredos são armazenados?
Alguma chave é enviada para o navegador?
Como um usuário é impedido de acessar dados de outro?
A validação ocorre apenas na tela ou também no servidor?
Existe proteção contra envio duplicado?
Quais informações aparecem nos logs?
Como os dados são excluídos?
Quais bibliotecas foram instaladas?
Para sistemas que lidam com pagamentos, saúde, dados pessoais, documentos ou credenciais, a revisão humana especializada é indispensável.
A IA pode acelerar o trabalho.
Ela não pode assumir legalmente a responsabilidade pelo vazamento.
Capítulo 11 — Teste o usuário real, não o usuário imaginário
A IA costuma demonstrar o caminho perfeito:
o usuário preenche tudo corretamente;
clica uma vez;
a conexão está estável;
o banco responde;
a operação termina.
Usuários reais fazem coisas muito mais interessantes.
Eles:
deixam campos vazios;
digitam texto em campos numéricos;
clicam duas vezes;
perdem a conexão;
voltam pelo navegador;
abrem várias abas;
colam textos enormes;
utilizam caracteres especiais;
fecham a tela no meio da operação.
Por isso, teste pelo menos os seguintes cenários.
Caminho feliz
Dados válidos, fluxo normal e resultado esperado.
Entrada inválida
Campos vazios, números negativos, datas impossíveis e formatos errados.
Repetição
Cliques duplos, envio repetido e atualização da página.
Interrupção
Falha de rede, erro do servidor ou fechamento inesperado.
Permissão
Tentativa de acessar recursos de outro usuário.
Persistência
Verificação de que os dados permanecem corretos após reiniciar.
Responsividade
Teste em computador, tablet e celular.
Volume
Teste com dez, cem e mil registros, quando fizer sentido.
O programa não está pronto porque funcionou uma vez.
Ele começa a merecer confiança quando continua funcionando diante de comportamentos imperfeitos.
Capítulo 12 — Controle de versão: o botão de voltar no tempo
Uma das práticas mais importantes no desenvolvimento é o controle de versão.
Ferramentas como Git permitem registrar o estado do projeto ao longo do tempo.
Antes de uma mudança importante, você cria um ponto de recuperação.
Se algo quebrar, pode comparar versões ou retornar.
Sem controle de versão, o fluxo costuma ser:
projeto-final
projeto-final-2
projeto-final-agora-vai
projeto-final-correto
projeto-final-correto-mesmo
projeto-final-correto-mesmo-ultimo
Esse sistema de nomes funciona apenas até o dia em que ninguém lembra qual versão realmente funcionava.
No Vibe Coding, o controle de versão é ainda mais importante porque agentes podem alterar vários arquivos rapidamente.
Uma boa instrução é:
Antes de modificar, informe quais arquivos serão alterados. Faça a mudança em uma etapa isolada e gere um resumo ao final.
E, idealmente:
Crie um commit antes da alteração.
Mesmo quem está começando deve aprender pelo menos:
git init
git status
git add .
git commit -m "Versão inicial funcional"
Isso já cria uma rede de segurança.
Na Frota Estelar, antes de testar uma dobra experimental, alguém certamente registra o estado dos sistemas. Pelo menos deveria.
Capítulo 13 — Publicar cedo, mas não de maneira irresponsável
Manter o projeto para sempre no computador impede o aprendizado real.
O usuário precisa testar.
A publicação revela problemas que não aparecem no ambiente local:
Entretanto, publicar cedo não significa lançar um sistema inseguro para milhares de pessoas.
Uma estratégia sensata é:
testar localmente;
compartilhar com uma pessoa;
corrigir problemas graves;
liberar para cinco usuários;
observar o uso;
coletar feedback;
estabilizar;
ampliar gradualmente.
Essa abordagem é chamada de liberação progressiva.
Ela reduz risco e melhora o aprendizado.
Tenha um plano de reversão
Antes de publicar, responda:
como volto para a versão anterior?
existe backup?
onde os erros serão registrados?
quem será avisado em caso de falha?
consigo desativar a funcionalidade?
os dados serão preservados durante a reversão?
Publicar sem rollback é como entrar em dobra sem saber como reduzir a velocidade.
Pode funcionar.
Mas você não quer descobrir o contrário perto de uma estrela.
Capítulo 14 — Feedback real vale mais que elogio educado
Depois que os primeiros usuários testarem, não pergunte apenas:
“Você gostou?”
Quase todos responderão “sim”.
Perguntas melhores são:
Em que momento você ficou confuso?
O que esperava que acontecesse ao clicar?
Qual etapa demorou mais?
Que tarefa você ainda precisou fazer fora da aplicação?
Qual parte parece desnecessária?
Você usaria isso novamente amanhã?
O objetivo não é receber aplausos.
É descobrir atrito.
Talvez você tenha criado um painel sofisticado com gráficos, enquanto os usuários realmente desejam um botão simples para duplicar o registro anterior.
O usuário real frequentemente destrói nossas teorias em menos de cinco minutos.
E isso é ótimo.
Cada hipótese destruída cedo economiza meses de trabalho na direção errada.
Capítulo 15 — O programador COBOL possui uma vantagem secreta
À primeira vista, Vibe Coding parece pertencer apenas ao universo de JavaScript, aplicações web e startups.
Mas programadores COBOL possuem uma vantagem enorme.
Eles estão acostumados a pensar em:
Um programador COBOL sabe que o valor do sistema não está apenas na sintaxe.
Não é o MOVE, o PERFORM ou o EVALUATE que sustenta um banco.
É o entendimento do processo.
Da mesma forma, no Vibe Coding, saber pedir código é apenas uma parte.
O verdadeiro diferencial é saber:
o que deve ser construído;
o que não deve ser construído;
qual regra não pode falhar;
qual dado precisa ser protegido;
qual cenário precisa ser testado;
qual alteração pode afetar outra rotina.
O Padawan COBOL que aprende a utilizar IA sem abandonar seus fundamentos pode se tornar um profissional extremamente poderoso.
Ele combina:
experiência de negócio;
disciplina de sistemas críticos;
conhecimento de dados;
capacidade de modernização;
velocidade de ferramentas generativas.
É quase como instalar motores de dobra em uma nave construída para sobreviver décadas.
Capítulo 16 — Exemplo completo: COBOL Learning Log
Vamos construir mentalmente uma aplicação simples.
Problema
Estudantes de mainframe aprendem muitos assuntos, mas não acompanham o que já estudaram e o que precisa de revisão.
Público
Programadores COBOL iniciantes.
Objetivo
Registrar tópicos estudados e indicar o nível de confiança.
Funcionalidade principal
Cadastrar e consultar tópicos de estudo.
Dados mínimos
assunto;
categoria;
data;
nível de confiança;
observação.
Categorias
COBOL;
JCL;
Db2;
CICS;
VSAM;
z/OS.
Fora do escopo inicial
Prompt inicial
Ajude-me a criar uma aplicação web responsiva chamada COBOL Learning Log, destinada a estudantes iniciantes de mainframe. O problema é que eles estudam vários tópicos, mas não possuem uma visão clara do que aprenderam e do que precisa de revisão.
A primeira versão deve permitir cadastrar um tópico contendo nome, categoria, data de estudo, nível de confiança de 1 a 5 e observação opcional. A tela inicial deve listar os registros e permitir filtro por categoria.
Não implemente login, pagamentos, certificados, compartilhamento, chat ou integração com IA.
Antes de gerar código, apresente a arquitetura mais simples, o fluxo do usuário, as telas, a estrutura dos dados, as validações, os testes e a estratégia de publicação.
Utilize armazenamento local inicialmente. Faça no máximo cinco perguntas caso alguma decisão seja indispensável.
Critérios de aceitação
assunto obrigatório;
categoria obrigatória;
nível entre 1 e 5;
data não pode estar no futuro;
dados permanecem após atualizar;
filtro funciona corretamente;
exclusão exige confirmação;
interface funciona no celular.
Perceba como o projeto deixou de ser uma ideia vaga.
Agora temos uma missão clara, critérios objetivos e fronteiras definidas.
Capítulo 17 — O ciclo Bellacosa de Vibe Coding
Um fluxo seguro pode seguir dez etapas.
1. Descrever
Explique o problema e o público.
2. Limitar
Escolha uma única funcionalidade principal.
3. Planejar
Peça arquitetura, telas e dados antes do código.
4. Questionar
Investigue suposições, riscos e custos.
5. Construir
Implemente uma parte pequena.
6. Executar
Teste no ambiente real.
7. Observar
Compare o resultado com os critérios.
8. Corrigir
Faça uma mudança por vez.
9. Publicar
Disponibilize para poucos usuários.
10. Aprender
Use o feedback para decidir o próximo passo.
Depois, repita.
Esse ciclo é muito mais importante do que qualquer ferramenta específica.
Ferramentas mudam.
Modelos mudam.
Plataformas surgem e desaparecem.
O processo continua válido.
Capítulo 18 — Um prompt mestre para sua próxima missão
Utilize este modelo:
Atue como analista de produto, arquiteto de software, desenvolvedor e testador responsável.
Ajude-me a criar um aplicativo para [PÚBLICO] resolver [PROBLEMA].
O resultado principal esperado é [RESULTADO].
Antes de gerar código:
reescreva o problema de forma objetiva;
identifique dúvidas e suposições;
proponha um MVP com uma única funcionalidade central;
liste o que ficará fora da primeira versão;
recomende a ferramenta mais simples;
descreva o fluxo do usuário;
proponha as telas;
modele os dados mínimos;
liste validações;
identifique riscos de segurança;
crie critérios de aceitação;
prepare casos de teste;
explique a publicação;
defina uma estratégia de rollback.
Não acrescente funcionalidades sem minha autorização.
Durante a implementação, faça uma mudança por vez, informe quais arquivos serão alterados e preserve tudo o que já estiver funcionando.
Esse prompt não garante perfeição.
Mas cria um ambiente muito mais controlado.
Curiosidades do convés de engenharia
A IA não “entende” seu projeto como um colega humano
Ela trabalha a partir do contexto disponível.
Quando informações faltam, ela pode completar as lacunas com padrões estatísticos.
Isso significa que uma resposta convincente pode conter uma decisão errada.
Código bonito não significa código correto
Uma interface elegante pode esconder:
O protótipo é uma pergunta, não uma resposta
Seu objetivo inicial não é provar que a ideia é genial.
É descobrir se ela resolve um problema.
A complexidade cobra juros
Cada banco, integração, serviço e dependência adiciona custo de manutenção.
O usuário raramente pede aquilo de que realmente precisa
Ele pode pedir um gráfico.
Após observar seu trabalho, você descobre que ele precisava de um alerta.
Easter egg da Frota Estelar
Em muitas histórias de Star Trek, o computador da Enterprise parece capaz de executar quase qualquer ordem:
“Computador, analise a composição da atmosfera.”
“Computador, localize a nave.”
“Computador, simule o cenário.”
Mas observe um detalhe.
Os oficiais fazem perguntas específicas.
Eles informam parâmetros.
Eles verificam resultados.
Eles discordam do computador.
Eles cruzam dados.
Eles assumem o comando quando a situação muda.
A ficção nunca disse que possuir um computador poderoso eliminaria a necessidade de julgamento humano.
Na verdade, ela sugeriu o contrário.
Quanto mais poderosa a tecnologia, mais importante se torna a responsabilidade de quem a utiliza.
Vibe Coding é exatamente isso.
Temos acesso a uma espécie de computador de bordo capaz de criar sistemas em minutos.
A pergunta não é apenas:
“O que ele consegue construir?”
A pergunta mais importante é:
“Somos capazes de descrever corretamente o que deve ser construído?”
Conclusão — A IA é o motor de dobra, não o capitão
Vibe Coding representa uma transformação extraordinária.
Pessoas que nunca construíram software podem criar protótipos.
Programadores experientes podem acelerar tarefas repetitivas.
Empresas podem validar ideias em menos tempo.
Estudantes podem aprender observando código funcional.
Mas nenhum desses benefícios elimina os fundamentos.
Um bom sistema ainda exige:
clareza;
escopo;
análise;
validação;
testes;
segurança;
controle de versão;
observabilidade;
responsabilidade;
aprendizado contínuo.
A habilidade principal do futuro talvez não seja escrever cada linha manualmente.
Será saber conduzir máquinas capazes de escrevê-las.
O programador deixará de ser apenas quem produz instruções e se tornará cada vez mais quem:
define intenções;
estabelece limites;
avalia riscos;
verifica resultados;
protege usuários;
decide prioridades;
mantém coerência.
Para o Programador COBOL Padawan, isso não é uma ameaça.
É uma oportunidade histórica.
Você já conhece o valor da precisão.
Já sabe que uma pequena regra pode movimentar milhões.
Já aprendeu que sistemas vivem muito mais tempo do que a primeira versão imaginava.
Agora chegou o momento de levar essa disciplina para o universo da inteligência artificial.
Use a IA.
Explore.
Construa.
Publique.
Mas nunca abandone o painel de comando.
Porque, no final, não importa quantos agentes, modelos ou geradores estejam trabalhando na sala de máquinas.
Quando o alerta vermelho tocar, alguém ainda precisará sentar na cadeira do capitão e dizer:
“Computador, explique exatamente o que você alterou.”
E talvez acrescentar:
“Desta vez, sem mexer no módulo que já estava funcionando.”
Vibe on, Padawan. Mas mantenha o controle da nave.
