كونك مهندس برمجياتٍ جيدًا لا يعني فقط كتابة كودٍ يعمل. بل يعني كتابة كودٍ يستطيع الآخرون (بمن فيهم أنت في المستقبل) فهمه وصيانته والبناء عليه. كما يعني التواصل بوضوحٍ، والمساهمة بتفكيرٍ، وأن تكون مواطنًا صالحًا في النظم البيئية التي تشارك فيها — سواءً كانت مفتوحة المصدر أو مغلقة.

التواصل أحادي الاتجاه

يتضمن جزءٌ كبيرٌ من هندسة البرمجيات الكتابة لأشخاصٍ يفتقرون إلى سياقك الحالي: زملاء ينضمون لاحقًا، ومشرفون (maintainers) يرثون كودك، أو أنت بعد ستة أشهر عندما تكون قد نسيت سبب اتخاذك قرارًا معيّنًا. نصيحةٌ أساسيةٌ لكل هذا النوع من الكتابة هي أن هدفك هو التقاط اللماذا (the why) ونقله، وليس فقط الـماذا (the what). فالـماذا يميل إلى أن يكون واضحًا بذاته، بينما اللماذا معرفةٌ مكتسبةٌ بصعوبةٍ تضيع بسهولةٍ مع مرور الوقت.

ربما يكون أكثر أشكال التواصل بين المهندسين شيوعًا (بعيدًا عن الكود نفسه) هو تعليقات الكود (code comments). وجدتُ شخصيًا أن الكثير من تعليقات الكود عديمة الفائدة. لكن لا يجب أن تكون كذلك! التعليقات الجيدة تشرح أشياءً لا يستطيع الكود نفسه شرحها: لماذا يُفعل شيءٌ ما بطريقةٍ معينة، وليس كيف يعمل (وهذا ما يعرضه الكود). يمكنها توفير ساعاتٍ من الحيرة، بينما تضيف التعليقات السيئة ضجيجًا أو، الأسوأ، تضلل.

أنواع التعليقات التي تكاد تكون دائمًا جديرةً بالاهتمام:

• مهام مستقبلية (TODOs): حدّد الكود غير المكتمل أو غير المصقول، لكن اترك سياقًا كافيًا ليفهم شخصٌ آخر ما المتبقي ولماذا أُجّل. "TODO: optimize" بلا فائدة؛ أما "TODO: هذه الحلقة O(n²) مناسبةٌ للقيم n<100، لكنها ستحتاج إلى فهرسةٍ إذا توسعنا" فقابلةٌ للتنفيذ.
• المراجع (References): اربط بالمصادر الخارجية عندما ينفّذ الكود خوارزميةً من ورقةٍ بحثية، أو يقتبس كودًا من مكانٍ آخر، أو يرمز سلوكًا محددًا في وثائقٍ. استخدم روابط دائمة (permalinks). ولاحظ أي انحرافاتٍ عن المرجع.
• حجج الصحة (Correctness arguments): اشرح لماذا ينتج الكود غير البديهي نتائجَ صحيحة. يعرض الكود الخطوات؛ والتعليق يشرح لماذا تعمل تلك الخطوات.
• الدروس المكتسبة بصعوبة (Hard-learned lessons): إذا أمضيت 30+ دقيقةً في تصفية خطأٍ ما وكان الإصلاح عبارةً عن طقوسٍ غير واضحةٍ (incantation)، فوثّقه. ذاتك السابقة لم تدرك أنه ضروري؛ ولن يدرك ذلك قراء المستقبل أيضًا.
• مبرر الثوابت (Rationale for constants): الأرقام السحرية تستحق تفسيرًا. لماذا 1492؟ لماذا 16 بت؟ هل اختيرت عشوائيًا، أو اشتُقت من الاختبار، أو كانت مطلوبةً للصحة؟ حتى عبارة "اختيرت بشكلٍ تعسفي" معلومةٌ مفيدة.
• الاختيارات الحاملة للوزن (Load-bearing choices): إذا كانت الصحة تعتمد على تفصيلة تنفيذٍ تبدو بريئةً (مثل: "يجب أن تكون BTreeSet لأن ترتيب التكرار مهمٌّ أدناه")، فنادِ بها صراحةً.
• "لماذا لا" (Why nots): عندما تتجنب عمدًا المنهج الواضح، اشرح السبب. وإلا فسوف "يصلحها" شخصٌ آخر لاحقًا ويكسر الأشياء.

