Author: Iago Cavalcante Platform: iagocavalcante.com Cadence: 1 article per week Languages: PT-BR first, EN adaptation after series completion Future: Consolidated into a bilingual book (separate editions)
The same qualities that make an RFC effective for human engineers — clarity of constraints, explicit non-goals, well-defined interfaces, concrete acceptance criteria — are exactly what make a prompt effective for AI agents. The discipline of writing good RFCs is the discipline of writing good prompts. Most developers already have this skill; they just don't recognize it yet.
- Software engineers who already use AI coding tools but write mediocre prompts
- Engineering leads/architects who write RFCs but haven't connected the dots to AI-assisted development
- AI-curious developers who haven't adopted agent-driven workflows yet
Each article follows this structure:
- An RFC principle (e.g., "Explicit Non-Goals")
- Why it works for humans
- The equivalent prompt pattern
- A fictional but realistic example showing the transformation
- The anti-pattern (what happens without it)
(The RFC nobody read and the prompt nobody wrote)
Opens with a universal pain: the Jira ticket that says "add authentication." A human engineer asks 15 clarifying questions. An AI agent guesses and builds the wrong thing. Then shows how an RFC would have prevented both failures — and how the same structure prevents prompt failures. Establishes the central metaphor: an RFC is a prompt for humans; a prompt is an RFC for agents.
(Anatomy of a good RFC)
Dissects the structural elements that make RFCs work: Problem Statement, Proposed Solution, Constraints, Non-Goals, Open Questions, Acceptance Criteria. Not a history lesson on IETF — focused on what engineering teams actually write today. Each element gets a one-paragraph explanation of why it exists (what failure it prevents). Sets up the vocabulary the rest of the series will use.
(Anatomy of a good system prompt)
The mirror of Article 2. Takes each RFC element and shows its prompt equivalent: Problem Statement becomes Context/Role, Constraints become Rules, Non-Goals become Explicit Exclusions, Acceptance Criteria become Output Format. The fictional example: a team rewrites their "build a notification service" RFC as a prompt and gets dramatically better results from their AI agent. First "aha moment" of the series.
(Explicit constraints: the power of "don't do this")
The most underrated section of any RFC is "Non-Goals." For humans, it prevents scope creep. For AI agents, it prevents hallucinated features. Shows how a single line — "This service does NOT handle payment processing" — changes agent behavior dramatically. The fictional example: an agent asked to build a user profile service that, without constraints, also builds auth, email verification, and avatar upload. With explicit non-goals, it builds exactly what's needed.
(Interfaces and contracts: how agents respect boundaries)
RFCs define boundaries — input/output formats, API contracts, what crosses the wire. This maps directly to how agents need type definitions, data schemas, and integration points spelled out. Explores the pattern: when you define the interface first (like an RFC does), the agent fills in implementation correctly. When you describe implementation without interfaces, the agent invents incompatible contracts. The fictional example: two agents building microservices that need to talk to each other — one team writes interface-first prompts, the other doesn't.
(Acceptance criteria: when the agent knows it's done)
RFCs have "success looks like X." Without this, an agent either under-delivers or gold-plates. Maps RFC acceptance criteria to prompt output validation — test cases, expected behaviors, edge cases. Shows how writing "the endpoint returns 404 for unknown users" is simultaneously a test spec, an RFC criterion, and a prompt instruction. The fictional example: the same feature built with vague vs. precise acceptance criteria.
(Where prompts go beyond RFCs: feedback loops)
This is the pivot point of the series. RFCs are static — once approved, they're a reference document. But AI-agent prompts live inside iterative cycles: the agent builds, you review, you refine the prompt, the agent rebuilds. Introduces concepts RFCs never needed: incremental context, memory across turns, correction without starting over. The fictional example: a team treats their prompt like a frozen RFC and gets frustrated when the agent can't adapt. Another team builds feedback checkpoints into their prompt structure and gets compound improvement with each iteration.
(Shared context: what RFCs assume and agents need to be told)
RFCs rely on implicit shared context — the team knows the codebase, the tech stack, the business domain. Agents know nothing unless told. This article explores what to externalize: project conventions, architectural decisions, existing patterns, naming standards. Maps to CLAUDE.md files, system prompts, and project-level instructions. The fictional example: an agent that writes perfect code for the wrong architecture because nobody told it the team uses event sourcing, not CRUD.
(The unified document: writing for humans and agents simultaneously)
The practical culmination. Proposes a document format that works as both an RFC for team review and a prompt for AI agents. Not two separate documents — one artifact that serves both audiences. Shows the structural additions needed: explicit tech stack declarations, file path references, test expectations as executable criteria. The fictional example: a team adopts the unified format. Their RFCs get better because the rigor required by agents forces clarity that humans also benefit from. The surprise insight: writing for agents makes you a better writer for humans.
(The future of specification: when the RFC is the code)
The forward-looking closer. As agents get more capable, the line between "specifying what to build" and "building it" blurs. The RFC doesn't describe the system — it becomes the system through agent execution. Explores what this means for engineering roles, team structures, and the craft of software development. Ends with a provocation: the engineers who thrive won't be the fastest coders or the best prompt writers — they'll be the best thinkers and specifiers. The RFC skill, once considered bureaucratic overhead, becomes the most valuable skill in software engineering.
| Blog Article | Book Chapter |
|---|---|
| Art. 1 (O RFC que ninguem leu) | Ch. 1 — Introduction |
| Art. 2 (Anatomia de um RFC) | Ch. 2 — The RFC Discipline |
| Art. 3 (Anatomia de um prompt) | Ch. 3 — The Prompt Discipline |
| Art. 4 (Restricoes explicitas) | Ch. 4 — Constraints |
| Art. 5 (Interfaces e contratos) | Ch. 5 — Interfaces |
| Art. 6 (Criterios de aceite) | Ch. 6 — Acceptance |
| Art. 7 (Loops de feedback) | Ch. 7 — Beyond Static Specs |
| Art. 8 (Contexto compartilhado) | Ch. 8 — Shared Context |
| Art. 9 (O documento unico) | Ch. 9 — The Unified Document |
| Art. 10 (O futuro da especificacao) | Ch. 10 — The Future |
Book additions: Foreword, expanded examples per chapter, practical appendix with the unified document template.
- Use
write-like-iagoskill for every article to maintain authentic voice - PT-BR first, EN adaptation after full series
- Fictional but realistic examples throughout
- Each article is self-contained but builds on previous ones
- Target: 1 article per week