TidyFactor: مراجعة شاملة لمنظومة جديدة من مهارات وأدوات تطوير البرمجيات بالاعتماد على AI Agents

مقدمة: ما وراء فخ توليد الكود السطحي

ظهرت خلال الفترة الأخيرة مجموعة من المشاريع تحت منظمة GitHub باسم TidyFactor، وهي لا تحاول تقديم Framework جديد بالمعنى التقليدي، وإنما تتبنى اتجاهًا مختلفًا نسبيًا: بناء Skills وWorkflows وArchitectural Knowledge مخصصة لوكلاء البرمجة بالذكاء الاصطناعي (AI Coding Agents).

الفكرة الأساسية أن المشكلة في تطوير البرمجيات باستخدام الذكاء الاصطناعي ليست دائمًا قدرة النموذج على كتابة الكود، بل قدرته على العمل داخل سياق هندسي محدد، وفهم الـ architecture، والالتزام بقواعد المشروع، وتنفيذ العمل بطريقة قابلة للتكرار والتحقق.

لذلك تقدم TidyFactor مجموعة من المسارات المتخصصة مثل: Design، Styler، Cinematic، HTML، HTMX، Vanilla JS، PHP، Next.js، Documentation، و Marketing. وتصف المنظمة نفسها بأنها منظومة لـ AI-Native Web Architecture, Design Systems & Agent Skills.

وهنا تكمن أهمية المشروع: هو ليس محاولة أخرى لصنع "AI coding assistant"، وإنما محاولة لصنع طبقة معرفة وسلوك فوق الـ coding agent نفسه.

أولًا: ما المشكلة التي تحاول TidyFactor حلها؟

الطريقة التقليدية لاستخدام AI في البرمجة غالبًا تبدو هكذا:

Developer  ──►  Prompt  ──►  AI Model  ──►  Generated Code

وهذه الطريقة تعمل جيدًا في المهام المعزولة أو التمارين السريعة. لكن عندما ندخل في مشروع إنتاجي حقيقي، تصطدم النماذج بواقع معقد:

• Existing Codebase Architecture
• Business Rules & Domain Invariants
• Design System & Token Hierarchy
• Legacy Decisions & Technical Debt
• Security Constraints & Threat Boundaries
• Performance Requirements (TTFB, Core Web Vitals)
• Localization & RTL Subtleties
• Deployment & Operational Environments

المطور في هذه البيئة لا يحتاج فقط إلى نموذج "يعرف" PHP أو React؛ بل يحتاج إلى Agent يدرك بدقة كيف يتصرف داخل هذا النوع من المشاريع.

وهنا يأتي مفهوم الـ Skill. فبدلاً من تضخيم الـ System Prompt بنصوص هائلة تدعي الشمولية، تقسم TidyFactor المعرفة إلى وحدات مستقلة يتم تحميلها تدريجيًا حسب المهمة، وهو ما يُعرف بـ Context-Efficient Architecture و Progressive Disclosure؛ حيث يظل مدخل الـ Skill صغيرًا (Dispatcher بحجم ~350 token)، ثم يتم استدعاء الذاكرة المتخصصة عند الحاجة الحتمية.

ثانيًا: الصورة الكاملة للمنظومة والـ Frontend Triad

تتوزع منظومة TidyFactor عبر أربع مجموعات وظيفية متكاملة:

TidyFactor
├── Design Layer
│   ├── Cinematic (Scroll-Driven Luxury Experience)
│   ├── Design (Code-Native UI Lifecycle)
│   └── Styler (Production In-Place Refactoring)
├── Development Tracks
│   ├── HTML (Semantic Static 0$ Edge Hosting)
│   ├── HTMX (Server-Driven Hypermedia)
│   ├── Vanilla JS (Framework-Free Web Components SPA)
│   ├── PHP (Flight + Medoo + Plates Modular Monolith)
│   └── Next.js (Strict Multi-Tenant Postgres RLS)
├── Documentation
│   └── Doc (AST Codebase Interviewing & Docsify)
└── Growth & Strategy
    └── Marketing (7 Pillars & 28 Direct-Response Capabilities)

