چطور سه شرکت بزرگ فن‌آوری: مایکروسافت، آمازون و گوگل نیرو استخدام میکنند؟

این مقاله که نوشته‌ی Carlos Arguelles رو توصیه میکنم که از دست ندین.

پ.ن: نویسنده، خودش رو اینطوری معرفی میکنه:
Senior Principal Engineer (L8) at Amazon. In the last 26 years, I've worked at Google and Microsoft as well.

اگر اهل کتابید (نه اون اهل کتاب معروف، منظورم اهل کتاب خوندنه) به‌نظرم راه انداختن اکانت goodreads و کانکت شدن با آدم‌های کتاب‌خون و یا دوست و رفیقاتون یک لطفیه در وهله‌ی اول به خودتون و بعدش به رفیقاتون. چقدر بدون مقدمه‌چینی شروع کردم! :))

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

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

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


اگر خواستید توی کامنت‌های این پست میتونید اکانت خودتون رو بذارید که هرکسی که مایل بود بهتون کانکت بشه.

محسن طهماسبی توی این پست سعی کرده تا وضعیت "اینترنت" (بخونید اینترانت ملی!) رو شرح بده و این رو مطرح کنه که شرایط اینترنت در ایران حتی بدون فیلترینگ هم وخیم و بغرنجه.

این نوشته رو در ویرگول بخونید:

"داستان یک شبکه معیوب: چرا شبکه و اینترنت ایران بدون فیلترینگ هم خراب است؟"

نسیمی کز بن آن کاکل آیو
مرا خوشتر ز بوی سنبل آیو

حدس کولاتز

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

این حدس می‌گوید: مهم نیست که مقدار n چه باشد، در نهایت این دنباله همیشه به ۱ ختم خواهد شد.

مسئله حل نشده در ریاضیات:
آیا دنباله کولاتز در نهایت با شروع از هر عدد طبیعی دلخواه به ۱ ختم می‌گردد؟

اینجا بیشتر بخونید.

اینجا هم میتونید برای عدد دلخواهتون، دنباله اعداد تولید شده رو روی نمودار ببینید.

نمودار دنباله‌ی اعداد، با نقطه‌ی شروع ۷.

این متن رو از توییت رامین خسروی مستقیم نقل میکنم. روایتی واقعا خوندنی و صد البته دیدنی:

ماریا ژِآوُ پرز، پیانیست پرتغالی برای کنسرتی به رهبری ریکاردو شایی به آمستردام دعوت می‌شود، اما پشت تلفن، کنسرتو پیانو k. 466 را با k. 488 اشتباه می‌‌گیرد. و هفته‌ها کنسرتوی اشتباه را تمرین می‌کند. در روز کنسرت در برابر ۲۰۰۰ تماشاچی، با اولین نت‌های ارکستر متوجه اشتباهش می‌شود. لحظاتی از هراس و به قول خودش مسئولیت بزرگ در برابر شنوندگان، اما با کمک رهبر بزرگی مانند شایی، در عرض چند دقیقه و بدون قطع اجرای ارکستر، حافظه عضلانی خود برای اجرای قطعه درست را باز می‌یابد و بدون حتی یک خطا، تا انتها اجرا را ادامه می‌دهد.


مستند زیر، روایتیه از زبان Riccardo Chailly راجع‌به ماجرا و اون لحظه که ثبت شد:

https://www.youtube.com/watch?v=fS64pb0XnbI

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

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

میخوام سعی کنم که اون‌جا بیشتر بنویسم و این‌جا بهش رفرنس بدم. اگر نظری داشتید توی کامنت‌های این پست واسم بنویسید. ممنونم.

قانون Littlewood's

“a person can expect to experience events with odds of one in a million (referred to as a "miracle") at the rate of about one per month.”

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

چراییش و مفروضاتش از این قراره:

“Littlewood defines a miracle as an exceptional event of special significance occurring at one in-a-million frequency. He assumes that during the hours a human is awake and alert, a human will see or hear one "event" per second, which may be either exceptional or unexceptional. Additionally, Littlewood supposes that a human is alert for about eight hours daily.
As a result, in 35 days, a human will have experienced about one million events under these suppositions. Therefore, accepting this definition of a miracle, one can expect to observe one miraculous event every 35 days, on average – therefore, according to this reasoning, seemingly miraculous events are commonplace.”

