VOL99: Harness Engineering 🚀

مبدأ الـ Harness Engineering هو التحول الجديد في Software Engineering مع AI Coding Agents؛ حيث ينتقل دور المهندس من كتابة الكود يدويًا إلى بناء البيئة، القيود، والـ guardrails التي تجعل الـ AI يكتب So

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

---

أهلًا وسهلا بكم في العدد التاسع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

---

Harness Engineering

في سنة 1973، شركة General Dynamics طلّعت prototype لطائرة مقاتلة جديدة اسمها YF-16. من برّه، الطيارة كانت شكلها عادي بالنسبة لمقاتلة حديثة: جناحات حادة، engine قوي، وتصميم كله سرعة ومناورة.

بس الحقيقة إن الطيارة دي كان جواها سر غريب جدًا: هي كانت متصممة بطريقة تخلي الإنسان مستحيل تقريبًا يطيرها لوحده.

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

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

فالمهندسين عملوا حاجة جريئة جدًا: حطّوا Computer بين الطيار والطيارة.

لما الطيار يحرك عصاية القيادة، هو في الحقيقة مش بيحرك الجناح مباشرة. هو بيبعت request للـ Computer. والـ Computer هو اللي بيترجم الطلب ده لمجموعة ضخمة من التعديلات الصغيرة في أجزاء من الثانية علشان الطيارة تفضل طايرة بثبات.

في اللحظة دي، دور الطيار اتغير: هو مبقاش الشخص اللي بيتحكم في كل جزء بإيده. ولكن بقى الشخص اللي بيوجّه نظام معقد جدًا.

وده بالضبط اللي بيحصل دلوقتي في مهنة الـ Software Engineering.

---

تجربة OpenAI — خمسة شهور من غير ما إنسان يكتب كود

في تجربة مثيرة، فريق داخلي في OpenAI اشتغل لمدة خمسة شهور على بناء software product حقيقي.

بس كان عندهم شرط واحد غريب: ممنوع أي إنسان يكتب كود بإيده. وكل حاجة تقريبًا اتعملت عن طريق الـ AI Agent Codex.

• البشر كانوا بيشرحوا المطلوب.

• والـ Agent هو اللي يكتب الكود ويشغّل tests ويصلح errors ويكرر المحاولة لحد ما يوصل لنتيجة شغالة.

الموضوع مش معناه إن البشر اختفوا ولكن بالعكس البشر كانوا مهمين جدًا، بس دورهم اتغير.

بدل ما يكتبوا implementation سطر بسطر، بقوا يحددوا الاتجاه، يكتبوا design docs، يحطوا constraints، يراجعوا القرارات، ويبنوا البيئة اللي تخلي الـ AI Agent يعرف يشتغل من غير ما يحوّل المشروع لفوضى.

ووقتها OpenAI سمّت النوع ده من الشغل: Harness Engineering.

---

المشكلة عمرها ما كانت في كتابة الكود

لسنين طويلة فضلنا نتعامل مع كتابة الكود كأنها قلب المهنة.

• المبرمج الشاطر مش بس اللي يكتب بسرعة واللي حافظ syntax ولكن برضو اللي يعرف يبني feature كاملة لوحده وكمان اللي يغوص في الكود ويصلح كل حاجة بإيده.

  بس الحقيقة إن هندسة البرمجيات عمرها ما كانت مجرد typing .. كتابة الكود كانت بس الوسيلة اللي بنعبّر بيها عن قراراتنا. والشغل الحقيقي دايمًا كان في حاجات أدق وأعمق بكتير زي:

• إننا نفهم المشكلة.

• نقسم التعقيد.

• نختار abstraction مناسب.

• نرسم boundaries بين components.

• نوازن بين performance وmaintainability.

• نعرف إمتى نخلي الحل simple وإمتى نستثمر في الـ scalability وإمتى نقول “لا” لفكرة شكلها ذكي بس هتبوّظ النظام بعدين.

  فبشكل تاني إحنا لما بنشوف مهندس برمجة بيكتب كود، احنا مش بنتفرج عله وهوشغال typing ... ولكن احنا بنتفرج على التفكير وهو بيتحوّل لكود.

فلو الـ AI قدر ياخد التفكير ده ويحوّله لكود شغال، يبقى الـ bottleneck الحقيقي مكنش سرعة صوابعنا وهي بتكتب على الكيبورد. الـ bottleneck الحقيقي كان دايمًا وضوح التفكير.

---

Harness Engineering

