{
"version": "0.1.0",
"updated": "2026-10-25",
"intro": {
"en": "A shared vocabulary for the ways engineers direct AI when they write software. Each style has a definition, an example prompt, what it reveals about the person using it, when it fits, what to watch out for, and where the term came from.",
"pt": "Um vocabulário comum para as formas como engenheiros conduzem a IA ao escrever software. Cada estilo tem definição, exemplo de prompt, o que revela sobre quem usa, quando faz sentido, onde estão os riscos e de onde veio o termo."
},
"note": {
"en": "Horizontal: how much the prompt dictates the implementation. Vertical: how much the output is checked against an explicit contract (tests, a spec, review). Styles are a spectrum, not exclusive boxes. Strong engineers combine them and switch on purpose as risk and complexity change. Positions are approximate and open to debate: propose a change with a pull request.",
"pt": "Horizontal: o quanto o prompt dita a implementação. Vertical: o quanto o output é conferido contra um contrato explícito (testes, uma spec, revisão). Os estilos formam um espectro, não caixas exclusivas. Bons engenheiros combinam vários e trocam de propósito conforme o risco e a complexidade mudam. As posições são aproximadas e abertas a debate: proponha mudanças com um pull request."
},
"axes": {
"how": {
"low": {
"en": "Describes the outcome",
"pt": "Descreve o resultado"
},
"high": {
"en": "Dictates the implementation",
"pt": "Dita a implementação"
}
},
"verification": {
"low": {
"en": "Trusts the output",
"pt": "Confia no output"
},
"high": {
"en": "Verifies the output",
"pt": "Verifica o output"
}
}
},
"scenario": {
"title": {
"en": "One feature, eight ways",
"pt": "Uma feature, oito jeitos"
},
"description": {
"en": "Every style shows a prompt for the same feature so you can compare them side by side: an image carousel for a home page that shows 5 images from the database, advances every 5 seconds, lazy-loads images and flashes twice when switching.",
"pt": "Todos os estilos mostram um prompt para a mesma feature, para dar para comparar lado a lado: um carrossel de imagens na home que mostra 5 imagens do banco, troca a cada 5 segundos, faz lazy load e pisca duas vezes ao trocar."
}
},
"styles": [
{
"id": "declarative",
"order": 1,
"status": "draft",
"name": {
"en": "Declarative",
"pt": "Declarativo"
},
"aka": [
"outcome-oriented",
"result-driven"
],
"map": {
"how": 22,
"verification": 38
},
"summary": {
"en": "Describe what the software must do and let the AI decide how.",
"pt": "Descreve o que o software precisa fazer e deixa a IA decidir como."
},
"definition": {
"en": "You specify behavior, business rules and user experience, and leave data structures, algorithms and file layout to the model. Strong declarative prompts are precise about outcomes and constraints and silent about implementation. This is how product-minded engineers usually start a feature.",
"pt": "Você especifica comportamento, regras de negócio e experiência do usuário, e deixa estruturas de dados, algoritmo e organização dos arquivos com o modelo. Um bom prompt declarativo é preciso sobre resultado e restrições, e não fala nada de implementação. É assim que engenheiros com cabeça de produto costumam começar uma feature."
},
"example": {
"prompt": {
"en": "Create an image carousel for the home page.\n- Show the 5 most recent images from the database.\n- Advance every 5 seconds.\n- Lazy-load images that are not visible yet.\n- Flash twice when switching images.\n- Work on mobile and pause while the user hovers or touches it.",
"pt": "Crie um carrossel de imagens para a home.\n- Mostre as 5 imagens mais recentes do banco.\n- Troque a cada 5 segundos.\n- Faça lazy load das imagens que ainda não estão visíveis.\n- Pisque duas vezes ao trocar de imagem.\n- Funcione no celular e pause enquanto o usuário passa o mouse ou toca nele."
}
},
"reveals": {
"en": [
"Ability to specify a problem clearly and completely",
"Product thinking: edge cases, UX, constraints",
"Knowing which details matter and which can be delegated"
],
"pt": [
"Capacidade de especificar um problema de forma clara e completa",
"Pensamento de produto: casos de borda, UX, restrições",
"Saber quais detalhes importam e quais podem ser delegados"
]
},
"use_when": {
"en": [
"The outcome is clearer than the design",
"The codebase has strong conventions the model can follow",
"UI and product work"
],
"pt": [
"O resultado está mais claro que o design",
"O codebase tem convenções fortes que o modelo consegue seguir",
"Trabalho de UI e produto"
]
},
"watch_out": {
"en": [
"Ambiguity: the model fills every gap with its own assumptions",
"Accepting whatever architecture comes back without reviewing it",
"Hard to steer once the implementation goes in the wrong direction"
],
"pt": [
"Ambiguidade: o modelo preenche cada lacuna com as próprias suposições",
"Aceitar qualquer arquitetura que vier sem revisar",
"Difícil de corrigir o rumo quando a implementação vai para o lado errado"
]
},
"interview": {
"look_for": {
"en": [
"Are requirements, constraints and edge cases stated before anything is generated?",
"Does the candidate review the implementation, or only the visible behavior?"
],
"pt": [
"Requisitos, restrições e casos de borda são ditos antes de gerar qualquer coisa?",
"A pessoa revisa a implementação ou só o comportamento visível?"
]
},
"ask": {
"en": [
"Which decisions did you leave to the model, and why were they safe to delegate?",
"What would you have specified differently if this were a checkout page?"
],
"pt": [
"Quais decisões você deixou com o modelo, e por que era seguro delegar?",
"O que você especificaria diferente se isso fosse uma página de checkout?"
]
}
},
"origin": {
"summary": {
"en": "Borrowed from declarative programming (SQL, HTML, functional and logic languages), which describes the desired result instead of the steps to reach it. No single author applied the term to prompts; the declarative vs. imperative framing for AI coding is community usage.",
"pt": "Emprestado da programação declarativa (SQL, HTML, linguagens funcionais e lógicas), que descreve o resultado desejado em vez dos passos para chegar nele. Nenhum autor específico aplicou o termo a prompts; a divisão declarativo vs. imperativo em AI coding é uso da comunidade."
},
"sources": [
{
"title": "Declarative programming (Wikipedia)",
"url": "https://en.wikipedia.org/wiki/Declarative_programming"
}
]
},
"related": [
"imperative",
"vibe-coding",
"spec-driven"
]
},
{
"id": "imperative",
"order": 2,
"status": "draft",
"name": {
"en": "Imperative",
"pt": "Imperativo"
},
"aka": [
"implementation-oriented",
"step-by-step"
],
"map": {
"how": 88,
"verification": 52
},
"summary": {
"en": "Dictate how the code should work: data structures, algorithm, control flow.",
"pt": "Dita como o código deve funcionar: estruturas de dados, algoritmo, fluxo de controle."
},
"definition": {
"en": "You tell the model the implementation step by step: which structures to use, how data flows, what happens on each tick. The model becomes a fast typist for a design that already exists in your head. You get maximum control and an easy review, at the cost of speed and of ideas you would not have had on your own.",
"pt": "Você passa a implementação para o modelo passo a passo: quais estruturas usar, como os dados fluem, o que acontece a cada ciclo. O modelo vira um digitador rápido para um design que já está na sua cabeça. Você ganha controle máximo e revisão fácil, ao custo de velocidade e de ideias que você não teria sozinho."
},
"example": {
"prompt": {
"en": "Fetch the latest 5 images from the database into an array.\nUse setInterval every 5s. On each tick, shift the first item, push it\nto the end and prefetch the URL of the next image.\nUse IntersectionObserver for lazy loading.\nWhile an image loads, show a skeleton sized from its stored width and height.\nFor the transition, toggle a CSS class twice with 150ms between toggles.",
"pt": "Busque as últimas 5 imagens do banco num array.\nUse setInterval a cada 5s. A cada tick, faça shift do primeiro item,\ndê push no final e faça prefetch da URL da próxima imagem.\nUse IntersectionObserver para o lazy load.\nEnquanto a imagem carrega, mostre um skeleton com a largura e a altura salvas.\nNa transição, alterne uma classe CSS duas vezes com 150ms entre as trocas."
}
},
"reveals": {
"en": [
"Technical depth: data structures, performance, platform APIs",
"Architecture and design ability",
"Capacity to guide and review generated code precisely"
],
"pt": [
"Profundidade técnica: estruturas de dados, performance, APIs da plataforma",
"Capacidade de arquitetura e design",
"Capacidade de guiar e revisar o código gerado com precisão"
]
},
"use_when": {
"en": [
"Performance-sensitive or security-sensitive code",
"You already know the right design and want exactly that",
"Fixing a specific bug or refactoring a known hot spot"
],
"pt": [
"Código sensível a performance ou segurança",
"Você já sabe o design certo e quer exatamente ele",
"Corrigir um bug específico ou refatorar um ponto crítico conhecido"
]
},
"watch_out": {
"en": [
"Micromanaging the model can be slower than typing the code yourself",
"It shuts out better approaches the model might have suggested",
"Prompts get long and brittle"
],
"pt": [
"Microgerenciar o modelo pode ser mais lento que escrever o código você mesmo",
"Fecha a porta para abordagens melhores que o modelo poderia sugerir",
"Os prompts ficam longos e frágeis"
]
},
"interview": {
"look_for": {
"en": [
"Are the dictated decisions correct, and can the candidate justify them?",
"Does the candidate know when to stop dictating and delegate?"
],
"pt": [
"As decisões ditadas estão corretas, e a pessoa consegue justificá-las?",
"A pessoa sabe a hora de parar de ditar e delegar?"
]
},
"ask": {
"en": [
"Why setInterval here and not requestAnimationFrame or a CSS animation?",
"What did you dictate that you could have safely delegated?"
],
"pt": [
"Por que setInterval aqui e não requestAnimationFrame ou uma animação CSS?",
"O que você ditou que poderia ter delegado com segurança?"
]
}
},
"origin": {
"summary": {
"en": "Borrowed from imperative programming, which describes computation as a sequence of statements that change state. As with declarative, there is no single author for the prompt-style usage.",
"pt": "Emprestado da programação imperativa, que descreve a computação como uma sequência de comandos que mudam o estado. Assim como no declarativo, não há um autor único para o uso em prompts."
},
"sources": [
{
"title": "Imperative programming (Wikipedia)",
"url": "https://en.wikipedia.org/wiki/Imperative_programming"
}
]
},
"related": [
"declarative",
"example-based",
"iterative"
]
},
{
"id": "vibe-coding",
"order": 3,
"status": "draft",
"name": {
"en": "Vibe coding",
"pt": "Vibe coding"
},
"map": {
"how": 6,
"verification": 6
},
"summary": {
"en": "Describe loosely, accept what comes back, barely read the code.",
"pt": "Descreve de forma solta, aceita o que volta e quase não lê o código."
},
"definition": {
"en": "The far declarative end of the spectrum. You steer by feel, judge the result by running it and paste errors back until it works. The code itself is treated as disposable. Great for throwaway prototypes and exploration. Risky anywhere the code has to be maintained, secured or trusted.",
"pt": "O extremo declarativo do espectro. Você conduz pela sensação, julga o resultado rodando e cola os erros de volta até funcionar. O código em si é tratado como descartável. Ótimo para protótipos e exploração. Arriscado em qualquer lugar onde o código precise ser mantido, protegido ou confiável."
},
"example": {
"note": {
"en": "Two turns. The second one only reacts to how it looks.",
"pt": "Dois turnos. O segundo só reage a como ficou na tela."
},
"prompt": {
"en": "make a cool image carousel for the home page with our photos, make it feel alive\n\nit's kind of janky, fix it and make it smoother",
"pt": "faz um carrossel de imagens massa pra home com as nossas fotos, deixa com vida\n\ntá meio travado, arruma e deixa mais suave"
}
},
"reveals": {
"en": [
"Speed of exploration and willingness to try things",
"Product intuition, when the result is judged critically",
"In production work: a red flag if the person cannot explain the code"
],
"pt": [
"Velocidade de exploração e disposição para testar ideias",
"Intuição de produto, quando o resultado é avaliado com senso crítico",
"Em código de produção: sinal de alerta se a pessoa não consegue explicar o código"
]
},
"use_when": {
"en": [
"Throwaway prototypes, demos and spikes",
"Exploring an unfamiliar idea or API quickly",
"Personal tools where failure is cheap"
],
"pt": [
"Protótipos descartáveis, demos e spikes",
"Explorar rápido uma ideia ou API desconhecida",
"Ferramentas pessoais onde errar custa pouco"
]
},
"watch_out": {
"en": [
"Code nobody understands ends up in the main branch",
"Security problems (secrets, injection, auth) slip through unread",
"Errors get \"fixed\" by piling more generated code on top"
],
"pt": [
"Código que ninguém entende vai parar na branch principal",
"Problemas de segurança (segredos, injection, auth) passam sem ninguém ler",
"Erros são \"corrigidos\" empilhando mais código gerado por cima"
]
},
"interview": {
"look_for": {
"en": [
"Does the candidate say they are prototyping, and switch styles when the stakes rise?",
"Do they read the diff before accepting it?"
],
"pt": [
"A pessoa avisa que está prototipando e troca de estilo quando o risco aumenta?",
"Ela lê o diff antes de aceitar?"
]
},
"ask": {
"en": [
"Walk me through the part that loads the images, line by line.",
"What would you change before this goes to production?"
],
"pt": [
"Me explica, linha por linha, a parte que carrega as imagens.",
"O que você mudaria antes de isso ir para produção?"
]
}
},
"origin": {
"summary": {
"en": "Coined by Andrej Karpathy in a post on X in February 2025, describing a way of coding where you give in to the vibes and forget the code even exists. The term spread quickly across the industry.",
"pt": "Cunhado por Andrej Karpathy num post no X em fevereiro de 2025, descrevendo um jeito de programar em que você se entrega às vibes e esquece que o código existe. O termo se espalhou rápido pela indústria."
},
"people": [
"Andrej Karpathy"
],
"date": "2025-02-02",
"sources": [
{
"title": "Andrej Karpathy: “There's a new kind of coding I call vibe coding” (X, 2025-02-02)",
"url": "https://x.com/karpathy/status/1886192184808149383"
}
]
},
"related": [
"declarative",
"iterative"
]
},
{
"id": "spec-driven",
"order": 4,
"status": "draft",
"name": {
"en": "Spec-driven development",
"pt": "Spec-driven development"
},
"aka": [
"SDD",
"spec-first"
],
"map": {
"how": 34,
"verification": 78
},
"summary": {
"en": "Write a specification first. The AI implements from it.",
"pt": "Escreve uma especificação primeiro. A IA implementa a partir dela."
},
"definition": {
"en": "Before any code, you write (often with the model's help) requirements, a design and a task list. The spec becomes the source of truth: the model implements one task at a time against it, and every change starts by updating the spec. It trades upfront time for predictability on larger features.",
"pt": "Antes de qualquer código, você escreve (muitas vezes com ajuda do modelo) requisitos, design e uma lista de tarefas. A spec vira a fonte da verdade: o modelo implementa uma tarefa por vez em cima dela, e toda mudança começa atualizando a spec. Troca tempo no início por previsibilidade em features maiores."
},
"example": {
"note": {
"en": "A short SPEC.md, then a prompt that points at one task.",
"pt": "Um SPEC.md curto e depois um prompt que aponta para uma tarefa."
},
"prompt": {
"en": "# SPEC.md: Home carousel\n## Requirements\nR1. Show the 5 most recent published images.\nR2. Advance every 5s; pause on hover or touch.\nR3. Lazy-load images outside the viewport.\nR4. Flash twice (2 x 150ms) on each transition.\n## Acceptance criteria\n- With 0 images, render nothing and log no errors.\n- If an image fails to load, skip to the next one.\n## Tasks\n1. Data hook useCarouselImages() (R1)\n2. Carousel component with timer (R2, R4)\n3. Lazy loading and error handling (R3)\n\n> Implement task 1 from SPEC.md. Do not start task 2.\n> If you find a gap in the spec, stop and propose an update.",
"pt": "# SPEC.md: Carrossel da home\n## Requisitos\nR1. Mostrar as 5 imagens publicadas mais recentes.\nR2. Trocar a cada 5s; pausar com hover ou toque.\nR3. Lazy load das imagens fora da tela.\nR4. Piscar duas vezes (2 x 150ms) a cada troca.\n## Critérios de aceite\n- Com 0 imagens, não renderizar nada e não logar erro.\n- Se uma imagem falhar, pular para a próxima.\n## Tarefas\n1. Hook de dados useCarouselImages() (R1)\n2. Componente do carrossel com timer (R2, R4)\n3. Lazy load e tratamento de erro (R3)\n\n> Implemente a tarefa 1 do SPEC.md. Não comece a tarefa 2.\n> Se encontrar uma lacuna na spec, pare e proponha uma atualização."
}
},
"reveals": {
"en": [
"Engineering discipline and problem decomposition",
"Ability to write unambiguous requirements and acceptance criteria",
"Thinking about change: how the spec evolves with the code"
],
"pt": [
"Disciplina de engenharia e decomposição de problemas",
"Capacidade de escrever requisitos e critérios de aceite sem ambiguidade",
"Pensamento sobre mudança: como a spec evolui junto com o código"
]
},
"use_when": {
"en": [
"Features that span many files or several days",
"Work shared between several people or agents",
"Domains where requirements must be auditable"
],
"pt": [
"Features que atravessam muitos arquivos ou vários dias",
"Trabalho dividido entre várias pessoas ou agentes",
"Domínios em que os requisitos precisam ser auditáveis"
]
},
"watch_out": {
"en": [
"Over-specifying small tasks (waterfall in miniature)",
"The spec and the code drifting apart",
"Treating the spec as finished instead of as a living document"
],
"pt": [
"Especificar demais tarefas pequenas (cascata em miniatura)",
"Spec e código se distanciando com o tempo",
"Tratar a spec como pronta em vez de um documento vivo"
]
},
"interview": {
"look_for": {
"en": [
"Is the spec testable (acceptance criteria), or just prose?",
"Does the candidate implement in small steps and check each one against the spec?"
],
"pt": [
"A spec é testável (critérios de aceite) ou é só texto?",
"A pessoa implementa em passos pequenos e confere cada um contra a spec?"
]
},
"ask": {
"en": [
"Which requirement was the hardest to state precisely?",
"If product changes R2 tomorrow, what is your workflow?"
],
"pt": [
"Qual requisito foi o mais difícil de escrever com precisão?",
"Se produto mudar o R2 amanhã, qual é o seu fluxo?"
]
}
},
"origin": {
"summary": {
"en": "Writing specifications before code is an old engineering practice, and the name \"specification-driven development\" appears in research as early as 2004. As an AI coding workflow, it was popularized in 2025 by AWS Kiro (July) and GitHub Spec Kit (September), tools that turn a spec into a plan and a task list for an agent.",
"pt": "Escrever especificações antes do código é uma prática antiga de engenharia, e o nome \"specification-driven development\" aparece em pesquisa desde 2004. Como fluxo de AI coding, foi popularizado em 2025 pelo AWS Kiro (julho) e pelo GitHub Spec Kit (setembro), ferramentas que transformam uma spec em plano e lista de tarefas para um agente."
},
"date": "2025-07-14",
"sources": [
{
"title": "Kiro: Introducing Kiro (2025-07-14)",
"url": "https://kiro.dev/blog/introducing-kiro/"
},
{
"title": "GitHub Blog: Spec-driven development with AI (2025-09-02)",
"url": "https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/"
},
{
"title": "GitHub Spec Kit (repository)",
"url": "https://github.com/github/spec-kit"
},
{
"title": "Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (2025)",
"url": "https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html"
},
{
"title": "Ostroff, Makalsky, Paige: Agile Specification-Driven Development (2004)",
"url": "https://doi.org/10.1007/978-3-540-24853-8_12"
}
]
},
"related": [
"test-driven",
"declarative",
"context-engineering"
]
},
{
"id": "test-driven",
"order": 5,
"status": "draft",
"name": {
"en": "Test-driven prompting",
"pt": "Test-driven prompting"
},
"aka": [
"TDD with AI",
"tests-first"
],
"map": {
"how": 50,
"verification": 94
},
"summary": {
"en": "Write the tests first and ask the AI to make them pass.",
"pt": "Escreve os testes primeiro e pede para a IA fazer o código passar neles."
},
"definition": {
"en": "You express the contract as executable tests, then ask the model to implement until they pass, without touching the tests. Tests turn a vague request into an objective target and give both you and the model a fast feedback loop. It works especially well with agents that can run the test suite on their own.",
"pt": "Você expressa o contrato como testes executáveis e pede para o modelo implementar até passarem, sem mexer nos testes. Os testes transformam um pedido vago num alvo objetivo e dão a você e ao modelo um ciclo de feedback rápido. Funciona muito bem com agentes que conseguem rodar a suíte de testes sozinhos."
},
"example": {
"note": {
"en": "The test file is written by you. The prompt only sets the rules.",
"pt": "O arquivo de teste é escrito por você. O prompt só define as regras."
},
"prompt": {
"en": "// carousel.test.ts (written by you)\nit('shows the 5 most recent images', ...)\nit('advances every 5 seconds', ...)\nit('pauses while hovered', ...)\nit('flashes twice on transition', ...)\nit('skips an image that fails to load', ...)\n\n> Implement so every test in carousel.test.ts passes.\n> Do not modify the test file. Run the tests after each change\n> and stop when they are all green.",
"pt": "// carousel.test.ts (escrito por você)\nit('mostra as 5 imagens mais recentes', ...)\nit('troca a cada 5 segundos', ...)\nit('pausa com hover', ...)\nit('pisca duas vezes na transição', ...)\nit('pula uma imagem que falhou ao carregar', ...)\n\n> Implemente para todos os testes de carousel.test.ts passarem.\n> Não altere o arquivo de teste. Rode os testes depois de cada mudança\n> e pare quando estiverem todos verdes."
}
},
"reveals": {
"en": [
"Thinking in contracts and observable behavior",
"Commitment to quality and verification",
"Ability to design testable code"
],
"pt": [
"Pensamento em contratos e comportamento observável",
"Compromisso com qualidade e verificação",
"Capacidade de desenhar código testável"
]
},
"use_when": {
"en": [
"Logic with clear inputs and outputs",
"Bug fixes: write the failing test first",
"Agent workflows where the model can run the tests itself"
],
"pt": [
"Lógica com entradas e saídas claras",
"Correção de bug: escreva o teste que falha primeiro",
"Fluxos com agentes em que o modelo consegue rodar os testes sozinho"
]
},
"watch_out": {
"en": [
"The model cheating: special-casing tests or quietly editing them",
"Tests that only cover the happy path",
"Testing implementation details instead of behavior"
],
"pt": [
"O modelo trapaceando: tratando casos de teste à parte ou editando os testes",
"Testes que só cobrem o caminho feliz",
"Testar detalhe de implementação em vez de comportamento"
]
},
"interview": {
"look_for": {
"en": [
"Do the tests describe behavior or implementation?",
"Does the candidate check that the model did not weaken the tests?"
],
"pt": [
"Os testes descrevem comportamento ou implementação?",
"A pessoa confere se o modelo não enfraqueceu os testes?"
]
},
"ask": {
"en": [
"Which test is missing from this suite?",
"How would you notice if the model had special-cased a test?"
],
"pt": [
"Qual teste está faltando nessa suíte?",
"Como você perceberia se o modelo tivesse tratado um teste como caso especial?"
]
}
},
"origin": {
"summary": {
"en": "Derived from test-driven development (TDD), which Kent Beck rediscovered and popularized through Extreme Programming and described in \"Test-Driven Development: By Example\" (2002). Beck himself later applied TDD to coding agents in \"Augmented Coding: Beyond the Vibes\" (2025), and Simon Willison documents \"red/green TDD\" as an agentic engineering pattern. Nobody is credited with the name \"test-driven prompting\".",
"pt": "Derivado do test-driven development (TDD), que Kent Beck redescobriu e popularizou com o Extreme Programming e descreveu em \"Test-Driven Development: By Example\" (2002). O próprio Beck depois aplicou TDD a agentes de código em \"Augmented Coding: Beyond the Vibes\" (2025), e Simon Willison documenta o \"red/green TDD\" como um padrão de engenharia com agentes. Ninguém leva o crédito pelo nome \"test-driven prompting\"."
},
"people": [
"Kent Beck"
],
"date": "2002",
"sources": [
{
"title": "Kent Beck: Test-Driven Development: By Example (Addison-Wesley, 2002)",
"url": "https://www.informit.com/store/test-driven-development-by-example-9780321146533"
},
{
"title": "Kent Beck: Augmented Coding: Beyond the Vibes (2025-06-25)",
"url": "https://newsletter.kentbeck.com/p/augmented-coding-beyond-the-vibes"
},
{
"title": "Simon Willison: Red/green TDD (Agentic Engineering Patterns)",
"url": "https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/"
},
{
"title": "Mathews, Nagappan: Test-Driven Development for Code Generation (2024)",
"url": "https://arxiv.org/abs/2402.13521"
}
]
},
"related": [
"spec-driven",
"iterative",
"imperative"
]
},
{
"id": "example-based",
"order": 6,
"status": "draft",
"name": {
"en": "Example-based (few-shot)",
"pt": "Baseado em exemplos (few-shot)"
},
"aka": [
"few-shot",
"pattern-following",
"do it like this"
],
"map": {
"how": 68,
"verification": 46
},
"summary": {
"en": "Point to an existing pattern and ask for the same thing, adapted.",
"pt": "Aponta para um padrão que já existe e pede o mesmo, adaptado."
},
"definition": {
"en": "Instead of describing the solution, you show it: an existing component, test or module that already follows the house style. Then you ask for the new thing in the same shape. It relies on knowing the codebase well and is the fastest route to consistent code.",
"pt": "Em vez de descrever a solução, você mostra: um componente, teste ou módulo que já segue o padrão da casa. Depois pede a coisa nova no mesmo formato. Depende de conhecer bem o codebase e é o caminho mais rápido para código consistente."
},
"example": {
"prompt": {
"en": "Look at src/components/ProductSlider.tsx and its test.\nBuild src/components/HomeCarousel.tsx following the same patterns:\nthe same data-fetching hook, the same component,\nthe same test layout.\n\nDifferences: 5 images from the `images` table, 5s interval,\nflash twice on transition.",
"pt": "Olhe src/components/ProductSlider.tsx e o teste dele.\nCrie src/components/HomeCarousel.tsx seguindo os mesmos padrões:\no mesmo hook de busca de dados, o mesmo componente ,\na mesma estrutura de teste.\n\nDiferenças: 5 imagens da tabela `images`, intervalo de 5s,\npiscar duas vezes na transição."
}
},
"reveals": {
"en": [
"Knowledge of the codebase and its conventions",
"Focus on consistency and maintainability",
"Ability to pick a good reference, not just any similar file"
],
"pt": [
"Conhecimento do codebase e das suas convenções",
"Foco em consistência e manutenção",
"Capacidade de escolher uma boa referência, não qualquer arquivo parecido"
]
},
"use_when": {
"en": [
"Adding one more of something that already exists",
"Keeping conventions in a large codebase",
"Migrations repeated across many files"
],
"pt": [
"Adicionar mais um de algo que já existe",
"Manter convenções num codebase grande",
"Migrações repetidas em muitos arquivos"
]
},
"watch_out": {
"en": [
"Copying the reference's bugs and tech debt",
"Picking an outdated example",
"Forcing a pattern onto a problem it does not fit"
],
"pt": [
"Copiar os bugs e a dívida técnica da referência",
"Escolher um exemplo desatualizado",
"Forçar um padrão num problema em que ele não se encaixa"
]
},
"interview": {
"look_for": {
"en": [
"Why that reference? Is it the best example in the codebase?",
"Does the candidate state the differences explicitly?"
],
"pt": [
"Por que essa referência? É o melhor exemplo do codebase?",
"A pessoa deixa as diferenças explícitas?"
]
},
"ask": {
"en": [
"What would make ProductSlider a bad reference here?",
"What did the model copy that it should not have?"
],
"pt": [
"O que faria do ProductSlider uma referência ruim aqui?",
"O que o modelo copiou que não deveria?"
]
}
},
"origin": {
"summary": {
"en": "From few-shot prompting: giving a model a few examples of a task inside the prompt. The term was established by Brown et al. in \"Language Models are Few-Shot Learners\", the GPT-3 paper (2020).",
"pt": "Vem do few-shot prompting: dar ao modelo alguns exemplos da tarefa dentro do prompt. O termo foi consolidado por Brown et al. em \"Language Models are Few-Shot Learners\", o paper do GPT-3 (2020)."
},
"people": [
"Tom B. Brown et al."
],
"date": "2020-05-28",
"sources": [
{
"title": "Brown et al.: Language Models are Few-Shot Learners (arXiv:2005.14165, 2020)",
"url": "https://arxiv.org/abs/2005.14165"
}
]
},
"related": [
"context-engineering",
"imperative"
]
},
{
"id": "iterative",
"order": 7,
"status": "draft",
"name": {
"en": "Iterative / conversational",
"pt": "Iterativo / conversacional"
},
"aka": [
"conversational",
"incremental"
],
"map": {
"how": 58,
"verification": 58
},
"summary": {
"en": "Short cycles of ask, review and correct.",
"pt": "Ciclos curtos de pedir, revisar e corrigir."
},
"definition": {
"en": "You build the feature through a conversation: a small request, a careful look at the result, a correction, the next step. Each turn is cheap, and judgment is applied all the time instead of only at the start. Most real work with AI looks like this. The skill is in the quality of each review, not in the first prompt.",
"pt": "Você constrói a feature numa conversa: um pedido pequeno, uma olhada cuidadosa no resultado, uma correção, o próximo passo. Cada turno custa pouco, e o julgamento é aplicado o tempo todo em vez de só no começo. A maior parte do trabalho real com IA é assim. A habilidade está na qualidade de cada revisão, não no primeiro prompt."
},
"example": {
"note": {
"en": "Five turns. Turn 3 catches a problem the model did not mention.",
"pt": "Cinco turnos. O turno 3 pega um problema que o modelo não mencionou."
},
"prompt": {
"en": "1. Create a HomeCarousel component that renders images passed as props. No timer yet.\n2. Good. Now advance every 5s, and clean up the timer on unmount.\n3. The timer keeps running when the tab is hidden. Pause it on visibilitychange.\n4. Add lazy loading and a fixed aspect ratio to avoid layout shift.\n5. Now the double flash on transition. Keep it in CSS, not JS.",
"pt": "1. Crie um componente HomeCarousel que renderiza as imagens recebidas por props. Sem timer ainda.\n2. Boa. Agora troque a cada 5s e limpe o timer no unmount.\n3. O timer continua rodando com a aba escondida. Pause no visibilitychange.\n4. Adicione lazy load e uma proporção fixa para evitar layout shift.\n5. Agora a piscada dupla na transição. Faça em CSS, não em JS."
}
},
"reveals": {
"en": [
"Debugging skill and critical reading of the output",
"Ability to break work into reviewable steps",
"Judgment applied in real time"
],
"pt": [
"Capacidade de depuração e leitura crítica do output",
"Capacidade de quebrar o trabalho em passos revisáveis",
"Julgamento aplicado em tempo real"
]
},
"use_when": {
"en": [
"Most day-to-day feature work",
"Unclear problems where you learn by building",
"Pairing with an agent on an unfamiliar codebase"
],
"pt": [
"A maior parte do trabalho de feature do dia a dia",
"Problemas pouco claros, em que você aprende construindo",
"Parear com um agente num codebase desconhecido"
]
},
"watch_out": {
"en": [
"Endless \"still broken, fix it\" loops without a diagnosis",
"Losing track of the overall design across many turns",
"Context drift in long conversations"
],
"pt": [
"Loops infinitos de \"continua quebrado, arruma\" sem diagnóstico",
"Perder a visão do design geral depois de muitos turnos",
"Contexto que se perde em conversas longas"
]
},
"interview": {
"look_for": {
"en": [
"Is each step small enough to review?",
"Does the candidate catch problems the model did not mention?"
],
"pt": [
"Cada passo é pequeno o suficiente para revisar?",
"A pessoa pega problemas que o modelo não mencionou?"
]
},
"ask": {
"en": [
"At which step did you catch something the model missed?",
"When would you throw this conversation away and start over?"
],
"pt": [
"Em qual passo você pegou algo que o modelo deixou passar?",
"Quando você jogaria essa conversa fora e começaria de novo?"
]
}
},
"origin": {
"summary": {
"en": "Community practice with no single author. It mirrors iterative and incremental development, and it is how chat-based assistants are used by default.",
"pt": "Prática da comunidade, sem autor único. Espelha o desenvolvimento iterativo e incremental, e é o jeito padrão de usar assistentes de chat."
},
"sources": [
{
"title": "Simon Willison: Here's how I use LLMs to help me write code (2025-03-11)",
"url": "https://simonwillison.net/2025/Mar/11/using-llms-for-code/"
},
{
"title": "Iterative and incremental development (Wikipedia)",
"url": "https://en.wikipedia.org/wiki/Iterative_and_incremental_development"
}
]
},
"related": [
"vibe-coding",
"test-driven",
"imperative"
]
},
{
"id": "context-engineering",
"order": 8,
"status": "draft",
"name": {
"en": "Context engineering",
"pt": "Context engineering"
},
"map": {
"how": 44,
"verification": 68
},
"summary": {
"en": "Engineer what the model sees (files, docs, rules, tools) more than the wording.",
"pt": "Trabalha o que o modelo enxerga (arquivos, docs, regras, ferramentas) mais que o texto."
},
"definition": {
"en": "The prompt is only the last line of what the model sees. Context engineering is the work of assembling everything else: the right files, docs, schemas, conventions, examples, tools and constraints, and keeping out what does not help. With good context, short prompts work. With bad context, no wording will save you. It is central to working with coding agents.",
"pt": "O prompt é só a última linha do que o modelo enxerga. Context engineering é o trabalho de montar todo o resto: os arquivos certos, docs, schemas, convenções, exemplos, ferramentas e restrições, e deixar de fora o que não ajuda. Com um bom contexto, prompts curtos funcionam. Com um contexto ruim, nenhum texto salva. É central para trabalhar com agentes de código."
},
"example": {
"note": {
"en": "Most of the work happens before the prompt, which is a single line.",
"pt": "Quase todo o trabalho acontece antes do prompt, que tem uma linha só."
},
"prompt": {
"en": "# AGENTS.md (project rules, always loaded)\n- Stack: React + Vite, tests with Vitest.\n- Images come from GET /api/images?limit=N.\n- Components live in src/components, one test file each.\n- Never fetch inside components. Use hooks in src/hooks.\n\n# Attached\nsrc/hooks/useImages.ts\nsrc/components/LazyImage.tsx\ndocs/design-tokens.md (transition timings)\n\n> Build the home carousel described in issue #142.",
"pt": "# AGENTS.md (regras do projeto, sempre carregadas)\n- Stack: React + Vite, testes com Vitest.\n- As imagens vêm de GET /api/images?limit=N.\n- Componentes ficam em src/components, um arquivo de teste cada.\n- Nunca faça fetch dentro de componente. Use hooks em src/hooks.\n\n# Anexados\nsrc/hooks/useImages.ts\nsrc/components/LazyImage.tsx\ndocs/design-tokens.md (tempos de transição)\n\n> Construa o carrossel da home descrito na issue #142."
}
},
"reveals": {
"en": [
"Maturity with agents and larger systems",
"Understanding of what the model needs to know, and what it does not",
"Ability to make a team's conventions readable by machines"
],
"pt": [
"Maturidade com agentes e sistemas maiores",
"Entendimento do que o modelo precisa saber, e do que não precisa",
"Capacidade de tornar as convenções do time legíveis para máquinas"
]
},
"use_when": {
"en": [
"Working with coding agents on a real codebase",
"Recurring tasks where rules should be written once",
"Large codebases where the model cannot see everything"
],
"pt": [
"Trabalho com agentes de código num codebase real",
"Tarefas recorrentes em que as regras devem ser escritas uma vez só",
"Codebases grandes em que o modelo não consegue ver tudo"
]
},
"watch_out": {
"en": [
"Context stuffing: irrelevant material dilutes the model's attention",
"Stale rules files that contradict the code",
"Leaking secrets or private data into the context"
],
"pt": [
"Excesso de contexto: material irrelevante dilui a atenção do modelo",
"Arquivos de regras desatualizados que contradizem o código",
"Vazar segredos ou dados privados no contexto"
]
},
"interview": {
"look_for": {
"en": [
"What did the candidate give the model, and what did they leave out on purpose?",
"Do they keep rules and docs up to date as the project changes?"
],
"pt": [
"O que a pessoa deu ao modelo, e o que deixou de fora de propósito?",
"Ela mantém regras e docs atualizadas conforme o projeto muda?"
]
},
"ask": {
"en": [
"Why these three files and not the whole folder?",
"What would you add to AGENTS.md after this task?"
],
"pt": [
"Por que esses três arquivos e não a pasta inteira?",
"O que você adicionaria ao AGENTS.md depois dessa tarefa?"
]
}
},
"origin": {
"summary": {
"en": "Popularized in June 2025 by Shopify CEO Tobi Lütke, who said he preferred the term to \"prompt engineering\", and amplified a week later by Andrej Karpathy, who described it as the art of filling the context window with just the right information for the next step. The term was already in use earlier that year, for example in Dex Horthy's 12-Factor Agents and in Cognition's \"Don't Build Multi-Agents\". Nobody is credited with coining it.",
"pt": "Popularizado em junho de 2025 por Tobi Lütke, CEO da Shopify, que disse preferir o termo a \"prompt engineering\", e amplificado uma semana depois por Andrej Karpathy, que o descreveu como a arte de preencher a janela de contexto com só a informação certa para o próximo passo. O termo já aparecia antes naquele ano, por exemplo no 12-Factor Agents de Dex Horthy e no \"Don't Build Multi-Agents\" da Cognition. Ninguém leva o crédito por ter cunhado o termo."
},
"people": [
"Tobi Lütke",
"Andrej Karpathy"
],
"date": "2025-06-19",
"sources": [
{
"title": "Tobi Lütke: “I really like the term context engineering over prompt engineering” (X, 2025-06-19)",
"url": "https://x.com/tobi/status/1935533422589399127"
},
{
"title": "Andrej Karpathy: “+1 for context engineering over prompt engineering” (X, 2025-06-25)",
"url": "https://x.com/karpathy/status/1937902205765607626"
},
{
"title": "Dex Horthy (HumanLayer): 12-Factor Agents (2025)",
"url": "https://github.com/humanlayer/12-factor-agents"
},
{
"title": "Walden Yan (Cognition): Don't Build Multi-Agents (2025-06-12)",
"url": "https://cognition.com/blog/dont-build-multi-agents"
}
]
},
"related": [
"example-based",
"spec-driven"
]
}
],
"rubric": {
"intro": {
"en": "A rubric for interviews where candidates build with AI. It scores the process, not just the code: how the problem is framed, how the model is directed, how the output is checked and who really owns the result. Share it with candidates before the interview.",
"pt": "Uma rubrica para entrevistas em que o candidato constrói com IA. Ela avalia o processo, não só o código: como o problema é enquadrado, como o modelo é conduzido, como o output é verificado e quem de fato é dono do resultado. Compartilhe com o candidato antes da entrevista."
},
"levels": [
{
"level": 1,
"name": {
"en": "Operator",
"pt": "Operador"
},
"summary": {
"en": "Uses a single style and accepts the output without real review.",
"pt": "Usa um único estilo e aceita o output sem revisar de verdade."
}
},
{
"level": 2,
"name": {
"en": "Practitioner",
"pt": "Praticante"
},
"summary": {
"en": "Switches between describing and dictating, reviews the code and fixes errors.",
"pt": "Alterna entre descrever e ditar, revisa o código e corrige os erros."
}
},
{
"level": 3,
"name": {
"en": "Engineer",
"pt": "Engenheiro"
},
"summary": {
"en": "Chooses the style by risk and complexity, uses tests and specs as contracts, manages context.",
"pt": "Escolhe o estilo pelo risco e pela complexidade, usa testes e specs como contrato, gerencia o contexto."
}
},
{
"level": 4,
"name": {
"en": "Architect",
"pt": "Arquiteto"
},
"summary": {
"en": "Sets standards for the team, knows when not to use AI, weighs cost, security and maintenance.",
"pt": "Define padrões para o time, sabe quando não usar IA, pesa custo, segurança e manutenção."
}
}
],
"dimensions": [
{
"id": "framing",
"name": {
"en": "Problem framing",
"pt": "Enquadramento do problema"
},
"question": {
"en": "Does the candidate understand and specify the problem before generating code?",
"pt": "A pessoa entende e especifica o problema antes de gerar código?"
},
"descriptors": [
{
"en": "Pastes the task into the model as it is.",
"pt": "Cola a tarefa no modelo do jeito que veio."
},
{
"en": "Restates the task and adds the obvious requirements.",
"pt": "Reescreve a tarefa e adiciona os requisitos óbvios."
},
{
"en": "States requirements, constraints and edge cases, and asks clarifying questions.",
"pt": "Define requisitos, restrições e casos de borda, e faz perguntas para esclarecer."
},
{
"en": "Questions the problem itself, finds hidden requirements (security, scale, operations) and cuts scope on purpose.",
"pt": "Questiona o próprio problema, encontra requisitos escondidos (segurança, escala, operação) e corta escopo de propósito."
}
]
},
{
"id": "style",
"name": {
"en": "Style selection",
"pt": "Escolha de estilo"
},
"question": {
"en": "Does the candidate choose how to direct the model, on purpose?",
"pt": "A pessoa escolhe de propósito como conduzir o modelo?"
},
"descriptors": [
{
"en": "Uses one habitual style, whatever the task.",
"pt": "Usa um estilo por hábito, qualquer que seja a tarefa."
},
{
"en": "Alternates between describing the outcome and dictating the implementation.",
"pt": "Alterna entre descrever o resultado e ditar a implementação."
},
{
"en": "Picks the style according to risk and complexity, and can explain the choice.",
"pt": "Escolhe o estilo de acordo com o risco e a complexidade, e consegue explicar a escolha."
},
{
"en": "Combines styles fluently, switches mid-task when the situation changes and can teach the trade-offs.",
"pt": "Combina estilos com fluência, troca no meio da tarefa quando a situação muda e consegue ensinar os trade-offs."
}
]
},
{
"id": "verification",
"name": {
"en": "Verification",
"pt": "Verificação"
},
"question": {
"en": "How does the candidate check that the output is correct?",
"pt": "Como a pessoa confere se o output está correto?"
},
"descriptors": [
{
"en": "Runs it once. If it looks right, it ships.",
"pt": "Roda uma vez. Se parece certo, vai."
},
{
"en": "Reads the diff and fixes visible errors.",
"pt": "Lê o diff e corrige os erros visíveis."
},
{
"en": "Uses tests, specs or types as a contract and checks edge cases and failure modes.",
"pt": "Usa testes, specs ou tipos como contrato e confere casos de borda e modos de falha."
},
{
"en": "Designs verification upfront (tests, evals, monitoring) and catches subtle problems in security, performance and concurrency.",
"pt": "Planeja a verificação desde o início (testes, evals, monitoramento) e pega problemas sutis de segurança, performance e concorrência."
}
]
},
{
"id": "context",
"name": {
"en": "Context management",
"pt": "Gestão de contexto"
},
"question": {
"en": "Does the candidate give the model what it needs, and only that?",
"pt": "A pessoa dá ao modelo o que ele precisa, e só isso?"
},
"descriptors": [
{
"en": "Gives no context, or dumps everything.",
"pt": "Não dá contexto nenhum, ou joga tudo."
},
{
"en": "Adds relevant files after the model fails.",
"pt": "Adiciona arquivos relevantes depois que o modelo erra."
},
{
"en": "Curates context upfront with relevant files, conventions, constraints and examples.",
"pt": "Monta o contexto antes, com arquivos relevantes, convenções, restrições e exemplos."
},
{
"en": "Makes context reusable for the team (rules files, docs, tools) and keeps it current.",
"pt": "Torna o contexto reutilizável para o time (arquivos de regras, docs, ferramentas) e mantém atualizado."
}
]
},
{
"id": "ownership",
"name": {
"en": "Ownership and judgment",
"pt": "Domínio e julgamento"
},
"question": {
"en": "Does the candidate own the result as if they had written every line?",
"pt": "A pessoa é dona do resultado como se tivesse escrito cada linha?"
},
"descriptors": [
{
"en": "Cannot explain parts of the generated code.",
"pt": "Não consegue explicar partes do código gerado."
},
{
"en": "Explains the code and changes it when asked.",
"pt": "Explica o código e altera quando pedem."
},
{
"en": "Rejects or rewrites weak output and defends design decisions with reasons.",
"pt": "Rejeita ou reescreve output fraco e defende as decisões de design com argumentos."
},
{
"en": "Knows when not to use AI and weighs cost, security and maintainability for the team.",
"pt": "Sabe quando não usar IA e pesa custo, segurança e manutenção para o time."
}
]
}
],
"interview": {
"title": {
"en": "How to run the interview",
"pt": "Como conduzir a entrevista"
},
"steps": [
{
"minutes": 5,
"name": {
"en": "Brief",
"pt": "Alinhamento"
},
"description": {
"en": "Share your AI policy and this rubric. Say which tools are allowed and that you evaluate the process, not only the output.",
"pt": "Compartilhe sua política de IA e esta rubrica. Diga quais ferramentas são permitidas e que você avalia o processo, não só o resultado."
}
},
{
"minutes": 10,
"name": {
"en": "Framing",
"pt": "Enquadramento"
},
"description": {
"en": "Present a realistic problem from your domain, not a puzzle. Ask the candidate to restate it, ask questions and outline a plan before prompting.",
"pt": "Apresente um problema realista do seu domínio, não um puzzle. Peça para a pessoa reformular, fazer perguntas e esboçar um plano antes de escrever prompts."
}
},
{
"minutes": 30,
"name": {
"en": "Build",
"pt": "Construção"
},
"description": {
"en": "The candidate builds with their usual AI tools and thinks out loud. Watch style choices, the context they provide and how they review output. Do not help with prompts.",
"pt": "A pessoa constrói com as ferramentas de IA que usa no dia a dia e pensa em voz alta. Observe as escolhas de estilo, o contexto que ela fornece e como revisa o output. Não ajude com prompts."
}
},
{
"minutes": 10,
"name": {
"en": "Change",
"pt": "Mudança"
},
"description": {
"en": "Introduce a new requirement or a subtle bug. Watch how the candidate verifies and adapts.",
"pt": "Introduza um requisito novo ou um bug sutil. Observe como a pessoa verifica e se adapta."
}
},
{
"minutes": 10,
"name": {
"en": "Debrief",
"pt": "Conversa final"
},
"description": {
"en": "Ask the candidate to explain the code, their choices and what they would do before production. The interview questions on each style page help here.",
"pt": "Peça para a pessoa explicar o código, as escolhas e o que faria antes de ir para produção. As perguntas de entrevista de cada estilo ajudam aqui."
}
}
],
"scoring": {
"en": [
"Score each dimension from 1 to 4 with written evidence. Write down what you saw, not what you felt.",
"Do not average blindly. Decide upfront which dimensions matter most for the role.",
"A 1 in ownership is a strong no for production roles, whatever the other scores.",
"Calibrate. Interviewers should score the same recorded session together at least once."
],
"pt": [
"Dê de 1 a 4 em cada dimensão, com evidência escrita. Anote o que você viu, não o que sentiu.",
"Não tire média no automático. Decida antes quais dimensões pesam mais para a vaga.",
"Nota 1 em domínio é um não forte para vagas de produção, quaisquer que sejam as outras notas.",
"Calibre. Os entrevistadores devem avaliar juntos a mesma sessão gravada pelo menos uma vez."
]
},
"green_flags": {
"en": [
"States assumptions before prompting",
"Rejects output that is plausible but wrong",
"Switches style when the risk changes, and says why",
"Writes or asks for tests before trusting the code"
],
"pt": [
"Declara as suposições antes de escrever o prompt",
"Rejeita output plausível mas errado",
"Troca de estilo quando o risco muda, e diz por quê",
"Escreve ou pede testes antes de confiar no código"
]
},
"red_flags": {
"en": [
"Accepts large diffs without reading them",
"Cannot explain the generated code",
"Loops on \"fix it\" without a diagnosis",
"Hides AI use, or uses tools that were not allowed"
],
"pt": [
"Aceita diffs grandes sem ler",
"Não consegue explicar o código gerado",
"Fica em loop de \"arruma isso\" sem diagnóstico",
"Esconde o uso de IA ou usa ferramentas que não foram permitidas"
]
}
},
"prepare": {
"title": {
"en": "How to prepare as a candidate",
"pt": "Como se preparar como candidato"
},
"items": {
"en": [
"Pick one small feature and build it in every style of the taxonomy. Compare the results and how long each one took.",
"Practice thinking out loud. Say which style you are choosing and why.",
"Read every diff before you accept it. Be ready to explain any line.",
"Write tests or acceptance criteria before you prompt, at least once a day.",
"Keep a rules file (AGENTS.md, CLAUDE.md or similar) in a side project and maintain it.",
"Ask the company for its AI policy and rubric before the interview. Under this manifesto, that is a fair question."
],
"pt": [
"Escolha uma feature pequena e construa em cada estilo da taxonomia. Compare os resultados e quanto tempo cada um levou.",
"Treine pensar em voz alta. Diga qual estilo está escolhendo e por quê.",
"Leia todo diff antes de aceitar. Esteja pronto para explicar qualquer linha.",
"Escreva testes ou critérios de aceite antes do prompt, pelo menos uma vez por dia.",
"Mantenha um arquivo de regras (AGENTS.md, CLAUDE.md ou parecido) num projeto pessoal.",
"Pergunte à empresa qual é a política de IA e a rubrica antes da entrevista. Por este manifesto, é uma pergunta justa."
]
}
}
}
}