1 Conversation, Not Delegation
The difference between using AI well and using it poorly is not technical skill. It is whether you are thinking or just accepting.
1.1 The Core Distinction
When you interact with AI, you make a choice, often unconsciously, about the nature of that interaction.
Delegation is handing off a task: “Write me a marketing plan.” “Create a Python function that does X.” You ask, AI delivers, you accept. It’s transactional. The AI does the thinking; you consume the output.
Conversation is collaborative thinking: You engage the AI in dialogue. You ask questions, challenge assumptions, build understanding together. The AI contributes, but you remain the architect of the outcome.
This distinction matters because:
Delegation makes you dependent. You get output but not understanding. When something goes wrong, you can’t fix it. When requirements change, you start from scratch.
Conversation makes you capable. You build understanding alongside output. You can explain, modify, and improve. You grow with each interaction.
The philosophy of this book is simple: Treat AI as a thinking partner, not a task executor.
1.2 Vibe Coding and What Comes After
There is a popular approach to AI-assisted development called “vibe coding” — a term coined by Andrej Karpathy to describe coding by feel, prompting AI until something works, without necessarily understanding the code it produces. The idea is liberating: anyone can build software by describing what they want and iterating until it runs.
Vibe coding is real, and for quick prototypes and throwaway scripts it can be genuinely useful. Communities like roadmap.sh/vibe-coding have documented practical workflows around it: plan before you code, be specific in your prompts, manage context, test your output, use version control. These are sensible practices, and many of them overlap with what this book teaches.
The difference is what happens when something goes wrong — or when something needs to change.
A vibe coder who gets a working function cannot explain why it works. When a bug appears in production, they paste the error back into the AI and hope for a fix. When requirements shift, they start the conversation from scratch because they never understood the original design. Each interaction is independent. Nothing compounds.
An intentional prompter who gets the same function can explain the algorithm, identify where it will fail, and modify it confidently. When they ask the AI for help, they can describe the problem precisely — not “it’s broken” but “the expand_around_center function isn’t handling even-length palindromes because the boundary check is off by one.” That precision gives the AI the context it needs to be genuinely useful, rather than guessing.
Understanding compounds. Each problem you work through intentionally makes the next one easier — you recognise patterns, you know what questions to ask, you can evaluate AI suggestions against your own mental model. Vibe coding does not compound. Each session starts from zero because no understanding was built in the previous one.
The six-step methodology in this book is not slower than vibe coding. It is faster in the medium term, because the understanding you build in Steps 1-4 makes Steps 5-6 dramatically more productive. You are not guessing at prompts — you are giving the AI precise specifications based on work you already did. The AI responds better because you gave it better input. And when the output needs fixing, you know exactly where to look.
There is also a complexity ceiling. Vibe coding works for single-file scripts and quick prototypes. But when a project grows to multiple modules, shared state, external APIs, and concurrent users, the AI gets stuck too. It suggests fixes that introduce new bugs because it is guessing at the architecture — just like you are. A developer who understands the system’s structure can describe the problem precisely enough for the AI to help. A developer who does not understand the structure is reduced to pasting error messages and hoping. The gap between those two developers widens with every layer of complexity.
An important clarification: intentional prompting does not mean avoiding AI until Step 5. AI is your partner through all six steps — brainstorming requirements in Step 1, exploring edge cases in Step 2, tracing through examples in Step 3, refining pseudocode in Step 4. The methodology is not “think without AI, then code with AI.” It is “think with AI at every stage, so that when you reach the coding stage, both you and the AI have the context to produce something good.” This is the Conversation Loop from Conversation, Not Delegation applied to programming: brainstorm, ideate, iterate, amplify — with AI as your thinking partner throughout.
This book does not argue against using AI to write code. It argues for understanding what you are asking the AI to build, so that when it builds it, you can tell whether it is right.
1.3 What is a “Prompt”?
Before we go further, let’s demystify some terminology.
A prompt is simply a request or instruction you give to AI.
That’s it. When you type “Explain how photosynthesis works” into ChatGPT, that’s a prompt. When you ask Claude to “Review this code for bugs,” that’s a prompt. When you tell Copilot to “Write a function that calculates shipping costs,” that’s a prompt.
Prompts can be simple or complex, vague or precise, single questions or multi-paragraph specifications. The quality of AI’s response depends heavily on how you craft your prompt, but at its core, a prompt is just a request.
1.4 What is “Intentional Prompting”?
Intentional prompting is the practice of crafting each AI interaction deliberately, to build understanding, not just get output.
The word “intentional” is key. It means:
- Purposeful: Each prompt has a clear goal beyond “give me an answer”
- Thoughtful: You consider what you’re asking and why
- Sequential: Each prompt builds on previous exchanges
- Learning-oriented: You seek understanding, not just solutions
A single prompt is a request. A series of intentional prompts becomes a conversation.
Consider the difference:
Unintentional prompting:
"Write a function to validate email addresses"
[Accept output, move on]Intentional prompting:
"I need to validate email addresses. Before we write code,
what makes an email address valid? What edge cases should we consider?"
[AI explains the rules and edge cases]
"Good. Now, what are the trade-offs between using a regular expression
versus parsing the parts individually?"
[AI compares approaches]
"Let's go with regex for simplicity. Can you show me the pattern
and explain each part?"
[AI provides explained solution]
"What inputs would break this? Let's test some edge cases."
[Collaborative refinement]The second approach takes longer but produces:
- A solution you understand and can modify
- Knowledge that transfers to similar problems
- Confidence in the code’s limitations
- Skills that grow with each interaction
1.5 One Prompt, One Job
A related principle: give each prompt a single focused task.
When you ask AI to “write a function, add error handling, write tests, and document it,” you get shallow results for all four. When you ask it to write the function first, then handle errors in the next message, then write tests, each response is deeper and more useful. The model calibrates its depth to match the scope of what you asked. A checklist gets checklist responses. A focused question gets a considered answer.
This is the foundation of the conversation approach. You are not handing over a task list. You are working through a problem one step at a time, reviewing each result before moving on.
1.6 The Philosophy in Action
Let’s see how delegation and conversation differ in practice.
1.6.1 A Python Example
Delegation approach:
Human: Write a Python function that calculates total price with tax and discounts.
AI: [Generates function - works for simple cases but what about negative
prices, multiple discounts, or tax-exempt items?]Conversation approach:
Human: I need to calculate total price with tax and discounts. Before we
write code, what business rules should I consider?
AI: [Explains order of operations, compound discounts, rounding, edge cases]
Human: Those are good points. Lets handle discounts before tax.
What is a clean way to structure this?
AI: [Proposes design with clear separation of concerns]
Human: Now lets implement it. Can you explain each part as we go?
[Collaborative implementation with understanding]The same principle applies beyond programming. Whether you are planning a marketing launch, designing a research methodology, or writing a policy document, the difference between delegation and conversation determines whether you understand the result or just received it.
1.7 Beyond Programming
While this book applies intentional prompting to software development, the philosophy of Conversation, Not Delegation works in any domain: business planning, creative writing, research, education, and beyond. The principles transfer - only the examples change.
1.8 The Two-Chat Workflow
One practical way to build this discipline into your development workflow is to separate thinking from building entirely. Instead of doing everything in one session, run two.
Chat 1: Understand the problem. Open a session with no intention of writing code. Use it to explore the requirements, challenge your assumptions, and clarify what you are actually trying to build. What are the edge cases? What are the real constraints? What approaches have you not considered? Let the conversation wander. This session is messy by design. Its purpose is to sharpen your thinking until you know what you actually need.
Chat 2: Write the code. Start a fresh session and arrive with a clear specification: what the function should do, what inputs it takes, what edge cases it must handle, and what design decisions you have already made. The code will be dramatically better because the input is better.
The critical step is the gap between the two chats. You do not dump everything from the first session into the second. You review what emerged, keep what matters, discard what does not, and write a focused brief that reflects your decisions. That act of curation is where your engineering judgement lives.
This maps directly to the average-versus-precise framework. A project that starts in the danger zone (large, precise) gets decomposed during the thinking chat into components that each sit in different quadrants. The architecture discussion belongs in Chat 1. The individual functions can be written in Chat 2 with appropriate trust for their position on the grid.
1.9 What is Ahead
This book will teach you to have productive conversations with AI:
- Part 1: Foundations establishes the core concepts and principles
- Part 2: Methodology provides a structured six-step approach
- Part 3: Patterns and Practices offers reusable conversation patterns
- Part 4: Advanced Topics addresses complex scenarios and future directions
Throughout, you will see examples in both programming and business contexts, reinforcing that these principles apply wherever you work with AI.
The goal is not to make you dependent on AI, but to make you more capable with AI as your partner.
Lets begin.