چگونه در دنیای LLM از برنامه نویسی لذت ببریم

آیا به سمت فرسودگی هوش مصنوعی هدایت می‌شوید؟ می ترسید شغل خود را به دست فردی با مهارت های برنامه نویسی کمی، بدون آرزوی کیفیت و حساب کلود بزرگ از دست بدهید؟ از کیفیت کد در پروژه های خود ناامید شده اید، یا بدتر از کد "خود"؟ این برای شماست.

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

همچنین: از آنجایی که مردم قبلا متن‌های من را با LLM تولید شده اشتباه می‌گیرند، به شما می‌گویم که این متن 100% انسان بدون هیچ گونه کمک هوش مصنوعی نوشته شده است.

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

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

من به عنوان یک برنامه نویس Haskell از نوشتن Haskell لذت می برم. بله، من محصولی را که در محل کار می‌سازیم بسیار دوست دارم، کارهایی را که می‌توانید با کتابخانه‌های منبع باز من انجام دهید را دوست دارم، اما من واقعا از فرآیند بیان افکارم به این زبان لذت می‌برم. من فرض می‌کنم که این برای بسیاری از شما صادق است، و همچنین در بسیاری از زبان‌های دیگر صادق نیست، که تا حدودی توضیح می‌دهد که چرا علاقه‌مندان به زبان‌های برنامه‌نویسی مختلف نظرات متفاوتی درباره روشن یا تاریک بودن آینده با کمک LLM دارند.

وقتی من کد تولید می کنم، بسیاری از این لذت در خطر است. پس، نکن، شاید. من می خواهم به نوشتن (حداقل بخش های لذت بخش) برنامه های Haskell ادامه دهم و نیازی به خواندن و بررسی (بیش از حد) کدهای تولید شده نداشته باشم. در عین حال، می‌خواهم از آن توکن‌ها استفاده خوبی کنم که به آرامی مغزم را نسوزد.

من می‌خواهم راهی را به شما نشان دهم که از برنامه‌نویسی لذت ببرید و در عین حال با LLM به‌جای اینکه ظاهرا سازنده‌تر به نظر برسید و لذت را از دست بدهید، با LLM کارآمدتر شوید.

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

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

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

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

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

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

از ابزارهایی مانند ابزار TODO یا حتی بهتر است فایل‌ها را با frontmatter علامت گذاری کنید تا موارد برنامه ریزی را به درستی دنبال کنید. LLM ها می توانند زمینه بزرگی داشته باشند، اما با این حال اگر بیش از حد پر باشد می تواند بی سر و صدا اطلاعات را از دست بدهد.

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

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

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

هدف از انجام تحقیقات عامل این نیست که تمام دانش مربوطه را به شما ارائه دهد یا تصمیمی بهتر از آنچه می توانستید بگیرید. نکته این است که شما مجبور نیستید روی آن عبارت «Let Me Google That For You» را انتخاب کنید. شما باید دامنه‌ای را که مدل‌سازی می‌کنید به خوبی نماینده درک کنید، در حالت ایده‌آل حتی بهتر.

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

مهارهای کد نویسی معمولی شما را به سمت "ابتدا برنامه ریزی، سپس اجازه کد عامل" را فریب می دهند. امتناع کنید. با هم برنامه ریزی کنید، اما بعد کدنویسی می کنید. به LLM بگویید که پایه کد شما را بررسی کند، اجازه دهید کارهای فعلی را به شما بگوید و همه مکان‌هایی را که باید ویرایش کنید، بیاورد، مشکلات احتمالی را ذکر کند، اجازه دهید تحقیقات پیشینه مرتبط را به شما یادآوری کند.

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

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

این گردش کار چندین مزیت دارد:

