PromptCast بدأت عشان كنت عايز سطح المكتب يظهر مقروء صح في مراية التيليبرومتر. الفكرة كبرت وبقت بث من Windows لـ Android، مع تحكم باللمس، وصوت، وإملاء. AI coding agent كتب الكود، وأنا وجّهت الشغل واختبرته على أجهزتي.
الفيديو ممكن يشتغل والميكروفون يطقطق أو Windows Explorer يكراش. حكيت عن المشكلتين في مقالة المشروع. حلول شكلها منطقي كانت بتفوّت السبب. طلبت تسجيل للموجة الصوتية عشان نفحص الطقطقة، وlogging يورّينا اللي حصل قبل ما Explorer يقع.
الأعطال دي غيّرت اللي محتاج أختبره. بث الفيديو كان كفاية أعرض بيه الفكرة. عشان أفضل أستخدمها على جهازي، كان لازم الصوت والتحكم يشتغلوا كويس كمان. أي مشكلة هنسيبها، أنا اللي هعيش معاها.
بحب أوصل لنموذج شغّال وأنا لسه مهتم بالفكرة. PromptCast خلّتني أفكّر كمان في الشغل اللي هتحمّله لو قررت أكمل.
نحدد التجربة هتجاوب على إيه#
قبل ما أبني نموذج أولي، بحب أحدد إيه اللي متوقع أتعلمه. اختبار لو طريقة التفاعل مفهومة ممكن يحتاج شاشة مقنعة من غير backend حقيقي. واختبار إمكانية تنفيذ حل تقني ممكن يحتاج تنفيذ شكله وحش، بس قياسه دقيق. وساعات ببني أداة لنفسي، والتعلّم منها يبقى سبب كفاية إني أكمل.
نطاق التجربة المفروض يتحدد على أساس غرضها. غير كده، كل خاصية سهلة الإضافة بتبقى خاصية كمان محتاجة تقييم. والنموذج الأولي يكتسب بالتدريج التزامات منتج، من غير ما حد يقرر إنه هيدعمه.
بفكر كمان في أداة موجودة، أو تعديل أصغر، أو إني أسيب المشكلة دلوقتي. سرعة البناء بتضيف اختيار؛ ولسه محتاج أقارنه بالاختيارات دي.
نخلي قرار التوقف متاح#
النموذج الأولي المتظبّط بيشجّع على الاستمرار. فيه حاجة موجودة نقدر نعرضها، والتحسين اللي بعدها قريب.
بحاول أقيّم استثمار وقت ومجهود أكتر على أساس المشكلة اللي المشروع بيحلها، والناس اللي هتستفيد، وتكلفة دعمه. الديمو دليل ضمن القرار ده. والاقتراح المكتوب بوضوح يستحق يتقيّم على نفس الأساس، حتى لو لسه ما اتبناش.
النموذج الأولي ممكن ينجح في مهمته لما يورّينا إن الفكرة صعبة الاستخدام، أو صيانتها مكلفة، أو فائدتها أقل من المتوقع. التوقف عند النقطة دي نتيجة عايز التجربة تسيبها متاحة.
نسهّل التغيير اللي بعده#
لما أقرر أكمل في مشروع، محتاج أقدر أفهمه وأغيّره بعدين، حتى لو النسخة الأولى ما أخدتش مجهود كبير.
الـ version control بيسمح لي أراجع التعديلات وأقارنها بنسخ أقدم أو أرجع لها. ده مفيد لما AI agent يعدّل حاجات كتير مرة واحدة. مقدمة كتاب Git بتشرح فايدة السجل ده.
النسخة الجديدة من المشروع محتاجة كمان خطوات موثّقة لتجهيز بيئة شغّالة. في مشروع Node، حفظ الـ lockfile في Git واستخدام npm ci بيساعدوا إن تثبيت الاعتماديات يبقى متسق. الأمر بيرفض لو بيانات الحزم والـ lockfile مش متوافقين، بدل ما يعدّل الـ lockfile من نفسه. إعادة تجهيز البيئة بتعتمد كمان على نسخة بيئة التشغيل، والإعدادات، والخدمات التانية اللي التطبيق محتاجها. توثيق npm بيشرح سلوك التثبيت هنا.
باقي الشغل بيعتمد على مين بيستخدم المنتج. محتاج أحدد إيه الأعطال اللي تستحق اختبارات، وبيانات الدخول تتحفظ فين، وإزاي أنشر تغيير وأتعافى لو حاجة باظت. أداة بستخدمها لوحدي وخدمة ناس تانية معتمدة عليها محتاجين درجات مختلفة من الاستعداد.
عايز أجرّب الخطوات دي: أجهّز المشروع من جديد، وأغيّره، وأكتشف عطل له معنى، وأتعافى من إصدار فيه مشكلة. لو علّمت على بنود في قائمة من غير ما أجرّبها، هفضل مش عارف لو بتشتغل فعلًا.