LevelUpGo
تسجيل الدخول
العودة إلى المدونة
Go · مقالة16 دقيقة للقراءة

كيف تحافظ على مهاراتك البرمجية حين يكتب الذكاء الاصطناعي الكود

ما المهارات الهندسية التي تضعف أولًا حين يكتب الذكاء الاصطناعي معظم الكود، وكيف تعرف أن مهاراتك بدأت تتراجع، وروتين أسبوعي للتدرب بلغة Go دون ذكاء اصطناعي يحافظ عليها.

Patrik Nilsson
مؤسس LevelUpGo
نُشر في 30 سبتمبر 2026
كيف تحافظ على مهاراتك البرمجية حين يكتب الذكاء الاصطناعي الكود

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

الخلاصة

  • مهارات التفكير تضعف أكثر من المهارات اليدوية. الطيارون المعتادون على الطيران بالأتمتة احتفظوا بقدرتهم على قيادة الطائرة يدويًا، لكنهم واجهوا صعوبة أكبر في الملاحة واكتشاف الأعطال (Casner et al., Human Factors, 2014). وأقرب ما يقابل ذلك لدى المبرمجين هو تتبع الأخطاء وقراءة الكود.
  • قد يظهر تراجع المهارة خلال أشهر. في دراسة رصدية، اكتشف الأطباء الذين استخدموا الذكاء الاصطناعي في تنظير القولون عددًا أقل من الزوائد السابقة للسرطان بعد إيقافه، إذ انخفضت النسبة إلى 22.4% بعد أن كانت 28.4% (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025).
  • اختبر نفسك بانتظام. هل تستطيع أن تشرح آخر diff دمجته؟ هل تستطيع أن تتتبع اختبارًا فاشلًا لمدة 20 دقيقة دون أن تكتب طلبًا للمساعد؟ إن لم تستطع، فهذه هي المهارات التي عليك أن تتدرب عليها.
  • روتين أسبوعي يكفي. حل مشكلة صغيرة واحدة يدويًا، وتتبع الخطأ قبل أن تسأل المساعد، وراجع الـ diffs التي يكتبها الذكاء الاصطناعي كأن مبتدئًا كتبها، واقرأ كود المكتبة القياسية، واكتب الاختبارات بنفسك.
  • اسأل الذكاء الاصطناعي «لماذا» لا «أصلح». توقّع الجواب أولًا ثم قارن. المهندسون الذين كانوا يتعلمون مكتبة جديدة واستخدموا الذكاء الاصطناعي لطرح الأسئلة تعلموها بقدر يقارب من كتبوا الكود يدويًا. أما الذين سلّموه المشكلة كلها فكانوا الأقل تعلمًا (Anthropic, 2026).

ما المهارات التي تضعف أولًا حين يكتب الذكاء الاصطناعي الكود؟

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

الطيران مثال مفيد للمقارنة. في دراسة أُجريت عام 2014، قاد 16 طيارًا تجاريًا جهاز محاكاة لطائرة Boeing 747-400، وخضعوا لاختبار في قيادتها يدويًا. كانت مهاراتهم في القيادة اليدوية «سليمة في معظمها». ظهرت المشكلات في المهام الذهنية: متابعة موقع الطائرة دون شاشة الخريطة، وتقرير الخطوة التالية، وملاحظة تعطل أحد الأجهزة (Casner et al., Human Factors, 2014). واقترح الباحثون أن يحافظ الطيارون على هذه المهارات بالبقاء منخرطين فعليًا في الإشراف على الأتمتة.

ووجد الطب شيئًا مشابهًا في 2025. في أربعة مراكز للتنظير في بولندا، قيس أداء أطباء كانوا يستخدمون أداة كشف بالذكاء الاصطناعي في عمليات تنظير قولون أُجريت من دونها. انخفض معدل اكتشافهم للأورام الغدية من 28.4% قبل إدخال الذكاء الاصطناعي إلى 22.4% بعده (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025). كانت دراسة رصدية وليست تجربة عشوائية، لكن الانخفاض حدث خلال أشهر.

