Day 4 / 30 — الكود صار رخيص… القرار صار غالي

30 Day Problem Solving

Day 4 / 30

المرحلة الأولى: كيف ترى المشكلة؟

الكود صار رخيص… القرار صار غالي

في شغلة تغيّرت كثير بعد AI. زمان كان أصعب جزء إنك توصل للحل: تدور، تجرب، تقرأ Documentation، تفتح Stack Overflow، تكتب كود، تغلط، وترجع تعيد.

اليوم الحلول صارت تطلع قدامك بثواني. كود، Architecture، Refactor، Tests، Explanation. كل شيء صار أسرع.

بس مع السرعة هاي، ارتفعت قيمة شيء ثاني: القرار.

مين يقرر أي حل يدخل على النظام؟ مين يقرر أي كود يتحمل الواقع؟ مين يشوف الحل ويعرف شو ثمنه بعد 6 أشهر؟

هون يبدأ مستوى جديد من التفكير.

AI كسر ندرة الحلول

قبل AI، كان الوصول للحل يأخذ وقت. تقرأ، تبحث، تجرب، تسأل، وتوصل أحيانًا لحل واحد بعد ساعات. هذا كان يعطي الحل قيمة عالية، لأنه كان نادر.

اليوم الندرة تغيّرت. AI يقدر يعطيك أكثر من حل لنفس المشكلة بنفس اللحظة: حل سريع، حل منظم، حل scalable، حل مبالغ فيه، حل نظيف على الورق، وحل يعيش داخل النظام فعليًا.

وهون صار التحول. المبرمج اليوم يغرق بطريقة جديدة. كثرة الحلول صارت هي الضباب.

وفرة الحلول زادت صعوبة القرار

لما يكون عندك حل واحد، سؤالك الطبيعي يكون: كيف أطبقه؟ لكن لما يكون عندك خمسة حلول، السؤال يصير أثقل:

أي حل يستحق يدخل على النظام؟

هذا السؤال يحتاج عين مختلفة، لأن كل حل من AI يطلع مرتب. الكود واضح، الأسماء جميلة، الشرح مقنع، والنتيجة تشتغل.

بس النظام يعيش على أثر القرار، أكثر من شكل الكود. بعد أول تغيير، بعد أول نمو في البيانات، بعد أول developer جديد يدخل على المشروع، وبعد أول feature تركب فوقه... هون يظهر الفرق بين حل يشتغل، وحل يتحمل.

كل حل هو صفقة

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

AI يعطيك الكود، والثمن يبقى داخل نظامك أنت. أنت اللي رح ترجع للكود بعد أسبوع، وتضيف عليه، وتشرح قراره لشخص ثاني، وتدفع ثمن abstraction مبكر، أو ثمن حل سريع تمدد أكثر من حجمه.

السؤال الذي يغيّر طريقة قراءتك لأي حل:

شو الصفقة التي أقبل بها الآن؟

في حلول قوية على الورق، وتصير ثقيلة داخل السياق الغلط. وفي حلول بسيطة جدًا، وتصير أذكى قرار في مرحلة مبكرة.

مثال واقعي: API منتجات بطيئة

تخيل عندك endpoint بسيط:

GET /products

في البداية كان يرجع 200 منتج، وكل شيء كان سريع. بعد فترة صار عندك 10,000 منتج، والصفحة فيها:

• Search.
• Category filter.
• Sort by price.
• Pagination.

AI ممكن يعطيك أكثر من اتجاه. ممكن يقترح pagination على مستوى قاعدة البيانات، أو indexing، أو caching، أو فصل search على محرك مثل Elasticsearch، أو materialized view، أو denormalization.

كل اقتراح له منطق، وكل اقتراح له ثمن. Pagination يحل جزء كبير بسرعة، بس يحتاج تصميم واضح للـ query parameters. Indexing يرفع الأداء، بس يحتاج فهم لطبيعة البحث والفلترة. Caching يعطي سرعة قوية، بس يدخل سؤال التحديث والـ invalidation.

Search engine يعطي تجربة بحث أفضل، بس يضيف نظام جديد عليك مراقبته وتشغيله. Materialized view ممكن تريح الـ queries، بس تدخل مسؤولية تحديث البيانات.

هون AI عطاك احتمالات. والهندسة تبدأ لما تختار.

Mental Model

اقرأ الثمن قبل الكود.

