هوش مصنوعی برای برنامه نویسی: وقتی چند مدل کد و طراحی‌ات را نقد می‌کنند

برایِ کارهایِ تکراریِ یک برنامه‌نویس، از انتخابِ معماری تا پیدا کردنِ ریشه‌یِ باگ، کدام نوعِ نشستِ چندهوش به کار می‌آید و صندلی‌ها را چطور بچینی.

هوش مصنوعی برای برنامه نویسی معمولاً یعنی یک دستیار که کد می‌نویسد؛ ولی سخت‌ترین بخشِ کار، تصمیم‌هایی است که اشتباه‌شان دیر معلوم می‌شود: کدام معماری، کدام کتابخانه، ریشه‌یِ این باگ کجاست. در چندهوش این سؤال‌ها را جلویِ چند مدلِ مختلف می‌گذاری تا جدا جدا جواب بدهند و هم را نقد کنند، و در پایان یک حکمِ نوشته‌شده می‌گیری که اختلاف‌ها را هم پنهان نمی‌کند.

کارهایِ رایجِ برنامه‌نویس‌ها و نشستِ مناسبِ هرکدام

جدولِ زیر شش کاری را که زیاد پیش می‌آید به یک تنظیمِ مشخص وصل می‌کند. این‌ها پیشنهادِ شروع‌اند؛ بعد از دو سه نشست، چیدمانِ خودت را پیدا می‌کنی.

در ردیفِ بازبینیِ کد، داور تشخیص می‌دهد که تو یک خروجیِ آماده خواسته‌ای، پس حکم خودِ همان فهرستِ ایرادهاست که بهترین بخش‌هایِ نظرِ صندلی‌ها را کنارِ هم می‌گذارد، بدونِ تاریخچه‌یِ بحث. اگر می‌خواهی ببینی چرا نظرِ چند مدل در بازبینی به کار می‌آید، این نوشته درباره‌یِ نقدِ کد توسطِ چند مدل را بخوان.

نقش‌ها و دستورالعمل‌هایی که برایِ کدنویس‌ها جواب می‌دهد

چندهوش یک قالبِ نقشِ آماده برایِ برنامه‌نویسی دارد که می‌توانی مستقیم رویِ صندلی‌ها بگذاری. ولی ارزشِ واقعی در «دستورالعملِ این صندلی» است، چون می‌توانی هر صندلی را رویِ یک دغدغه‌یِ مشخص قفل کنی:

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

یک مدل می‌تواند در بیش از یک صندلی بنشیند، پس اگر به یک خانواده بیشتر اعتماد داری، می‌توانی آن را با دو نقشِ متفاوت بنشانی و یک خانواده‌یِ دیگر را منتقد کنی. سبکِ مدل‌ها با هر نسخه عوض می‌شود؛ ترکیبی را نگه دار که رویِ کدِ خودت نتیجه داده است.

هوش مصنوعی برای برنامه نویسی وقتی پایِ تصمیمِ پرهزینه وسط است

بعضی تصمیم‌ها، مثلِ انتخابِ پایگاه‌داده یا شکستنِ یک سیستمِ بزرگ، ماه‌ها رویِ کارت اثر می‌گذارند. برایِ این‌ها دو ابزارِ چندهوش را جدی بگیر. اول «وکیلِ مدافعِ شیطان»: صندلی‌ای که کارش مخالفت است تا میز زود به یک جوابِ راحت قانع نشود. دوم «حالتِ دقتِ بالا»: بعد از حکم، قوی‌ترین مخالفتی را که حل نشده با دو صندلیِ منتقد مستقیم به چالش می‌کشد. اگر حکم از این مرحله سالم بیرون بیاید، با خیالِ راحت‌تری سراغِ پیاده‌سازی می‌روی. برایِ منطقِ پشتِ این کار، نوشته‌یِ انتخابِ معماری با کمکِ چند مدل را ببین.

«نقشه‌ی تصمیم» هم برایِ مستندسازی به درد می‌خورد: نشان می‌دهد کجا توافق بود، کجا اختلاف ماند و چرا حکم این شد. حکم را می‌توانی به PDF یا Word خروجی بگیری یا با یک پیوندِ فقط‌خواندنی برایِ هم‌تیمی‌ها بفرستی، و متنِ کاملِ گفتگو را هم دانلود کنی.

کنترلِ هزینه وقتی هر روز سؤال داری