وفي البرمجيات، يقودنا هذا إلى خمس مهارات.

عمودان. تضعف دون تدريب: تتبع الأخطاء دون مساعد، وقراءة كود غير مألوف، وتذكر الـ APIs من الذاكرة، والموازنة بين الخيارات في تصميم الأنظمة، وتقدير المدة التي يستغرقها العمل. تزداد أهميتها الآن: مراجعة diffs لم تكتبها، وكتابة مواصفات واضحة، والاختبارات والحالات الحدية، والبنية المعمارية والحدود.

تتبع الأخطاء

تتبع الأخطاء هو المهارة التي تستحق أن تراقبها عن كثب أكثر من غيرها. في تجربة Anthropic لعام 2026، واجهت مجموعة الكتابة اليدوية أخطاءً أكثر من مجموعة الذكاء الاصطناعي، ويعتقد الباحثون أن التعامل مع تلك الأخطاء هو ما بنى مهارتهم في تتبعها (Anthropic, 2026). وإذا كان المساعد يصلح لك كل خطأ، فلن تحصل على هذا التدريب أبدًا.

قراءة كود غير مألوف

حين يشرح لك وكيل ذكاء اصطناعي مشروعًا ما، فأنت لا تبني خريطتك الخاصة له. ولا بأس في ذلك إلى أن يكون الشرح خاطئًا أو لا يكون الوكيل متاحًا أثناء حادثة. وجد تحليل GitClear لـ623 مليون تغيير في الكود أن الاستدعاءات إلى كود موجود انخفضت من 343 إلى 223 لكل ألف سطر متغير بين 2023 و2026 (GitClear, 2026). وإعادة الاستخدام الأقل تتسق مع قراءة أقل لما هو موجود أصلًا.

معرفة الـ APIs من الذاكرة

التذكر أقل أهمية من المهارات الأخرى هنا، لكنك ما زلت تحتاج إلى قدر منه. لا تحتاج إلى حفظ كل دالة في strings. لكنك تحتاج إلى أن تعرف أن context.WithTimeout تعيد دالة إلغاء يجب أن تستدعيها، وأن http.Error لا تُنهي الـ handler الخاص بك. ودون هذه المعرفة لن تستطيع أن تعرف متى يكون الاقتراح خاطئًا.

تصميم الأنظمة والموازنة بين الخيارات

سيقترح عليك الذكاء الاصطناعي تصميمًا إذا طلبت منه. لكن الاختيار بين تصميمين معقولين يتطلب حُكمًا، والحُكم يُبنى باتخاذ القرارات والتعايش مع نتائجها. وإذا كان الوكيل هو من يختار الـ queue والـ schema وسياسة إعادة المحاولة، فلن تعرف أبدًا أي حدوسك كانت صائبة.

التقدير

إذا كان المساعد يؤدي جزءًا من العمل، فقد يبتعد إحساسك بالمدة التي تستغرقها الأشياء عن الواقع. في تجربة METR لعام 2025، استغرق المطورون ذوو الخبرة وقتًا أطول بنسبة 19% مع الذكاء الاصطناعي، لكنهم اعتقدوا بعد ذلك أنه جعلهم أسرع بنسبة 20% (METR, 2025). وإذا كان إحساسك بسرعتك قد يبتعد عن الواقع إلى هذا الحد، فقد تبتعد تقديراتك أيضًا.

كيف تعرف أن مهاراتك بدأت تتراجع؟

تعرف ذلك باختبار نفسك دون المساعد، لأن ملاحظته صعبة وأنت تعمل معه. وجدت Microsoft Research وCarnegie Mellon أن العاملين في مجال المعرفة الأكثر ثقة بالذكاء الاصطناعي أفادوا بأنهم يفكرون بطريقة أقل نقدًا في ما ينتجه (Lee et al., CHI, 2025).