قانون Truly Large Numbers

اگر به تعدادی زیاد (و کافی)، نمونه‌ی تصادفی مستقل داشته باشیم، امکان وقوع هر رخداد نادری (یا به تعبیر بالاتر، معجزه) ممکنه.

مثالی که براش میزنه هم جالبه:

“In high availability systems even very unlikely events have to be taken into consideration, in series systems even when the probability of failure for single element is very low after connecting them in large numbers probability of whole system failure raises (to make system failures less probable redundancy can be used - in such parallel systems even highly unreliable redundant parts connected in large numbers raise the probability of not breaking to required high level).”

منابع: ۱، ۲

خب ماجرا از این جا شروع شد که یه استاد اقتصاد دانشگاه Milan-Bicocca در این توییت سر گشاده خیلی بی‌اعصاب‌طور به تمام متقاضیان PhD در سرتاسر جهان گفتش که اگه research statement‌تون رو با چت جپت/Chatgpt نوشتید، اسم منه دیه نیارید! عکس research statement نمونه‌ای رو هم گذاشته زیر توییتش.
بعدش گفته نمره‌ات رو صفر میدم، ازین به بعد وقت ما و خودتم نگیر. مرسی اه :)) [بزرگوار لامصب استریتوتایپ استاد ایرانیه‌ها قشنگ! حالا جلوتر میبینید چرا. تایم امتحانا و نمراتم هست ذهنا آمادست و دل‌ها خون😭😢]

و بزرگوار شب خوابید و صبحش پا شد(البته خودش میگه نصف شب نوتیفاشو دیدم دیگه خوابم نبرد) دید هزارتا کامنت و فحش و اینا گرفته که بَبَم جان تو از کجا فهمیدی chatgpt بوده و روشی نیست که به صورت قطعی بتونه تشخیص بده و ازین جور احادیث خلاصه.

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

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

اولیشو میگه پر لغاتی بود که تیکه کلام chatgpt عه! اع مگه chatgpt هم تیکه کلام داره؟
بله متاسفانه. کلماتی مثل delve, crucial, intricate, ... اینا از کلمات پرتکراری هستن که جپت عاشق اوناست.

این وسط یه پرانتز نسبتا بزرگ هم باز کنم که یه مقاله‌ای اخیرا منتشر شده به اسم
"Delving into Chatgpt usage in academic writing through excess vocabulary"
که توش میان و بررسی میکنن که چقدر از جپت تو نوشتارهای علمی استفاده شده است. جواب یک کلمه‌ایش اینه که خیلی! خیلی خییلی زیاد(همون اندازه که کافیه عشقت رو به پول بفروشی). ولی موردهای جالبی هم داره که این توییت یه سری نتایج رو نشون میده که تو عکس در پیام پایین میذارم.
🔗 توییت مربوط به مقاله، پایان پرانتز.

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

چرا اینارو دارم میگم؟
نکته اینجاست که این مسئله از چند جنبه جالبه و این ازون جاهاست که به قول جادی موضوع در تقاطع تکنولوژی و جامعه است. پس فکر کردن به اینا و بحث و گفتگو راجع بهش به‌نظرم جالب و مفیده(حتما اگه خواستید نظرتونو نسبت به این نوشته یا کلا موضوع بگید.).

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

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

خلاصه این بود انشای من.
#LLM
@SingularThinker

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

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

https://youtu.be/41RqAbh0D4k

تایتل شاید سیاسی به‌نظر بیاد ولی ماجرا اصلا سیاسی نیست،‌ اساسا اقتصادیه! تو این ویدیوی چراز، به بررسی قسمت‌های مختلف بودجه می‌پردازن. اکیدا توصیه میکنم که ببینید.

«ملت میخوان بچه‌دار شن هم باید برن بودجه رو بخونن پس؟! باید بخونن!»

داستان تعزیه در ایران، به روایت MMehran. رشته‌ توییتی‌ست خوندنی:

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

https://x.com/MMehran/status/1560264132703571968

بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشن‌ای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابع‌تون چیزی شبیه به اینه :

fun foo(int x, int y, int z, int t) {
    
    // bunch of statements

    if ( (x^t+1)^3 + (2.3*y)^2.3 - 0.8*(z^4) == 0) { // call the condition as 'f'
        Bug();
    }

    // bunch of statements
}

