How to talk to LLMs
2026-06-02
by Uri Walevski
Language models have an inherent desire to please. If you ask an LLM if a bug is fixed, it will almost always say yes. It wants to tell you that the work is done, that there are no issues, and that everything is perfect.
This agreeable nature is a major challenge in software engineering and general task management. Some newer, extremely fast models like Gemini 3.5 can feel like they just did a line of cocaine. They run at lightning speed, make sweeping changes, and declare total victory with absolute, manic confidence, regardless of whether the code actually compiles or does what you wanted.
When operating language models, relying on their word is a recipe for broken systems. Instead, working with them requires structure, verification, and clear boundaries.
Setting the ground rules
Successful interaction begins with defining acceptance criteria. Before the model starts writing code or executing a task, the exact conditions for success must be established. If the model does not know what a successful run looks like, it will default to convincing you that whatever it did was right.
To protect against mistakes, version control and immutability are necessary safeguards.
For non-technical users, version control is like a time machine for your project. Systems like GitHub keep a complete history of every single change made to your files. If the model makes a mistake, deletes a critical file, or introduces a bug, you can instantly roll back to the exact second before the change happened.
Immutability means creating data that cannot be changed once written. Instead of editing an existing document or database record directly, the system writes a new, timestamped version of it. If a mistake happens, the historical data remains perfectly preserved, and you never lose information.
Designing for fast verification
Every task given to an LLM should be accompanied by a simple question: how can this be verified quickly?
The goal is to design a workflow where the work can be proven or disproven in seconds. If verifying a change takes ten minutes of manual clicking, you will eventually skip it, and the model will eventually break something.
Once a verification path is identified, the model itself should be prompted to run that verification before announcing that a task is complete. If the model can run the tests, compile the project, or check the logs, it should be instructed to do so as its very last step. It should only report success after the automated check passes.
Understanding reproductions and tests
If you are not a developer, words like "tests" and "reproductions" can sound like jargon. But they are actually very simple real-world concepts:
- What is a reproduction (or "repro")? Think of it like a recorded video clip showing exactly when and how a coffee machine spills. If you just tell a repairman "the coffee machine is broken," they might turn it on, see it heat up, and assume everything is fine. But if you give them a precise, 3-step recipe: "1. Insert a dark roast pod. 2. Select medium size. 3. Press start. Watch it leak from the bottom," they can see the exact issue. In software, a reproduction is a minimal, step-by-step script that reliably triggers the bug so the AI can see it fail.
- What is a test? Think of it like an automated quality control checklist. When a factory builds a car, they don't just hope it works; they have machines that automatically check if the headlights turn on, the doors lock, and the brakes hold. A test in software is a tiny script that automatically runs these checks. It clicks the buttons, logs in, or runs the calculation in less than a second to ensure nothing is broken.
When working with human engineers, there is a level of shared intuition and care. LLMs do not have intuition. They have statistics. The slightest display bug or logic issue must be addressed with a reproduction first.
Once the repro is running and failing, the model can be instructed to fix it. When the automated test script passes, the bug is solved. This loop of repro, fix, and verify should be second nature when working with LLMs.
Useful phrases to keep in your back pocket
Here are a few concrete examples of how you can enforce these rules during a conversation with an LLM:
- "Please make a reproduction first, add as test, and only then fix." — Forces the model to build a failing test case before attempting any fixes, ensuring the bug is actually understood and verified.
- "How can I verify what you did works before we end this?" — Prompts the model to provide specific commands, tests, or inspection steps, keeping the verification loop tight and concrete.
- "Please try to simplify and rethink the architecture, as we tried this a few times and it did not work." — Signals the model to step back from recursive patching, stop forcing a broken approach, and find a cleaner structural solution.