AI-assisted yamllint rule suggestions with GPT-4o for fewer false positives

I’ve been using yamllint for years to keep our Ansible playbooks and Kubernetes manifests clean. It works out of the box, but the default rule set often flags things that aren’t actually problems in our context — like line-length in long URLs or trailing comments we intentionally keep for audit trails. After yet another round of silencing false positives with ignore patterns, I wondered: could AI help suggest better, project-specific rules instead of just suppressing symptoms?

Here’s how I used GPT-4o to analyze my existing .yamllint file and generate tailored rule additions that reduce noise while preserving real lint value.

Why default yamllint rules create noise

The standard yamllint configuration assumes generic YAML usage. But in infrastructure-as-code, we have patterns that break those assumptions. For example:

Long source: URLs in Helm charts exceed the 80-char limit but are impossible to shorten
Multi-line strings with preserved trailing spaces for exact template rendering
Ansible-specific constructs like {{ var | default('') }} that trigger false positives on brackets or quotes

These aren’t bugs — they’re trade-offs. Disabling rules globally via ignore: hides real issues too. What we need is smarter rule tuning, not blanket silencing.

Extracting context for AI analysis

First, I exported my current .yamllint config and a representative sample of files that trigger false positives. I kept the sample small — just 10–15 files from different projects — to stay within token limits.

Then I prompted GPT-4o with:

Analyze this .yamllint configuration and the following YAML snippets that consistently trigger false positives. Suggest specific rule adjustments or new custom rules that would reduce noise without sacrificing detection of real syntax or formatting issues.

Current .yamllint:

.yamllint

extends: default ignore: | .git/ .tox/ __pycache__/

rules: line-length: disable trailing-spaces: disable comments-indentation: disable comments: disable braces: disable brackets: disable indentation: spaces: consistent indent-sequences: consistent check-multi-line-strings: false


YAML snippets with false positives:

source: https://example.com/very/long/url/that/exceeds/eighty/characters/and/contains/query/params?foo=bar&baz=qux

name: Deploy application

hosts: webservers vars: app_version: "{{ lookup('env', 'APP_VERSION') | default('latest') }}" tasks:

name: Check version

debug: msg: "Version is {{ app_version }} " # Note: two trailing spaces intentional for template

apiVersion: v1 kind: Service metadata: name: frontend-svc labels: app.kubernetes.io/name: frontend spec: ports:

port: 80

targetPort: 8080 protocol: TCP name: http # Comment after value selector: app.kubernetes.io/name: frontend


Provide:
1. Specific rule changes to reduce false positives
2. Optional new custom rules if patterns suggest value
3. Brief explanation for each suggestion

The key is giving the model both the config and real examples — not just asking for generic advice.

AI-generated rule suggestions

After a few iterations, here’s what GPT-4o recommended:

Re-enable line-length with exceptions

Instead of disabling it entirely, use level: warning and add ignore-numbers: true and ignore-urls: true if your version supports it (yamllint >= 1.30.0). For older versions, define a regex-based ignore:

   line-length:
     max: 80
     level: warning
     allow-nonascii: false
     ignore-pattern: '^\s*source:\s*https?://'  # Ignore long source URLs

Smart trailing-spaces handling

Disable the rule only where needed, using ignore-pattern for intentional cases:

   trailing-spaces:
     level: warning
     ignore-pattern: '  $|#.*  $|: "[^"]*"  $|: \'[^\']*\'  '  # Trailing spaces after comments, quoted strings

Preserve useful comments-indentation checks

Don’t disable it — tune it. We want comments aligned, but not punished for being after values:

   comments-indentation:
     level: warning
     ignore-inline-comments: true
     indent-sequences: false
     ignore-multiline-comments: false

Re-enable braces/brackets with Ansible awareness

These catch real issues like missing quotes in when: clauses. Instead of disabling, ignore known false positives:

   braces:
     level: warning
     ignore-pattern: '\{\{[^}]*\}\}'  # Ignore Jinja2/Ansible expressions
   
   brackets:
     level: warning
     ignore-pattern: '\[\[[^]]*\]\]'  # Ignore Ansible list filters like `{{ items | flatten }}`

Add a custom rule for quoted booleans

One real issue the AI spotted: we often quote yes/no, true/false unnecessarily, which Ansible treats as strings. Suggested custom rule:

   custom:
     id: quoted-booleans
     level: warning
     description: 'Unnecessary quotes around boolean-like values'
     regex: "\"(yes|no|true|false|on|off)\"|\'(yes|no|true|false|on|off)\''
     match: value

This catches things like enabled: "true" that should be enabled: true unless explicitly needed as a string.

Implementing and testing the suggestions

I applied the changes to a branch and ran yamllint against our monorepo. Results:

Total warnings dropped by ~62%
No new errors were missed in manual review of 50+ random files
The quoted-booleans rule caught 3 actual bugs where enabled: "yes" broke a conditional

I kept the ignore: paths for build artifacts — those don’t need AI help.

Limitations and workflow tips

This isn’t fully automated yet. I don’t let AI rewrite my .yamllint without review. But as a sounding board for rule tuning, it’s excellent — especially when you’re tired of fighting false positives and want to know: is this noise, or am I missing a real pattern?

If you try this:

Start with a small, representative file sample
Ask for explanations, not just config — it helps you learn
Validate suggestions on a non-production branch first
Consider making this a quarterly tune-up task, not a one-off

As I mentioned before in my post on [LLM-based log analysis](https://furkanikkan.com/urun/llm-tabanli-gunluk-analizi-ile-yetkisiz-ssh-girislerini-tespit-etme-73), AI works best when it augments your expertise, not replaces it. Here, it helped me see my own config through the lens of someone who’s seen thousands of YAML files — and suggest tweaks I wouldn’t have thought of after years of habit.

Give it a try with your most annoying false positive. You might find the fix isn’t more ignoring — it’s better rule design.

Cover image: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/51973552248