سلّم لم نتوقف عن صعوده. منذ ثمانين سنة.

في 2025، تغيّرت البرمجة من سؤال تقني إلى سؤال ذهني: هل تعرف ماذا تريد؟

ليست جملة تسويقية عن الذكاء الاصطناعي. أتحدث عن شيء عملي عشته خلال شهر تقريبًا مع «Claude Code». للمرة الأولى، شعرت أن الحاجز لم يعد في كتابة الـ «code». الحاجز صار في وضوح الفكرة، وترتيب النظام، ومعرفة ما يستحق البناء أصلًا.

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

في 2025، انكسر هذا النمط. الواجهة الجديدة صارت أبسط من أي لغة برمجة: كلمات ← منتج.

قصة سلّم: من الثنائي إلى الكلمات.

بدأت القصة من مكان قاسٍ. في الأربعينيات، كانت البرمجة تعني أن تكتب بلغة الآلة نفسها. أصفار وآحاد. تعليمات مباشرة للمعالج.

10110000 01100001

هذه تعليمة حقيقية لمعالج «x86». حتى تكتب برنامجًا، كان عليك أن تفكر مثل الآلة: تحفظ الأنماط الثنائية، تفهم الـ «hardware» من الداخل، وتقبل أن الخطأ الصغير لا يرحم. عدد قليل جدًا من الناس كان يستطيع فعل ذلك. ليس لأن البقية لا يفهمون المنطق، بل لأن الواجهة نفسها كانت طاردة.

ثم جاء «Assembly» في 1949، وأعطانا كلمات تُقرأ.

MOV AL, 61h

التعليمة نفسها تقريبًا، لكن الإنسان صار يقرأها. الـ «assembler» يحوّلها إلى لغة الآلة. ما زلت تحتاج إلى فهم الذاكرة والـ «registers»، لكنك لم تعد تكتب الأصفار والآحاد بيدك. كانت هذه أول طبقة تخفي التعقيد.

المشكلة أن «Assembly» مرتبط بالـ «hardware». تكتب لمعالج، ثم تكتشف أن ما كتبته لا يعمل على معالج آخر. البرمجة صارت أوضح، لكنها بقيت ملتصقة بالآلة.

في 1972، جاءت «C» وحرّكت الحاجز خطوة أخرى.

char c = 'a';

هنا لم تعد تسأل: أي «register» أستخدم؟ الـ «compiler» يتكفّل بذلك. تكتب مرة، ثم تجمع البرنامج للبيئة التي تريدها.

لهذا كانت «C» أساسًا لجزء كبير من عالم البرمجيات. منها خرجت أنظمة تشغيل مثل «UNIX»، ثم «Linux»، ثم «Windows». لم تكن سهلة، لكنها كانت نقلة ضخمة. صار المطور يفكر في البرنامج أكثر من المعالج.

لكن «C» بقيت صعبة. إدارة الذاكرة. تعريف الأنواع. تفاصيل كثيرة بينك وبين الفكرة.

ثم ظهرت «Python» في 1991، وكانت فلسفتها واضحة: اجعل المطور أقرب إلى ما يريد قوله.

c = 'a'

لا تعريف أنواع في كل سطر. لا إدارة ذاكرة في كل زاوية. ضجيج أقل حول الفكرة. ما كان يحتاج 50 سطرًا في «C» صار يكتب في 5 أسطر في «Python».

هنا دخلت فئات جديدة إلى البناء. باحثون، محللو بيانات، هواة، طلاب. لم يصبح الجميع مهندسين، لكن الباب صار أوسع. ومن هذا الاتساع خرجت موجة علم البيانات، وتعلم الآلة، ثم طفرة الذكاء الاصطناعي.

من الأوامر إلى الوصف

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

الأسلوب الأول مباشر: خطوة، ثم خطوة، ثم خطوة.

results = []

for user in users:
    if user["active"]:
        results.append({
            "id": user["id"],
            "name": user["name"]
        })

أنت هنا تشرح الطريق. تمر على العناصر. تفحص الشرط. تضيف النتيجة.

أما الأسلوب الوصفي، فيسأل سؤالًا مختلفًا: ما الحالة التي تريد الوصول إليها؟ لا يهمه أن تشرح كل خطوة. المهم أن تصف النتيجة بدقة.

دخلت «YAML» هذا الباب من أوسع جهاته في 2001. ثم بنت «Kubernetes» و«Terraform» حوله أنظمة كاملة في 2014.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: nginx:latest
          ports:
            - containerPort: 80

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

هذه الفكرة مهمة. لأنها تقرّبنا مما يحدث الآن مع الـ «agents». نحن لا ننتقل إلى لغة أسهل فقط. نحن نغيّر الواجهة بين الإنسان والآلة.

السلّم كاملًا

لو ضغطنا 80 سنة في جدول واحد، يظهر النمط بوضوح.

