<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>regex on Arrans Technical blog</title><link>https://arran4.github.io/blog/tags/regex/</link><description>Recent content in regex on Arrans Technical blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>technicalblog123@arran4.com (Arran Ubels)</managingEditor><webMaster>technicalblog123@arran4.com (Arran Ubels)</webMaster><copyright>Arran Ubels. This work is licensed under a &lt;a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License&lt;/a>.</copyright><lastBuildDate>Mon, 13 Jul 2026 13:33:09 +1000</lastBuildDate><atom:link href="https://arran4.github.io/blog/tags/regex/index.xml" rel="self" type="application/rss+xml"/><item><title>Why LLMs Should Conditionally Avoid Regex and Aim for Exhaustive Test Coverage</title><link>https://arran4.github.io/blog/post/2026/022-llm-expand-regex-test/</link><pubDate>Mon, 13 Jul 2026 13:33:09 +1000</pubDate><author>technicalblog123@arran4.com (Arran Ubels)</author><guid>https://arran4.github.io/blog/post/2026/022-llm-expand-regex-test/</guid><description>When generating code, Large Language Models (LLMs) often default to using Regular Expressions (regex) for string parsing and validation tasks. While regex is a powerful tool for human developers aiming for concise code, it is rarely the optimal choice for LLMs writing production-grade software.
Instead of always defaulting to dense regular expressions, LLMs should often expand logic into explicit, step-by-step procedural code and accompany that code with comprehensive, table-driven unit tests.</description></item></channel></rss>