چرا باید اصول برنامه‌نویسی رو یاد بگیری وقتی AI همه چیز رو می‌نویسه؟

یه سوال جدی هست که بیشتر و بیشتر آدم‌ها می‌پرسن — خصوصاً کسایی که تازه شروع کردن: الان که Claude Code یه component کامل React رو توی ده ثانیه می‌نویسه، الان که GPT یه API endpoint رو با تمام error handling‌اش تحویل می‌ده، واقعاً باید بشینم data structure یاد بگیرم؟ باید algorithm بفهمم؟ باید بدونم HTTP دقیقاً چطور کار می‌کنه؟

جواب صادقانه: بله. ولی نه به همون دلیلی که فکر می‌کنی.

مدل کد می‌نویسه، تو تصمیم می‌گیری

یه چیزی که توی استفاده از AI coding tools خیلی زود مشخص می‌شه اینه که کیفیت خروجی مستقیماً به کیفیت input تو وابسته‌ست. اگه ندونی چی می‌خوای، مدل هم نمی‌دونه. اگه ندونی معماری درست چیه، خروجی مدل ممکنه technically بی‌نقص باشه ولی برای پروژه‌ات کاملاً اشتباه.

یه مثال ساده: از Claude Code می‌خوای یه caching layer بسازه. اگه ندونی فرق Redis و یه in-memory cache ساده چیه، نمی‌دونی کِی از کدوم بخوای. اگه ندونی race condition یعنی چی، نمی‌فهمی که خروجی مدل این مشکل رو داره یا نه. اگه ندونی TTL چطور کار می‌کنه، نمی‌تونی بگی آیا مدل اون رو درست تنظیم کرده یا نه.

مدل کد می‌نویسه. تو تصمیم می‌گیری این کد چیه و چرا.

review کردن بدون فهمیدن ممکن نیست

یه اشتباه رایج اینه که فکر می‌کنیم «می‌خونیم» کد AI رو. ولی خوندن بدون درک، review نیست — یه نگاه انداختنه که حس خوبی می‌ده ولی هیچ چیزی رو تضمین نمی‌کنه.

وقتی AI یه function می‌نویسه که O(n²) complexity داره و تو نمی‌دونی این یعنی چی، می‌گی «خوبه، merge می‌کنم» — و شاید واقعاً هم خوب باشه. ولی وقتی data ات از ده هزار record به یه میلیون رکورد می‌رسه، اون function سرور رو می‌خوابونه. این اتفاق نه به‌خاطر اینه که مدل اشتباه کرد — مدل چیزی نوشت که برای context ای که داشت معقول بود. اشتباه اینجا بود که کسی که review کرد نفهمید مشکل کجاست.

debugging جایی‌ه که اصول واقعاً مهم می‌شن

هر چیزی که AI می‌نویسه، در یه لحظه‌ای اشتباه می‌کنه — یا مدل اشتباه می‌کنه، یا کد توی production با شرایطی مواجه می‌شه که مدل پیش‌بینی نکرده بود. اون لحظه، تنها کسی که می‌تونه مشکل رو پیدا کنه و درستش کنه توئی.

debugging یه مهارتیه که بدون فهمیدن اصول ممکن نیست. نمی‌تونی race condition پیدا کنی اگه ندونی thread یعنی چی. نمی‌تونی memory leak رو trace کنی اگه lifecycle object ها رو نفهمی. نمی‌تونی بفهمی چرا request تایم‌اوت می‌شه اگه ندونی TCP handshake چطور کار می‌کنه.

AI توی debugging هم کمک می‌کنه — ولی فقط اگه بدونی چه اطلاعاتی بهش بدی. اگه ندونی دنبال چی می‌گردی، error log رو copy می‌کنی توی chat و امیدوار می‌شی مدل جواب بده. گاهی می‌ده. ولی این یه روش قابل اعتماد نیست.

یه نقطه‌ی ظریف درباره‌ی سرعت

یه غلط‌فهمی وجود داره که «اصول یاد گرفتن» یعنی زمان زیادی می‌بره و در آخر هم مستقیماً استفاده نمی‌شه. ولی اصول قراره چیزی باشن که دیگه بهشون فکر نمی‌کنی — اتوماتیک تبدیل می‌شن به شهود.

وقتی یه توسعه‌دهنده باتجربه یه codebase جدید رو می‌بینه، می‌فهمه مشکل architecture کجاست — نه به‌خاطر اینکه یه checklist داره، بلکه چون دیده‌ها و تجربه‌هاش به یه حس تبدیل شدن. این همون چیزیه که با AI codingهای سطحی از دست می‌ره.

هرچقدر اصول قوی‌تر باشن، از AI هم بهتر استفاده می‌کنی. چون prompt های بهتری می‌نویسی، خروجی رو بهتر ارزیابی می‌کنی، و زودتر می‌فهمی کِی باید از مدل کمک بخوای و کِی باید خودت فکر کنی.

اصول چه چیزی نیستن

اینجا یه تفاوت مهم هست که باید مشخص بشه: یاد گرفتن اصول با حفظ کردن syntax یه زبان یا دونستن تمام APIهای یه فریم‌ورک فرق داره. دومی رو الان واقعاً AI بهتر از تو می‌دونه. اگه نمی‌دونی Array.reduce چطور کار می‌کنه، بپرس. اگه نمی‌دونی کدوم CSS property برای این استفاده می‌شه، بپرس.

ولی اینکه چرا state management پیچیده می‌شه، چرا database query ات کند شده، چرا این race condition فقط توی production اتفاق می‌افته — اینا رو باید بفهمی. اینا قراره بخشی از طرز فکر تو بشن، نه اینکه هر بار از صفر از مدل بپرسی.

جواب سوال اول

پس چرا باید اصول یاد بگیری؟

نه برای اینکه AI کدت رو بنویسه و تو باید بدونی که نوشته. نه برای اینکه شاید یه روز AI نباشه — هست و بیشتر هم می‌شه.

بلکه چون کار یه توسعه‌دهنده همیشه بیشتر از نوشتن کد بوده. طراحی سیستم، تصمیم‌گیری، تشخیص مشکل، ارزیابی trade-off ها — اینا هنوز جایی هستن که ابزار جایگزین فکر نمی‌شه. AI سرعت رو بالا می‌بره، ولی اگه نقطه‌ی شروع ضعیف باشه، فقط سریع‌تر به جای اشتباه می‌رسی.

اصول یاد می‌گیری تا بتونی از AI درست استفاده کنی — نه به‌رغم اینکه AI هست.