# Prompt Iteration and Follow-ups

### Prompting isn’t so much a command-and-control process as much as it is a conversation. Throughout any conversation, you gauge if your conversation partner ‘gets’ what you’re saying. That’s the same here.

With that in mind, here are some important tips:

1. **Start off small, then go deeper.** – Consider how you would introduce a new topic to a class of beginners, but then also how you would go into detail. It should be a process without assuming the student understands everything right away.
2. **Read *****into***** the LLM’s answer.** – Evaluate the details of each LLM response. See if they are responding in a way that someone who understands your comments would.
3. **Distill**. – Refine what you mean in the feedback of *your* response.
   1. Reference previous responses (“in your last response” / “in the code you just generated”)
   2. “Can you try again but treat this as a Vue 3 project (Composition API) and update only the current component file?”
4. **Ask for clarification.** – Ask the model itself to reissue the response to be sure it understands you right:
   1. “Can you rephrase that in layman’s terms?”
   2. “That’s close—just take this in mind…”
   3. “Please show me what you mean.” / “Add a test case for that example.”
   4. ### “Actually, I meant a recursive version, not iterative.”
   5. ### “This is good, but can you include error handling?”

###

Like a good manager, be specific about what you want to critique in each comment. With an agent, each follow-up prompt is a course correction: tell it what to inspect next, what to stop doing, and what new constraints now apply.

**Tip:**

### Avoid vague corrections like “That’s not what I meant.” Instead, **explicitly say what you want changed.**

### **A. When to clarify or restart**

### Use **clarification** when the thread’s still salvageable. Use **restart** when history becomes baggage. In Tabnine, that means clicking “New Conversation” to ensure a clean context window.

### ---

* ### If the model is **only a little wrong**, clarify.
* ### If you find yourself typing **“Forget what I said earlier…”**, restart.

| Situation                                  | Recommended Action | Justification                                                                                                                                                                                     |
| ------------------------------------------ | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Minor misunderstanding                     | Clarify            | The model likely retained the correct context but misinterpreted or guessed incorrectly on a detail. A follow-up (e.g., “Use a hashmap instead”) typically corrects this without needing a reset. |
| Response is correct but incomplete         | Clarify            | The model is aligned with your goal—just nudge it further. Follow-ups like “Add edge case handling” work well here and preserve useful context.                                                   |
| Model keeps misunderstanding core intent   | Restart            | If several clarifications don’t resolve the confusion, context drift has likely occurred. Old messages may bias the model, so a fresh thread is cleaner and more efficient.                       |
| You introduced unrelated topics mid-thread | Restart            | LLMs prioritize recency but can mix topics. Starting fresh ensures the new task isn’t contaminated by unrelated context.                                                                          |
| You see weird or contradictory output      | Restart            | This often signals corrupted or conflicting memory—especially when the model contradicts itself or changes direction erratically.                                                                 |
| Tabnine/LLM refers to outdated messages    | Restart            | When it hallucinates old input or can’t seem to "forget" a shift in scope, a restart ensures that only your new input is influencing the response.                                                |

###

### **B. Code Formatting for Accuracy**

When prompting with or about code, **format it cleanly and consistently**—as if you were writing for a teammate doing code review.

#### **Why It Matters:**

Large Language Models (LLMs) like Tabnine rely heavily on **token structure** and **formatting cues** to interpret what your intent is. Sloppy or inconsistent formatting introduces ambiguity, which leads to vague, broken, or off-target responses.

***

#### **Recommended Formatting Tactics**

| Technique                                | Example                                                      | Why It Helps                                                 |
| ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **Use syntax-highlighted code blocks**   | `python<br>```python<br>def get_user():<br> pass<br>```<br>` | Ensures model parses it as *code*, not prose.                |
| **Label your code explicitly**           | “Here’s my `User` class”                                     | Adds semantic clarity—models use these cues to match intent. |
| **Show input/output clearly**            | `Input: [1, 2, 3] → Output: 6`                               | Enables better example matching and test generation.         |
| **Break long prompts into parts**        | “Here’s the class. Now write a test.”                        | Modular input improves comprehension and results.            |
| **Avoid inline code in long paragraphs** | Don't bury `def` or `var` calls in walls of text             | Makes parsing harder; model may ignore or mangle it.         |

***

#### **Common Pitfalls**

| Pitfall                                        | Impact                                                  |
| ---------------------------------------------- | ------------------------------------------------------- |
| Missing indentation                            | LLM assumes malformed logic or syntax                   |
| Incomplete snippets                            | LLM guesses the rest—often incorrectly                  |
| Mixed languages or styles                      | Confuses intent; may switch languages mid-reply         |
| Describing code in prose instead of pasting it | Increases hallucination risk; LLM has to infer too much |

***

#### **Prompt Examples**

**Less Effective:**

Can you help fix my function that checks if a string is a palindrome?

**More Effective:**

python

CopyEdit

` ```python `

`def is_palindrome(s):`

`return s == s[::-1]`

` ``` `

`Can you help me fix the indentation and make sure it works for input with spaces and punctuation?`

### **C. Be Concise but Complete**

While prompts often need to grow gradually as you refine a task, it’s just as important to know when to scale back. This balance is what keeps prompts concise: specific and tight, without becoming overly descriptive.

Things to keep in mind when maintaining a concise prompt (most of which we’ve already discussed):

1. Start small, then expand only as misunderstanding appears.
2. Keep additions short and targeted.
3. Stay clear and focused on the goal.

| !Note: Conciseness isn’t the same as avoiding *redundancy*. Redundancy can sometimes be necessary for clarity; conciseness is about keeping the prompt free of anything that doesn’t move the task forward. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Consider these examples:

#### **Too Vague**

| `Can you help me with reading my CSV in Python? I need it to have name, age, and email.` |
| ---------------------------------------------------------------------------------------- |

This is extremely vague. Even if you have attached the CSV file, this leaves the model to make interpretations on its own. It might infer that you have that data in the file already, or it might hallucinate 'filler' data to ensure there are some names, ages, and email addresses.

While models continue to get better at inference through context, this sort of thing should not be left to chance anymore than you would with giving instructions to a human.

#### **Too Verbose**

| `I have this CSV file I’m trying to read in Python, but I’m not sure how to handle it correctly. The file has some columns like name, age, and email. I think I should probably use the CSV module but I’m not positive. Also I need to print each row, but I don’t want the program to crash if the file is missing or the path is wrong. Could you maybe write a function for me? I’m using Python 3.11. I want it to gracefully handle errors and just read the file and print everything in a clean format. I’m not sure if I’m thinking about it the right way, so feel free to correct any assumptions.` |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

With LLMs, you need to be more definitive.

“Could you maybe,” “should probably,” and “I’m not sure if I’m thinking about it the right way” signal a lot of wiggle room to the model.

It needs a clear task (and order of priority if covering multiple tasks). Otherwise, extra narrative, pleasantries, and words might confuse the LLM on the priorities of your request.

#### **Just Right**

| `Write a Python 3.11 function that reads a CSV file with the columns name, age, and email. Use the csv module, print each row, and raise a FileNotFoundError if the file does not exist. Keep the implementation simple and readable.` |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

This gets the best of both worlds from the previous two examples:

1. Clear task (*Write a Python 3.11 function that reads a CSV file with the columns name, age, and email.*)
2. Clear parameters. (*Use the csv module, print each row, and raise a FileNotFoundError if the file does not exist.*)
3. Clear notes about style at the end (*Keep the implementation simple and readable.*)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.tabnine.com/main/getting-started/tabnines-prompting-guide/prompt-iteration-and-follow-ups.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.