همونطور که ملاحظه می‌کنید، توی برنامه‌ما یک point ای وجود داره که اگر reachable باشه به باگ می‌خوریم. حالا سوالی که وجود داره اینه که بفهمیم آیا این امکان وجود داره که شرط f ارضا بشه یا خیر. برای اینکه به جواب سوال‌مون برسیم، باید یک decision procedure پیاده‌ کنیم که به عنوان ورودی فرمول f رو ازمون بگیره، و بهمون true یا false برگردونه. یک computer scientist اولین سوالی که به ذهنش میرسه اینه که آیا این مسئله محاسبه پذیره یا خیر و اگر هست از نظر پیچیدگی در چه کلاسی قرار داره. به طور خلاصه خدمتتون میگم که این مسئله undecidable هستش. حالا سوالی که پیش میاد اینه که چیکار کنیم؟ رهاش کنیم بره؟ خب قطعا نه. یه راهی که از دهه ۵۰ میلادی، یعنی از زمان پانچ کارت ها وجود داره اینه که بیایم شروع کنیم با یک الگوریتم Pseudo random number generating برای این ۴ تا متغیر value جنریت کنیم و چک کنیم ببینیم که آیا این فرمول تحت اون assignment ارضا میشه یا نه. اگر شد که خب میگیم بله reachable هستش و برنامه مون باگ داره. اگر نشد... خب بیاید این یه تیکه رو فعلا اسکیپ کنیم :)

حالا قضیه‌ی Fuzzing هم ریشه‌اش برمیگرده به random testing اما قطعا با رندوم تستینگ فرق داره. می‌تونیم بگیم رندوم تستینگ ساده‌ترین و naive ترین نوع Fuzzing هستش. تکنیک‌های Fuzz testing با توسعه‌ای که از دهه ۹۰ تا الان داشتن، ساختارمند شدند و باهوش تر عمل می‌کنند. یک سری‌هاشون از نوع generation-based هستند یعنی هر iteration ورودی‌ها رو از اول تعیین می‌کنند. یک سری‌هاشونم mutation-based هستند و میان input ها رو modify می‌کنند. فاز تستینگ‌ها به شکل white و black و gray box انجام میشن. بلک باکس اینطوریه که fuzzer هیچی از ساختار برنامه نمی‌دونه. gray box یعنی اینکه ما نیاز داریم کمی instrumentation روی کدمون انجام بدیم و به طبع white box هم که مشخص میشه چیه.

فازری که داچمن رفته سراغش از نوع gray-box و mutation-based هستش. منتهی باهوش تره، یعنی بلده که mutation هاش رو به سمت یک سری هدف و یا coverage خاص که از پیش براش مشخص شدن هدایت کنه. اصلاحا به این نوع فازرها میگن Directed Grey-box fuzzing. این تکنیک توسعه‌ و پیاده‌سازیش توسط آقای Abhik Roychoudhury و تیمش صورت گرفته. ایشون یه گروه بسیار سوپر و قوی توی دانشگاه NUS دارن که تو حوزه‌ی Fuzzing و Automated Program Repair فعاله. بسیار توصیه می‌کنم اگر به این بحثا علاقه‌مند هستید برید و کارشون رو بخونید.

تا اینجا مقدمه بود میریم سراغ بحث اصلی.