ملفات README (لديك واحدة، أليس كذلك؟) هي أيضًا نقطة تواصلٍ أولى شائعةٌ مع المطورين الآخرين. الجيد منها يجيب على أربعة أسئلةٍ فورًا: ماذا يفعل هذا؟ لماذا يجب أن أهتم؟ كيف أستخدمه؟ كيف أثبّته؟ وبهذا الترتيب. نظّمه كقمعٍ (funnel): سطرٌ واحدٌ وربما عرضٌ مرئيٌّ في الأعلى ليتمكن شخصٌ ما من اتخاذ القرار في ثوانٍ عما إذا كان هذا يحل مشكلته، ثم أضف العمق تدريجيًا. اعرض الاستخدام قبل التثبيت — يريد الناس رؤية ما سيحصلون عليه قبل الالتزام بخطوات الإعداد.

رسائل الالتزام (commit messages) نوعٌ آخر من "الكتابة للآخرين" الذي يُهمَل كثيرًا. كثيرًا ما تُكتب بصيغة "أصلحت كذا" أو "أضفت كذا"، ورغم أن ذلك قد يكون كافيًا في بعض الحالات، فمن السهل أن تنسى أنها تشكل السجل التاريخي لـ_لماذا_ تطورت قاعدة الكود بالطريقة التي تطورت بها. عندما يشغّل شخصٌ ما (بمن فيك أنت!) الأمر git blame محاولًا فهم تغييرٍ محير، يجب أن تمنحه رسائل الالتزام الجيدة الإجابات.

بشكلٍ عام، يجب أن يجيب النص على:

• ما المشكلة التي فرضت هذا التغيير؟
• ما البدائل التي نظرت فيها؟
• ما المقايضات أو الآثار المترتبة؟
• ما الذي قد يكون مفاجئًا في هذا النهج؟

من الواضح أنه يجب عليك قياس التفاصيل حسب التعقيد. إصلاح خطأٍ مطبعيٍّ بسطرٍ واحدٍ يحتاج إلى سطر موضوعٍ فقط. أما إصلاح حالة سباقٍ خفيةٍ استغرق ساعاتٍ في التصفية فيستحق فقراتٍ تشرح المشكلة والحل.

بالنسبة للتغييرات المعقدة، قد يكون من المفيد اتباع بنية مشكلة (Problem) → حل (Solution) → آثار (Implications): ابدأ بالسبب المُلزم أو القيد، ثم اشرح ما تغيّر وقرارات التصميم الأساسية، ثم ادرج العواقب الجديرة بالملاحظة (الإيجابية والسلبية). ذلك الجزء الأخير مهمٌّ بشكلٍ خاص؛ الهندسة الحقيقية تتضمن موازنة الاعتبارات، وتوثيق أن مقايضةً ما كانت مقصودةً يمنع المطورين المستقبليين من الاعتقاد أنك غفلت عن المشكلة.

يمكن لنماذج اللغة الكبيرة أن تكون مفيدةً في كتابة رسائل الالتزام. مع ذلك، إذا أشرتَ ببساطةٍ إلى تغييرك وطلبتَ منها كتابة رسالة الالتزام للتغيير، فلن يكون لدى نموذج اللغة الكبيرة سوى الوصول إلى الـماذا، وليس اللماذا. وستكون رسالة الالتزام الناتجة إذًا وصفيةً في معظمها (عكس ما نريده تمامًا!). إذا كنت قد استخدمت نموذج لغةٍ كبيرةٍ لمساعدتك في إجراء التغيير في المقام الأول، فإن مطالبة النموذج بكتابة الالتزام في الجلسة نفسها يمكن أن تكون خيارًا أفضل بكثير، لأن محادثتك مع النموذج تعد بطبيعتها مصدرًا غنيًا بالسياق حول التغيير! وإلا، أو بالإضافة إلى ذلك، هناك حيلةٌ مفيدةٌ تتمثل في إخبار النموذج صراحةً أنك تود رسالة التزامٍ تركّز على "اللماذا" (وفروقٍ دقيقةٍ أخرى من الملاحظات أعلاه)، ثم اطلب منه الاستفسار منك عن السياق المفقود. بشكلٍ أساسي، أنت تتصرف كـ"أداة" MCP لوكيل البرمجة يستطيع استخدامها "لقراءة" السياق.

