کدنویسی با هوش مصنوعی

مدل ها در کدنویسی دقیقا در چه کاری خوب اند؟

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

کارهایی که واقعا خوب انجام می شوند: نوشتن کدی که هزار بار مشابهش نوشته شده، مثل خواندن یک فایل، اعتبارسنجی یک فرم، یا یک درخواست شبکه با مدیریت خطا. ترجمه از زبانی به زبان دیگر. تبدیل داده از یک شکل به شکل دیگر. نوشتن تست برای تابعی که خودتان نوشته اید. توضیح دادن کدی که کس دیگری نوشته و شما با آن غریبه اید. و کاری که کمتر کسی از آن استفاده می کند و بازده اش از همه بیشتر است: نقد کردن کدی که خودتان نوشته اید.

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

موضع ما ساده است: مدل را روی کاری بگذارید که خودتان می توانستید انجام دهید ولی حوصله اش را ندارید، نه روی کاری که خودتان بلد نیستید. چون در حالت اول می توانید خروجی را قضاوت کنید و در حالت دوم فقط می توانید امیدوار باشید.

توسعه دهنده هایی که هر روز از این ابزارها استفاده می کنند چه می گویند؟

به جای حدس زدن، به بزرگ ترین نظرسنجی عمومی این حوزه نگاه کنیم. نظرسنجی سالانه توسعه دهندگان استک اورفلو در سال ۲۰۲۵ می گوید ۸۴ درصد پاسخ دهندگان از ابزارهای هوش مصنوعی استفاده می کنند یا قصد دارند، و ۵۱ درصد توسعه دهندگان حرفه ای هر روز از آنها استفاده می کنند. پس بحث «آیا استفاده کنیم» تمام شده است.

ولی همان نظرسنجی چیز دومی هم می گوید که کمتر نقل می شود. وقتی از همین آدم ها پرسیده شد ابزارهایی که استفاده می کنند کارهای پیچیده را چقدر خوب انجام می دهند، ۴.۴ درصد گفتند خیلی خوب و ۲۵.۲ درصد گفتند خوب ولی نه عالی. در مقابل، ۲۲ درصد گفتند بد و ۱۷.۶ درصد گفتند خیلی ضعیف. ۱۴.۱ درصد نه خوب و نه بد، و ۱۶.۸ درصد گفتند برای کارهای پیچیده از این ابزارها استفاده نمی کنند یا نمی دانند. یعنی کسانی که این ابزارها را روزانه دستشان است، در کارهای پیچیده بیشتر منفی اند تا مثبت.

و عدد سومی که کل این درس را جمع می کند: بزرگ ترین شکایت، با ۶۶ درصد، «راه حل هایی که تقریبا درست اند ولی نه کاملا» بود. «تقریبا درست» بدترین حالت ممکن است. کد کاملا غلط را کامپایلر یا اولین اجرا می گیرد. کد تقریبا درست از هر دو رد می شود و ماه ها بعد در یک حالت خاص خودش را نشان می دهد.

بقیه همان فهرست شکایت ها هم ارزش خواندن دارد، چون شکل هزینه را نشان می دهد: ۴۵.۲ درصد گفتند دیباگ کردن کد تولیدشده وقت بیشتری می برد، ۲۰ درصد گفتند به توانایی حل مسئله خودشان کم اعتمادتر شده اند، و ۱۶.۳ درصد گفتند فهمیدن اینکه کد چطور و چرا کار می کند سخت است. در آن سر فهرست، فقط ۴ درصد گفتند اصلا به هیچ مشکلی برنخورده اند.

یک نکته درباره خود این عددها، چون درس صداقت هم هست: اینها نظر آدم ها است و نه اندازه گیری کیفیت کد. یعنی می گویند توسعه دهندگان چه تجربه ای دارند، نه اینکه مدل ها به طور عینی چقدر خوب اند. برای این درس همان اولی مهم است.

کدام ابزارها، و از ایران کدامشان واقعا در دسترس اند؟

ابزارها سه شکل دارند و انتخاب بین آنها بیشتر از آنکه به مدل ربط داشته باشد، به این ربط دارد که کجا کار می کنید.