Layer              Year     What You Write              What Disappeared
---------------------------------------------------------------------------
Machine Code       1940s    10110000 01100001        Human-readable text
Assembly           1949     MOV AL, 61h              Binary patterns
C                  1972     char c = 'a';            Hardware registers
Python             1991     c = 'a'                  Memory management noise
Declarative        2001     replicas: 3              Step-by-step scripts
Agentic Coding     2025     "Build me..."            Programming as a barrier

في كل درجة من هذا السلّم، حدث شيء أكبر من اللغة نفسها. «C» لم تعطنا صياغة أجمل فقط. أعطتنا أساس صناعة البرمجيات. «Python» لم تختصر الأسطر فقط. فتحت الباب لعلم البيانات وتعلم الآلة.

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

لكن هناك ملاحظة لا يمكن تجاهلها: في كل هذه المراحل، بقيت البرمجة شرط الدخول. الصياغة تغيّرت. التعقيد قلّ. الأدوات تحسّنت. لكنك ما زلت تحتاج إلى أن تتعلم كيف تكتب الـ «code».

2025 ليست لغة جديدة

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

أتحدث عن سقوط البرمجة كحاجز أولي للبناء.

الواجهة الآن: تشرح ما تريد. الـ «agent» يقرأ المشروع، يكتب الـ «code»، يشغّله، يرى الخطأ، يصلحه، ثم يعرض عليك النتيجة. لا تنسخ من محادثة إلى محرر. ولا تلصق الخطأ في نافذة أخرى. ولا تدير الدورة بيدك.

هذا يعني أن بناء موقع، أو تطبيق، أو لعبة، أو أداة ذكاء اصطناعي، لم يعد يبدأ بسؤال: هل تعرف البرمجة؟ يبدأ بسؤال أدق: هل تستطيع وصف النتيجة؟

نعم، هناك حدود. الـ «agents» تخطئ، والجودة لا تأتي وحدها. لكن القفزة حقيقية. نسخ أولى من مشاريع كانت تحتاج فريقًا وميزانية كبيرة قبل سنتين، صارت تُبنى في أيام. أحيانًا في جلسة واحدة.

المهارة التي صعدت إلى الواجهة ليست حفظ الصياغة. بل الوضوح: أن تعرف ما تريد، أن تقسّمه، أن تراجعه، أن تحكم على جودته.

هذا ما شعرت به مع «Claude Code». وقتي لم يعد يذهب في سؤال: كيف أكتب هذا؟ صار يذهب في سؤال: ما الذي يجب أن يفعله هذا النظام؟

ما الـ «agentic coding» وكيف تستفيد منها

الفرق بين الدردشة والـ «agent»

أغلب الناس جرّبوا «ChatGPT» أو «Claude» في المتصفح. تسأل سؤالًا، يعطيك جوابًا. تطلب منه «code»، يعطيك كتلة جاهزة. تنسخها. تلصقها في المحرر. تشغّلها. يظهر خطأ. ترجع للمحادثة. تلصق الخطأ. يعطيك تعديلًا. ثم تعيد الدورة.

هذا ذكاء اصطناعي قائم على المحادثة. هو يتكلم. أنت تنفّذ.

CHAT-BASED AI

You ask:
  "Write a function that does X"

AI responds:
  "Here is the code..."

You:
  Copy code
  Paste into editor
  Run it
  See error
  Copy error
  Paste back into chat
  Get fix
  Copy fix
  Paste again

YOU are the executor. AI just talks.

الـ «agentic AI» مختلف. لا يكتفي بالكلام. يتصرف داخل بيئة العمل.

AGENTIC AI

You ask:
  "Add a contact form to this site"

Agent:
  Reads the codebase
  Finds the right files
  Writes the component
  Creates validation
  Runs the build
  Sees the error
  Fixes the error
  Tests again
  Shows the result

AI is the executor. You review and direct.

الـ «agent» لديه وصول إلى الـ «terminal». يقرأ الملفات، يكتب ملفات، يشغّل أوامر، يرى المخرجات، ثم يتصرف بناء عليها. هو لا يعطيك تعليمات. هو ينفّذ.

دورة الـ «agent»

داخل جلسة الـ «agentic coding»، تتكرر دورة بسيطة حتى تنتهي المهمة.

Prompt
  |
  v
Agent Thinks
  |
  v
Writes Code
  |
  v
Runs Command
  |
  v
Checks Output
  |
  v
Error?
  |---- Yes ----> Fixes Code ----> Runs Command
  |
  No
  |
  v
Shows Result / Asks for Feedback

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

كيف تطلب من «agent»

التعامل مع الـ «agent» ليس مثل البحث في «Google»، وليس مثل سؤال «chatbot». أنت لا تبحث عن معلومة. أنت تعطي مهمة لشخص سينفّذها داخل مشروعك.

لذلك، ابدأ بالنتيجة.

BAD:
"Make the site better"

GOOD:
"Add a contact form with name, email, and message fields.
Validate the email.
Send submissions to my-email@domain.com"

الجملة الأولى لا تعني شيئًا. ما معنى أفضل؟ أسرع؟ أجمل؟ أوضح؟ الجملة الثانية تقفل مساحة التخمين. النتيجة محددة، والحقول واضحة، والسلوك معروف.

