Mental Models for AI Development

Use role labels as review lenses, not as credentials. In one conversation, you can ask for an implementation draft, a critical review, architecture alternatives, or debugging hypotheses. The model remains the same fallible system in every role.

Changing the requested role can shift the focus and format of the response. Using an implementation lens followed by a review lens may surface additional issues, but it is not independent review and can repeat the same assumptions.

A useful default is to iterate: get a reviewable first result, evaluate it, and refine it. For high-risk work, invest more in requirements and verification before generating an implementation.

Your first prompt needs enough context and acceptance criteria to make the result testable. Follow-up turns should close observed gaps rather than add conversation for its own sake.

A direct implementation question and a comparison question serve different purposes. Ask for alternatives and trade-offs when the choice matters, then verify the comparison against documentation, experiments, and project constraints.

This model treats AI as a thinking amplifier, not a code vending machine. You bring the judgment and direction; AI brings breadth of knowledge and speed of exploration. Together, you cover more ground than either could alone.

Manage context deliberately: what the model has been shown, what it still needs, and which assumptions require confirmation. Provide permitted code, interfaces, tests, decisions, and constraints that affect the task, while keeping authoritative state in project files.

Think of context as the terrain map for AI's navigation. Without a map, AI wanders. With a detailed map, it goes exactly where you need it.

• Share permitted context — provide relevant interfaces, tests, conventions, or sanitized excerpts
• Share types — Interfaces define the contract AI's output must respect
• Share decisions — "We chose Zustand because..." prevents AI from suggesting alternatives you've already rejected
• Share constraints — "Must work without external libraries" prevents wasted suggestions

Use AI for critique as well as generation. Ask for failure modes, counterexamples, and missing assumptions, then verify each proposed issue independently.

This applies to code, architecture, API design, database schemas, and even your prompts themselves. Get in the habit of following every creative step with a critical step. Build → critique → improve. The critique step is where the real quality comes from.

System-level context matters when a change crosses interfaces: data flow, ownership, dependencies, trust boundaries, and likely ripple effects. Provide the relevant portion of that context without overwhelming the task or disclosing restricted material.

When you ask AI to add a feature, tell it where the feature fits in the system: "This component receives data from the useSchedule hook, which talks to the /api/activities endpoint, which reads from the activities table." Now AI understands the chain and can produce code that fits.

For recurring consequential work, a documented prompt-and-check sequence can prevent skipped stages. Measure its results and revise it when the task, model, or tool changes.

The most powerful pipeline:

1. Design — "Plan the approach before writing code"
2. Critique — "What's wrong with this plan?"
3. Implement — "Now build it, addressing those issues"
4. Review — "Review the implementation critically"
5. Test — "Generate tests for edge cases"

For consequential features, this pipeline adds checkpoints where a wrong direction can be detected before it spreads. Measure whether it reduces rework in your own workflow.

Sometimes the most valuable thing AI can do is summarize and question your own thinking. Ask: "Summarize what we've built so far. What assumptions are we making? Which assumptions might be wrong?" This mirrors your thinking back in a clearer form, often revealing blind spots.

This is especially powerful mid-project, when you've been deep in implementation and may have lost sight of the bigger picture. AI's summary forces you to step back and evaluate whether you're still on track.

Before automating consequential work, understand the problem, interfaces, failure modes, and checks well enough to review and maintain the result. For a learning task, use generated code only to the degree that it preserves the intended learning outcome.

AI can help with unfamiliar work, but greater uncertainty requires stronger evidence and review. Accepting code you cannot explain, test, or debug creates an operational dependency rather than durable capability.

AI can lower the cost of producing small prototypes. When alternatives are genuinely uncertain, compare them with the same acceptance criteria and realistic tests rather than relying only on a written comparison.

When the uncertainty justifies the cost, build small prototypes of credible approaches and compare them with the same criteria. Do not prototype every decision; use cheaper evidence when it is sufficient.