Why do AI coding tools struggle with RTL layouts by default?

Most training data and component libraries default to left-to-right assumptions, so an AI coding assistant will reach for `left-*`/`right-*` utility classes and LTR-only patterns unless the prompt or project rules explicitly call out RTL requirements.

What is the single most common RTL bug an AI tool introduces?

Using physical positioning classes (`left-4`, `right-4`) instead of logical properties (`start-4`, `end-4`) or an explicit `dir` attribute - the code compiles and looks correct in an English preview, then renders mirrored or misaligned the moment the page runs in RTL.

Can you verify RTL correctness just by reading the generated code?

Not reliably. Terminal output and diff viewers often misrender right-to-left text, so a layout that reads fine in a code review can still be visually broken - checking in an actual browser preview with `dir="rtl"` set is the only reliable verification step.

Does this apply to Arabic as well as Hebrew?

Yes. Both are right-to-left languages that share the same underlying CSS and layout considerations, though bidirectional text handling (Arabic numerals inside RTL Arabic text, for example) has its own edge cases worth testing separately.

Building RTL Websites with AI Coding Tools

AI coding tools default to left-to-right assumptions unless told otherwise, and RTL bugs are easy to miss in a code diff but obvious the moment a Hebrew or Arabic reader opens the page. This guide covers the direction, logical-property, and verification rules that keep an AI-assisted RTL build from shipping broken.