ایده آل برای پاکسازی، کارهای کوچک، کارهای معمولی، بازسازی های کم خطر. FIXME ها را در کد خود جا گذاشته اید (شاید عمدا برای صرفه جویی در وقت و انرژی)؟ شما 3 مورد جالب را نوشتید و 7 مورد مشابه خسته کننده را رها کردید؟ شما یک ماژول reorg در ذهن دارید و می خواهید آن را محک بزنید؟ آیا نیاز به تعویض یک کتابخانه نگهداری نشده با یک کتابخانه بهتر دارید؟ این موارد استفاده معتبر هستند. طراحی چیزی پیچیده از پایه احتمالا اینطور نیست.

گاهی وقت‌تان تمام می‌شود، اما می‌خواهید چیزی تمام شود، و شاید بقیه کارهایی که در برنامه‌تان وجود دارد، کارهای کم‌ریسکی باشند. خوب است که به نماینده سرپرست خود بگویید "من afk، این را تمام کن"، با کمی خوش شانسی صبح روز بعد به یک ویژگی تمام شده برمی گردی. اما مهم است که بیشتر کارهای کدنویسی را خودتان انجام دهید.

شاید به یاد داشته باشید که چگونه با ظهور شبکه های متخاصم مولد، تصاویر تولید شده توسط هوش مصنوعی ناگهان بسیار واقعی تر شدند. به طور خلاصه، شما یک مدل دارید ("مولد") که یک تصویر تولید می کند، و دیگری ("تبعیض کننده") که به آن می گوید چقدر خوب عمل کرده است. اینها با هم می توانند نتایج بسیار بهتری نسبت به ژنراتور به تنهایی ایجاد کنند. با استفاده از این ایده (که در شکل تعمیم‌یافته‌اش، اصلا جدید نیست) در کدنویسی به کمک LLM، یک چرخه بررسی خودکار دریافت می‌کنید.

قبول نکنید، حتی هیچ اثر هنری تولید شده توسط یک LLM را بدون چرخه بررسی خودکار مطالعه نکنید. این بدیهی است که مستقیما در مورد کد (در مواردی که هنوز اجازه تولید آن را می‌دهید) صدق می‌کند، اما به‌ویژه برای برنامه‌ریزی نیز. وقتی یک نماینده چیزی را کد می‌کند، وقتی کار را تحویل می‌دهد کار انجام نمی‌شود (یعنی برای چشم انسان مناسب است) زمانی که یک نماینده بازبینی یافته دیگری در مورد آن نداشته باشد. در مورد طرح ها هم همینطور.

عبور از حفره‌های منطقی در یک طرح (بازسازی یک تابع در کار شماره 2 که قرار است در مرحله 7 نوشته شود) و پیدا کردن آنها واقعا خسته کننده است، بنابراین یک نماینده بازبینی اضافه کنید که این کار را انجام دهد.

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

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

بله. این نتیجه منطقی حرف من است.

اما دلایل متعددی وجود دارد که چرا تکیه بر ویژگی های مدل مرزی ایده بدی است.

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

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

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

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

البته صرفه جویی در توکن ها ضروری است. برای صرفه جویی در توکن ها، تنظیمات نماینده، استفاده، اندازه زمینه، مهارت های خود و غیره را دوباره ارزیابی کنید. اما حتی اگر این کار را انجام دهید، و حتی اگر صندلی بزرگتری خریداری کرده باشید، ممکن است کافی نباشد.

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

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

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

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

برنامه نویسی در کل یک تلاش اجتماعی است. به عنوان مثال، در یک شرکت یا یک پروژه منبع باز، ما به یکدیگر درخواست های کششی ارسال می کنیم، مسائل را می نویسیم و پیام هایی را متعهد می کنیم. این یک شکل ارتباط است. حتی اگر شما تنها در پروژه خود باشید، خود گذشته شما مسائلی را می نویسد، پیام ها و روابط عمومی را برای خود آینده شما می نویسد. ارتباط بین انسان ها ستون توسعه نرم افزار است.

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

