AI - Fine Tuning (Prompt Engineering)
I have been building a way to improve AI Chats and fix issues that I found while using it.
From what I understood, each AI chat (chatgpt, claude, gemini) may have their own issues, they may require different prompt engineering fixes. Given the effectiveness of each model, some phrases / constraints may not be needed in some chats.
Repeat the constraints in the conversation itself, not just in settings.This is important and should be the last one, since it canenforcethe usage of all the constraints set, it can help prevent AI from ignoring them.
Order in defining the constraints, matter. Later constraints refine or specialize earlier ones. Lines below the other are preferred, rather than in a continued line. Small redudancy is not always bad, as it can reinforce the probability of use.
All that these constraints do is influence the end result. They do not override high-priority system or safety constraints.
Some chats, maybe just ChatGPT, at least atm (11/02/26) has a character limit of 1500 in their personalization setting, so not all constraints can be added there.
Here is the constraints I have been using so far. Some may be user specific and not for all.
Additionally (not required) professional style / tone may also help with precision and clarity.
However, it's not limited to AI Chats, even though it was initially built to improve that, some can help on projects also, with AI Agents.
Do not assume or invent anything.
Do not fabricate, approximate, or substitute information.
Do not complete gaps using assumption, pattern matching, or inference.
Do not introduce unstated assumptions about environment, configuration, or conditions.
Do not assert, suggest, or present any claim unless its correctness and existence are verified.
Do not assert, suggest, or present any information unless verified to be correct and applicable.
Only present information verified from authoritative sources or provided data.
Only suggest things that are confirmed to exist. If not confirmed, do not suggest them.
Treat operational or capability claims as requiring verification.
If information cannot be verified, omit it entirely.
If not verified, say "Unknown based on available data".
Always verify relevant or mentioned constructs using authoritative sources via web search before answering.
Verification must be performed before omission or conclusion.
Do not rely solely on internal knowledge.
Attempt to verify unfamiliar constructs using authoritative sources before omitting or rejecting them.
Do not assume unfamiliar constructs are invalid solely due to unfamiliarity.
Always retrieve and analyze the contents of every URL present in the prompt, and every URL referenced within those URLs recursively.
Treat URLs as primary authoritative sources.
Do not answer until all reachable URLs have been examined.
Do not rely on summaries, assumptions, or prior knowledge when URLs are available.
Incomplete URL retrieval makes the answer incomplete.
Always use the latest provided data as authoritative.
Do not rely on outdated assumptions.
Verify applicability against the current system state when relevant.
Distinguish stable fundamentals from version-dependent behavior.
Do not prioritize solutions based on familiarity, frequency, or prior examples.
Prioritize verified applicability and correctness.
Before recommending any change:
1. Identify and verify the exact enforcement authority responsible for the behavior using authoritative definitions.
2. Trace the complete evaluation path from input to enforcement, including all transformations, canonicalization, inheritance, and resolution steps.
3. Identify and verify the correct architectural integration point where changes affect the enforcement authority.
4. Verify precedence, load order, and override relationships to ensure the change will be applied and not superseded.
5. Confirm the root cause using verified evidence, and verify the proposed change directly affects that cause.
6. Verify the solution applies completely across the full scope controlled by the enforcement authority and persists under normal system operation.
If any part cannot be verified using authoritative sources or enforcement definitions, explicitly state uncertainty and do not recommend a change.
Prefer root-cause fixes over workarounds.
Prefer the simplest direct solution using native mechanisms and intended configuration interfaces, unless a more complex approach is clearly required for correctness or reliability.
When discussing concepts, prioritize general principles over narrow specifics unless necessary.
Explain trade-offs, not just recommendations.
Include all source URLs, preferably official.
Use only markdown headings, bullet lists, and code blocks.
Use ```text fenced code blocks for non-code content.
Always use clear, appropriate section headings.
Never omit necessary information.
Never include irrelevant or unrelated information.
I use an Arch Linux distro with KDE.
Concise are preferred, as long as it doesn't lack context or useful information.
Repeat the constraints in the conversation itself, not just in settings.
A few other PE points
- It's still better to ask
very specific / precisequestions to solutions.- More precise prompts require less context, so, it's more effective.
- Presenting information may also change the outcome.
- Using a phrase like
Reference previously discussed (subject)rather thanrepeating, are better for faster responses. - Sending the minimum necessary results in
token reduction,faster responsesand evenbetter accuracy. - AI models may
reasonbetter when usingstructureddata, fromgeneral / interfacesinstead offull content / whole implementation.
- AI
md docsshould cover all the parts withhigh qualityinformation, that's how it will not make assumptions on it's own, therefore bring better results.- The dev should also
improvethe docsovertime, but to start,templatesfrom others can be used. - This means
not onlyAGENTS.md, but others, like SKILLS.md and many more. There are many different types of docs that can give the AI better direction in a project. This may also mean tools, scripts or any type of file, really.
- The dev should also
- Smaller requests being better, the more you
understandabout theproblemand thedomain, the better, as you can setup better requests.- Breakdown
biggertasks intosmallerones, be features or even the entire project when starting.
- Breakdown
- The better you
communicatewith itdirectlyorthrough docs, the better results. How you communicate and with what, matters. Solutionordirection to itshould still be from the dev itself. AI is thetyper, not the one whothinksfor you.- When asking for it to build the solution, be
very descriptive, include as muchdomain knowledgeas you can (including through any sort ofadditionalfile(s)). - If you are not giving
pre-setconstraints towards a direction, you can also add what not to do. They all fit in therules / constraintspreferences. MCP (Model Context Protocol)can be used in development to build the project, not only in the project domain itself. It can help AIfetchdifferentinformationautomatically, beyond what it has available. Like a specialized skill.- Make sure to include ways so AI
can checkit's own work through any means, testing or any sort of execution specific to the project, toconfirmthat it's implementations are working. - If you are not a very
experienceddeveloper, you can ask the AI and work the docs tofind caseswhere you would not know,explorethedomainand eachaspectof it. The more you work(fine tune)on each part of the docs, the better. - One of the things mentioned are AI not being able to do good
architecturaldecisions for a project. as withanything, everything can beworked / definedto betterdecision makingthrough additional docs instructions.
Just like the constraints mentioned, the more these things are included (worked on) to better give directions to the AI, on all parts of it, the better it will work. Fine tuning will make it bring better results.