مع زيادة تعقيد تغييراتك، تأكد أيضًا من تقسيم الالتزامات منطقيًا (git add -p صديقك). يجب أن يمثل كل التزامٍ تغييرًا واحدًا متماسكًا يمكن فهمه ومراجعته بشكلٍ مستقل. لا تخلط إعادة الهيكلة مع الميزات الجديدة، ولا تجمع إصلاحات أخطاءٍ غير مرتبطة، لأن هذا يكدّر سردية أي تغييرٍ أصلح أي مشكلة، وسيؤدي شبه المؤكد إلى إبطاء المراجعة النهائية لتغييراتك. كما يمنحك قدراتٍ خارقةً عبر git bisect، لكن تلك قصةٌ لوقتٍ آخر.

ملاحظةٌ واحدةٌ عندما تبدأ في أن تصبح أكثر جديةً في الكتابة التقنية، واستخدامها بشكلٍ أوسع: تأكد من احترام القارئ. من السهل أن ينتهي بك الأمر إلى الإفراط في الشرح بمجرد أن تبدأ، لكن عليك مقاومة هذا الدافع، وإلا فلن يقرأ القارئ شيئًا مما كتبته. اشرح "اللماذا" وثق بهم لاستنتاج "الكيف" لموقفهم.

التعاون

كمهندسين، قد نقضي جزءًا كبيرًا من عملنا في البرمجة أمام لوحة المفاتيح الخاصة بنا، لكن جزءًا لا بأس به من وقتنا يشغله أيضًا التواصل مع الآخرين. ينقسم هذا الوقت عادةً إلى تعاونٍ وتثقيف، والعائد من الاستثمار في تحسين كلٍّ منهما كبيرٌ.

المساهمة

سواءً كنت تقدم تقرير خطأٍ (bug report)، أو تساهم بإصلاح خطأٍ بسيط، أو تنفّذ ميزةً ضخمة، فمن الجدير أن تضع في اعتبارك أن عدد المستخدمين عادةً ما يفوق عدد المساهمين بعدة مراتب من حيث الحجم، وعدد المساهمين يفوق عدد المشرفين بمرتبةٍ من حيث الحجم. نتيجةً لذلك، فإن وقت المشرف مطالبٌ به بشدةٍ. إذا كنت تريد زيادة احتمال أن تذهب مساهمتك في اتجاهٍ مثمر، فيجب عليك التأكد من أن مساهماتك تحمل نسبة إشارةٍ إلى ضجيجٍ عاليةً وأنها تستحق وقت المشرفين.

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

• البيئة (Environment): نظام التشغيل، وأرقام الإصدارات، والإعدادات ذات الصلة
• ما توقعته مقابل ما حدث فعلًا
• خطوات إعادة الإنتاج: كن محددًا. "اضغط على الزر" أقل فائدةً من "اضغط على زر الإرسال (Submit) في صفحة /settings بينما تكون مسجّل الدخول كمدير."
• ما جرّبته بالفعل: هذا يمنع الاقتراحات المكررة ويُظهر أنك أجريت بعض التحقيق

إذا وجدت ثغرةً أمنية، فلا تنشرها علنًا. تواصل مع المشرفين على انفرادٍ أولًا وامنحهم وقتًا معقولًا لإصلاحها قبل الإفصاح. لدى العديد من المشاريع ملف SECURITY.md أو ما شابه لهذا الغرض.

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

الأمثلة المصغّرة القابلة لإعادة الإنتاج (minimal reproducible examples) ذهبٌ، إذا استطعت ابتكار واحدة. فهي توفر على المشرف قدرًا هائلًا من الوقت والجهد، وإعادة إنتاج الخطأ بشكلٍ موثوقٍ غالبًا ما تكون أصعب جزءٍ في إصلاحه. ناهيك عن أن الجهد الذي تبذله في عزل المشكلة يساعدك غالبًا على فهمها بشكلٍ أفضل، ويقودك أحيانًا إلى اكتشاف إصلاحٍ بنفسك.

إذا لم تسمع ردًا فورًا، فضع في اعتبارك أن المشرفين غالبًا ما يكونون متطوعين ذوي وقتٍ محدود. إذا كنت تنتظر ردهم، فالمتابعة المهذبة بعد أسبوعين جيدةٌ؛ أما التنبيهات اليومية فليست كذلك. وبالمثل، فإن تعليقات "أنا أيضًا" (me too)، أو تقارير الأخطاء التي هي مجرد نسخٍ ولصقٍ لبعض مخرجات الطرفية، تميل إلى أن تكون سلبيةً صافيةً من حيث جذب الانتباه إلى مشكلتك.