جرّب هذه الفحوصات مرة في الشهر:

  1. اشرح آخر diff دمجته. اختر pull request حديثًا كتب الذكاء الاصطناعي معظمه. اشرح لزميل، أو بصوت عالٍ، لماذا يوجد كل تغيير فيه. إذا لم تستطع أن تشرح تغييرًا ما، فأنت لا تعرفه حقًا.
  2. تتبع خطأً لمدة 20 دقيقة دون أن تسأل المساعد. خذ الاختبار الفاشل التالي أو بلاغ الخطأ التالي واعمل عليه مستعينًا بالسجلات والـ debugger والكود المصدري فقط. لاحظ هل تمد يدك إلى المساعد خلال الدقيقتين الأوليين.
  3. اكتب دالة صغيرة انطلاقًا من ملف فارغ. حلّل ملف إعدادات، أو أعد محاولة استدعاء HTTP مع تأخير متزايد (backoff)، أو أزل التكرار من slice مع الحفاظ على الترتيب. تحقق هل تتذكر استدعاءات المكتبة القياسية أم تضطر إلى البحث عن كل واحد منها.
  4. توقّع قبل أن تشغّل. قبل تشغيل اختبار، اكتب هل سينجح. وإذا فشل، اكتب ما ستقوله رسالة الخطأ. إذا أخطأت في التخمين كثيرًا، فصورتك الذهنية عن الكود قد ابتعدت عن الكود نفسه.
  5. قدّر ثم قِس. قدّر المدة التي ستستغرقها مهمة ما، ثم قارنها بالمدة التي استغرقتها فعلًا. واتساع الفجوة يشير إلى أنك فقدت إحساسك بأين يذهب الوقت.

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

ما الفرق بين أن تفوّض العمل وأن تفوّض تفكيرك؟

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

وجدت تجربة Anthropic أن طريقة استخدام الناس للمساعد كانت أهم من مسألة استخدامه أصلًا، وخلص الباحثون إلى أن الجهد الذهني، «بل وحتى التعثر المؤلم»، مهم على الأرجح لإتقان المهارة (Anthropic, 2026). ويستعرض مقال هل ما زال عليك كتابة الكود يدويًا؟ أنماط الاستخدام التي حققت درجات جيدة.

وأبحاث التعلم تفسر السبب. يسمي Robert وElizabeth Bjork هذا النوع من الجهد «صعوبة مرغوبة» (desirable difficulty): يبدو أبطأ في حينه، لكنه يؤدي إلى تعلم أفضل على المدى الطويل (Bjork & Bjork, 2011). ومن أمثلتهما التباعد. فالتدرب الموزع على أسابيع يرسخ أفضل من القدر نفسه مضغوطًا في جلسة واحدة، ولهذا فالروتين أدناه أسبوعي. كذلك يتفوق استرجاع المعلومة على إعادة قراءتها (APS Observer on Roediger & Karpicke, 2006)، وهي دراسة يتناولها مقال هل ما زال عليك كتابة الكود يدويًا؟ بتفصيل أكبر.

لتعرف أيهما فعلت، اسأل نفسك بعد أسبوع: هل أستطيع أن أعيد كتابة هذا الكود دون أن أنظر إليه؟ إن استطعت، فقد فوّضت عملًا تفهمه. وإن لم تستطع، فعد وتعلّمه قبل أن تبني فوقه.

روتين أسبوعي للتدرب دون ذكاء اصطناعي

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

حل مشكلة صغيرة واحدة يدويًا

مرة في الأسبوع، افتح ملفًا فارغًا بعد إيقاف المساعد، وحل مشكلة واحدة صغيرة وحقيقية. اختر شيئًا قريبًا من عملك: محدِّد معدل (rate limiter)، أو محلل CSV يتعامل مع الحقول المحاطة بعلامات الاقتباس، أو worker pool يتوقف عند أول خطأ. التزم بمدة بين 30 و45 دقيقة. أنت تتدرب على الانتقال من ملف فارغ إلى كود يعمل، لذلك لا بأس أن تكون المشكلة صغيرة.

