Teach AI to Code Better - A Guide to Sanity and Productivity

Let’s face it: using an AI programmer like Claude can feel like having a brilliant but eccentric intern. One moment, it’s a genius who refactors your entire codebase in seconds. The next, it’s hallucinating shit and setting your project on fire (metaphorically, I hope).

The difference between a coding wizard and a chaos agent often comes down to one thing: the user.

Before Writing a Single Prompt

Good code doesn’t start with code; it starts with a plan. The same is true for AI. Rushing in with a vague idea is a recipe for disaster.

So have a good plan first, never open an AI tool without a clear functional specification document. AI may amplify everything. Give it clarity, and you’ll get a clear solution. Give it chaos, and you’ll get a beautiful, magnificent mess.

XML is in fact, love. XML is in fact, life. – Mrwest16

XML or Json seems to be the way to go in terms of the AI actually listening to your instructions and being able to pull information. This is something everybody else probably already knows, but it’s a foundational trick for a reason: wrapping your prompts in structured data forces the model to slow down, parse the context, and pay attention.

LLMs are naturally skilled at parsing structured data because they were trained on it. Wrap your files, instructions, and examples in clear , , and tags. Search "XML tags claude" in Google. They have documentation with examples where they explain it. In addition, Markdown is a good choice for GPT.

Context is Everything. Don’t be shy. Provide it all: file structures, database schemas, API documentation, and even screenshots of the UI you’re trying to build.

If you can’t articulate the problem and desired outcome clearly to yourself, the AI has no chance. Take a moment to clear your own head before you try to direct it. If you feel confused, the AI does too.

Every conversation should begin with three things: the project context, a set of rules (e.g., “use C++20,” ), and a list of prohibitions (e.g., “do not modify files outside of this directory”).

Interactions

• The 50% Token Rule, once your conversation hits about 50% of the context token limit, start a new one. As the context window fills up, the model’s compression can degrade the quality of its output. Fresh conversations mean fresh, high-quality results. Anyway, don’t let the conversation be too long.

• Developing multiple features in a single chat is like trying to code while drunk. It feels efficient at the time, but the morning-after cleanup is a nightmare. Dedicate each session to a single, specific task.

• Don’t create a single, “all-powerful” agent. Build a team of specialists. Have a frontend agent, a backend agent, and a database agent. A specialist will always outperform a generalist.

• Maintain files like project_context.md to summarize the project’s state. Update it after each session. This ensures continuity and helps the AI (and you) get back up to speed quickly.

• Don’t let the AI run wild. Give it explicit stopping points. A prompt like, “Implement the user authentication logic, then stop and wait for my review before writing the tests,” prevents it from making a series of compounding errors.

• When asking for a bug fix, add these words: “Fix this bug without changing any other code.” This simple constraint can prevent a small fix from causing a cascade of new problems.

Integrate into Workflow

Integrating AI into workflow isn’t about replacing skills; it’s about augmenting them.

• Write Tests Before Code (Yes, Really): The old principle of Test-Driven Development (TDD) is the new best friend. Ask the AI to write the tests first. This forces a clear definition of “done” and saves you from a debugging hellscape later.

• Commit Everything: The moment a feature is working, git commit. It’s much easier to roll back to a working state than to manually undo a series of AI shit.

• Ask for a Check: After the AI generates code, give it a new task: “Check the code you just wrote and list/fix any potential errors or edge cases.” This forces the model to switch from a creative mode to an analytical one, catching its own mistakes.

• Demand Explanations: Don’t just accept the code. Force the AI to explain what it changed and why.

• Keep a “Book of Wrongs”: The AI will forget its past mistakes, but you shouldn’t. Maintain a dont_do.md file that records failed approaches and bad patterns. This serves as a valuable, project-specific knowledge base.

• Keep Rule Files Simple: Your custom rule files should be concise. A rule file under 100 lines is more effective than a comprehensive but bloated one. Brevity wins.