إذا كنت تبحث عن تقديم مساهمةٍ برمجية، فستريد أيضًا أن تتعرف على إرشادات المساهمة. لدى العديد من المشاريع ملف CONTRIBUTING.md — اتبعه. كما ستريد عادةً أن تبدأ صغيرًا؛ إصلاح خطأٍ مطبعيٍّ أو تحسين توثيقٍ يعد مساهمةً أولى رائعةً لأنه يساعدك على تعلم عمليات المشروع دون الاضطرار أيضًا إلى المرور بكمّ كبيرٍ من الذهاب والإياب حول المحتوى.

تحقق من الترخيص الذي يستخدمه المشروع، لأن أي كودٍ تساهم به سيخضع لنفس الترخيص. على وجه الخصوص، انتبه لتراخيص الحقوق المتروكة (copyleft) (مثل GPL)، التي تتطلب أن تكون المشتقات مفتوحة المصدر أيضًا وقد يكون لها آثارٌ على صاحب عملك إذا تعاملت معها! يحتوي choosealicense.com على معلوماتٍ أكثر فائدة.

عندما تقرر فتح طلب سحب ("PR")، تأكد أولًا من عزل التغيير الذي تريد فعلًا أن يُقبل. إذا غيّر طلب السحب الخاص بك الكثير من الأشياء غير المرتبطة في الوقت نفسه، فمن المرجح أن يعيده المراجع إليك طالبًا تنظيفه. هذا مشابهٌ لكيفية تقسيم التزامات git إلى مجموعاتٍ ذات دلالةٍ منطقية.

في بعض الحالات، إذا كانت لديك تغييراتٌ كثيرةٌ تبدو متباينةً لكنها كلها مطلوبةٌ لتمكين ميزةٍ واحدة، فقد يكون من المقبول فتح طلب سحبٍ أكبر يلتقط كل التغييرات. مع ذلك، في هذه الحالة، تكون نظافة الالتزامات مهمةً بشكلٍ خاص حتى تتاح للمشرفين خيار مراجعة التغيير "التزامًا بالتزامٍ".

بعد ذلك، تأكد من شرح "اللماذا" وراء التغيير جيدًا. لا تصف فقط ما تغيّر — اشرح لماذا هناك حاجةٌ إلى التغيير و_لماذا_ هذه طريقةٌ جيدةٌ لمعالجة المشكلة. يجب عليك أيضًا أن تنادي بشكلٍ استباقيٍّ على أجزاء التغيير التي تستحق اهتمامًا خاصًا في المراجعة، إن وجدت. اعتمادًا على CONTRIBUTING.md وطبيعة تغييرك، قد يتوقع المراجعون رؤية معلوماتٍ إضافيةٍ مثل المقايضات التي قمت بها أو كيفية اختبار التغيير.

نوصي بالمساهمة مرةً أخرى في المشاريع المنبع (upstream) بدلًا من "تفرّع" (forking) المشروع، على الأقل كمنهجٍ أول. يجب حجز التفرّع (عندما يسمح الترخيص) للحالات التي تكون فيها المساهمات التي تريد تقديمها خارج نطاق المشروع الأصلي. إذا قمت بالتفرّع، فتأكد من الإقرار بالمشروع الأصلي!

يجعل الذكاء الاصطناعي توليد كودٍ وطلبات سحبٍ تبدو قابلةً للتصديق بشكلٍ سهلٍ لا يُصدَّق وبسرعةٍ، لكن هذا لا يعفيك من فهم ما تساهم به. إرسال كودٍ مولّدٍ بالذكاء الاصطناعي لا يمكنك شرحه يثقل كاهل المشرفين بمراجعة كودٍ وربما صيانته حتى مؤلفه لا يفهمه. لا بأس في استخدام الذكاء الاصطناعي لمساعدتك في تحديد المشكلات وإنتاج إصلاحات/ميزات، ما دمت لا تزال تقوم بالعناية الواجبة لصقله إلى مساهمةٍ جديرةٍ، بدلًا من تمرير ذلك العمل إلى المشرفين (المثقلين أصلًا).

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

عند تلقي ملاحظاتٍ على طلب سحبٍ، تذكر أن كودك ليس أنت! المراجعون يحاولون جعل الكود أفضل، ولا ينتقدونك شخصيًا. اطرح أسئلةً توضيحيةً إذا كنت لا توافق — قد تتعلم شيئًا، أو ربما يتعلمون هم.

المراجعة

