TL;DR
- مهندسی برگشت 20 نوامبر 2025•6 دقیقه خواندن از زمانی که توسعه دهندگان وجود داشته اند،.
- ما به دنبال تجربه بهتر توسعه دهنده بوده ایم.
- هر جهش عمده در نرم افزار - از کامپایلرها و کنترل نسخه گرفته تا یکپارچه سازی مداوم و.
چه اتفاقی افتاد
مهندسی برگشت 20 نوامبر 2025•6 دقیقه خواندن از زمانی که توسعه دهندگان وجود داشته اند،. ما به دنبال تجربه بهتر توسعه دهنده بوده ایم.
هر جهش عمده در نرم افزار - از کامپایلرها و کنترل نسخه گرفته تا یکپارچه سازی مداوم و. زیرساخت ابری - از یک هدف ناشی شده است:.
ساختن چیزها سریعتر،. آسانتر و رضایت بخشتر شود.
اکنون، ما در نقطه عطف دیگری هستیم. برای اولین بار،.
ما ابزارهایی ساخته ایم که نه تنها روند نوشتن کد را بهبود میبخشند،. بلکه در واقع کد را برای ما مینویسند.
این تغییر،. از افرادی که بیشتر کدها را مینویسند به عواملی که بخش قابل توجهی از آن را می.
نویسند،. برخی از اساسیترین فرضیات ما را در مورد معنای "تجربه توسعه دهنده خوب" به چالش میکشد.
در Modal، ما همیشه به تجربه توسعه دهندگان وسواس داشتیم. بنابراین بهطور طبیعی،.
ما زمان زیادی را صرف فکر کردن در مورد معنای آن در این دنیای جدید کرده ایم. این پست چارچوبی برای نحوه تفکر ما ارائه میدهد تجربه توسعهدهنده در عصر عاملان کدنویسی - مجموعهای.
از اصول که طی سالها تکرار به آن رسیده ایم. آنها ایدههایی هستند که انسانها را خوشحالتر میکنند،.
ماموران را سریعتر میکنند و فاصله بین آنها را کمیآسانتر میکنند. انسانها و عوامل زمانی موفق میشوند که حلقههای بازخورد تنگ باشد اگر از ده مهندس بخواهید «تجربه توسعهدهنده.
خوب» را تعریف کنند،. ده پاسخ متفاوت دریافت خواهید کرد.
برای ما، چند الگو از کار با هزاران کاربر پدید آمده است. بیش از هر چیز دیگری، حلقههای تکرار سریع بیشترین اهمیت را دارند.
فاصله بین نوشتن کد و مشاهده نتایج باید تا حد امکان کوتاه باشد. چرا؟
زیرا برنامهنویسی یک چرخه مداوم از فرضیهها و اصلاحات است. شما تغییری ایجاد میکنید، کد را اجرا میکنید، ببینید چه اتفاقی میافتد و تنظیم کنید.
هرچه این حلقه تنگتر باشد، سریعتر یاد میگیرید. هر ثانیه اضافی - انتظار برای ساخت،.
تماشای استقرار،. کندن سیاههها - به اصطکاک تبدیل میشود که سرعت را کاهش میدهد.
کشف وقتی عوامل کدنویسی وارد تصویر شدند،. ابتدا نگران بودیم که طراحی برای انسان و طراحی برای عوامل ممکن است متفاوت باشد.
برخلاف انسانها، وقتی کارها کند میشوند، کارگزاران «ناامید» نمیشوند. اما با گذشت زمان،.
ما یک افشاگری شگفتانگیز داشته ایم:. بسیاری از کارهایی که برای عالی کردن تجربه توسعهدهنده Modal برای انسانها انجام داده ایم،.
برای نمایندگان نیز جواب میدهد. این به این دلیل است که عوامل به همان اندازه که انسانها به حلقههای بازخورد متکی.
هستند. آنها کد تولید میکنند،.
آن را اجرا میکنند،. آنچه را که اتفاق میافتد مشاهده میکنند و تطبیق میدهند.
این همان فرآیند تکراری است، فقط سریعتر و تحت اللفظیتر. وقتی این حلقه تنگ باشد، عوامل میتوانند به سرعت پیشرفت کنند.
هنگامیکه خراب میشود - به دلیل مبهم بودن یک خطا،. عدم دسترسی به پیکربندی یا نیاز به مداخله انسانی - آنها متوقف میشوند.
بهترین طراحی توانایی آنها را برای تلاش مجدد، سریع و صحیح تسریع میکند. بنابراین، طراحی برای نمایندگان، به معنای اختراع مجدد تجربه توسعه دهنده نیست.
در مورد استفاده از همان اصولی که انسانها را مولد میکند و اطمینان از اینکه زمانی که توسعهدهنده. دیگر انسان نیست،.
پایدار میمانند. بیایید در مورد اینکه آن اصول چیست صحبت کنیم.
دسترسی برنامهریزی شده حلقههای بازخورد را کوتاه میکند برای انسانها،. CLI یکی از مؤثرترین راهها برای محکم نگه داشتن حلقههای تکرار است.
به جای کلیک کردن روی یک رابط کاربری یا منتظر ماندن برای یک خط لوله استقرار چند مرحله. ای،.
یک فرمان را تایپ میکنید و بلافاصله نتایج را میبینید. نمایندگان حتی بیشتر سود میبرند.
هر کسی که از عاملهای کدنویسی استفاده کرده است میداند که شما باید ابزارهایی را در. اختیار آنها قرار دهید،.
و CLI سادهترین و جهانیترین ابزاری است که میتوانید به یک نماینده تحویل دهید. این یک روش ساختاریافته و قابل تکرار برای اجرای کد،.
گرفتن خروجیها و تلاش مجدد ارائه میدهد. اما کلید واقعی حلقههای بازخورد سریع، داشتن تمام عملکردهای مرتبط به صورت برنامهنویسی است.
یک CLI شروع خوبی است،. اما یک SDK یا API برای انعطافپذیری بیشتر و درجات حتی بیشتر باز میشود.
اتوماسیون اگر اطلاعات صورتحساب،. گزارشها یا جزئیات مربوط به محیط زمان اجرا شما - مانند تعداد کانتینرهای فعال یا سختافزاری که کد.
شما روی آن اجرا میشود - فقط از طریق یک رابط کاربری در دسترس هستند،. این امر هم انسانها و هم عوامل را محدود میکند.
Agentها،. به ویژه،.
زمانی بهترین کار را دارند که بتوانند از رابطهای مبتنی بر متن و ساختار یافته به جای. رابطهای گرافیکی استفاده کنند.
پیامهای خطای قابل اجرا،. اشکالزدایی را سریعتر میکنند،.
بیشتر زمان برنامهنویسی صرف رفع اشکال میشود،. به همین دلیل است که پیامهای خطا بسیار اهمیت دارند.
یک شکست کوتاه یا مرموز شما را گیر میکند و به دنبال اسناد یا Stack Overflow هستید. یک پیام خطای دقیق و کاربردی،.
همراه با نکات یا مثالها،. در عوض شما را به مسیر شاد باز میگرداند.
برای انسانها، این حلقه بازخورد را بهطور چشمگیری کوتاه میکند. برای نمایندگان، پیامهای خطا حتی مهمتر هستند.
مانند انسانها، عاملها به پنجرههای زمینه محدود متکی هستند. میتوانید آنها را با یک پایگاه کد کامل یا هزاران بارگذاری کنید از نشانههایی از اسناد.
- و گاهی اوقات لازم است - اما به ندرت کارآمد است. آنچه به مراتب بهتر است این است که فقط مرتبطترین اطلاعات را در لحظهای که به.
آن نیاز دارند ارائه دهند. یک پیام خطای دقیق و توضیحی که به شما میگوید چگونه مشکل را برطرف کنید،.
دقیقاً این است:. یک قطعه زمینه با سیگنال بالا که یک عامل میتواند بلافاصله برای اصلاح رفتار خود از آن.
استفاده کند. مثال زیر هشداری را نشان میدهد که یک باگ ظریف را میگیرد،.
که به راحتی از دست میرود،. و نحوه رفع آن را توضیح میدهد.
تجربه ما این است که این سطح از جزئیات در خطاها و هشدارها تجربه توسعهدهنده را هم برای. انسانها و هم برای عوامل به میزان قابل توجهی بهبود میبخشد.
مثالها پایهی یادگیری هستند که انسانها موجوداتی با الگو هستند. آنها با خواندن شرحهای طولانی درباره «مفاهیم اصلی» نمیآموزند،.
بلکه با تطبیق نمونههای عینی یاد میگیرند. کارگزاران نیز به همین صورت عمل میکنند.
آنها در پیروی و ترکیب مجدد الگوهایی که دیده اند فوق العاده هستند قبل از بنابراین،. هر چه مثالهای بیشتری ارائه کنید،.
احتمال بیشتری وجود دارد که یک عامل یا انسان،. نمونهای را به اندازه کافی نزدیک به مشکل خود بیابد تا بتواند با یک راهحل سازگار شود.
هر چند فقط داشتن مثالهای زیاد کافی نیست. هم انسانها و هم عاملها باید بتوانند از آنها استنباط کنند،.
بنابراین الگوها باید در سراسر کتابخانه شما سازگار باشند. اگر سه راه برای رسیدن به یک چیز وجود داشته باشد،.
و هر سه در مثالهای شما استفاده شود،. هم انسانها و هم کارگزاران دچار مشکل میشوند.
ما همچنین متوجه شده ایم که هم انسانها و هم عوامل از توضیحاتی که در نزدیکی کد قرار دارند،. سود میبرند.
در زیر قطعهای از مثال استنتاج vLLM ما آورده شده است:. حفظ زیرساخت و منطق در کنار هم از drift جلوگیری میکند.
YAML یک مثال کلاسیک است:. یک استقرار را در یک مکان بهروزرسانی کنید،.
و شما نیز نیاز دارید تطبیق تغییرات در سایر فایلها انسانها در اینجا اشتباه میکنند،. اما ماموران حتی بیشتر با هم مبارزه میکنند و اغلب زمینههای جدید را توهم میکنند یا تنظیمات را.
نادرست تنظیم میکنند. یک رویکرد بهتر این است که زیرساختها و منطق را با هم،.
در یک مکان و یک زبان حفظ کنیم. پیکربندی زیرساخت با پایتون به جای YAML مزایای زیادی دارد:.
از تجزیه و تحلیل استاتیک پشتیبانی میکند،. مستندات واضح و تکمیل خودکار را ارائه میدهد و برای عوامل کارآمدتر است.
با نزدیک نگه داشتن کد و پیکربندی مرتبط با هم،. موقعیت رفتار را بهبود میبخشد،.
بنابراین تعامل آنها به راحتی قابل مشاهده و استدلال است. همچنین قابلیت کشف را ساده میکند—شما میتوانید یک تابع را بررسی کنید یا آرگومانهای پشتیبانیشده را مستقیماً بررسی.
کنید،. بهجای شکار از طریق اسناد طرحواره.
و با کوچک و ثابت نگه داشتن سطح SDK،. هم برای انسانها و هم برای عوامل آسانتر است که در مورد آنچه ممکن است استدلال.
کنند. بهعنوان مثال،.
در اینجا نحوه تعریف شما آمده است یک تابع،. محیط آن و الزامات سخت افزاری آن در یک بلوک کد واحد با استفاده از Modal:.
وقتی همه چیز در کنار هم زندگی میکند - کد،. منابع،.
محیط - شما یک منبع خوانا و منفرد از حقیقت دریافت میکنید. بهویژه برای بارهای کاری هوش مصنوعی،.
که در آن محاسبات،. کد و دادهها به شدت با هم مرتبط هستند،.
این باعث میشود که تکرار سریعتر و کمتر در معرض خطا باشد. اسامینحوه تفکر ما را در مورد سیستمها شکل میدهند حتی با ظهور عوامل،.
انسانها هنوز در حال خواندن،. مرور و استدلال درباره کد هستند.
این امر نامگذاری را در تجربه توسعهدهنده مرکزی میکند:. نامها نحوه درک شما از یک سیستم را شکل میدهند.
توابع،. کلاسها و پارامترها باید آنچه را که واقعاً انجام میدهند منعکس کنند و به مفاهیمیکه انسانها قبلاً.
درک کردهاند،. ترسیم کنند.
وقتی نامها از شهود فاصله میگیرند، مدل ذهنی از بین میرود. ما زمانی از اصطلاح concurrency_limit برای توصیف اینکه چند کانتینر موازی میتوانند یک تابع را اجرا کنند.
استفاده کردیم. از نظر فنی درست بود،.
اما گیج کننده بود زیرا مدال همچنین از همزمانی درون کانتینرها پشتیبانی میکند. تغییر نام آن به max_containers این رفتار را آشکار کرد،.
زیرا نام را با مفهوم خاصی که کنترل میکرد همسو میکرد. این برای نمایندگان نیز مهم است.
نامهای مبهم خطر خطا و شکسته شدن حلقههای بازخورد را افزایش میدهند. میتوانید برخی از مشکلات را با نامهای طولانی و بیش از حد توصیفی بررسی کنید،.
اما این نامها برای انسانها دست و پا گیر میشوند – و برای نمایندگان گران قیمت هستند. با این حال،.
ارزش واقعی در هر انتخاب نام فردی نیست،. بلکه در سازگاری آن تصمیمات در سراسر سیستم شما است.
نامگذاری مختصر،. منسجم و شهودی به انسانها و عوامل کمک میکند تا بفهمند سیستم واقعا چگونه کار می.
کند. طراحی برای انسانها همچنین به معنای طراحی برای نمایندگان است که ما قصد نداشتیم برای نمایندگان طراحی.
کنیم. هدف ما کاهش زحمت برای انسانها و نگه داشتن آنها در حلقههای تکراری سریع و رضایت.
بخش بود. اما همان اصول - بازخورد سریع،.
خطاهای مفید،. قابل اجرا مثالها،.
منطق یکپارچه و مادونفرم،. و کد خوانا - همچنین شانس موفقیت عوامل را به حداکثر میرساند.
آینده توسعه ممکن است متفاوت به نظر برسد،. زیرا انسانها و عوامل کار بیشتری را به اشتراک میگذارند.
اما اساس یکسان است: هر دو به تجربه توسعهدهنده خوب برای پیشرفت نیاز دارند.
چرا مهم است
اهمیت این خبر در این است که روی استفاده واقعی از AI و تصمیمگیری سازمانی اثر میگذارد.
منبع
لینک منبع اصلی در کارت و صفحه مقاله نمایش داده میشود.