وإذا أردت مشكلات تأتي مع اختباراتها، ففي Training Ground على LevelUpGo تمارين Go مستقلة مصممة لهذا الغرض تحديدًا.

تتبع الخطأ قبل أن تسأل المساعد

حين يتعطل شيء ما، امنح نفسك وقتًا محددًا، 20 دقيقة مثلًا، قبل أن تسأل المساعد. ضع فرضية، وأعد إنتاج الخطأ، وقِس، وبعد ذلك فقط اسأل.

إليك خطأً يستحق التدرب عليه. خدمة تجلب أسعار الصرف من API بطيئة تابعة لجهة أخرى، وتتوقف عن الانتظار بعد 10 ميلي ثانية:

example.gogo
package main

import (
	"context"
	"errors"
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
	"time"
)

type Rate struct {
	Currency string
	Value    float64
}

func fetchRate(currency string) Rate {
	time.Sleep(50 * time.Millisecond) // a slow upstream API
	return Rate{Currency: currency, Value: 1.08}
}

func rateWithTimeout(ctx context.Context, currency string) (Rate, error) {
	ctx, cancel := context.WithTimeout(ctx, 10*time.Millisecond)
	defer cancel()

	result := make(chan Rate)
	go func() {
		result <- fetchRate(currency)
	}()

	select {
	case r := <-result:
		return r, nil
	case <-ctx.Done():
		return Rate{}, errors.New("rate lookup timed out")
	}
}

func main() {
	timeouts := 0
	for range 100 {
		if _, err := rateWithTimeout(context.Background(), "EUR"); err != nil {
			timeouts++
		}
	}
	fmt.Println("timeouts:", timeouts)
	time.Sleep(100 * time.Millisecond)
	runtime.GC()
	fmt.Println("goroutines:", runtime.NumGoroutine())
	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
}

في بيئة الإنتاج، يظهر هذا الخطأ على شكل نمو بطيء في الذاكرة، لا على شكل انهيار. وأول ما ينبغي قياسه هو عدد الـ goroutines. جعلت Go 1.27 ملف التحليل goroutineleak متاحًا للجميع (ملاحظات إصدار Go 1.27)، فصار بإمكان الـ runtime أن يدلك على التسريب بنفسه. وعند تشغيل البرنامج على Go 1.27 يطبع:

example.texttext
timeouts: 100
goroutines: 101
goroutineleak profile: total 100
100 @ 0x1048c59a8 0x10485e854 0x10485e468 0x10491c5ac 0x1048cbc74
#	0x10491c5ab	main.rateWithTimeout.func1+0x5b	./main.go:29

انتهت مهلة كل عمليات البحث المئة، وما زالت 100 goroutine حية إلى جانب main. السطر 29 هو result <- fetchRate(currency). كل عملية بحث تنتهي مهلتها تترك خلفها goroutine عالقة عند إرسال لن يستقبله أحد أبدًا، لأن rateWithTimeout قد عادت بالفعل. والإصلاح هو buffer بسعة واحد، حتى ينجح الإرسال دائمًا:

example.gogo
result := make(chan Rate, 1)

مع هذا التغيير، يطبع البرنامج نفسه goroutines: 1 وgoroutineleak profile: total 0. على الأرجح سيجد المساعد هذا الخطأ بسرعة. لكن الفائدة في أن تجده بنفسك، لأن التسريب التالي قد يكون في مكتبة لم يرها المساعد من قبل، أثناء حادثة تكون فيها وحدك. ويشرح مقال الكلمة المفتاحية chan في Go: الـ channels واتجاهاتها وحالات الـ deadlock قواعد الـ channels التي يقوم عليها هذا الخطأ بتعمق أكبر.

راجع الـ diff الذي كتبه الذكاء الاصطناعي كأن مبتدئًا كتبه