قد تعتقد أن مراجعة الكود شيءٌ يفعله المطورون الكبار، لكن من المحتمل أن يُطلب منك مراجعة كودٍ في وقتٍ أبكر بكثير مما تتوقع، ورأيك قيّم. فالعيون الجديدة تلتقط الأشياء التي يتجاهلها المطورون ذوو الخبرة، والأسئلة من شخصٍ أقل إلمامًا بالكود تكشف غالبًا افتراضاتٍ ينبغي توثيقها أو تبسيطها.

المراجعة أيضًا من أسرع طرق التعلّم. سترى كيف يتعامل الآخرون مع المشكلات، وتلتقط الأنماط والتعابير الاصطلاحية (idioms)، وتطوّر حدسًا حول ما يجعل الكود قابلاً للقراءة. بعيدًا عن النمو الشخصي، تلتقط المراجعات الأخطاء قبل وصولها إلى الإنتاج، وتنشر المعرفة عبر الفريق، وتحسّن جودة الكود من خلال التعاون. إنها ليست مجرد عبءٍ إداريٍّ بيروقراطي.

مراجعة الكود الجيدة مهارةٌ تحتاج إلى صقلها بمرور الوقت، لكن هناك بعض النصائح التي يمكنها جعلها أفضل بكثير وبشكلٍ أسرع:

• راجع الكود، لا الشخص: "هذه الدالة محيرة" مقابل "كتبت كودًا محيرًا."
• فضّل التعليقات القابلة للتنفيذ: "هل يمكنك استبدال هذه المتغيرات العامة بفئة إعداداتٍ (config dataclass)؟" تعليقٌ أسهل في المعالجة من "لا تستخدم متغيراتٍ عامة هنا"
• اطرح أسئلةً بدلًا من إصدار المطالب: "ماذا يحدث إذا كانت X فارغةً هنا؟" يدعو للنقاش بشكلٍ أفضل من "عالج حالة الفراغ."
• اشرح "اللماذا": "فكّر في استخدام ثابتٍ هنا" أقل فائدةً من "فكّر في استخدام ثابتٍ هنا حتى نتمكن من ضبط المهلة بسهولةٍ بناءً على البيئة."
• ميِّز المشكلات المانعة عن الاقتراحات: كن واضحًا بشأن ما يجب أن يتغير مقابل ما هو مسألة تفضيل.
• أقر بما هو جيد: الإشارة إلى الحلول الذكية أو التنفيذات النظيفة مشجّعةٌ وتُعلم المؤلف بما يستحق مواصلته.
• اعرف متى تتوقف: لا يملك المساهمون سوى قدرٍ معينٍ من الوقت والصبر، وليس من الأفضل دائمًا إنفاقه في معالجة كل الملاحظات الصغيرة (nits). ركّز على الأمور الكبيرة، وفكّر في ترتيب الملاحظات الصغيرة بنفسك بعد ذلك.

يمكن للأدوات الذكية التقاط بعض المشكلات، لكنها ليست بديلًا عن المراجعة البشرية. فهي تفتقد السياق، ولا تفهم متطلبات المنتج، وقد تقترح أشياءَ خاطئةً بثقةٍ. من الجدير استخدامها كمراجعةٍ أولية (first pass)، لكنها ليست بديلًا عن المراجعة البشرية المدروسة.

التثقيف

يقضي الكثير من وقتنا خارج البرمجة كمهندسين في طرح الأسئلة أو الإجابة عنها، وربما مزيجٍ من الاثنين؛ أثناء التعاون، أو في حوارٍ مع الزملاء، أو أثناء محاولة التعلّم. طرح الأسئلة الجيدة مهارةٌ تجعلك أفضل في التعلّم من أي شخص، وليس فقط من الشرّاح المثاليين. لدى جوليا إيفانز (Julia Evans) بعض التدوينات الممتازة حول "كيف تطرح أسئلةً جيدة" و"كيف تحصل على إجاباتٍ مفيدةٍ لأسئلتك" تستحق القراءة.

بعض النصائح القيّمة بشكلٍ خاصٍّ هي:

• اذكر فهمك أولًا: قل ما تعتقد أنك تعرفه واسأل "هل هذا صحيح؟" وهذا يساعد المجيب على تحديد الفجوات الفعلية في معرفتك.
• اطرح أسئلةً بنعم/لا: "هل X صحيحة؟" تمنع الشروحات الجانبية وعادةً ما تحفّز توضيحًا مفيدًا على أي حال.
• كن محددًا: "كيف تعمل عمليات الربط (joins) في SQL؟" غامضةٌ جدًا. "هل يتضمن LEFT JOIN الصفوفَ التي لا يوجد لها تطابقٌ في الجدول الأيمن؟" قابلةٌ للإجابة.
• اعترف عندما لا تفهم: قاطع واسأل عن المصطلحات غير المألوفة. هذا يعكس الثقة، لا الضعف. وبالمثل، إذا طرحوا عليك أسئلةً لا تعرف إجابتها، فمن الأفضل أن تقول "لا أعرف"، وربما تتابع بـ"لكنني أعتقد ..." أو حتى "لكنني أستطيع معرفة ذلك".
• لا تقبل الإجابات الناقصة: واصل طرح الأسئلة المتابِعة حتى تفهم فعلًا.
• قم ببعض البحث أولًا: التحقيق الأساسي يساعدك على طرح أسئلةٍ أكثر استهدافًا (رغم أن الأسئلة العابرة بين الزملاء جيدةٌ).

تذكر: الأسئلة المصاغة جيدًا تفيد المجتمعات بأكملها. فهي تُبرز الافتراضات الخفية التي يحتاج الآخرون أيضًا إلى فهمها.

لاحظ أن هذه النصيحة تنطبق أيضًا تمامًا عند التواصل مع نماذج اللغة الكبيرة!

آداب الذكاء الاصطناعي

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

أولها أنه عندما يساهم الذكاء الاصطناعي بشكلٍ ذي معنى في عملك، اكشف عن ذلك (disclose). هذا ليس عن الخجل — بل عن الصدق، وتحديد التوقعات المناسبة، وضمان حصول العمل الناتج على المستوى المناسب من المراجعة. ومن الجدير أيضًا الكشف عن الأجزاء التي تستخدم الذكاء الاصطناعي فيها — فهناك فرقٌ ذو معنى بين "هذا الشيء بأكمله مبنيٌّ بأسلوب الـvibecoding" و"كتبت أداة النسخ الاحتياطي هذه واستخدمت نموذج لغةٍ كبيرةٍ لتنسيق واجهة الويب الأمامية". على سبيل المثال، استخدمنا نماذج اللغة الكبيرة للمساعدة في كتابة بعض ملاحظات هذه المحاضرات، بما في ذلك التدقيق اللغوي، والعصف الذهني، وتوليد مسوداتٍ أولى لمقاطع الكود والتمارين.

ستريد أيضًا اتباع أعراف الفرق والمشاريع التي تساهم فيها. لدى بعض الفرق سياساتٌ أكثر صرامةً حول استخدام الذكاء الاصطناعي من غيرها (مثلًا، لأسباب الامتثال أو إقامة البيانات (data residency))، ولا تريد أن تصادفك تلك السياسات عن طريق الخطأ. كونك منفتحًا بشأن استخدامك يساعد على منع أخطاء قد تكون مكلفة.

إذا كنت تهدف إلى التعلّم كجزءٍ من العمل الذي تقوم به، ضع في اعتبارك أن جعل الذكاء الاصطناعي يقوم بكل العمل أو معظمه من أجلك قد يكون هزيمةً ذاتيةً؛ فمن المرجح أن تتعلم المزيد عن المطالبة (وربما مراجعة مخرجات الذكاء الاصطناعي) أكثر من تعلمك للمهمة نفسها. خاصةً عندما تتعلم، قد يكون الهدف هو الرحلة، لا الوجهة، لذا فإن استخدام الذكاء الاصطناعي "للحصول على الحل بسرعة" هو هدفٌ مضادّ.

مشكلةٌ ذات صلةٍ تظهر في المقابلات ومواقف التقييم الأخرى. هذه عادةً ما تكون مصممةً خصيصًا لتقييم مهاراتك وقدراتك، وليس مهارات نموذج لغةٍ كبيرةٍ. المزيد من الشركات تسمح الآن لك باستخدام نماذج اللغة الكبيرة والأدوات المدعومة بالذكاء الاصطناعي في المقابلات طالما تتيح لهم ملاحظة تلك التفاعلات كجزءٍ من المقابلة (أي أنهم يقيّمون مهارتك في استخدام تلك الأدوات أيضًا!)، لكنها ما تزال الأقلية. إذا لم تكن متأكدًا مما إذا كانت المساعدة الذكية ضمن نطاق مهمةٍ معينة، فاسأل!

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