دستیارِ هوش مصنوعی: همکار، نه جایگزین

در این فصل چه یاد می‌گیری#

هر کسی که امروز برنامه‌نویسی یاد می‌گیرد، یک دستیارِ هوش مصنوعی هم در دسترس دارد. وانمود کردن به اینکه تو استفاده نمی‌کنی بی‌صداقتی است، و رها کردنت با آن هم بی‌مسئولیتی. پس این فصل صریح دربارهٔ آن حرف می‌زند: چه سؤال‌هایی واقعاً یادگیری‌ات را تندتر می‌کنند، چه سؤال‌هایی بی‌سروصدا از یادگیری بازت می‌دارند، و یک قاعدهٔ ساده که در کلِ این دوره تکرار می‌شود.

آخر این فصل می‌توانی:

• بگویی چرا «برایم بنویس» و «توضیح بده» دو نتیجهٔ کاملاً متفاوت می‌دهند
• چهار سؤالی را که واقعاً کمک می‌کنند از بر بگویی و به‌کار ببری
• خروجیِ یک دستیار را با اجرای واقعی وارسی کنی
• بگویی چه چیزهایی را هرگز نباید داخلِ پرامپت بگذاری

قبل از شروع#

از فصل ۷: تابع، return، و اینکه یک تابع باید بتواند ورودیِ بد را هم مدیریت کند.

از فصل ۸: خواندنِ traceback از خطِ آخر.

📓 نوت‌بوک: نوت‌بوک این فصل را در Colab باز کن — همهٔ کدهای این فصل آماده و به‌ترتیب داخلش هست.

۱. آنچه پژوهش می‌گوید، بدونِ تعارف#

بررسی‌های آموزشیِ چند سالِ اخیر یک الگوی روشن دارند: برای کسی که تازه شروع کرده، دستیارِ کدنویسی مثلِ یک جعبهٔ سیاه عمل می‌کند — کدِ آماده تحویل می‌دهد بدونِ آنکه یادگیرنده درگیرِ همان فرآیندِ استدلالی شود که اصلاً دانشِ برنامه‌نویسی از آن ساخته می‌شود. استفادهٔ زیاد هم با «برون‌سپاریِ شناختی» همراه شده است: کارِ فکری به ابزار سپرده می‌شود و مهارت شکل نمی‌گیرد.

ولی تصویر یک‌طرفه نیست. یک مطالعهٔ کنترل‌شده روی مبتدی‌ها نشان داد کسانی که از تولیدکنندهٔ کد استفاده کردند تکلیف‌ها را بیشتر و بهتر تمام کردند، و در کارهای بعدیِ بدونِ کمک هم بدتر نشدند.

جمع‌بندیِ همان پژوهش‌ها این است: مسئله خودِ ابزار نیست، نوعِ سؤال است. تمرکز باید از تولیدِ کد به استدلال، توضیح و تجزیهٔ مسئله جابه‌جا شود. کلِ این فصل همان یک جمله است.

۲. قاعدهٔ ثابتِ این دوره#

از دستیارت بخواه چیزی را توضیح بدهد، نه اینکه برایت بنویسد. هر کدی که نمی‌توانی خط‌به‌خط توضیحش بدهی، کدِ تو نیست.

این سخت‌گیری نیست، حسابِ سرانگشتی است. کدی که نفهمیده‌ای، وقتی خراب شود نمی‌توانی درستش کنی؛ وقتی نیاز به تغییر داشته باشد نمی‌دانی کجایش را دست بزنی؛ و وقتی جوابِ غلط بدهد اصلاً متوجه نمی‌شوی. پس هزینه‌اش را نه امروز، بلکه دقیقاً وقتی می‌پردازی که بیشترین فشار را داری.

اگر کدی گرفتی که نمی‌فهمی، دو راه بیشتر نداری: یا بفهمش، یا دورش بینداز. راهِ سوم — «فعلاً کار می‌کند، بعداً می‌فهمم» — همان راهی است که آدم‌ها را بعد از شش ماه در جایی نگه می‌دارد که روزِ اول بودند.

۳. چهار سؤالی که واقعاً کار می‌کنند#

و چهار سؤالی که در ظاهر مفیدند و در عمل یادگیری را متوقف می‌کنند: «کلِ این تمرین را برایم بنویس»، «چرا کار نمی‌کند؟ فقط کدِ درست را بده»، «بهترین راه چیست؟» (بدونِ گفتنِ اینکه بهتر از نظرِ چه چیزی)، و «این را ساده‌تر کن» روی کدی که هنوز نفهمیده‌ای.

۵. یک نکتهٔ ظریف: دستیار مطمئن حرف می‌زند، حتی وقتی غلط است#

دستیارِ هوش مصنوعی هیچ نشانه‌ای به تو نمی‌دهد که کِی مطمئن است و کِی حدس می‌زند. لحنش در هر دو حالت یکسان است. این خصوصیتِ ذاتیِ این ابزارهاست، نه یک نقصِ قابلِ‌رفع.

در برنامه‌نویسی این یک مزیتِ بزرگ دارد که در خیلی حوزه‌های دیگر نداری: کد را می‌شود اجرا کرد. لازم نیست بحث کنی که جواب درست است یا نه — بگذارش در نوت‌بوک، اجرا کن، حالت‌های مرزی‌اش را امتحان کن. اجرا داورِ نهایی است.

پس قاعدهٔ ساده: هر کدی که از دستیار می‌گیری، قبل از اعتماد اجرا و آزمایش می‌شود. مخصوصاً وقتی نامِ کتابخانه یا متدی می‌آورد که نمی‌شناسی — گاهی متدی را پیشنهاد می‌دهد که اصلاً وجود ندارد و کاملاً منطقی هم به‌نظر می‌رسد.

💡 نکته: این همان نخی است که خودآموزِ هم‌هوش کلِ دوره‌اش را رویش بنا کرده: «مدل مطمئن است؛ دلیل نمی‌شود درست باشد». اگر می‌خواهی بدانی این ابزارها چرا این‌طورند — چرا توهم می‌کنند و چطور وارسی‌شان کنی — آن دوره دقیقاً همان را کامل توضیح می‌دهد.

واژه‌های تازهٔ این فصل#

در فصل بعد#

فصلِ بعد به یک تلهٔ کاملاً متفاوت می‌پردازد، تله‌ای که خاصِ محیطِ کارِ ماست: نوت‌بوک می‌تواند دروغ بگوید. کدی که روی صفحه کاملاً درست به‌نظر می‌رسد، ممکن است اصلاً اجرا نشود؛ و عددی که می‌بینی، ممکن است حاصلِ کدی باشد که ده دقیقه پیش پاکش کرده‌ای. یاد می‌گیری چرا این اتفاق می‌افتد و تنها آزمونی که واقعاً جوابش را می‌دهد چیست.