Two Skeletons: Generative or Agentic, Pick One First
AI products come in two skeletons: generate an answer, or act on your behalf across steps. Get the skeleton right first.
When an idea lands in your hands, ask one question first: is the core of this product "answer a question" or "act on your behalf, step by step"? Get the skeleton wrong and no amount of architecture, prompting, or model-tuning later will save it. If you want vibe coding to go smoothly, get the skeleton right first.
After reading, you should be able to answer:
- Which skeleton is the product you're building now?
- How do the two skeletons differ in development, verification, and launch?
- When you mix them, where do you draw the line?
The generative skeleton
In one line: user input → the model generates a piece of output → the user reads it and judges. No side effects, no state written.
Typical examples:
- Q&A bots, writing helpers, copywriters, prompt-to-design, code explainers
- Given a snippet, explain what it does
- Given a requirement, produce a PRD or technical plan
- Summarize a long article and pull out keywords
Properties:
- The input is done once it's processed; no state carries to the next round
- Side effects are contained: if the model generates wrong, you just regenerate next round
- Verification is simple: output reads well, stays on topic, doesn't hallucinate—and you're done
- It's fast to build: you can scaffold the skeleton in minutes of vibe coding
The catch is equally direct: it can't do multi-step work, can't handle state, and can't depend on external tools. If you hand a pure generative skeleton "remove every console.log in this repo," it can't—it can't read your files.
The agentic skeleton
In one line: user gives a goal → AI breaks it into steps → reads files, calls tools, edits code, calls APIs → executes toward the goal step by step. It can read, write, and mutate state.
Typical examples:
- Coding agents: read code in your repo, edit files, run tests
- Automation workflows: handle a GitHub Issue → open a PR → run CI → report results google-patterns
- Data-analysis agents: read a database → run queries → produce charts → write a summary
- Project scaffolding: generate an entire project structure from your requirement
Properties:
- Handles complex tasks, reuses existing environments, reads and writes state
- AI plans its own path; you set the goal and accept the result
- Verification is complex: every step needs verifying, then the whole goal needs a final check
- It's slow to build: you need tool definitions, permission control, and error retry; the skeleton itself takes time to assemble
The catch: using it for a trivial problem is overkill—where a minute of outputs would do, it spends ten minutes reading files to figure out its path vibe-report.
How to choose
A simple test: when the user clicks a button, does anything get changed?
- Nothing changes → generative
- Something changes → agentic
For example:
- "What did this PR change?" → generative (it answers your question; it doesn't touch code)
- "Review this PR and suggest edits" → generative (outputs suggestions; doesn't change code)
- "Fix the issues this review found" → agentic (it will edit code)
Mixing them
The two skeletons get mixed all the time: front-end Q&A uses generative, back-end actions use agentic. That's fine as long as the boundary is clear:
- The generative side only produces content and never touches state or side effects
- The agentic side executes, and can push tricky reasoning to the generative side to think
Say you have an "help me refactor" feature:
- Agentic reads the file (side effect: read)
- Generative analyzes the code and proposes a refactor plan (no side effect: generates an answer)
- Agentic edits the file per the plan (side effect: write)
Split that way, each plays to its strength: generative is good at analysis and expression, agentic is good at execution and state change.
Once you've picked a skeleton, move on to the problems where AI truly adds value instead of bolting AI onto everything.