Prompts para programar com IA: código que funciona

Um prompt de programação é uma especificação. O modelo não viu o seu projeto, não sabe que versão da linguagem você usa e não tem como perguntar o que deve acontecer quando a entrada estiver vazia. O que o prompt deixa de fora, ele preenche com a escolha mais comum nos dados de treinamento, e a escolha mais comum muitas vezes não é a sua. Os prompts abaixo deixam menos coisas para o modelo adivinhar.

Escreva a especificação antes do código

O bloco abaixo pede uma pequena função em Python. Cada parte do prompt responde a uma pergunta que o modelo responderia por você. Desligue as partes uma por vez e imagine a resposta sem elas: sem as restrições, você pode receber uma biblioteca de terceiros; sem o contexto, o modelo precisa adivinhar o que conta como entrada válida; sem o formato, você pode ficar sem testes.

Função a partir de uma especificação

EditCopy

Fill inversao

PartsRoleTaskContextConstraintsFormat

Role

Você é um desenvolvedor Python cuidadoso que escreve funções pequenas e testadas.

Task

Escreva uma função `parse_duration(text)` que transforma uma string de duração em um número de segundos.

Context

Entradas válidas são como "1h30m", "45m", "2h" e "90s": horas, minutos e segundos, cada um opcional, sempre nessa ordem. "1h30m" retorna 5400. Qualquer outra coisa, incluindo uma string vazia, é inválida.

Constraints

Python 3.11, só a biblioteca padrão. Gere um ValueError para entradas inválidas, com a entrada na mensagem. Não aceite decimais como "1.5h".

Format

Dê primeiro a função e depois testes em pytest cobrindo todos os exemplos acima mais três entradas inválidas. Nenhuma explicação além de uma frase.

Try it

Example replyReplies vary between models and runs.

A função casa as três partes opcionais em ordem e rejeita um resultado em que as três estejam vazias.

import re

_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text: str) -> int:
    match = _PATTERN.fullmatch(text)
    if not match or not any(match.groups()):
        raise ValueError(f"invalid duration: {text!r}")
    hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
    return hours * 3600 + minutes * 60 + seconds

import pytest
from duration import parse_duration

@pytest.mark.parametrize("text, expected", [
    ("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
    assert parse_duration(text) == expected

@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
    with pytest.raises(ValueError):
        parse_duration(text)

Quatro detalhes nesse prompt fazem a maior parte do trabalho:

• Exemplos com as respostas. "1h30m retorna 5400" é um teste com o qual o modelo pode conferir o próprio código, e elimina qualquer dúvida sobre a unidade.
• A versão da linguagem e as bibliotecas permitidas. Sem elas, você pode receber uma biblioteca que não instalou ou uma sintaxe mais nova que o seu interpretador.
• O que conta como inválido, e o que deve acontecer nesse caso. O tratamento de erros é fácil de o modelo esquecer quando ninguém pede.
• Testes na resposta. Eles transformam "parece certo" em algo que você pode rodar. Se um teste falhar, você cola a falha de volta, o que é uma continuação muito melhor do que "não funciona".

A verificação any(match.groups()) também merece atenção: o padrão sozinho casa com uma string vazia, porque todas as partes são opcionais. A linha do prompt sobre a string vazia é o que faz esse caso aparecer no código e nos testes.

Diga a versão, a stack e o que já existe

Os modelos puxam para o estilo que era mais comum nos dados de treinamento. Em JavaScript, isso pode significar require do CommonJS em um projeto que usa ES modules; em Python, pode significar a API de uma biblioteca que já mudou (Pydantic 1 e 2 é um caso comum); e em qualquer framework que muda rápido, pode significar o padrão de duas versões principais atrás. Uma linha costuma resolver: "Node 22, ES modules, sem TypeScript" ou "React 19, componentes de função, CSS modules simples".

Quando você está acrescentando algo a um projeto existente, o modelo precisa ver as partes que o código novo vai tocar. Cole a assinatura da função que ele precisa chamar, o formato dos dados que ele vai receber e um arquivo existente que mostre as suas convenções. "Use o helper db.query(sql, params) do arquivo abaixo" gera um código que se encaixa; sem isso, você pode receber uma conexão nova com o banco escrita do zero. Deixe de fora arquivos que não têm nada a ver com a mudança, porque cada linha sem relação é algo que o modelo pode tentar reaproveitar.

Peça um passo pequeno por vez

A falha mais comum no "vibe coding", criar um app descrevendo-o para uma IA, é pedir o app inteiro de uma vez. O modelo precisa escolher um framework, um banco de dados, uma estrutura de pastas e uma dúzia de recursos em uma única resposta, e uma única resposta raramente comporta código funcionando para tudo isso, então o que costuma voltar é um esboço. Compare as duas abas.

O app inteiro de uma vezUm passo pequeno

EditCopy

Crie para mim um app de tarefas com contas de usuário, banco de dados, lembretes e modo escuro.

Try it

Example replyReplies vary between models and runs.

Aqui está um app de tarefas full stack usando React, Node.js com Express e MongoDB.

Estrutura do projeto

todo-app/
  client/   (front end em React)
  server/   (API em Express, autenticação, lembretes)

server/index.js

const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here

Para a autenticação você pode acrescentar JWT com jsonwebtoken, e para os lembretes um agendador como o node-cron. Me avise se quiser que eu preencha alguma dessas partes.

A primeira resposta não está errada, mas é um esqueleto: ela escolheu três tecnologias por você e deixou o trabalho de verdade como comentários. A segunda resposta é curta o bastante para ler, roda assim que você abre o arquivo e dá uma base funcionando para o passo 2 ("agora salve a lista no localStorage para ela sobreviver a um recarregamento"). Cada passo é pequeno o bastante para que, quando algo quebrar, você saiba qual mudança quebrou.

Isso é encadeamento de prompts feito à mão: a saída de um pedido vira o ponto de partida do seguinte. Cole a versão atual do arquivo em cada passo novo, para que o modelo edite o código que você realmente tem, e não o que ele lembra de ter escrito.

Peça um plano antes de uma mudança grande

Para qualquer coisa maior que uma função, peça primeiro o plano e depois o código: "Liste os arquivos que você mudaria e o que cada mudança faz. Não escreva código ainda." Um plano é rápido de ler e rápido de corrigir. Se ele propõe uma dependência nova que você não quer ou esquece um arquivo que você sabe que está envolvido, você corrige isso em uma frase, em vez de descobrir no meio de trezentas linhas de código.

Confira o que volta

O código gerado falha de alguns jeitos previsíveis, e cada um tem um hábito de prompt que o pega:

• APIs inventadas. Um modelo pode chamar uma função ou importar um pacote que não existe, porque o nome soa plausível. Pesquise imports desconhecidos antes de instalar; alucinação de IA explica por que isso acontece.
• Casos extremos esquecidos. Código que funciona no caminho feliz e quebra com uma lista vazia. Listar os casos extremos no prompt e pedir testes é a solução mais barata.
• Mudanças silenciosas. Quando você pede uma correção em um arquivo longo, o modelo pode também renomear coisas ou reorganizar código que você não pediu. Acrescente "mude só o necessário e liste todas as mudanças que você fez".

Quando o código roda, mas se comporta mal, passe para um prompt de depuração: prompts para depuração mostra o que colar. Antes de fazer merge de algo importante, uma segunda passada com um prompt de code review pode pegar problemas que o prompt de escrita não pensou em perguntar.