ببساطة: الـ Harness Engineering هو إننا نبني البيئة اللي تخلي الـ AI Agent يقدر يكتب Software كويس، آمن، مفهوم، وقابل للصيانة.

فالفكرة هنا مش إننا نقول للـ Agent:

“ابني النظام ده” ونسيبه يسرح.

لأن الـ AI Agent سريع جدًا. متحمس جدًا. وبيقدر يطلع آلاف الأسطر في وقت قليل. وطبعًا كل ده من غير حدود، هنلاقي إن السرعة دي بتتحول لفوضى.

هيضيف abstractions مش محتاجينها ، وهيكرر logic في كذا مكان ، وهيكسر architectural boundaries وممكن يبني حاجة شغالة النهارده، بس صعب جدًا تتفهم أو تتعدل بعد شهرين.

علشان كده دورنا في الـ Harness Engineering مش إننا نجري ورا الـ Agent نصلحله كل حاجة بإيدينا ولكن دورنا إننا نبني الطريق ليه من خلال إننا نبني rails ، نحط guardrails ، نكتب docs واضحة ، نحدد rules ، نقوّي الـ tests ونظبط الـ CI ونخلي إمكانية الغلط أصعب، وإنه يطلع المطلوب الصح هو الأسهل.

فبدل ما تسأل نفسك:

“هكتب الكود إزاي؟”

تبدأ تسأل نفسك:

“أبني environment إزاي يخلي الـ Agent يكتب الكود الصح من غير مشاكل؟”

---

الـ Agent محتاج حدود مش حرية مطلقة

لو تخيلنا إن عندنا junior developer سريع جدًا، عنده طاقة رهيبة، وممكن يكتب كود طول اليوم من غير ما يتعب .. ده طبعًا هيكون شيء ممتاز.

بس الحقيقة المرة هي .. إن لو دخل codebase كبيرة من غير onboarding، من غير conventions، من غير architecture واضحة، ومن غير tests محترمة، هيعمل كارثة بسرعة.

الـ AI Agent شبه كده، بس أسرع بكتير .. هو مش محتاج إنك تشرحله كل تفصيلة يدويًا كل مرة ولكن محتاج system يفهمه.

محتاج يعرف:

• يبدأ فين بالظبط؟ وإيه الـ architecture؟ وإيه المسموح والممنوع؟ وإيه الـ naming conventions؟ طب إزاي نكتب tests؟ وإزاي نضيف feature من غير ما نكسر boundaries؟ وإيه الملفات اللي يرجع لها؟ ووإيه الحاجات اللي ممنوع يعملها حتى لو “شكلها” أسهل؟

هنا بقى قيمة الـ Software Engineer بتظهر .. مش في إنه يكتب كل function بإيده ولكن في إنه يبني codebase وworkflow يخلي الـ Agent يعرف يتحرك جواهم بأمان.

---

حكاية الـ Progressive Disclosure — ما ترميش المشروع كله في وش الـ Agent!

من أهم الأفكار في الـ Harness Engineering فكرة اسمها الـ Progressive Disclosure

ودي بكل بساطة يعني ما تديش للـ Agent كل حاجة مرة واحدة ، فما ترميش عليه architecture كاملة، وrequirements ضخمة، و20 ملف docs، وتستنى منه يطلعلك implementation ممتاز.

بدل كده، اديله entry point واضح وصغير مثلاً ملف زي: AGENTS.md الملف ده مش لازم يشرح كل حاجة ولكن هو بس يقول للـ Agent:

• ابدأ من هنا.

• لو بتشتغل على API، اقرأ الملف الفلاني.

• لو بتضيف database migration، اتبع القواعد دي.

• لو بتكتب tests، استخدم pattern ده.

• لو هتغير في module معين، ما تكسرش الحدود دي.

• يعني بدل ما تحط كل الـ Knowledge في prompt واحد ضخم، تبني نظام من docs صغيرة ومترابطة ، فكل layer تكشف اللي بعدها لو احتاجنا ليها وعند الضرورة.

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

---

شكل الشغل بيتغير

في الـ workflow القديم، المهندس يفتح IDE، يقرأ الكود، يكتب implementation، يشغّل tests، يصلح الأخطاء، ويعمل pull request ولكن في الـ workflow الحالي والقائم على مبدأ الـ Harness Engineering، المشهد بيكون مختلف.

المهندس ممكن يكتب task واضحة:

“ضيف user login feature، التزم بالـ existing architecture، اكتب tests، وحدّث docs.”

بعدها الـ Agent يبدأ يشتغل.

