1Health تعمل في BETA في الإمارات اليوم: اكتشاف المرضى، قوائم مقدّمي الخدمة، مكتب خلفي للمقدّمين، مستويات القوائم، ونظام علامة داخل المنتج. قبل اثني عشر شهرًا كان حوارًا عائليًا. البناء الذي كان يعني فريقًا ممولًا وخطة توظيف هو في الغالب أنا، بالإضافة إلى وكلاء أثق بهم فقط بقدر ما أستطيع قراءة diffs الخاصة بهم.
الناس ما زالوا يسألون هل شخص واحد، أو مطوّر واحد، يستطيع تشغيل شركة حقيقية بالذكاء الاصطناعي. توقفت عن الجدال وشحنت. هذا تقرير ميداني عن ما هي الوظيفة فعلًا عندما تكون المسودة الأولى رخيصة: ليس تنبؤًا، وليس عرضًا لاستبدال فريقكم.
يمكنكم وصف تطبيق في فقرة والحصول على شيء يعمل بحلول بعد الظهر. هذا أسبوع عادي في 2026. أحدث نماذج Anthropic تستطيع بناء مشروع كامل دفعة واحدة كان يستغرق من فريقي sprint كاملًا قبل عامين. السؤال القديم كان هل انتهى المطوّرون. السؤال المفيد هو ما الذي تغيّر في العمل عندما أخذت الآلات الكتابة وتركت لكم كل شيء آخر.
ماذا يعني «المسودة الأولى» الآن
قبل عامين، برمجة الذكاء الاصطناعي تعني الإكمال التلقائي. اليوم تصفون النتيجة ووكيل ينجز الباقي. الوكيل ذكاء اصطناعي يستطيع التخطيط، كتابة الملفات، تشغيل اختباراته، وإصلاح أخطائه دون أن تراقبوه. أدوات مثل Claude Code ووكلاء Cursor-style يعطونكم برمجيات عاملة كثيرًا بما يكفي ليتوقف حجم الكود عن كونه القيد.
لكن «المسودة الأولى» ليست كودًا فقط. هي أيضًا تدفق UX يُجمَع لكنه يفوّت المهمة. ميزة من شريحة خارطة طريق لم يطلبها أحد. ثلاث مسودات، نفس الاختبار: شيء معقول يصل بسرعة؛ شخص ما ما زال يجب أن يقرر إن كان صحيحًا.
الصناعة رأت هذا قادمًا. في مارس 2025، تنبأ Dario Amodei، CEO Anthropic، أن الذكاء الاصطناعي سيكتب 90% من الكود خلال أشهر. أضاف سطرًا حصل على اهتمام أقل: «المبرمج ما زال يحتاج أن يحدد شروط ما تفعله، ما التطبيق الشامل الذي تحاول صنعه، ما قرار التصميم الشامل.» الجزء الأول صنع العناوين. الجزء الثاني هو الوصف الوظيفي للمؤسسين والمهندسين على حد سواء.
الهيكل التنظيمي للواحد
شركة من شخص واحد لا تعني أن الوظائف اختفت. تعني أنكم تحملونها جميعًا، والوكلاء أخذوا واحدة فقط: الكتابة.
شخص ما ما زال يقرر ما يُبنى. شخص ما يقرر من يرى معلومات مريض، لأن في الرعاية الصحية ذلك السؤال مرتبط بجسد. شخص ما يقرر ماذا تدفع العيادة وماذا يبقى مجانيًا. شخص ما يقرر ماذا يحدث عندما يفشل حجز ليلًا مع شخص حقيقي ينتظر. شخص ما يجيب بريد الدعم. شخص ما مسؤول قانونيًا.
وكيل سيقرر كل ذلك لكم إن تركتموه. يقرر بتخمين. التخمين يُجمَع، يعرض جيدًا في العرض التجريبي، ويكون خاطئًا بطرق تكتشفونها من مستخدم أو diff.
يومي الفعلي يبدو أكثر إدارة من هندسة. أخطط العمل وأترك وكيلًا يقطع المهام على اللوحة. أقرأ الخطط قبل أي كود. أقرأ diffs، لا ملخصات أبدًا، لأن الملخص هو القصة التي يريد الوكيل روايتها والdiff هو ما حدث. أبحث عن بدائل احتياطية وعناصر placeholder يتركها الوكلاء عندما لم يكونوا متأكدين أن نهجهم الحقيقي سيثبت. أقتل الجلسات المتعبة وأبدأ جديدة. حلقة التحقق هذه ثلث أسبوعي، كل أسبوع.
الوكلاء أخذوا الكتابة. احتفظت بكل شيء آخر. كل شيء آخر اتضح أنه الشركة.
1Health: عندما يكتب الوكلاء الهيكل
Andrej Karpathy أعطى طريقة البناء هذه اسمها:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Vibe coding انتقل من تغريدة عابرة إلى مدخل قاموس، وأنا أبني بهذه الطريقة يوميًا. 1Health بدأ كأساس مبني بـ vibe coding: الوكلاء كتبوا معظم هيكل التطبيق، التوجيه، وواجهة المستخدم المبكرة. امتلكت تسجيل الدخول، الحجوزات، أمان الإدارة، وكل تدفق يواجه المريض يلمس الثقة.
السرعة لم تكن مشكلتنا أبدًا. الأسئلة البطيئة كانت لنا. من يرى معلومات المريض؟ ماذا تدفع العيادة، وماذا يبقى مجانيًا؟ ماذا يجب أن يحدث عندما يفشل حجز ليلًا؟ وكيل سيجيب على تلك أيضًا، بتخمين يبدو واثقًا حتى تقرأ diff وتجد placeholder حيث يجب أن تكون سياسة إعادة محاولة حقيقية.
الرعاية الصحية لا تسامح التخمين على تلك الحواف. احتفظت بالحكم على UX في المجال المنظّم، مستويات المقدّمين، والمكتب الخلفي للإدارة خلف القوائم والحسابات. المواد التقديمية والتوقعات المالية تحركت بالتوازي حتى تطابق القصة على الشرائح ما في البناء. هذا ملمس الوظيفة: ليس حيل prompts، بل حكم تحت الحمل بلا أحد آخر يلتقط ما تفوتكم.
Paper: عندما كانت مسودة التدفق الأولى خاطئة
في Paper، ظهر نفس الاختبار قبل وجود وكلاء البرمجة. التوليد نادرًا ما كان ما يعطلنا. الاختبار الحقيقي كان هل الميزة تساعد معلمًا في يوم مدرسي عادي وتستمر عبر منطقة كاملة.
الطلاب هبطوا على شاشة بيضاء فارغة مع صندوق يطلب اختيار موضوع. تردّدوا. وضعنا محدّد الموضوع فوق معاينة للمحادثة تحته. ارتفعت بدايات الجلسات بنحو 25%. وصفها الطلاب بأنها بديهية بأثر رجعي. كتبت أكثر عن ذلك الإصلاح في تجربة المستخدم الرائعة تبتعد عن الطريق. ربع تلميع خارطة الطريق لم يحرّك الاحتفاظ بنفس القدر.
بنينا Paper Review لأن المعلّمين كانوا يراجعون أوراقًا يدويًا في المحادثة. الطلاب كانوا يسألون باستمرار إن كان أحد يستطيع المساعدة في ورقتهم. تدفق مخصص وفر على المعلّمين 30%+ من وقتهم وأصبح منتج الشركة الرائد. لم يخمّن أحد ذلك على لوحة بيضاء. الطلب كان أصلًا في المنتج.
وكلاء البرمجة جلبوا نفس الاختبار لكل من يشحن برمجيات. مسودة الكود، الشاشة، أو الميزة الأولى يمكن أن تصل في ساعات. المسودة الثانية ما زالت تأتي من مراقبة جلسات حقيقية.
كيف أدير الحجم
عندما ينتج الوكلاء migrations ومكونات واختبارات وربطًا بين الأجزاء بالتوازي، الإنتاجية لم تعد عنق الزجاجة. التنسيق والذاكرة هما.
أعامل اللوحة كمصدر الحقيقة لما يعني «منجز» هذا الأسبوع. خطط قبل الكود. أراجع الخطة كما كنت أراجع ملخص sprint، ثم أترك وكيلًا ينفّذ. بلا هذه الخطوة، عشرون وكيلًا متوازيًا يصبحون عشرين رؤية منتج متعارضة.
MCP، Model Context Protocol، يتيح للوكلاء استدعاء أدوات خارجية بدل التخمين. سجلات النشر، DNS، البريد، استعلامات قاعدة البيانات: الوكيل يقرأ الحالة من النظام، لا من آخر محادثة. أستخدم MCP hooks لمراجعات البنية التحتية وفحوص الإنتاج حتى «يجب أن يعمل» تصبح «هذا استجابة API.»
الجلسات بلا حالة. التعليمات المحددة نطاقًا ليست. قواعد مكتوبة وskills وقوائم تحقق هي قاعدة بيانات كيف نعمل: ماذا نتحقق، ماذا لا نثبت في git أبدًا، أي متغيرات بيئة تهم. تنجو من إعادة تشغيل الجلسة حتى لا يعيد الوكيل التالي فتح قرارات اتخذتموها.
للمنتجات الثقيلة على المحتوى والبيانات، أحتفظ بقاعدة بيانات حقيقية كحقيقة: seed files تتزامن إلى SQLite، API يخدم ما شُحن، وأتحقق من البناء قبل أن أسميه منجزًا. العملية تحل محل الزملاء كنظام تصحيح أخطاء. فريق أبطأ، لكن فريق يلتقط أيضًا نقاط عمى. أعدت بناء تلك الوظيفة من اللوحات وdiffs ومراجعات نهاية الجلسة.
ما هي وظيفة المطوّر الآن
عنق الزجاجة تحرّك. كان سابقًا كم سرعة تستطيعون البناء. الآن كم سرعة تستطيعون القرار والتحقق. منصتي تشحن بالضبط بالسرعة التي أستطيع قراءة diffs، الإجابة على أسئلة صعبة، والتحقق أن «منجز» يعني منجز.
هذا ذوق وتفكير نقدي باسم آخر. الذوق معرفة أي تخمين وكيل يطابق المنتج الذي ستشحنونه. التفكير النقدي سؤال «لماذا» قبل الإصلاح، لأن الخطأ يُظهر أين يخمّن الوكيل وتلك المعرفة تتراكم أسرع من أي حيلة prompt.
قضيت عشرين عامًا عبر التصميم والمنتج والقيادة التقنية قبل هذا: VP Product في Paper، co-founder وCTO في Openfair، حيث وصلنا إلى 1M+ ARR في نحو اثني عشر شهرًا. كل واحدة من تلك الوظائف كانت تدريبًا على الحكم. الوكلاء جعلوا كل ذلك ذا صلة فجأة، لأنني الآن أتخذ في أسبوع مدى القرارات الذي كان موزّعًا على فريق قيادة.
في Openfair، وكيل يمكنه أن يعطينا عرضًا تجريبيًا في يوم. مستخدمون حقيقيون وبيانات حقيقية ومال حقيقي ما زالوا يضعون معيارًا أعلى. الفجوة بين العرض التجريبي وذلك المعيار هي حيث تكسب المنتجات الثقة. نفس الفجوة أغرقت أجهزة الذكاء الاصطناعي المبكرة؛ كتبت عنها في دروس أجهزة الذكاء الاصطناعي من Humane وRabbit.
ممارسات تنجو من السرعة
إذا بنيتم بالوكلاء كمطوّر أو مؤسس-مشغّل، هذه العادات تحمل معظم الوزن:
- اكتبوا ما يعني «منجز» قبل prompt. قواعد البيانات، سلوك الفشل، من يرى ماذا. الوكيل يملأ الوسط؛ التعريف لكم.
- اقرأوا diffs، لا ملخصات. الملخص هو القصة التي يريد الوكيل روايتها. الdiff هو ما حدث.
- أبقوا كل تغيير صغيرًا بما يكفي للمراجعة. راجعوا diff كما كنتم تراجعون عمل زميل. هذا ما هو الآن.
- ضعوا الخطط على اللوحة قبل الكود. مصدر حقيقة واحد للنطاق هذا الأسبوع يتفوق على عشرين وكيلًا واثقًا.
- عندما يخطئ المخرج، اسألوا لماذا قبل الإصلاح. الأخطاء ترسم أين يخمّن الوكيل.
- استخدموا MCP للحقيقة الخارجية. حالة النشر، قواعد البيانات، APIs: اقرأوا النظام، لا تثقوا بذاكرة المحادثة.
شركة من شخص واحد فريق مضغوط في نقطة حكم واحدة. الوكلاء هم الأيدي. كل زوج أيدي يتحرك بسرعة الآلة. كل قرار عما إذا كان حقيقيًا، أو مُلبَسًا ليبدو حقيقيًا، ما زال يمر عبر إنسان واحد.
إذا وفّرتم الحكم من سنوات في مجال، الرافعة سخيفة. إذا أملتم أن الذكاء الاصطناعي يوفّر الحكم، تحصلون على شيء يبدو كشركة كما يبدو كود الوكيل «منجزًا». السوق يلعب نفس دوري في مراجعة الكود، إلا أن السوق يفرض الدرس أكثر.
إذا كنتم تتعلمون البرمجة، استمروا، وتعلّموا بالوكلاء من اليوم الأول. ابنوا شيئًا صغيرًا من البداية إلى النهاية كل أسبوع. المسار المستحق بناؤه في التحقق والذوق، لا سرعة الكتابة.
إذا كنتم تشحنون منتجًا الآن والشكل ما زال فوضويًا، أساعد المؤسسين على جعل الخطوة التالية أوضح. أخبروني ماذا تبنون.
نُشر أصلًا في Product, AI & Business على LinkedIn.