وقتی کد رو LLM مینویسه چطور باهاش آشنا بمونیم؟
هوش مصنوعیخلاصهٔ کاملتر
جاستین وایس تو وبلاگ مهندسی Aha! با یه سؤال ناراحتکننده شروع میکنه: کدی که یه ماه پیش با کمک LLM نوشتی و فرستادی روی پروداکشن، چقدر یادته؟ اگه کامیت امروزت اون رو بشکنه میفهمی؟ اگه مشتری باگ بده، هنوز اون حس «آهان، میدونم چیه» رو داری؟ به گفتهٔ او هرچی مدل بیشتر بنویسه، این آشنایی بیشتر آب میره: دیگه غریزی نمیدونی کد کجا زندگی میکنه و برای هر سؤال باید برگردی سراغ خود مدل.
مشکل اینجا حلقهٔ بازخورد منفیه. هرچی از کدبیس کمتر بدونی، راهنماییت به مدل بیکیفیتتر میشه؛ و وقتی مدل سر فیچر بعدی گیر میکنه، نه علتش رو میفهمی نه میتونی کمکش کنی. نویسنده میگه شاید برات مهم نباشه — مثلاً یه پروژهٔ یکبارمصرف که جای یه پکیج آماده رو گرفته — ولی اگه محصولیه که خودت یا شرکتت بهش وابستهاین، مهمه: آدمها به چیزی که میسازی تکیه میکنن و کد امروز باید سالها زنده بمونه.
چرا شهود اینقدر مهمه؟ چون از دل نوشتن دستی، خرابکردن و درستکردن، تصمیمگرفتن دربارهٔ جای کد جدید و ریفکتور کد قدیمی ساخته میشه. همون شهوده که وقتی یکی باگ پیدا میکنه بلافاصله جواب رو حدس میزنی، یا میدونی عوضکردن یه مقدار اینجا یعنی مایگریشن اونجا. نویسنده هشدار میده مدل با سه سیگنال کد مینویسه — دادهٔ آموزش، کدی که تو کدبیس میبینه، و راهنمایی تو — و وقتی سهم راهنمایی تو کم بشه و مدل بیشتر کد خودش رو ببینه، کدبیس آرومآروم به سمت میانگین کشیده میشه.
اولین پیشنهادش عجیبه: اشتباه کن. اون حس غافلگیری از جواب غلط چیزیه که یادگیری رو میچسبونه، ولی وقتی مدل کد مینویسه فرآیند خیلی صافه — مثل خوندن جوابهای آخر کتاب بدون فکرکردن به سؤال. پس عمداً موقعیت غافلگیری بساز: از مدل یه بهینهسازی عجیب بخواه، خودت حدس بزن چرا جواب نمیده و بعد ببین درست حدس زدی؛ یا ازش چند گزینه بگیر، مزیت و عیب هرکدوم رو خودت دربیار و بعد جهت بده.
دومی: خودت تایپ کن. مدل تو پیادهسازی اولیهٔ یه نقشه خیلی سریعتره ولی تو اصلاحهای ریز کندتر. همونطور که نوشتن دستنویسِ یادداشت کمک میکنه یادت بمونه، تایپکردن کد هم همینطوره؛ ضمن اینکه برای یه تغییر کوچیک مجبوری بفهمی مدل تا اینجا چی ساخته.
سومی: سؤال بپرس — اول از خودت. من چطور پیادهسازی میکردم؟ مدل چرا اینطوری کرد؟ چیزی رو که من از کد میدونم از قلم انداخته؟ اسم اون متغیر چرا اینه؟ حتی میتونی از خودت امتحان بگیری: بدون نگاهکردن، اسم همهٔ آبجکتهای درگیر این تغییر رو بگو، یا معماری سیستم بعد از این تغییر رو روی کاغذ بکش. بعد همون سؤالها رو از مدل بپرس؛ نویسنده میگه چیزهایی که اینطوری یاد گرفته موندگار بودن.
بقیهٔ عادتها دور و بر بازبینی میچرخن: بهجای نمای PR گیتهاب که فقط خطوط تغییرکرده رو نشون میده، کد رو تو ادیتور خودت باز کن تا بتونی جستوجو کنی، به تعریف بپری و بریکپوینت بذاری؛ بازبینی باید فعال باشه نه منفعل. برای تغییرهای بزرگ هم میشه از مدل خواست یه صفحهٔ HTML توضیحی با دیاگرام و لینک به کد بسازه، که البته فقط نقطهٔ شروعه. آخر کار مثل یه PR واقعی بازبینی کن: نویسنده به ایجنتهاش اجازهٔ کامیت تو مخزن اصلی نمیده و کامنتهاش رو با پیشوند AI? یا AI: تو کد میذاره.
نکات کلیدی:
- سپردن کد به مدل، شهود مهندس نسبت به کدبیس رو کم میکنه و راهنماییش رو ضعیفتر
- بدون راهنمایی انسانی، مدل کدبیس رو به سمت میانگین میکشه
- عمداً دنبال اشتباه و غافلگیری بگرد؛ تغییرهای کوچیک رو خودت تایپ کن
- از خودت و از مدل سؤال بپرس و از خودت امتحان بگیر
- کد رو تو ادیتور فعالانه بگرد و آخرش مثل یک PR واقعی بازبینی کن
- به حس «این زیادی پیچیدهست» اعتماد کن و همون رو به مدل بگو