ومن أعمق المفاهيم المعمارية في المنظومة هو Frontend Triad:

• Cinematic ──► Experience ──► "Wow": لصناعة التجربة البصرية والسردية الفاخرة لصفحات الهبوط.
• Design ──► Prototype ──► "Build": لبناء النماذج التفاعلية بالكود الأصيل والتوكنز دون الاعتماد على فيجما.
• Styler ──► Production ──► "Ship": للعمل الجراحي داخل واجهات موجودة بالفعل في الإنتاج دون كسر القواعد القائمة.

ثالثًا: التحليل النقدي للمسارات والـ Skills

1. TidyFactor Styler (التقييم: 9.5/10)

يمثل Styler أحد أكثر مسارات المنظومة نضجاً وقيمة عملية، لأنه يعالج المشكلة الأصعب في هندسة الـ Frontend: «خذ هذا المشروع القديم، وحسّن الواجهة دون أن تكسر أي شيء». وبدلاً من توليد CSS عشوائي، يفرض المهارة فحص القواعد القائمة، احترام الـ Conventions، واستخدام خصائص Logical CSS لضبط الـ RTL بنقاء تام.

2. TidyFactor Doc (التقييم: 9/10)

يعالج Doc معضلة جوهرية في عصر الـ AI: بناء طبقة سياق (Context Layer) مستقاة من الـ AST وتاريخ الـ Git بدلاً من توليد توثيق نظري عام. التوثيق هنا ليس مجرد نصوص للمطورين، بل هو بنية ذاكرة موجهة للـ Agent والإنسان معاً.

3. TidyFactor Next (التقييم: 9/10)

مسار ثقيل هندسياً يفرض عزل المستأجرين على مستوى قاعدة البيانات عبر سياسات Postgres Row-Level Security الحتمية، ويتبنى محرك قياسات الأداء (Measure ──► Change ──► Measure ──► Compare) بدلاً من نصائح التحسين العامة.

4. TidyFactor PHP & HTMX (التقييم: 8.5/10)

رأي معماري صريح ومحدد (Opinionated Architecture) يقدم بديلاً سريعاً ومنضبطاً لووردبريس عبر حزمة (Flight + Medoo + Plates) و 13 موديولاً مستقلاً بصفر أدوات بناء، مع تكامل رشيق مع HTMX للتبديل الجزئي عبر Morphdom.

رابعاً: النقد البناء ونقاط التحدي الحقيقية

لكي يكون التقييم موضوعياً ومنصفاً، هناك تحديات جوهرية يجب التعامل معها بوضوح:

1. مرحلة التبني المبكرة (Early Adoption): المنظومة لا تزال حديثة وتحتاج إلى إثبات أثرها عبر مجتمعات المطورين وحالات الاستخدام المستقلة.
2. الادعاءات المعمارية مقابل الأدلة التجريبية: التفريق بين النية المعمارية (Architectural Intent) وبين الإثبات الإحصائي (Empirical Evidence)؛ فاستخدام الـ RLS مبدأ ممتاز، لكن الأمان الفعلي يعتمد على جودة التطبيق والتكوين الشامل.
3. كلفة الـ Opinionation العالية: اختيار مكدس صارم يرفع الاتساق لكنه يقلل المرونة للمشاريع خارج هذا المسار.
4. الحاجة إلى Benchmarks قياسية معلنة: إجراء اختبارات مقارنة حقيقية لنفس المهمة: (بدون Skill مقابل مع Skill) لقياس زمن التنفيذ، استهلاك التوكنز، معدل الانحدار (Regressions)، وجودة الكود الناتج.

الخلاصة والحكم النهائي

القيمة الحقيقية لـ TidyFactor ليست مجرد "مساعدة الذكاء الاصطناعي على كتابة الكود"، بل هي الانتقال من نموذج توليد الكود العشوائي إلى منظومة هندسية محكومة بالسياق والذاكرة والتحقق الصارم:

AI Agent + Domain Skill + Architecture + Workflow + Memory + Validation 
═══════════════════════════════════════════════════════════════════════
                 = More Predictable Engineering Process