في عام 2007 نشر بول جراهام مقالًا بعنوان «أن تحتفظ بالبرنامج كله في رأسك». وحجّته تُختصر في جملة واحدة: المبرمج يعمل في أفضل حالاته حين يتّسع عقله للنظام كاملًا، يحمله دفعةً واحدة بدل أن يعود إليه بحثًا. يقول: «تحتفظ بالبرنامج كله في رأسك، فتتمكّن من تقليبه كيفما شئت».
وكل من بنى برمجيات يعرف هذه الحالة، ويعرف أنها ليست مجازًا. حين تكون حاضرة عندك، تُجيب فورًا عن سؤال «ما الذي سينكسر إذا غيّرت هذا؟» دون أن تفتح شيئًا. وحين تفقدها، تقرأ منتجك أنت كما يقرؤه غريب.
وكانت خلاصة جراهام متشائمة، وقالها صريحة: «المؤسسات مُصمَّمة لتمنع ما يسعى إليه المبرمجون». ثم جاءت توصياته: اعمل في مجموعات صغيرة، لا تدع أكثر من شخص يحرّر الشيفرة نفسها، أعد كتابة البرنامج باستمرار، وابدأ صغيرًا. أعد قراءة هذه القائمة وتأمّل حقيقتها: إنها ليست قائمة إنتاجية، بل جردٌ لكل ما عليك التخلّي عنه كي تكبر.
وبعد نحو عشرين عامًا، نرى أنه أصاب في الجوهر وأخطأ في مكان وجوده. وهذا الفرق تحديدًا هو ما بُني عليه استوديو InfiniteUp.
جراهام وصف الوعاء، لا الجوهر
موضوع ذلك المقال لم يكن الرأس في حقيقته، بل التماسك: نموذج واحد مكتمل ومتّسق للنظام، لا تبقى فيه حدودٌ لا يملكها أحد.
وقد وضع جراهام هذا النموذج داخل شخص واحد لأنه في 2007 لم يكن ثمة وعاء آخر يصمد. كل وعاء أكبر كان يُسرّب: شخصان يعنيان نموذجين ناقصين ومفاوضةً بينهما، وعشرة يعنون لجنةً تحتاج أن تجتمع كي تتذكّر منتجها. كان الجوهر والوعاء شيئًا واحدًا عمليًّا، فلم يكن هناك داعٍ للتفريق، فكتب الوعاء لأنه الظاهر للعيان.
لكن افصل بينهما، وينفتح الباب كلّه. فما تحتاجه هو نموذج واحد، لا صانع نموذج واحد.
وهذا ليس لعبًا بالألفاظ، لأن لكلٍّ منهما طريقة انهيار مختلفة. صانع النموذج الواحد ينهار حين تنفد يداه، وحين يحمل أربع طبقات فيحملها كلَّها سطحيًّا. أما النموذج الواحد الموزّع على عدة أشخاص فينهار حين تتباعد أطرافه عند المفاصل. مشكلتان مختلفتان، لكل منهما علاج مختلف — والأولى وحدها هي التي كان حلّها ألّا توظّف أحدًا.
القيد لم يكن العقل يومًا
اسأل نفسك: لماذا وظّفت الشخص السادس؟ الأرجح أن السبب لم يكن أن التصميم صار أدقّ من أن يستوعبه عقل واحد. التصاميم نادرًا ما تفوق قدرة مهندس جيد — الذي تفوقه هو أسبوع العمل. وظّفت لأن كمّ العمل كان أكبر: شاشات تُبنى، وحالات فارغة، ومعالجة أخطاء، ورفض من المتاجر، وترحيل بيانات. لا شيء من ذلك صعب ذهنيًّا، وكلّه يحتاج أيديًا.
وفي اللحظة التي أضفت فيها الأيدي بالطريقة القديمة، دفعت ضريبة فريد بروكس. كتابه «شهر العمل الأسطوري» سمّاها عام 1975: إضافة أشخاص إلى مشروع متأخّر تزيده تأخّرًا، لأن كل شخص جديد يضاعف مسارات انتقال المعلومة. عندها يغادر التصميم الرأس ويسكن الفراغات بين الناس — في التذاكر، وفي الاجتماعات اليومية، وفي الذاكرة الجماعية لفريقٍ لا يتذكّر منتجه إلا مجتمعًا.
هذه هي المقايضة التي عقدتها الصناعة طوال خمسين عامًا: تماسكٌ يُدفع ثمنًا للإنتاجية. كل فريق يعقدها، ومعظم الفرق لا تنتبه، لأنها تصل على هيئة تعيينٍ معقول تلو الآخر.
شهر العمل بمليون ساعة
نستخدم هذا التعبير مع عملائنا منذ فترة، وقد آن أوان تدوينه.
شهر العمل بمليون ساعة هو شهرٌ يقود فيه نموذجٌ واحد متماسك كمًّا هائلًا من الأيدي — دون أن تحتاج يدٌ منها إلى شرحٍ مرّتين، أو إلى تهيئة، أو إلى حضور اجتماع.
وكن متشكّكًا في الرقم، فنحن كذلك. لا أحد يفوتر مليون ساعة شهريًّا، ولا نحن. الرقم مبالغة مقصودة، ونسخته الصادقة تتغيّر كل أسابيع مع رخص النماذج — فاتورتنا نحن انخفضت نحو مئة ضعف في ثلاث سنوات.
أما غير المبالغ فيه فهو النسبة، وسبب ثباتها: ساعات الآلة قابلة للتبادل ولا تكلّف حوارًا. وشهر العمل كان وهمًا لأن البشر ليسوا كذلك في الحالتين. فالوحدة التي وصفها بروكس بحقٍّ بأنها أسطورة صارت لأول مرة تتصرّف تصرّفًا قريبًا مما تظاهر المحاسبون دائمًا بأنها تفعله.
لكن الأيدي كانت المُضاعِف السهل
وهنا الجزء الذي يُقفز عنه، وهو وحده الجزء الصعب.
الذكاء الاصطناعي لم يمنح أحدًا رأسًا ثانيًا. منح الجميع أيديًا. وكل من رأى نموذجًا يعيد بناء خاصية تعمل، بثقةٍ تامة، بطريقة تخالف معمار النظام كله، لمس الحدّ مباشرة: إنه بارع فيما تُوجّهه إليه، وضحل بثقة في اللحظة التي يحتاج فيها إلى فهم المشروع بأكمله. إنه لا يحمل نموذجًا. ولم يحمل واحدًا قط.
فالأيدي اليوم سلعة متاحة. كل من يقرأ هذا يملك اليدين نفسيهما اللتين نملكهما، وبالثمن نفسه تقريبًا. المُدخل النادر هو ما يوجّهها — وإلى هناك انتقلت الهندسة الحقيقية.
وجّه كمًّا هائلًا من الأيدي إلى نظام لا يحمله أحد بتماسك، فلن تحصل على منتج، بل على أكفأ آلة صُنعت لتضييع الطريق. مليون يدٍ بلا نموذج تحفر حفرة أعمق بكثير وأسرع بكثير، وتبدو تقدّمًا طوال الطريق إلى القاع. وقد رأى جراهام هذا قادمًا، في سطرٍ يُقرأ اليوم كتحذيرٍ من أدوات لم تكن قد وُجدت بعد: «شيفرتك هي فهمك للمشكلة التي تستكشفها». وإن لم تبنِ الفهم، فأنت لا تملكه، مهما كان الموجود في المستودع.
لماذا تتفوّق أربعة عقول على عقل واحد
وهذا يقودنا إلى الادّعاء الذي يبدو دفاعًا عن النفس من استوديو من أربعة أشخاص، فلنقُله كما ينبغي.
العقل الواحد الذي يحمل أربع طبقات لا يحمل أربع طبقات فعلًا. يحمل طبقةً واحدة جيدًا، وثلاثًا بالعمق الذي يسمح به وقته هذا الأسبوع. وليس في هذا انتقاصٌ من ذكاء أحد، بل هو حسابُ انتباه. فالمؤسّس-المهندس الذي يملك نمذجة البيانات وتصميم التجربة وامتثال الإصدار والاستراتيجية التجارية يحمل ذلك كله فعلًا، ويحمل معظمه رقيقًا فعلًا.
والآن أعد قراءة أول توصيتين عند جراهام: تجنّب التشتّت، واعمل على فترات طويلة. وكلتاهما قائمة على سبب واحد: إعادة تحميل النموذج إلى رأسك مكلفة. وهو مُصرّ على أن المقاطعة تكلّف أضعاف الدقائق التي تستهلكها، لأنك تدفع كلفة التحميل مرة أخرى عند العودة.
والعموميّ الذي يحمل أربع طبقات يدفع كلفة إعادة التحميل هذه في كل مرة ينتقل فيها بين طبقة وأخرى — عدة مرات يوميًّا، كل يوم، بحكم البنية لا بحكم سوء التنظيم. أما أربعة متخصّصين لا يغادر أحدهم طبقته فلا يدفعونها تقريبًا أبدًا.
ومعنى ذلك أن أربعة عقول، إذا قُسّمت تقسيمًا صحيحًا، لا تكتفي بالنجاة من معايير جراهام، بل تحقّقها أفضل مما يحقّقها رأس واحد. لم تكن الفكرة خاطئة. كانت ناقصة التحديد.
السرّ كلّه في طريقة الوصل، وليس في التواصل
كل شركة تطوير ستحدّثك عن التعاون، والتواصل الممتاز، وحلقات التغذية الراجعة السريعة. ونحن نرى أن هذا معكوس تمامًا، وأنه سبب كون معظم فرق الأربعة أربعةَ أدمغة لا دماغًا واحدًا.
ضريبة بروكس ضريبةٌ على التواصل. ولا تنجو من ضريبة تواصل بأن تتواصل بمهارة أكبر، بل بأن تحتاج إلى تواصل أقل — وسبيلك إلى ذلك أن تمرّر الحدود حيث تكون حركة المرور أخفّ، ثم تجعل كل شخص صاحب سيادة كاملة داخل جانبه من الحد.
وهذا أقدم مبدأ في هندسة البرمجيات — تماسكٌ عالٍ داخل الوحدة واقترانٌ منخفض بينها وبين غيرها — لكن مطبَّقًا على البشر بدل الوحدات البرمجية. وهو تقريبًا نصّ تعليمات جراهام نفسه للفرق، وهي التعليمات التي تُهمل عادةً لصالح ما هو أجدر بالاقتباس: «إذا أردت أن تُشغّل عدة أشخاص على مشروع، فقسّمه إلى مكوّنات وأعطِ كل مكوّن لشخص واحد». ويليها مباشرة: «لا تدع أكثر من شخص يحرّر القطعة نفسها من الشيفرة. فأنت لا تفهم شيفرة غيرك كما تفهم شيفرتك».
إنه لا يطلب منك أن تُحسن التعاون. يطلب منك أن تُحسن التقسيم حتى تكاد لا تحتاج إلى التعاون.
ورأسك أنت يعمل بهذه الطريقة أصلًا، وهذا أقوى دليل على أنها تنجح. فالدماغ ليس مفكّرًا واحدًا متجانسًا، بل مناطق متخصّصة، عرض النطاق داخل كل منطقة أكبر بكثير من عرضه بينها وبين جاراتها. قشرتك البصرية وقشرتك الحركية لا تعقدان اجتماعات. تلتقيان على حدٍّ ضيّق ومستقرّ وقديم، والنتيجة ليست أربعة عقول تتجادل، بل إنسان واحد لا يشعر بالحدّ ولو مرة.
أين تمرّ حدودنا نحن
نحن أربعة أشخاص، والتقسيم بيننا بحسب الحرفة لا بحسب الخاصية — وهذا مهم، لأن التقسيم بحسب الخاصية هو الطريق إلى أربعة نماذج ناقصة لشيء واحد بدل أربعة نماذج مكتملة لأربعة أشياء.
هناك ثلاث طبقات حرفية. وسيم يملك الواجهة الأمامية والتصميم — كيف يُركَّب المنتج وكيف يبدو في يد المستخدم. وملاذ يملك الواجهة الخلفية: نموذج البيانات، وقاعدة البيانات، وواجهات البرمجة ومعمار الذكاء الاصطناعي خلفها. وهبة تملك الجودة — لا تحرّر شيفرة أحد، بل تحاول كسرها، وتملك مسارات الامتثال والتحقّق.
أما الدور الرابع فليس طبقة، وهو الجزء الذي استغرق فهمه منّا أطول وقت. باريت يدير المشروع ويمتصّ الفجوات — العمل الذي لا ينتمي إلى طبقة بعينها، والسؤال الذي كان سيُخرج متخصّصًا من رأسه كي يُجيب عنه.
والحدود بينهم ضيّقة، ويُتَّفق عليها مرة واحدة في البداية بدل التفاوض عليها مع كل خاصية جديدة. فبين الأنظمة والواجهة، الحدّ هو عقد البيانات: اضبط شكل البيانات، ويستطيع الطرفان العمل أسابيع دون حوار. وبين البناء والجودة، الحدّ هو معنى كلمة «مُنجَز»، يُحدَّد قبل بدء العمل لا يُكتشف أثناء المراجعة. وبين المنتج وبقية الفريق، الحدّ هو النطاق: ما الذي يتضمّنه هذا الإصدار، والأهم، ما الذي لا يتضمّنه.
وهذا الدور يؤدّي عملًا أكبر مما يبدو. كانت أولى توصيات جراهام أن تتجنّب التشتّت، وقد كتبها نصيحةً شخصية — أغلق الباب، وتجاهل البريد. لكن التشتّت ليس شيئًا ينتصر عليه فرد، لأن المشروع يولّده بحكم بنيته: عميل يسأل، ومتجر يرفض، وطرف ثالث يغيّر واجهته يوم الثلاثاء. لا بدّ لأحدٍ أن يلتقط هذا كله. وإذا كان الملتقِط يملك طبقةً أيضًا، فالمقاطعة لم تتوقّف بل انتقلت فقط — صارت تسقط على رأسٍ كان يحمل شيئًا. وإسناد الالتقاط إلى شخص واحد هو ما يجعل الحدود الثلاثة الأخرى تصمد.
وهو أيضًا أقلّ الأدوار الأربعة راحة، ونقولها كما هي بلا تجميل: من يمتصّ الانتقالات بين السياقات يدفع كلفة إعادة التحميل التي يُعفى منها الثلاثة الآخرون. وهذه مقايضة مقصودة لا وجبة مجانية، وهي الحدّ الأكثر عرضةً للإجهاد حين نحمل أكثر مما ينبغي دفعةً واحدة.
لا أحد ينتظر إذن أحد داخل طبقته. هذه هي الخاصية التي تجعل أربعة أشخاص يتصرّفون كرأس واحد لا كلجنة صغيرة — وهي الشيء الذي يصعب شراؤه فعلًا، لأنه ليس إجراءً يمكنك تركيبه، بل مجموعة حدود استغرق العثور عليها وقتًا طويلًا.
أمام موعد تسليم حقيقي
أوضح مثال نملكه هو Vitalizer: شركة صحّة في فلوريدا احتاجت منصّة رعاية صحية عن بُعد متكاملة — تقييمات صحية وفرز بالذكاء الاصطناعي، ورعاية افتراضية، وسوق مزوّدي خدمات، واشتراكات، ودعم إمكانية الوصول وتعدّد اللغات — بعقدٍ مدّته 45 يومًا، من التصميم حتى الجاهزية لمتجر التطبيقات، على iOS وأندرويد والويب.
هذه ليست مدةً تعرضها شركة تطوير تقليدية، والسبب ليس أن مهندسيها أبطأ. السبب أن تنفيذها بالطريقة التقليدية يعني إنفاق أول أسبوعين من مشروع مدّته ستة أسابيع في بناء نموذج ذهني مشترك بين ثمانية أشخاص — ثم دفع ضريبة تواصل كل يوم بعد ذلك. الجدول الزمني يموت في مرحلة التهيئة قبل أن يكتب أحدٌ سطرًا واحدًا.
أما أربعة أشخاص استقرّت حدودهم منذ سنوات فيتجاوزون الكلفتين معًا. قرارات المعمار هي المشروع، وكل ما بعدها أيدٍ، والأيدي هي الجزء الرخيص اليوم. وقد أُطلق التطبيق على المنصّات الثلاث، مع نقل كامل للملكية الفكرية وضمان ثلاثة أشهر. وهو السبب نفسه الذي يجعلنا نشير إلى أكثر من أربعين تطبيقًا أُطلقت في الصحة والتعليم والعقار والتقنية المالية، بفريقٍ يفترض معظم العملاء أنه أصغر من أن يُذكر.
أين ينهار هذا كلّه
ثلاث حالات فشل صادقة، لأن أطروحةً بلا مثال مضاد ليست أطروحة، بل إعلان.
الحدود في المكان الخطأ أسوأ من غياب الحدود. مرِّر حدًّا في منتصف شيءٍ هو في حقيقته فكرة واحدة، وستكون قد صنعت مفاوضةً دائمة: شخصان عليهما أن يتّفقا باستمرار على أمرٍ كان يجب أن يملكه واحد. وهذا ليس خطأً صغيرًا تُعالجه بالإجراءات، بل ينتج بالضبط اللجنة التي كنت تتجنّبها، وعلاجه الوحيد أن تحرّك الحدّ.
وأحيانًا تكلّفك الأيدي أكثر مما توفّره. خسرنا وقتًا حقيقيًّا في مشروع أفسدت فيه أداة ذكاء اصطناعي، وهي تعمل داخل الشيفرة مباشرة، الشيفرةَ نفسها التي كان يُفترض أن تصلحها. وكان الحل أن نمنعها من الكتابة بتلك الطريقة ونعود إلى أداة أضيق. والدرس أن الرافعة على الأيدي ليست مجانية أبدًا، وتحتاج إشراف من يميّز الخطأ في المخرجات: لا الخطأ بمعنى «تعطّل التطبيق»، بل بمعنى هذا لا يطابق طريقة عمل هذا النظام — وهو ما لا يراه إلا من يحمل النموذج.
ولا شيء من هذا ينقذ فريقًا لم يبنِ نموذجًا أصلًا. كل ما سبق يفترض أن أحدهم أنجز الجزء الصعب أولًا. وإن لم يستقرّ نموذج البيانات، فإن المضاعفة تنطبق على الفوضى بالأمانة نفسها التي تنطبق بها على التقدّم — ولهذا صار إنقاذ التطبيقات المبنية بالذكاء الاصطناعي نوعًا قائمًا بذاته من العمل عندنا.
خطوات العمل عندنا
إذا كانت الأطروحة «نموذج واحد وأيدٍ كثيرة»، فعلى العملية أن تحمي النموذج وتُصنّع الأيدي. وهذا ترتيبنا:
- 1 · مكالمة تعارف. ثلاثون دقيقة بلا عرض تقديمي. تخرج منها بصورة أوضح عن مشروعك سواء تعاقدت معنا أو لا.
- 2 · تثبيت النموذج قبل أي شيفرة. نموذج البيانات، والمصادقة، وأين تعيش الحالة، والسلوك دون اتصال، وأي أطراف ثالثة نثق بها وماذا يحدث حين تتعطّل. كل ما يلي يعتمد على هذه الخطوة، وهي أكثر الخطوات عرضةً للتخطّي عند الاستعجال.
- 3 · رسم الحدود. الاتفاق على عقد البيانات، ومعنى «مُنجَز»، وحدّ النطاق مقدّمًا — وتسمية من يملك العمل الذي يقع بينها، فهو موجود في كل مشروع.
- 4 · تطبيق «مثلّث الذكاء الاصطناعي الحديدي». قبل سطر واحد من تكامل الذكاء الاصطناعي، نختبر النماذج الأساسية الكبرى — OpenAI وGemini وClaude وDeepSeek — على حالتك أنت، من حيث السرعة والتكلفة والقدرة. قياسًا لا افتراضًا. بلا ولاء لعلامة ولا ضريبة ضجيج.
- 5 · مضاعفة الأيدي. الذكاء الاصطناعي على المسارات المعروفة، بإشراف مالك الطبقة، وموجَّهًا إلى النموذج من الخطوة الثانية.
- 6 · تحقّق مستقل. اختبار جودة لا يقوم به كاتب الشيفرة، على iOS وأندرويد والويب، مع التعامل مع الامتثال كمسألة هندسية لا كإجراء قانوني لاحق.
- 7 · تسليم صحيح. إطلاق، ونقل كامل للملكية الفكرية، وضمان ثلاثة أشهر، ومشروع يستطيع أي فريق طبيعي أن يكمل عليه.
إذا كنت أنت من يشتري
طوال تاريخ بيع البرمجيات، كان عدد الموظفين هو المؤشّر على القدرة. وكان مؤشّرًا معقولًا، لأن الإنتاج كان يتناسب مع الأيدي، وكانت الأيدي لا بدّ أن تكون بشرًا.
وقد انكسر هذا المؤشّر حديثًا إلى حدّ أن معظم إدارات المشتريات لم تنتبه بعد. فشركة من ستين موظفًا ليست ستين ضعفًا من الإنتاج موجّهة إلى منتجك. إنها بضعة أشخاص يفهمون منتجك، وعددٌ آخر تجري إدارته وتنسيقه، وضريبة تواصل تدفعها أنت كاملة.
لذلك، حين تختار شركة برمجة تطبيقات، اسأل سؤالًا مختلفًا. لا «كم شخصًا سيعمل على مشروعي؟» بل «كيف يُقسَّم العمل، ومن صاحب السيادة على كل جزء؟» اسأل عن اسم من يملك نموذج بياناتك. اسأل ماذا يحدث عند الحدّ بين التصميم والهندسة حين يختلفان. اسأل من يقرّر معنى «مُنجَز». واسأل من يملك العمل الذي لا ينتمي إلى أحد — فهو موجود دائمًا، وإن كانت الإجابة «من يجد وقتًا»، فسيُقتطع من وقت الشخص الذي تدفع له كي يفكّر. ستخبرك الإجابات إن كنت تشتري نموذجًا واحدًا أم لجنة، وهذا الفارق صار أهمّ بكثير من حجم الفريق.
والسؤال نفسه ينطبق سواء كنت روّاد أعمال يأخذ فكرة إلى متجر التطبيقات، أو منشأة قائمة تحتاج برمجيات مخصّصة مبنية على طريقة عملك الفعلية. منتجان مختلفان، وطريقة الانهيار واحدة حين لا يملك أحدٌ النموذج.
كان جراهام محقًّا في أن المؤسسات مُصمَّمة لتمنع ما يسعى إليه المبرمجون. لكنه لم يكن ليعرف أيّ نصفَي المشكلة سيتصدّع أولًا: أن تصير الأيدي وفيرة، وأن يصير النادر مجموعةً صغيرة بما يكفي، ومقسّمة جيدًا بما يكفي، لتفكّر برأس واحد.