بحث Graybox Fuzzing بسیار توی این سال‌های اخیر مورد توجه قرار گرفته و سعی میشه توی کابردهای مختلفی بیان و یک فازر Target-specific طراحی کنن. بزرگترین ضعف Fuzzer ها زمانیه که به دنیای Distributed Systems و Concurrency ورود می‌کنن. تمام این حرفایی که توی پست بالا در مورد AFLGo زدم صرفا منوط میشه به برنامه‌های Sequential. توی برنامه‌های ترتیبی چون صرفا یک Thread داریم، واسه همین چیزی به اسم Scheduler وجود نداره در مقابل Fuzzer. مثلا همین مثالی که من زدم یا کیس استادی داچمن، این ابزارها میان با تکنیک‌های Static Analysis بررسی میکنن که آیا اون نقطه Reachable هست و هر جا که لازم باشه برای رسیدن به اون نقطه ورودی تهییه کنن، فازر رو صدا میزنن. خیلی بخوان براتون مرام خرج کنن به جای Static Analysis میان از تکنیک‌های Runtime Analysis استفاده میکنن که البته توی اینم خیلی ضعیفن و اکثر ابزارهای قوی این حوزه تکیه شون به Static Analysis عه. یعنی میان از طریق آنالیز سینتکس کدتون پیش میرن. خود غیرقطعی بودن Fuzzer یک طرف، اینکه Static Analysis بخاطر اینکه خیلی از مسائل کلیدیش Undecidable عه کلی corner case به جا می‌ذاره یک طرف.(اینجا یکم توضیح دادم اینو). خب همه‌ی اینا باعث میشه که Fuzzer ها نسبت به یک سری از برنامه‌های ترتیبی هم حتی خوب عمل نکنن. مثلا فرض کن برای اون فرمول f ای که توی پست قبل آوردیم، بیاد و ۱ میلیارد assignment جنریت کنه ولی هیچکدوم نتونن فرمول رو ارضا کنن. سوال، آیا فرمول ارضا ناپذیره، یا اینکه واقعا assignment ای وجود داره که fuzzer نتونسته پیداش کنه؟ جواب، نمی‌دونیم. ایراد بعدی شون توی برنامه‌های Sequential، گیرم Fuzzer بیاد و یه assignment به ما برگردونه و بگه این کار رو خراب میکنه. آقای داچمن هم برن و کلی کد رو بخونن و بالا و پایین کنن و یک patch ای بدن که دیگه برنامه روی اون assignment به باگ نخوره. آیا به راستی حالا که اینطور شده، باگ برنامه برطرف شده؟ جواب، نمی‌دونیم.

حالا بریم سراغ برنامه‌های Distributed و Concurrent. توی این برنامه‌ها یک چیزی هست به اسم Scheduler که داره thread ها رو زمان‌بندی می‌کنه. فازرها وقتی به چنین سدی میخورن هیچ برنامه‌ای براش ندارن. همینطور رندوم scheduler جلو میره و هر وقت لازم باشه برای جلو رفتن یک input ای داده بشه فازر کال میشه. حتی به فرض تهش هم یک assignment ای برگردونده بشه و شما بفهمی که برنامه‌ات باگ داره. از کجا میخوای بفهمی که چه Scheduling ای ما رو به این باگ رسونده؟ عملا دیباگینگ برنامه غیرممکن میشه. حالا همین آقای Abhik سال پیش یک مقاله‌ای رو چاپ کردن با عنوان Greybox Fuzzing of Distributed Systems که نشون بدن خیز برداشتن برای Distributed System. به زودی همین امسال دیس این مقاله میاد بیرون :) برای پیش درآمدش این تاک رو ببینید ( از 5:17:29 تا 5:48:36)

با همه‌ی این توصیفات جا داره بگم که Fuzzing و Static Analysis به هیچ وجه نمی‌تونن جای خالی Verification رو پر کنن و ما این رو با توسعه JMC نشون خواهیم داد. شما وقتی برنامه‌ات رو با JMC وریفای می‌کنی، اگر باگ داشته باشه قطعا پیداش میکنه، برات یک Execution Trace از ابتدای اجرای برنامه برمیگردونه که نشون بده چی شد که به این باگ رسیدیم و علاوه بر اون دیتای کامل Scheduling ای که ما رو به این باگ رسونده رو هم بهتون میده، شما مقایسه کنید Debugging با این حجم دیتا آسون تره و یا صرفا با داشتن چهار تا Value ؟

حالا برای اینکه خیلی هم سر دیباگینگ اذیت نشید یه کاری رو داریم با خانم Andreea Costa شروع میکنیم، ایشون یکی از محققین گروه Abhik هستند، که با استفاده از JMC برنامه رو وریفای کنیم و وقتی باگ رو پیدا کردیم به شکل Automated برنامه رو Repair کنیم تا دیگه باگی نداشته باشه. یعنی نه تنها باگ رو پیدا کنیم بلکه رفعش کنیم و ثابت کنیم که باگ واقعا رفع شده. تمام تکنیک‌های Automated Program Repair تا به امروز بر پایه‌ی Static Analysis و Fuzzing ساخته شدن و قطعا می‌تونید حدس بزنید که Patch هایی که می‌سازه ممکنه واقعا Bug-free نباشه.

خلاصه که فرمال پیشه کنید.