نمایندگان به راحتی به شما پیشنهاد می کنند که یک بدنه روابط عمومی کامل را به زبانی صحیح از نظر گرامری بنویسید و تمام جزئیات را در آنجا بنویسید. این ارتباط نیست. این یک خروجی ابزار است. با چنین متن‌هایی مانند اعداد محک یا اشکال‌زدایی رفتار کنید: آنها را به بدنه روابط عمومی دست‌نویس خود اضافه کنید، احتمالا در <جزئیات>، تا افراد بتوانند خودشان تصمیم بگیرند که آیا می‌خواهند آن را بخوانند یا نه. متوجه خواهید شد که اغلب آنها این کار را نمی کنند.

با همه اینها، من سازنده تر از بدون کمک LLM هستم. تشخیص دقیق آن دشوار است، شاید دو برابر سریعتر؟ این کمتر از آن چیزی است که بسیاری از کدنویس‌های فول ویبر به آن افتخار می‌کنند، اما اشکالی ندارد. من خودم را باغبانی تصور می‌کنم که از کودهای آلی ملایم استفاده می‌کند، در حالی که کدگذارهای vibe بیشتر شبیه غرق کردن مزارع خود در مواد شیمیایی صنعتی هستند. من معتقدم که راه من در حال حاضر پایدارتر است.

من عاشق برنامه نویسی Haskell هستم و انجام آن برای امرار معاش شغل رویایی من است. در ماه گذشته نگران بودم که این رویا اکنون متعلق به گذشته است. اما همه چیزهایی که در اینجا نوشتم چیزهایی است که یاد گرفتم تا این فعالیت را لذت بخش نگه دارم. به نظر می رسد کار می کند.

بیهودگی های LLM را به عنوان مضرات بالقوه برای سلامت روان خود در نظر بگیرید.

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

ای کاش ما قبلا از مزایای مطالعات عصبی آینده بر روی تأثیرات این موضوع بهره می بردیم، امیدوارم که خود را در معرض آزبست مغز قرار ندهیم.

آنچه من امیدوارم این است که حداقل در صنعت بتوانیم به نقطه‌ای برسیم که کارفرمایان متوجه شوند که استخدام مهندسان با الگوهای مختلف "هوش مصنوعی" و همکاری آنها در یک تیم ممکن است مفید باشد. این می تواند بسیار چالش برانگیز باشد (به عنوان مثال برای کاربران سخت گیر "بدون هوش مصنوعی")، اما من فکر می کنم راه هایی برای تحقق آن وجود دارد. بخش‌های مختلف یک سیستم (یا نقش‌های مختلف) ممکن است به رویکردهای متفاوتی نیاز داشته باشند، اما ممکن است مذاکره در مورد مرزها دشوار باشد: به عنوان مثال. من ترجیح می‌دهم که کاربران غیر هوش مصنوعی بررسی کد را انجام دهند، اما هنوز هم به سیاست‌گذاری جدی نیاز دارد (به عنوان مثال.

هیچ پیامی برای ارتکاب خودکار تولید نشده است؟) تا آنها را بسوزانید.

در متن باز، من به طور فزاینده ای آن را مانند @chrisdone می بینم ... ما به سمت یک تقسیم می رویم و فکر می کنم خوب است.

اوه، من در مورد کدبرگ شنیده بودم، اما نمی‌دانستم sourcehut نیز مبتنی است

همچنین به فکر شما در مورد استخدام مربوط می شود. من فکر کرده ام که آیا امروزه فقط مسئولیت یک شرکت و صدور حکم "کلیه کدنویسی LLM ممنوع است" سیاست خوبی خواهد بود. به نظر می رسد که یک "فیلتر" محکم و tbh idt شما را می سوزاند اگر به هر حال تجارت شما اساسا محکم باشد. (و اگر مهندس خوبی هستید که مهندسان خوبی را استخدام کرده اید. این فیلتر در این مورد کمک خواهد کرد.)