افزونه داخل ویرایشگر پیشنهاد می دهد در حالی که تایپ می کنید. گیتهاب کوپایلوت شناخته شده ترین شان است. مزیتش این است که چیزی را قطع نمی کند و ضررش این است که چون همیشه پیشنهاد می دهد، عادت می کنید بدون خواندن قبولش کنید.

گفتگوی جدا در مرورگر، مثل کلود یا جمنای. برای فکر کردن و نقد کردن و فهمیدن بهتر است تا برای نوشتن، چون کد را از متن پروژه جدا می کند و همین جدایی، شما را مجبور می کند خودتان بگویید مسئله چیست.

عامل خط فرمان یا ویرایشگر عامل دار، مثل کلود کد یا کرسر، که خودشان فایل ها را می خوانند و می نویسند. قوی ترین شکل و پرخطرترینش: وقتی ابزاری بدون اینکه هر تغییر را نشانتان بدهد ده فایل را عوض می کند، بازبینی تبدیل می شود به تنها چیزی که بین شما و یک باگ نامرئی ایستاده.

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

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

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

گردش کاری که کیفیت را نگه می دارد: تست اول، دیف کوچک، بازبینی واقعی

سه عادت هستند که تفاوت بین کسی که با مدل سریع تر کار می کند و کسی که با مدل بدهی فنی تولید می کند را می سازند. هیچ کدام به مدل ربط ندارند و هر سه مال شمایند.

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

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

بازبینی واقعی. بازبینی یعنی برای هر خط بتوانید بگویید چرا اینجاست. اگر به خطی رسیدید که نمی دانید چه کار می کند، سه راه دارید: بپرسید، خودتان بفهمید، یا حذفش کنید. راه چهارم که همه انتخاب می کنند این است که چون بقیه کار می کند رهایش کنید، و آن خط دقیقا همان خطی است که شش ماه بعد به آن برمی گردید.

یک عادت چهارم هم هست که ارزان است و کم استفاده می شود: کدی را که خود مدل نوشته، در یک پیام جدا از خودش نقد بخواهید. در یک پیام تازه، بدون تاریخچه گفتگو، فقط کد را بگذارید و بپرسید این چه ایرادهایی دارد. جواب هایی می گیرید که اگر همان جا در ادامه گفتگو می پرسیدید نمی گرفت، چون در ادامه گفتگو نقش مدل دفاع از چیزی است که خودش ساخته.

چه چیزی را هیچ وقت نباید در پیام بگذارید؟

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

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

راه عملی هم ساده است. کلید را با یک رشته بی معنی جایگزین کنید، و اگر کلیدی را یک بار در چت گذاشتید، آن کلید دیگر معتبر نیست و باید عوضش کنید؛ نه به این دلیل که حتما لو رفته، به این دلیل که دیگر نمی دانید کجا هست. برای داده کاربر، چند ردیف ساختگی با همان شکل بسازید. شکل داده همان چیزی است که مدل لازم دارد و محتوایش نه.

اگر تازه کارید، از کجا شروع کنید؟

یک نگرانی واقعی هست که ارزش دارد رک جوابش را بدهیم: اگر مدل کد را می نویسد، من کی یاد می گیرم؟

خطرش واقعی است و در همان نظرسنجی هم دیده می شود؛ ۲۰ درصد پاسخ دهندگان گفته اند در توانایی حل مسئله خودشان کم اعتمادتر شده اند. مکانیزمش هم روشن است: یادگیری از گیر کردن می آید، و ابزاری که گیر کردن را حذف می کند، همان چیزی را حذف کرده که یاد می داد.

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

و یک آزمون ساده که به شما می گوید کجای این طیف ایستاده اید: کدی را که مدل نوشته ببندید و همان کار را از حافظه توضیح دهید. اگر می توانید بگویید چه کار می کند و چرا این طور، خوب است. اگر نمی توانید، آن کد هنوز مال شما نیست؛ چیزی است که اجاره کرده اید و اجاره اش را روزی که خراب شود می پردازید. بقیه پایه هایی که این آزمون را ممکن می کنند در مسیر یادگیری برنامه نویسی هستند.