أعطه السياق عندما يحتاجه.

BAD:
"Fix the bug"

GOOD:
"When I click the submit button, nothing happens.
The form is in /components/ContactForm.tsx"

لا تجعله يبحث في الظلام إذا كنت تعرف أين المشكلة. السياق الجيد يوفّر وقتًا، ويقلّل القرارات الغلط.

واترك له مساحة الاستكشاف قبل التنفيذ.

GOOD:
"Look at the codebase and explain the architecture"

GOOD:
"What would be the best way to add authentication here?"

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

راجع النتيجة، ولا تدير كل تفصيل صغير.

GOOD:
"This works, but use a modal instead of a new page"

GOOD:
"Good, but the button should be on the right side"

الـ «agent» سيتخذ قرارات. هذا جزء من قيمته. لا تحوّله إلى يد بطيئة تكتب أوامرك حرفيًا. أعطه الهدف، ثم راجع. إذا انحرف، صحّح الاتجاه.

ماذا يمكن أن تبني في جلسة واحدة؟

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

Blog with markdown support
  -> Full blog with posts, tags, RSS

Expense-tracking API
  -> REST API with database, auth, docs

Chrome extension that summarizes articles
  -> Ready to install locally

Sales dashboard
  -> Interactive charts, filters, CSV export

CLI tool to organize downloads folder
  -> Working script with file type detection

ليست فرضيات. بنيت نسخًا من كل هذه الأفكار. ليست كلها منتجات جاهزة للبيع من أول جلسة، لكنها ليست عروض «demo» فارغة أيضًا. هي بدايات تعمل، ويمكن تحسينها بسرعة.

التحوّل الذهني

استخدام الـ «agentic coding» يغيّر السؤال داخل رأسك. لا تعود عالقًا في: كيف أكتب هذا؟ تبدأ من: ما الذي يجب أن يحدث؟

OLD MINDSET                         NEW MINDSET
-----------------------------------------------------------------------
"How do I parse JSON in Python?"     "Extract the user data from this API response"

"What's the syntax for a POST        "Add a new endpoint that creates users"
 route in Express?"

"How do I center a div?"             "Make the hero section look professional"

Focus: Implementation                Focus: Outcome

أنت تصبح المعماري. الـ «agent» يتولّى البناء.

هذا لا يعني أن المعرفة التقنية بلا قيمة. العكس. من يفهم الأنظمة سيحصل على نتائج أفضل بكثير. لكن نوع المعرفة المطلوب تغيّر. لم تعد القيمة في حفظ الصياغة. القيمة في الحكم، والتصميم، وتقسيم العمل.

المهارات التي صارت أهم

إذا كان الـ «agent» يكتب الـ «code»، فما دورك؟ دورك يكبر، لكنه يتحرك إلى طبقة أعلى.

«Solution Architecture»

تصبح شغلك الأساسي. قبل أن يوجد أي «code»، تحتاج إلى تصور واضح: ما أجزاء النظام؟ كيف تتحدث مع بعضها؟ أين تُحفظ البيانات؟ ماذا يحدث عند الفشل؟

الـ «agent» يستطيع بناء ما تصفه. لكن إذا كان وصفك مرتبكًا، ستخرج النتيجة مرتبكة. التفكير المعماري الواضح ينتج أنظمة أسهل في الفهم والتعديل.

«System Design»

تصميم الأنظمة قريب من المعمارية، لكنه يركّز أكثر على الاختيارات. هل تبني «monolith» أو «microservices»؟ هل تستخدم «SQL» أو «NoSQL»؟ هل تحتاج معالجة فورية، أو تكفي معالجة على دفعات؟

لا تحتاج إلى معرفة كل تفاصيل التنفيذ بنفسك. لكنك تحتاج إلى معرفة الخيار المناسب لحالتك. الـ «agent» قد يسألك أسئلة جيدة، لكنه لا يعرف سياقك التجاري أو قيودك إلا إذا قلتها له.

إدارة المشروع

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

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

ضمان الجودة

الـ «agent» يكتب. أنت تتحقق. تختبر الحالات الطرفية. تراجع الأخطاء. تتأكد أن النظام يفعل ما تريده، لا ما كتبته في الطلب فقط.

نقطة لا أتنازل عنها. الـ «agents» تخطئ. تفهم الطلب أحيانًا بشكل قريب، لا صحيح. تأخذ اختصارات. تضيف تعقيدًا غير مطلوب. وتبني شيئًا يعمل في المسار السعيد فقط.

وظيفتك أن تمسك هذه الأشياء قبل أن تصل إلى الـ «production».

ما التالي؟

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

إذا كنت تعرف كيف تفكّر في الأنظمة، ستتحرّك أسرع. وإذا كنت مبتدئًا، فالباب صار أقرب مما كان. المهم ألا تتعامل مع الـ «agent» كآلة سحرية. عامله كمنفّذ سريع يحتاج إلى توجيه واضح ومراجعة جادة.

إذا أردت أن تبدأ عمليًا، ابدأ من هنا: دليل المبتدئين للـ «agentic coding» مع «Claude Code».