آیا در حال حاضر در اکثر شرکت ها اینطور نیست؟ من شخصا در یک تیم مختلط کار می کنم و کاملا خوب کار می کند. و من خودم تمایل دارم بین کدگذاری عاملی و دستی جایگزین کنم.

یا منظورتان این است که استفاده از LLM باید واضح تر و ساختارمندتر شود؟ به عنوان مثال X یک توسعه دهنده بدون هوش مصنوعی است، بنابراین برای کار Y و غیره مناسب تر است…

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

به نظر می رسد که من قبلا بسیاری از پیشنهادات مقاله شما را دنبال کرده ام!

خیانت شده؟ آیا مطمئن هستید که این کلمه مناسبی برای استفاده در اینجا است؟ "خیانت" یک اتهام بسیار قوی است. من گیج شده‌ام زیرا در یک برنامه ماهانه OpenAI هستم و هزینه‌های اعتباری و محدودیت‌های زمانی مشخصی دارد که در آن محدودیت‌های استفاده از اعتبار اعمال می‌شود. ساختار محدودیت ها گهگاه تغییر می کند اما با تایپ /status در Codex شفاف هستند و به راحتی قابل مشاهده هستند.

شاید ارائه‌دهنده یا مهارکننده دیگر کارها را کمتر شفاف انجام دهد؟ یا شاید شما در حال صحبت از محدودیت‌هایی هستید که توسط کسی که هزینه اشتراک شما را پرداخت می‌کند (مانند کارفرمای شما)؟

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

شاید OpenAI این جنبه خاص را کمتر از Anthropic انجام دهد، که من نمی دانم. من نتوانستم بفهمم چند توکن در صندلی تیم کلود کد وجود دارد، بنابراین فقط باید آن را یک عدد دلخواه فرض کنم که بر اساس آنچه آنها می‌خواهند تغییر کند.

شاید من اشتباه می کنم، اما معتقدم که این توسط هیچ ارائه دهنده ای محقق نشده است.

من می‌دانم که این غیرواقعی است که در سرمایه‌داری/فئودالیسم فن‌آوری در مراحل پایانی، از یک فناوری مخرب در حال تکامل سریع تقاضا کنیم، اما این بدان معنا نیست که من باید وضعیت موجود را منصفانه بیابم.

FWIW من تا کنون تجربه بسیار خوبی با DeepSeek API و dsh (هرنس DeepSeek) داشته ام. من دقیقا می دانم که قیمت توکن ها چقدر است، از چند توکن استفاده می کنم و هر کاری که مدل انجام می دهد، از جمله فرآیند استدلال.

تجربه خود را در استفاده از LLM با وظایفی مانند نگهداری بسته چگونه ارزیابی می کنید؟

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

این مشکل به نظر می رسد، اگر چیزی باشد که هنگام شروع پرداخت به آنها از آن آگاه نبودید. با این حال، من برای آشتی دادن با "آیا به سمت فرسودگی هوش مصنوعی هدایت می‌شوید؟" و غیره با "ما به اندازه ای که می خواهیم هوش مصنوعی دریافت نمی کنیم". به نظر می رسد یک تناقض در آنجا وجود دارد! این من را به یاد وودی آلن می اندازد: "غذا اینجا وحشتناک است" - "بله، و چنین بخش های کوچک".

من نمی توانم به جای تام صحبت کنم، اما تجربه من در استفاده از LLM در حوزه "اولیه" و "API عجیب و غریب" (مانند ویندوز و پاورشل) بسیار ضعیف است. اما من فقط از آنها برای جستجو استفاده کرده ام. به عنوان مثال آنها powershell را به خوبی درک نمی کنند و درست کردن مواردی مانند فراخوانی فرآیند چیزی است که به تحقیق دقیق یا آزمون و خطای گسترده نیاز دارد. LLM ها اغلب به جای بهترین راه حل ممکن، به راه حل های رایج همگرا می شوند. و این احتمالا جایی نیست که بخواهید هنگام نگهداری از یک کتابخانه اصلی در آن باشید.