حين يفتح وكيل ذكاء اصطناعي pull request، اقرأه كما تقرأ واحدًا من عضو جديد في الفريق، ذكي لكنه لا يعرف نظامك. لا تكتفِ بسؤال نفسك هل يبدو صحيحًا. اسأل ما الذي افترضه. تحقق من مسارات الأخطاء، والتعامل مع الـ context، والأقفال، وما يحدث عند الاستدعاء الثاني.

الثقة بهذه الأدوات منخفضة أصلًا. في استطلاع Stack Overflow لعام 2025، كان 84% من المشاركين يستخدمون أدوات الذكاء الاصطناعي أو يخططون لاستخدامها، لكن 3.1% فقط كانوا يثقون بدقتها ثقة عالية (Stack Overflow, 2025). ووجد فريق DORA في Google أن الذكاء الاصطناعي لا يصلح الفريق. إنه «يضخّم ما هو موجود أصلًا» (DORA 2025, 2025). ولمعرفة ما يحدث حين تنهار المراجعة، يستعرض مقال الجانب المظلم لأدوات البرمجة بالذكاء الاصطناعي: ما تكشفه بيانات 2026 بيانات 2026.

اقرأ الكود المصدري للمكتبة القياسية

مرة في الأسبوع، اقرأ دالة واحدة من المكتبة القياسية في Go. إنها مكتوبة بعناية، وتعليقات التوثيق فيها كثيرًا ما تشرح قرارات التصميم. ولا تحتاج إلى تثبيت أي شيء:

example.bashbash
go doc -src net/http.Error
example.gogo
// Error replies to the request with the specified error message and HTTP code.
// It does not otherwise end the request; the caller should ensure no further
// writes are done to w.
// The error message should be plain text.
//
// Error deletes the Content-Length header,
// sets Content-Type to “text/plain; charset=utf-8”,
// and sets X-Content-Type-Options to “nosniff”.
// This configures the header properly for the error message,
// in case the caller had set it up expecting a successful output.
func Error(w ResponseWriter, error string, code int) {
	h := w.Header()
	// ...
	h.Del("Content-Length")
	h.Set("Content-Type", "text/plain; charset=utf-8")
	h.Set("X-Content-Type-Options", "nosniff")
	w.WriteHeader(code)
	fmt.Fprintln(w, error)
}

يشرح السطر الثاني من التعليق خطأً شائعًا: تكتب http.Error استجابة لكنها لا توقف الـ handler. إذا نسيت return بعدها، يواصل الـ handler التنفيذ. وإليك handler فيه هذا الخطأ بالضبط في فرع فك ترميز JSON:

example.gogo
type Order struct {
	ID       string `json:"id"`
	Quantity int    `json:"quantity"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
	var o Order
	if err := json.NewDecoder(r.Body).Decode(&o); err != nil {
		http.Error(w, "invalid JSON", http.StatusBadRequest)
	}
	if o.Quantity <= 0 {
		http.Error(w, "quantity must be positive", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(o)
}

اقتراحات كهذه تمر من المراجعة السريعة لأن الفرع الثاني يبدو صحيحًا. لكن بعد أن تقرأ الكود المصدري، يلفت نظرك غياب return فورًا. ومن الخيارات الجيدة للقراءة بعد ذلك sync.Once.Do وerrors.Is وcontext.WithCancel وhttp.MaxBytesReader.

اكتب الاختبارات بنفسك

اترك المساعد يكتب التنفيذ إن شئت، لكن اكتب حالات الاختبار بنفسك. تحديد ما يُعد صحيحًا هو الجزء من العمل الذي لا ينبغي أن تفوّضه. وإليك اختبارًا معتمدًا على الجداول للـ handler السابق:

example.gogo
func TestCreateOrder(t *testing.T) {
	tests := []struct {
		name     string
		body     string
		wantCode int
		wantBody string
	}{
		{"valid order", `{"id":"A1","quantity":2}`, http.StatusCreated, `{"id":"A1","quantity":2}` + "\n"},
		{"zero quantity", `{"id":"A1","quantity":0}`, http.StatusBadRequest, "quantity must be positive\n"},
		{"malformed JSON", `{"id":`, http.StatusBadRequest, "invalid JSON\n"},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(tt.body))
			rec := httptest.NewRecorder()

			createOrder(rec, req)

			res := rec.Result()
			body, _ := io.ReadAll(res.Body)
			if res.StatusCode != tt.wantCode {
				t.Errorf("status = %d, want %d", res.StatusCode, tt.wantCode)
			}
			if string(body) != tt.wantBody {
				t.Errorf("body = %q, want %q", body, tt.wantBody)
			}
		})
	}
}
example.texttext
--- FAIL: TestCreateOrder (0.00s)
    --- FAIL: TestCreateOrder/malformed_JSON (0.00s)
        handler_test.go:35: body = "invalid JSON\nquantity must be positive\n", want "invalid JSON\n"
FAIL

ينجح فحص رمز الحالة، لأن أول استدعاء لـ WriteHeader هو الذي يُعتمد، فتبقى الاستجابة 400. وحده فحص جسم الاستجابة يكتشف الخطأ. كان الخادم الحقيقي سيسجل أيضًا http: superfluous response.WriteHeader call، لكن فقط إن قرأ أحدهم السجلات. أن تقرر فحص جسم الاستجابة يعني أن تحكم على ما قد يسوء، وهذا الحُكم هو المهارة التي تتدرب عليها. وبعد إضافة return تنجح الحالات الثلاث كلها.

كيف تستخدم الذكاء الاصطناعي بحيث يعلّمك بدلًا من أن يحل محلك؟

استخدم الذكاء الاصطناعي لتختبر تفكيرك وتفهمه، وفكّر بنفسك أولًا. تساعدك في ذلك خمس عادات:

  • توقّع أولًا ثم قارن. قبل أن تطلب حلًا، اكتب طريقتك أنت في جملة أو جملتين، أو ارسم مسودة للكود. ثم اسأل المساعد وقارن. الفروق تكشف لك ما لم تكن تعرفه.
  • اسأل «لماذا» بدلًا من «أصلح». سؤال مثل «لماذا لا تنتهي هذه الـ goroutine أبدًا؟» يعطيك شرحًا يمكنك التحقق منه. أما «أصلح هذا» فيعطيك تعديلًا ستقبله دون أن تتعلم شيئًا.
  • اطلب تلميحات. أخبر المساعد أنك تتدرب وتريد تلميحًا واحدًا في كل مرة. معظم المساعدات ستتجاوب مع ذلك.
  • اجعله يختبرك. بعد انتهاء الجلسة، اطلب منه ثلاثة أسئلة عن الكود الذي غيّرته للتو. إذا لم تستطع الإجابة عنها، فاقرأ الكود من جديد.
  • أعد الكتابة من الذاكرة. حين تقبل كودًا مولَّدًا لم تفهمه تمامًا، أغلقه وأعد كتابته في وقت لاحق من اليوم نفسه. المواضع التي تتعثر فيها هي الأجزاء التي لم تتعلمها.

والفكرة نفسها تنطبق حين تتعلم من الصفر. يتناول مقال كيف تتعلم البرمجة في 2026 (دون أن تهدر سنتك الأولى) استخدام الذكاء الاصطناعي كمعلم خاص للمبتدئين.

ما المهارات التي صارت أهم الآن لا أقل؟

المهارات التي تحتاجها لتوجيه الذكاء الاصطناعي والتحقق من عمله صارت قيمتها أكبر مما كانت.

أوضحها المراجعة. يستطيع الوكلاء فتح pull requests أسرع مما يستطيع الفريق قراءتها، ولا بد أن يراجع أحدٌ كل واحد منها ويقرر ما يُدمج.

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

وتزداد أهمية الاختبارات حين لا تكون أنت من كتب الكود. الاختبارات هي طريقتك في إخبار الوكيل بمعنى الصواب وفي كشفه حين يخطئ، ولهذا ستستخدم الاختبارات المعتمدة على الجداول والـ fuzzing (درس Go عن الـ fuzzing) وأداة كشف التسابق (race detector) أكثر من قبل.

والأخيرة البنية المعمارية. يعمل الوكلاء جيدًا داخل حدود واضحة، لكن تحديد مكان هذه الحدود، وأي package يملك ماذا، وأي الـ interfaces تبقى ثابتة، ما زال مهمتك أنت.

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

أين يأتي دور LevelUpGo

يمكنك أن تؤدي الجزء الخالي من الذكاء الاصطناعي من هذا الروتين على LevelUpGo. يضع كل درس المفهوم على اليسار ومحررًا حقيقيًا على اليمين، دون إكمال تلقائي، ولا تتقدم إلا عندما يُترجَم كود Go الذي كتبته ويجتاز الاختبارات. تبدأ دورة Go Basics، التي يمكنك البدء فيها مجانًا، من الأساسيات. وفي دورة Professional Go Testing تتدرب على كتابة الاختبارات المعتمدة على الجداول بنفسك، أما دورة Concurrency Fundamentals فتغطي الـ goroutines والـ channels والإلغاء، وهو الكود الذي يستحق أكثر من غيره أن تكون قادرًا على تتبع أخطائه يدويًا.

الأسئلة الشائعة

كم من الوقت ينبغي أن أقضي في البرمجة دون ذكاء اصطناعي كل أسبوع؟

أنصحك بأن تبدأ بساعة إلى ساعتين في الأسبوع وأن تستمر على ذلك لأشهر. تفضّل أبحاث التعلم الجلسات القصيرة المتباعدة على الجلسات الطويلة المتفرقة (Bjork & Bjork, 2011). مشكلة صغيرة واحدة تحلها يدويًا، وخطأ واحد تتتبعه قبل أن تسأل المساعد، ودالة واحدة تقرؤها من المكتبة القياسية كل أسبوع تغطي المهارات الأكثر عرضة للخطر.

كيف أتدرب إذا كان فريقي يتوقع إنتاجًا بسرعة الذكاء الاصطناعي؟

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

هل يفقد المهندسون الأوائل مهاراتهم بسبب الذكاء الاصطناعي أيضًا؟

نعم. الخبرة لا تحميك. كان الطيارون في دراسة الطيران والأطباء في دراسة تنظير القولون محترفين ذوي خبرة، وأظهرت المجموعتان ضعفًا في المهارات حيث تولت الأتمتة جزءًا من العمل (Casner et al., 2014، Budzyń et al., 2025). يبدأ المهندسون الأوائل برصيد أكبر من المهارات التي يمكن أن يفقدوها، ومهارات التفكير هي التي تستحق المراقبة.

هل تكفي مراجعة كود الذكاء الاصطناعي للحفاظ على مهاراتي؟

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

هل يمكن استعادة المهارات التي فقدناها بسبب الذكاء الاصطناعي؟

الأبحاث في هذا الجانب قليلة، لذلك لا يستطيع أحد أن يعدك بذلك. قاست الدراسات المذكورة أعلاه المهارة في لحظة واحدة، ولم تقس التعافي. لكنها تُظهر أن المهارات التي واصل الناس استخدامها بقيت سليمة، مثل قيادة الطيارين اليدوية للطائرة (Casner et al., 2014). والإجابة العملية أن تبدأ بالفحوصات الذاتية المذكورة أعلاه، وتحدد أضعف مهاراتك، وتتدرب عليها أولًا.

المصادر

اكتب Go كما يكتبها مهندس أول

دروس تفاعلية في متصفحك. الدروس الأولى مجانية.

جرّب درسًا مجانيًاأو أنشئ حسابًا مجانيًا