پرداخت در چندهوش به اندازه‌یِ مصرف است و اشتراکِ ماهانه ندارد. قبل از هر نشست هزینه‌یِ تخمینی و بازه‌اش را می‌بینی و می‌توانی «سقفِ هزینه» بگذاری که از آن رد نشود. چند عادت که برایِ برنامه‌نویس‌ها هزینه را پایین نگه می‌دارد:

• به‌جایِ کلِ ریپازیتوری، فقط فایل‌هایی را بفرست که به سؤال ربط دارند؛ متنِ کمتر یعنی مصرفِ کمتر.
• برایِ سؤال‌هایِ روزمره عمقِ «سریع» یا «عادی» و مدل‌هایِ سبک‌تر کافی است؛ «خیلی عمیق» را برایِ تصمیم‌هایِ بزرگ نگه دار.
• برایِ دیدنِ سلیقه‌یِ مدل‌ها «مقایسه‌ی خالص» معمولاً ارزان‌ترین نوع است، چون فقط یک دور دارد.
• بعد از حکم، سؤالِ تکمیلی بپرس؛ همان صندلی‌ها کوتاه جواب می‌دهند و بحث از نو شروع نمی‌شود.

جزئیاتِ کیف پول و شارژ در صفحه‌یِ قیمت‌ها آمده است.

محدودیت‌هایی که یک برنامه‌نویس باید بداند

• توافق یعنی درستی نیست. چند مدل می‌توانند یک اشتباهِ رایج را با هم تکرار کنند، مثلاً یک تابعِ قدیمی را پیشنهاد بدهند. هر تغییری را خودت تست کن؛ حکم جایِ تست و اجرایِ واقعی را نمی‌گیرد.
• رمز و کلیدِ واقعی نفرست. پیش از پیوست کردنِ فایلِ تنظیمات یا لاگ، کلیدهایِ API، رمزها و اطلاعاتِ مشتری را پاک کن.
• زمینه را کامل بگو. نسخه‌یِ زبان، محدودیتِ سرور و اندازه‌یِ تیم را در موضوع بنویس؛ «بررسیِ برداشتِ ما» (رایگان) کمک می‌کند مطمئن شوی سؤالت درست فهمیده شده است.
• تصویر برایِ همه یکسان نیست. اگر اسکرین‌شاتِ خطا می‌فرستی، مدل‌هایی را انتخاب کن که تصویر را خوب می‌فهمند.

نمونه‌ی فرضی: انتخابِ روشِ ارسالِ یادآوری در یک اپِ نوبت‌دهی

این یک نمونه‌یِ ساختگی است، نه یک نشستِ واقعی. فرض کن بک‌اندِ یک اپِ نوبت‌دهیِ کلینیک را می‌نویسی و باید یادآوری‌هایِ پیامکی را بفرستی. سه راه داری: یک کارِ زمان‌بندی‌شده که هر چند دقیقه جدولِ نوبت‌ها را می‌خواند، یک صفِ پیام، یا یک سرویسِ زمان‌بندیِ جدا.

1. نوعِ نشست را «آرنا» می‌گذاری و سه گزینه را در موضوع می‌نویسی.
2. سه صندلی از سه خانواده‌یِ متفاوت می‌چینی و با «دستورالعملِ این صندلی» به هرکدام یک گزینه می‌دهی تا مدافعش باشد.
3. ریپازیتوریِ GitHub پروژه را پیوست می‌کنی و در موضوع می‌نویسی که سرور یکی است و تیم دو نفر.
4. عمق را «عمیق» می‌گذاری تا دورهایِ نقد بیشتر باشد و یک سقفِ هزینه تعیین می‌کنی.

با سه نامزد، حداکثر یک نفر ممکن است حذف شود، آن هم فقط اگر رأی‌گیری روشن باشد؛ رأیِ مساوی کسی را بیرون نمی‌کند. در حکم دنبالِ این‌ها باش: مسیرِ حذف و تعدادِ رأی‌ها، «برنده»، «چرا»، «قوی‌ترین نامزدِ حذف‌شده» (شاید صف کنار رفته ولی برایِ رشدِ بعدی بهتر بوده باشد)، «چه چیزی نتیجه را عوض می‌کرد» و «برایِ صاحبِ پروژه». اگر برنده کارِ زمان‌بندی‌شده باشد، یک سؤالِ تکمیلی بپرس: «از چه حجمی به بعد باید سراغِ صف رفت؟»

جمع‌بندی

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