يقرأ الملفات ويعمل plan وبعدين يعدل الكود ويشغّل tests ولو حاجة باظت يصلحها ويراجع التغيير واخيرا يفتح pull request.

وهنا الـ Software Engineer دوره مختفاش ولكن بقى شغله في Layer أعلى فبيسأل:

هل الحل ده مناسب ولا لا ؟ هل الـ Agent فهم المشكلة صح؟ هل الـ design ماشي مع الاتجاه اللي عاوزينه؟ هل فيه complexity زيادة؟ هل التغيير ده هيبقى مفهوم بعدين مع الوقت ومع وجود تغييرات؟ هل الـ tests بتثبت السلوك المهم فعلًا ولا مش بتقدم قيمة؟ هل الـ architecture لسه مظبوطة ولا فيه volations؟

وكل دي أسئلة محتاجة مهندس شاطر ويمكن كمان اشطر من الأول .. لأنك دلوقتي مش بس بتكتب كود ولكن أنت بتصمم وبتدير نام يقدر ينتج هو الـ functions دي.

---

لما الـ Agent يغلط، متصلحش الكود بس!

في الطريقة التقليدية، لما bug يظهر، أول حاجة بنعملها إننا نفتح الكود وندور على المشكلة علشان نحلها .. ولكن في الـ Harness Engineering، السؤال الأهم بيبقى:

“ليه النظام سمح للـ Agent يغلط بالطريقة دي؟”

هل الـ docs مش واضحة؟ طب هل الـ tests ضعيفة؟ هل ممكن الـ prompt كان مكتوب بشكل generic زيادة عن اللزوم؟ هل فيه conventions متضاربة؟ هل الـ architecture مكنتش مفهومة وواضحة؟ هل مفيش automated checks تمنع النوع ده من الغلط بعدين؟ وآخيرًا هل الـ codebase نفسها كانت صعبة إن الـ Agent يفهمها بسبب تعقيدها ؟

فالغلط هنا مش بس bug في الكود ولكن ممكن يكون bug في الـ harness نفسه وده فرق كبير جدًا!

فبدل ما نفضل نصلح في نفس المشكلة كل مرة، احنا بنحاول نبني نظام يمنع تكرارها من الأساس.

---

هل ده معناه إن الـ Software Engineer هينتهي؟

بكل تأكيد لأ .. ولكن المهندس اللي قيمته كلها إنه “بيعرف يكتب كود كتير” بس، هيواجه ضغط كبير.

وده جوهر الـ Harness Engineering: الذكاء مبقاش بس في الكود اللي بيتكتب، لكن في البيئة اللي بتخلي الكود يتكتب صح.

الطيار مبقاش بيمسك الجناح بإيده

نرجع تاني لتشبيه الـ F-16 .. الطيار مبقاش متوصل بالجناح بشكل ميكانيكي ، فمش بيحرك كل سطح في الطيارة بنفسه ولكنه برضه مبقاش أقل أهمية .. بل بالعكس هو بقى بيوجّه نظام أعقد وأسرع من قدرة الإنسان.

وده اللي بيحصل بالظبط مع الـ Software Engineers ، إننا ما نكتبش كل سطر بإيدينا مش معناه ابدأ إننا بقينا أقل قيمة ولكن معناه إننا بدأنا نشتغل في layer أعلى محتاجة مهارات ومتطلبات أكتر. وبدل ما نكون منفّذين لكل تفصيلة، هنبقى مصممين النظام اللي بينفذ ده.

---

في الختام

الـ Harness Engineering هو محاولة لوصف تحول حقيقي في طريقة بناء الـ Software مع AI Coding Agents .. زمان، قوة المهندس كانت بتاخد wight كبير في قدرته على كتابة الكود ولكن دلوقتي، القوة بتتحرك تدريجيًا ناحية قدرته على بناء systems تخلي الـ Agents تشتغل بشكل منتج وآمن.

والـ Software Engineering عمرها ما كانت عن سرعة الكتابة ولكن كانت دايمًا عن مهارات التفكير وحل المشاكل.. فكل ما الآلة بقت أقوى في التنفيذ، الإنسان اللي يعرف يحدد الاتجاه، ويبني الحدود، ويفهم الـ trade-offs، هيبقى أهم.

وآه يمكن المستقبل مش محتاج دلوقتي مهندسين يكتبوا كود أكتر .. ولكن محتاج مهندسين بيعرفوا يبنوا الـ harness اللي يخلي الـ AI ينطلق بسرعة وبدون مشاكل … من غير ما يوقع النظام كله!

---

---

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

---

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

---