Generating Production Code
Generating Production Code
Transforms a short natural-language request into complete, runnable, production-grade code by locking a senior-engineer persona, enforcing negative constraints against hallucination/placeholders, planning architecture silently, then emitting only clean code.
Given: "Buatkan komponen kartu profil modern untuk tim e-sport, warna dominan hitam dan neon ungu, ada tombol 'Follow' dan media sosial."
- Lock persona: "Senior Frontend Engineer & Tailwind Expert"
- Apply constraints: responsive (
md:,lg:), no truncated code, real icons (e.g. Lucide React), no placeholders - Silently plan structure: wrapper w/ glow effect → avatar + status dot → info block → social icons → CTA button
- Emit a single complete code block, no filler text before/after
Output: a full .tsx component, typed props with sane defaults, no // TODO or ...rest of code placeholders.
Progress:
- Step 1: Define intent — pin down exact scope (UI component / API boilerplate / DB script / CLI tool) to avoid scope creep
- Step 2: Map inputs & outputs — what the user must supply (framework, language, constraints) vs. expected deliverable shape
- Step 3: Determine stack — prompt-only (SKILL.md) vs. prompt + OpenAPI schema for external Actions
- Step 4: Draft persona + negative constraints + formatting rules
- Step 5: Assemble SKILL.md frontmatter (or Custom GPT instructions) and OpenAPI spec if actions are needed
- Step 6: Validate — run JSONLint/YAMLLint on schemas, test with vague/broken prompts to confirm clarifying questions trigger instead of hallucinated code
- Step 7: Generate final code block — persona-locked, constraint-checked, no conversational filler
1. Structure the Architecture
- Intent: one sentence describing exactly what the skill produces.
- Inputs/Outputs: list required user-supplied params (language, framework, style, constraints) and the output artifact type (single file, multi-file tree, API response).
- Stack decision: pure prompt vs. prompt + OpenAPI Actions schema.
2. Draft Core Prompt & Constraints
- Role prompting: assign a precise persona tied to the domain (e.g., "Senior DevSecOps Engineer", "Prisma ORM Expert").
- Negative constraints (always include):
- Never truncate code blocks or use
// code hereplaceholders - Never use deprecated libraries/APIs
- Never omit error handling
- Never add conversational preamble/postamble around code
- Never truncate code blocks or use
- Formatting rules: clean markdown, logical folder structure, split files when the deliverable spans multiple concerns.
- Chain-of-Thought (hidden): instruct the model to plan folder/architecture mentally (or in a brief comment) before writing the first line of code.
- Few-shot anchor: embed 1–2 ideal input→output examples to lock style and error-handling conventions.
3. Build Schema and Test
- Assemble into SKILL.md (YAML frontmatter + instructions) or Custom GPT instruction box.
- If external actions are needed, draft an OpenAPI 3.0 spec (
agents/*.yaml) mapping functions to HTTP endpoints. - Validate schemas with JSONLint/YAMLLint; validate API specs in Swagger Editor/Postman.
- Edge-case test: feed vague/broken requests — correct behavior is a clarifying question, not hallucinated code.
- Optionally validate runtime payloads with Zod/Pydantic when actions exchange structured data.
Example 1:
Input: "Buatkan komponen kartu profil modern untuk tim e-sport, warna dominan hitam dan neon ungu, ada tombol 'Follow' dan media sosial."
Output: Complete EsportProfileCard.tsx — typed props with defaults, Tailwind utility classes for responsive layout, Lucide icons (Twitch/Twitter/Youtube/UserPlus), hover/glow states, no placeholder comments, single self-contained export.
Example 2:
Input: "Generate a REST endpoint for user signup in Express with validation."
Output: Multi-file layout (routes/signup.ts, schemas/signup.schema.ts using Zod, controllers/signup.controller.ts) with full error handling, status codes, and no TODOs — persona locked as "Senior Node.js Backend Engineer".
Example 3(edge case): Input: "make me a thing for the app" Output: A single clarifying question ("What kind of component/feature, which framework, and what should it visually or functionally do?") — no code generated.
- Always lock a specific, domain-matched persona before generating — generic "AI assistant" tone produces weaker, hedgier code.
- Bake in 1–2 few-shot examples directly in the skill file; this does more to fix style/quality than long prose instructions.
- Make negative constraints explicit and itemized, not implied — "write good code" is not a constraint.
- Force silent architectural planning (folder/data-flow) before code emission to reduce structural inconsistency.
- Keep SKILL.md focused on one skill's scope; split unrelated capabilities into separate skill folders.
- Validate every schema file (YAML/JSON) before shipping — a single syntax error breaks the whole skill install.
- Omitting negative constraints → model fills gaps with placeholders or deprecated APIs.
- No persona lock → inconsistent tone/quality across generations.
- Skipping edge-case testing → skill hallucinates code for vague requests instead of asking for clarification.
- Mixing prompt-only skills with unneeded OpenAPI schemas (adds complexity with no actions to call).
- Letting the model add explanatory text around the code block — always constrain output to code only unless explicitly asked for explanation.
- Forgetting to lint OpenAPI/YAML configs — small syntax errors silently break skill installation.