قبل ما تنظر للحل وتسأل:

هل يشتغل؟

اسأل:

ماذا يدخل هذا الحل إلى النظام؟

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

كل قرار هندسي له فاتورة. أحيانًا تدفعها اليوم، وأحيانًا تدفعها بعد ما يكبر المشروع. المهندس القوي يشوف الفاتورة قبل ما يوقّع على الحل.

الفكرة اللي لازم تثبت بعقلك

الكود جواب. القرار مسؤولية.

AI ممكن يعطيك جواب ممتاز، بس جودة شغلك تظهر في السؤال الذي يأتي بعده:

هل هذا الجواب يستحق أن يدخل على نظامي؟

هذا السؤال يجبرك تشوف السياق: حجم المشروع، مرحلة المنتج، قدرة الفريق، وقت التسليم، نوع البيانات، والمكان الذي سيكبر فيه الضغط لاحقًا.

Day 4 ينقلك من استهلاك الحلول إلى تقييمها. ومن هنا يبدأ الفرق الحقيقي بين شخص يطارد سرعة الكتابة، وشخص يوافق على قرارات أذكى.

Task 1

اليوم التمرين جاهز بالكامل. اشتغل على هذا السيناريو:

عندك متجر إلكتروني.

في صفحة منتجات.

الـ API الحالي هو:

GET /products

حاليًا بيرجع كل المنتجات مرة وحدة.

عندك 10,000 منتج.

الصفحة فيها search و category filter و sort by price و pagination.

الصفحة صارت بطيئة.

المطلوب منك تستخدم AI حتى يعطيك أكثر من حل. انسخ هذا الـ prompt كما هو:

عندي API في متجر إلكتروني:

GET /products

الـ API بيرجع كل المنتجات مرة وحدة.
عندي 10,000 منتج.
صفحة المنتجات فيها:
- search
- category filter
- sort by price
- pagination

الصفحة صارت بطيئة.

أعطني 4 حلول مختلفة لهذه المشكلة:

1. حل سريع للتنفيذ.
2. حل بسيط وقابل للفهم.
3. حل قابل للتوسع.
4. حل مناسب لفريق صغير يريد تجنب التعقيد الزائد.

لكل حل اشرح:
- فكرة الحل.
- ماذا يربح المشروع من هذا الحل.
- ماذا يدفع المشروع لاحقًا بسبب هذا الحل.
- متى يكون هذا الحل مناسبًا.
- متى يتحول هذا الحل إلى عبء.
- أول مكان ممكن ينكسر فيه هذا الحل.

بعد ما يعطيك AI الحلول، اقرأها كمهندس؛ كحدا يفتش عن الثمن قبل الكود.

اكتب تحت كل حل:

هذا الحل يربحني...

وهذا الحل يكلّفني...

وهذا الحل يناسب مرحلة...

وهذا الحل يبدأ يتعبني لما...

هون يبدأ التمرين الحقيقي.

Task 2

هسا قيّم الحلول.

استخدم هذا الجدول:

بعد الجدول، اكتب قرارك بهذا القالب:

اخترت الحل رقم: __

لأن السياق الحالي هو: __

الثمن الذي أقبل به في هذا الحل هو: __

الثمن الذي أرفضه في الحلول الأخرى هو: __

سأغيّر قراري إذا: __

السطر الأخير مهم جدًا، لأن القرار الهندسي القوي يعرف اللحظة التي يتغير فيها.

هيك بتتعامل مع AI كمصدر خيارات، وتتعامل مع نفسك كصاحب القرار. والفرق بينهم كبير.

هذا هو تدريب Day 4.

1:1 Mentorship

جاهز تبني طريقة التفكير هاي؟

كل مقال في هاي السلسلة يعطيك Mental Model جديد.

داخل جلسات 1:1 بنطبق هاي النماذج على مشاريع ومشاكل حقيقية، مع مراجعة مباشرة لطريقة تفكيرك والقرارات اللي بتاخذها.

ابدأ التقديم →

الخلاصة

بعد AI، كتابة الكود صارت أسهل. إدخال الكود الصحيح صار أصعب.

الأدوات صارت أقوى، والقرارات صارت أثقل. Day 4 كان عن هذه النقلة: من مبرمج يبحث عن حل، إلى مهندس يختار ما يستحق الدخول على النظام.

الكود صار رخيص.

القرار صار غالي.