{"id":22095,"date":"2025-09-26T11:27:57","date_gmt":"2025-09-26T10:27:57","guid":{"rendered":"https:\/\/www.equalexperts.com\/?p=22095"},"modified":"2025-09-26T11:27:57","modified_gmt":"2025-09-26T10:27:57","slug":"from-madness-to-method-with-ai-coding-part-2-guardrails","status":"publish","type":"post","link":"https:\/\/www.equalexperts.com\/blog\/ai\/from-madness-to-method-with-ai-coding-part-2-guardrails\/","title":{"rendered":"From madness to method with AI coding: Part 2 – Guardrails"},"content":{"rendered":"

In part 1 of our series on applying methodology to AI, we talked about using meta-prompting<\/a> as a way to get closer to the mark – quicker – when using AI-assisted coding. Think of every AI-generated solution as a golf shot: you tee off, sometimes landing the ball neatly on the fairway, hopefully not into the rough. If you\u2019re lucky, you\u2019re approaching the green, where a few corrective actions with your putter get you quickly to your desired result. It\u2019s just like using prompts in the software development life cycle – a gradual narrowing down through a progressive precision refinement process.<\/p>\n

Before we even tee off, we need to know the boundaries of the fairway or the green, so we can aim to land the ball there. This is where guardrails come in. Guardrails – or rules, as they\u2019re known in software development – provide the LLM with guidelines – a system context for every prompt that we issue. So, what do we consider as the “fairway” when we\u2019re building a feature? What system context can we provide to bring us closer to our mark?<\/p>\n

How to use guardrails in AI-assisted coding<\/h2>\n

The trick is to carefully craft rules that are relevant to the project you\u2019re working on. For instance, one engineer\u2019s rules in a Node.js frontend app will look completely different to those in a Kotlin Ktor app. So, what do we include in the rules of our projects? And what format should they have? How do we write them? How long should they be? We\u2019ll go through these questions one by one.<\/p>\n

Why guardrails matter<\/h3>\n

AI coding assistants are powerful, but they don\u2019t know your rules by default. LLMs have been trained on code that reflects every opinion and pattern on the internet. If you want them to follow your way of working, you need to be explicit.<\/p>\n

For example, when I\u2019m writing code, I care about concepts like Domain-Driven Design, Hexagonal Architecture, outside-in testing and functional programming. So, I capture each of these values as a rule in the project. (As an example, here is a rules directory I use for my Kotlin project.) Your team\u2019s rules will differ, but the principle is the same: define what matters to you and give the LLM that context up front.<\/p>\n

Rule formation<\/h3>\n

So, what makes a good rule? Firstly, the less verbose the rules are, the better. In my experience, rules should never exceed ~200 lines \u2014 the longer they get, the more likely the LLM is to veer off into the rough. Meta-prompting (from part 1 of this series) helps here. For example, I asked the LLM:<\/p>\n

Please write me a rule in markdown to be used by an LLM that describes Domain Driven Design by Eric Evans in under 200 lines.<\/em><\/p>\n

To keep rules consistent, I use a simple template, the same way I do with prompts. Here it is:<\/p>\n

# [Rules Topic\/Domain Name]\r\n\r\n*Brief description of the rules domain and its scope. What aspect of development, architecture, or method do these rules<\/pre>\n
govern? Keep this concise and focused on the purpose and boundaries of these rules.*\r\n\r\n## Context\r\n\r\n*Provide the situational context where these rules apply. This helps the LLM understand when and why to apply these rules.*\r\n\r\n**Applies to:** [Project types, layers, components, or scenarios where these rules are relevant] \r\n**Level:** [Strategic\/Tactical\/Operational - helps prioritize rule application] \r\n**Audience:** [Developers\/Architects\/Product Team - who should follow these rules]\r\n\r\n## Core Principles\r\n\r\n*List the fundamental principles that underpin all the detailed rules. These are the \"why\" behind the rules and help<\/pre>\n
with decision-making when specific rules don't cover a scenario.*\r\n\r\n1. **Principle Name:** Brief explanation of the principle and its importance\r\n2. **Principle Name:** Brief explanation of the principle and its importance\r\n3. **Principle Name:** Brief explanation of the principle and its importance\r\n\r\n## Rules\r\n\r\n### Must Have (Critical)\r\n*Non-negotiable rules that must always be followed. Violation of these rules should block progress.*\r\n\r\n- **RULE-001:** Description of the rule with clear, actionable guidance\r\n- **RULE-002:** Description of the rule with clear, actionable guidance\r\n- **RULE-003:** Description of the rule with clear, actionable guidance\r\n\r\n### Should Have (Important)\r\n*Strong recommendations that should be followed unless there's a compelling reason not to.*\r\n\r\n- **RULE-101:** Description of the rule with clear, actionable guidance\r\n- **RULE-102:** Description of the rule with clear, actionable guidance\r\n- **RULE-103:** Description of the rule with clear, actionable guidance\r\n\r\n### Could Have (Preferred)\r\n*Best practices and preferences that improve quality but are not blocking.*\r\n\r\n- **RULE-201:** Description of the rule with clear, actionable guidance\r\n- **RULE-202:** Description of the rule with clear, actionable guidance\r\n- **RULE-203:** Description of the rule with clear, actionable guidance\r\n\r\n## Patterns & Anti-Patterns\r\n\r\n### \u2705 Do This\r\n*Concrete examples of what good implementation looks like*\r\n\r\n\/\/ Example of good practice in code block\r\n\/\/ Clear, concise code example\r\n\r\n### \u274c Don't Do This\r\n*Concrete examples of what to avoid*\r\n\r\n\/\/ Example of anti-pattern in code block\r\n\/\/ Clear example of what not to do\r\n\r\n## Decision Framework\r\n\r\n*Provide guidance for making decisions when rules conflict or when faced with novel situations*\r\n\r\n**When rules conflict:**\r\n1. Step 1 for resolution\r\n2. Step 2 for resolution\r\n3. Step 3 for resolution\r\n\r\n**When facing edge cases:**\r\n- Guideline 1\r\n- Guideline 2\r\n- Guideline 3\r\n\r\n## Exceptions & Waivers\r\n\r\n*Define when and how these rules can be broken*\r\n\r\n**Valid reasons for exceptions:**\r\n- Reason 1 (with approval process if needed)\r\n- Reason 2 (with approval process if needed)\r\n- Reason 3 (with approval process if needed)\r\n\r\n**Process for exceptions:**\r\n1. Document the exception and rationale\r\n2. [Additional approval steps if needed]\r\n3. [Time-bound review if applicable]\r\n\r\n## Quality Gates\r\n\r\n*Define how adherence to these rules should be verified*\r\n\r\n- **Automated checks:** What can be validated through tooling\r\n- **Code review focus:** What reviewers should specifically look for\r\n- **Testing requirements:** How rule compliance should be tested\r\n\r\n## Related Rules\r\n\r\n*Reference other rules files that complement or interact with these rules*\r\n\r\n- `rules\/related-rules-1.md` - Brief description of relationship\r\n- `rules\/related-rules-2.md` - Brief description of relationship\r\n- `rules\/related-rules-3.md` - Brief description of relationship\r\n\r\n## References\r\n\r\n*Links to external resources, standards, or documentation that inform these rules*\r\n\r\n- [Resource 1](url) - Brief description\r\n- [Resource 2](url) - Brief description\r\n- [Resource 3](url) - Brief description\r\n\r\n---\r\n\r\n## TL;DR\r\n\r\n*Ultra-concise summary of the most critical rules and principles. This section should be scannable in under<\/pre>\n
30 seconds and capture the essence of all rules above.*\r\n\r\n**Key Principles:**\r\n- Principle 1 in one sentence\r\n- Principle 2 in one sentence\r\n- Principle 3 in one sentence\r\n\r\n**Critical Rules:**\r\n- Must do X\r\n- Must not do Y\r\n- Always ensure Z<\/pre>\n
You can now open a new chat (to ensure no previous context) with your LLM and provide it with the prompt, along with the template provided above. In my case, it resulted in this Domain Driven Design rules file.<\/a> Once you have your template, you can generate clean, uniform rules that are easier for an LLM to follow. (Here\u2019s the meta-prompt<\/a> I used to generate this template.)<\/p>\n
Guardrails keep you on the fairway<\/h2>\n
By applying guardrails, you\u2019ll spend less time untangling the LLM\u2019s \u2018creative interpretations\u2019 and more time creating value. Remember, keep your rules:<\/p>\n