یکی از چیزهایی که از نظر من داره این روزها با رشد ابزارهای ai تهدید میشه اجایله.و اون هم اصل کامیونیکیشن اجایل.
از طرف سوال میپرسی چرا اینطوری پیاده کردی؟ میره سوال تو رو میده به همون ai و جوابشو کپی میکنه برات میفرسته. بعد دوباره میپرسی اگر فلانطور میشد بهتر نبود؟باز همینو هم کپی میکنه و جواب رو‌میگیره و میده بهت.
انگار با همکارت حرف نمیزنی. با ai فقط داری چت میکنی.
مخالف استفاده از ai برای جواب دادن نیستم ولی حداقل توقعم اینه جواب رو ازش بفهمید و جواب بدید و جواب رو به زبان خودتون بازنویسی کنید
از طرف سوال میپرسی چرا اینطوری پیاده کردی؟ میره سوال تو رو میده به همون ai و جوابشو کپی میکنه برات میفرسته. بعد دوباره میپرسی اگر فلانطور میشد بهتر نبود؟باز همینو هم کپی میکنه و جواب رو‌میگیره و میده بهت.
انگار با همکارت حرف نمیزنی. با ai فقط داری چت میکنی.
مخالف استفاده از ai برای جواب دادن نیستم ولی حداقل توقعم اینه جواب رو ازش بفهمید و جواب بدید و جواب رو به زبان خودتون بازنویسی کنید
❤1👏1
تو سفر کوتاهم به ایران دوتا مقاله تو فراغتم خوندم که یکیش خوب بود و اون یکی خیلی بهش نقد دارم:
اولیش میگفت زبان Go بهترین زبان برای توسعه تو دنیای ai هست. این مقاله تو کامیونیتی همون زبون به صورت کاملا بلایند ترند شد.بنظرم کل مقاله حرفای چالشی بود. اولیش اینکه خب این موضوع رو خود گوگل داره پرموت میکنه. طبیعتا من بهش بعنوان تبلیغ نگاه میکنم ولی یه عده خیلی جدیش گرفتند گویا. مثلا یکی از ادعاهاش اینه go اجازه خطا کردن رو به ایجنتها نمیده و safty ایجاد میکنه. بخوایم صادق باشیم زیانهای دیگه هم همینو دارن و باقی موارد ادعایی رو دارن.
اما دومیش بدیهی ولی جالب بود. میگفت تمیز نوشتن کد قبلا برای فهم انسان بوداما امروز که انسان داره کمتر کد رو خط به خط میخونه هم نیازه؟ اره. چون کثیف نوشتن باعث میشه توکنهای بیشتری مصرف بشه. اینکه ابسترکتهای خوبی نداشته باشی،گادکلاس داشته باشی و همه چیز یه جا باشه. اعدادش همونیه که تو پست اخر لینکدینم گذاشتم. حدود ۸۰ درصد کاهش مصرف.
اولیش میگفت زبان Go بهترین زبان برای توسعه تو دنیای ai هست. این مقاله تو کامیونیتی همون زبون به صورت کاملا بلایند ترند شد.بنظرم کل مقاله حرفای چالشی بود. اولیش اینکه خب این موضوع رو خود گوگل داره پرموت میکنه. طبیعتا من بهش بعنوان تبلیغ نگاه میکنم ولی یه عده خیلی جدیش گرفتند گویا. مثلا یکی از ادعاهاش اینه go اجازه خطا کردن رو به ایجنتها نمیده و safty ایجاد میکنه. بخوایم صادق باشیم زیانهای دیگه هم همینو دارن و باقی موارد ادعایی رو دارن.
اما دومیش بدیهی ولی جالب بود. میگفت تمیز نوشتن کد قبلا برای فهم انسان بوداما امروز که انسان داره کمتر کد رو خط به خط میخونه هم نیازه؟ اره. چون کثیف نوشتن باعث میشه توکنهای بیشتری مصرف بشه. اینکه ابسترکتهای خوبی نداشته باشی،گادکلاس داشته باشی و همه چیز یه جا باشه. اعدادش همونیه که تو پست اخر لینکدینم گذاشتم. حدود ۸۰ درصد کاهش مصرف.
👍2❤1
با درخواست انتشارات Packet به عنوان Early reader کتاب Claude Visual Bible بودم و قراره ۱۵ سپتامبر ریویو خودمو تو جاهایی که عرضه میشه بگم ولی قبلش به صورت غیررسمی دوس داشتم اینجا کوتاه بیانش کنم:
بیشتر از چیزی که از عنوانش انتظار داشتم، از خود کتاب خوشم اومد. تصورم اول و قبل از شروع کردن به خوندن این بود که با یک راهنمای تصویری برای کار با Claude و یه مجموعه از screenshot و prompt آماده روبرو میشم ، اما کتاب آروم آروم از آموزش ساده Chat عبور میکنه و به این میرسه که چطور میشه یک فرایند قابل کنترل و تکرارپذیر دور AI ساخت. یعنی بهتون فقط یاد نمیده چه فیچری کجاست بلکه میگه چطور از claude خوب استفاده کنیم. یکی از نقاط قوت اصلی کتاب اینه که تقریبا از همون اول روی نقش آدمیزاد تو بررسی نتیجه تاکید میکنه و اینکه Claude قرار نیست فقط جواب تولید کنه و ما اونو بپذیریم. کتاب بارها پیشنهاد میکنه قبل از اجرا هدف، محدودیت، منبع و معیار موفقیت را مشخص کنیم و بعد نتیجه رو با source اصلی بررسی کنیم. این طرز فکرو فصل‌های بعدی جدیتر هم میشه: از مشخص کردن اطلاعاتی که نیاز به بررسی داره بگیر تا جدا کردن evidence از interpretation و تعریف acceptance criteria برای کارهای تکرارشونده. چیزی که به نظرم کتابو از خیلی از آموزشای AI جدا میکنه اینه که فقط روی "prompt بهتر" تمرکز نمیکنه. کم کم وارد موضوعاتی مثل context، permissions، source boundaries، verification، reusable workflows، Skills و automation میشه.
مسیر کتاب از "چطوری سوال بهتری بپرسیم" به "چطوری AI را وارد یک workflow واقعی کنیم" حرکت میکنه.
با همه این اوصاف، کتاب ضعفهایی هم بنظرم داره. برای کسی که قبلا زیاد با ابزارهای AI کار کرده، بخشی از فصلای ابتدایی بیش از حد مقدماتی و گاهی تکراری هستن که البته بخشی از این موضوع اجتناب ناپذیره. چندین بار همون الگوی Brief → Outline → Generate → Review در contextهای مختلف تکرار میشه. از طرف دیگه قسمت‌های وابسته به UI، planها، نام featureها و مدلها احتمالا سریعتر از مفاهیم اصلی کتاب قدیمی شاید بشن اما خب نمیشد نگفتنشون هم.و شاید نقد بعدی این باشه که بعضی چیزها میشه کنار هم ذکر بشند ولی بدون اشاره به اینکه قراره بعدا بهش برسه میگذره و حتی بعدا هم که بهش میرسه خیلی سریع ازش عبور میکنه.
پ.ن: من Technical Reviewer نبودم و Early Reader بودم
بیشتر از چیزی که از عنوانش انتظار داشتم، از خود کتاب خوشم اومد. تصورم اول و قبل از شروع کردن به خوندن این بود که با یک راهنمای تصویری برای کار با Claude و یه مجموعه از screenshot و prompt آماده روبرو میشم ، اما کتاب آروم آروم از آموزش ساده Chat عبور میکنه و به این میرسه که چطور میشه یک فرایند قابل کنترل و تکرارپذیر دور AI ساخت. یعنی بهتون فقط یاد نمیده چه فیچری کجاست بلکه میگه چطور از claude خوب استفاده کنیم. یکی از نقاط قوت اصلی کتاب اینه که تقریبا از همون اول روی نقش آدمیزاد تو بررسی نتیجه تاکید میکنه و اینکه Claude قرار نیست فقط جواب تولید کنه و ما اونو بپذیریم. کتاب بارها پیشنهاد میکنه قبل از اجرا هدف، محدودیت، منبع و معیار موفقیت را مشخص کنیم و بعد نتیجه رو با source اصلی بررسی کنیم. این طرز فکرو فصل‌های بعدی جدیتر هم میشه: از مشخص کردن اطلاعاتی که نیاز به بررسی داره بگیر تا جدا کردن evidence از interpretation و تعریف acceptance criteria برای کارهای تکرارشونده. چیزی که به نظرم کتابو از خیلی از آموزشای AI جدا میکنه اینه که فقط روی "prompt بهتر" تمرکز نمیکنه. کم کم وارد موضوعاتی مثل context، permissions، source boundaries، verification، reusable workflows، Skills و automation میشه.
مسیر کتاب از "چطوری سوال بهتری بپرسیم" به "چطوری AI را وارد یک workflow واقعی کنیم" حرکت میکنه.
با همه این اوصاف، کتاب ضعفهایی هم بنظرم داره. برای کسی که قبلا زیاد با ابزارهای AI کار کرده، بخشی از فصلای ابتدایی بیش از حد مقدماتی و گاهی تکراری هستن که البته بخشی از این موضوع اجتناب ناپذیره. چندین بار همون الگوی Brief → Outline → Generate → Review در contextهای مختلف تکرار میشه. از طرف دیگه قسمت‌های وابسته به UI، planها، نام featureها و مدلها احتمالا سریعتر از مفاهیم اصلی کتاب قدیمی شاید بشن اما خب نمیشد نگفتنشون هم.و شاید نقد بعدی این باشه که بعضی چیزها میشه کنار هم ذکر بشند ولی بدون اشاره به اینکه قراره بعدا بهش برسه میگذره و حتی بعدا هم که بهش میرسه خیلی سریع ازش عبور میکنه.
پ.ن: من Technical Reviewer نبودم و Early Reader بودم
👏5
⚰ TDD is Dead. ⚰
به همین سادگی. تی دی دی رو میشه تو عصر کد نوشتن ai یه فرایند عبث فرض کرد که هیچ آورده ای نداره.
اینکه اول به مدلتون بگید براتون تست بنویسه عملا حتی کمکی به خود مدل برای کشف کانتکس نمیکنه.چون مدل برای نوشتن همون تستها باید بره سراغ کانتکسهایی که برای نوشتن کد هم نیازه پس فقط ترتیب نمایش و پیاده سازی کد و تست تغییر میکنه نه کیفیت و کارایی.
به همین سادگی. تی دی دی رو میشه تو عصر کد نوشتن ai یه فرایند عبث فرض کرد که هیچ آورده ای نداره.
اینکه اول به مدلتون بگید براتون تست بنویسه عملا حتی کمکی به خود مدل برای کشف کانتکس نمیکنه.چون مدل برای نوشتن همون تستها باید بره سراغ کانتکسهایی که برای نوشتن کد هم نیازه پس فقط ترتیب نمایش و پیاده سازی کد و تست تغییر میکنه نه کیفیت و کارایی.
👍3🤔1
یکی از چیزایی که خیلی داره صحبت میشه کیفیت تستهای نوشته شده است. چه ai بنویسه و چه خودت.
حرف درموردش واقعا زیاده.
بیشترین فرکانس صحبت تو تاک ها و مقالات شاید میوتیشن تست باشه.
یعنی تعمدا کدت رو بهم میریزی و میبینی آیا تستها تونستن کشفش کنن یا نه.
تجربه شخصیم رو بذارید درموردش بگم.
من هم شروع کردم به استفاده از stryker برای میوتیت کردن کدها و سنجششون. زمان صرف شده فاجعه بود. استفاده از سوییچهای خود کتابخونه مثل —since و ران کردنش صرفا روی pr ها زمان رو کم کرد ولی هنوز رضایت بخش نبود.
چون اساسا این نوع کتابخونه ها به صورت استاتیک شروع به بهم ریختن کد میکنن که گاها اصلا به هم ریختن اون بخش کد مفهوم و دغدغه بیزینسی نداره.
اما با دادن این وظیفه به ai میشد سناریوهای واقعی میوتیشن رو کشف کرد. توصیه میکنم این مقاله متا رو بخونید:
https://engineering.fb.com/2025/09/30/security/llms-are-the-key-to-mutation-testing-and-better-compliance/?utm_source=chatgpt.com
این مقاله اساس کار من شد برای نوشتن واسکیلی که میوتیشن توش سمنتیک باشه. این ایده خیلی خوب جواب داد و تو همون هفته اول تستش تونست تعداد خوبی باگ که توسط تستها و حتی تیم QA هنوز کشف نشده بود رو پیدا کنه. یعنی یه تستر بی نظیر.
تعداد میوتیشنها هم به صورت چشمگیری کم شد و فقط چیزهایی که معنی دار بودند مونده بودند. قبلا مثلا ۹۰ تا جا رو تغییر میداد ولی با روش جدید رسید به ۸-۹ تا.
موضوع بعدی فروش این دستاورد بود به تیم که بعدا میگم.
حرف درموردش واقعا زیاده.
بیشترین فرکانس صحبت تو تاک ها و مقالات شاید میوتیشن تست باشه.
یعنی تعمدا کدت رو بهم میریزی و میبینی آیا تستها تونستن کشفش کنن یا نه.
تجربه شخصیم رو بذارید درموردش بگم.
من هم شروع کردم به استفاده از stryker برای میوتیت کردن کدها و سنجششون. زمان صرف شده فاجعه بود. استفاده از سوییچهای خود کتابخونه مثل —since و ران کردنش صرفا روی pr ها زمان رو کم کرد ولی هنوز رضایت بخش نبود.
چون اساسا این نوع کتابخونه ها به صورت استاتیک شروع به بهم ریختن کد میکنن که گاها اصلا به هم ریختن اون بخش کد مفهوم و دغدغه بیزینسی نداره.
اما با دادن این وظیفه به ai میشد سناریوهای واقعی میوتیشن رو کشف کرد. توصیه میکنم این مقاله متا رو بخونید:
https://engineering.fb.com/2025/09/30/security/llms-are-the-key-to-mutation-testing-and-better-compliance/?utm_source=chatgpt.com
این مقاله اساس کار من شد برای نوشتن واسکیلی که میوتیشن توش سمنتیک باشه. این ایده خیلی خوب جواب داد و تو همون هفته اول تستش تونست تعداد خوبی باگ که توسط تستها و حتی تیم QA هنوز کشف نشده بود رو پیدا کنه. یعنی یه تستر بی نظیر.
تعداد میوتیشنها هم به صورت چشمگیری کم شد و فقط چیزهایی که معنی دار بودند مونده بودند. قبلا مثلا ۹۰ تا جا رو تغییر میداد ولی با روش جدید رسید به ۸-۹ تا.
موضوع بعدی فروش این دستاورد بود به تیم که بعدا میگم.
👌4👍2
بیاید صادق باشیم. اغلب نوشتن پیشنهاد و ارایه اش به تیم باعث پذیرفته شدنش نمیشه. اینو همه مون تجربه اش رو داشتیم. علتش هم ذات انسان و طبیعته و قانون اول نیوتن. دوس داریم ثبات داشته باشیم.
و من هم برای چند ایده ای که تو تیممون مطرح کردم نمیتونستم صرفا پیشنهاد بدم. اونم تو جایی که چندین نفر نویسنده کتاب و آدمای سنگین وزن بود.
راه حلم این نبود که بگم "این خوبه" . رفتم و اثبات کردم که خوبه. خوبه و برای ما هم کارکرد داره.چون خیلی از خوبها ممکنه به درد شرایط موجود نخورن.
تو کتاب Pragmatic Programing اسم این کار رو میذاره "سوپ سنگ".
اول یکی پیشنهاد میده یه سوپ سنگ بپزیم و همه ایراد میگیرن که نیمشه. طرف خودش شروع به پخت میکنه. بعد که بقیه میبینن داره پخته میشه همه میان و براش وسایل میارن.یکی سبزی میاره و اون یکی هویج و همینطوری یهو میبینن یه سوپ واقعی ساخته شده و حالا وقتشه اون سنگ رو از سوپ بردارن.
باید اقدام کرد و پیشنهاد رو با نتایجی که از دل خود پروژه اومده شرح داد. باید با داده صحبت کرد.
اما همیشه هم شدنی نیست. تو فصل آخر کتاب Staff Engineer یه جا جرف جالبی میزنه. میگه این حرفا رو که زدیم خیلی به ساختار سیستم وابسته است. قرار نیست شما تو همه سیستمها بتونید اظهارنظر کنید.بتونید تغییر ایجاد کنید. گاهی هم باید فهمید اون سیستم کشش اون رو نداره.
و من هم برای چند ایده ای که تو تیممون مطرح کردم نمیتونستم صرفا پیشنهاد بدم. اونم تو جایی که چندین نفر نویسنده کتاب و آدمای سنگین وزن بود.
راه حلم این نبود که بگم "این خوبه" . رفتم و اثبات کردم که خوبه. خوبه و برای ما هم کارکرد داره.چون خیلی از خوبها ممکنه به درد شرایط موجود نخورن.
تو کتاب Pragmatic Programing اسم این کار رو میذاره "سوپ سنگ".
اول یکی پیشنهاد میده یه سوپ سنگ بپزیم و همه ایراد میگیرن که نیمشه. طرف خودش شروع به پخت میکنه. بعد که بقیه میبینن داره پخته میشه همه میان و براش وسایل میارن.یکی سبزی میاره و اون یکی هویج و همینطوری یهو میبینن یه سوپ واقعی ساخته شده و حالا وقتشه اون سنگ رو از سوپ بردارن.
باید اقدام کرد و پیشنهاد رو با نتایجی که از دل خود پروژه اومده شرح داد. باید با داده صحبت کرد.
اما همیشه هم شدنی نیست. تو فصل آخر کتاب Staff Engineer یه جا جرف جالبی میزنه. میگه این حرفا رو که زدیم خیلی به ساختار سیستم وابسته است. قرار نیست شما تو همه سیستمها بتونید اظهارنظر کنید.بتونید تغییر ایجاد کنید. گاهی هم باید فهمید اون سیستم کشش اون رو نداره.
👏3❤2👍2
درمورد Opus 5.5 که اومده خود کلاد یه سری پیشنهادا داده:
- تسکو کامل بده، نه دستورای ریز
- دان (Done) را دقیق تعریف کن.
- لازم نیست بگی step by step فکر کن.
- فقط مشخص کن کی ادامه بده و کی توقف کنه.
- وسط کار میتونی instruction جدید اضافه کنی.
- برای کار بزرگ از subagent استفاده کن.
- برای کار طولانی وضعیتو در TASKS.md نگه دار.
- قبل merge، فقط blockerها رو review کن.
- در research بگو موارد verifyنشده رو مشخص کنه.
- برای مسائل بصری، خود تصویرو بده.
- در chat طولانی بگو فقط روی سوال جدید تمرکز کنه.
- به‌جای chain-of-thought، دلیل کوتاه تصمیمو بخواه.
- تسکو کامل بده، نه دستورای ریز
- دان (Done) را دقیق تعریف کن.
- لازم نیست بگی step by step فکر کن.
- فقط مشخص کن کی ادامه بده و کی توقف کنه.
- وسط کار میتونی instruction جدید اضافه کنی.
- برای کار بزرگ از subagent استفاده کن.
- برای کار طولانی وضعیتو در TASKS.md نگه دار.
- قبل merge، فقط blockerها رو review کن.
- در research بگو موارد verifyنشده رو مشخص کنه.
- برای مسائل بصری، خود تصویرو بده.
- در chat طولانی بگو فقط روی سوال جدید تمرکز کنه.
- به‌جای chain-of-thought، دلیل کوتاه تصمیمو بخواه.
👌3❤1👏1🤯1
با DAB کار کردید؟
Data API builder
یه ابزار خود مایکروسافته. برای اینه که اگر پروژه ات در حد کراد هست بجای اینکه کلی مکافات بکشی و چندین لایه تعریف کنی و کد بزنی بهت اجازه میدی با چندتا دستور ساده دسترسی تعریف کنی و بهت GraphQL و REST بهت میده.
Data API builder
یه ابزار خود مایکروسافته. برای اینه که اگر پروژه ات در حد کراد هست بجای اینکه کلی مکافات بکشی و چندین لایه تعریف کنی و کد بزنی بهت اجازه میدی با چندتا دستور ساده دسترسی تعریف کنی و بهت GraphQL و REST بهت میده.
👍2🔥2👏2
Akbar Dizaji
⚰ TDD is Dead. ⚰ به همین سادگی. تی دی دی رو میشه تو عصر کد نوشتن ai یه فرایند عبث فرض کرد که هیچ آورده ای نداره. اینکه اول به مدلتون بگید براتون تست بنویسه عملا حتی کمکی به خود مدل برای کشف کانتکس نمیکنه.چون مدل برای نوشتن همون تستها باید بره سراغ کانتکسهایی…
طبیعتا این نظر شخصی من نیست.
این براساس مقاله Birgitta Boeckeler تو وبلاگ مارتین فاولر بود.اما یه ویدیو از امیلی باچه دیدم که دقیقا همین مقاله رو نقد میکرد:
https://www.youtube.com/watch?v=wK5WgbqtI50
اون مقاله و این ویدیو یه جایی باهم تلاقی دارند و یه جاهایی جلوی هم وایمیستند.
اینکه به ai بگیم اول برامون تست بنویس و بعد پیاده اش کن قطعا از دید هردو ارزشی نداره و تو دنیای ai تی دی دی به این مفهوم مرده. اما اون چیزی که امیلی باچه داره بیانش میکنه اینه اگر tdd رو اون روند فکری ببینیمش که توش لیست آزمونها رو داریم(حالا به هرطریقی) و توش ریفکتورینگ داریم و براش هرنس بسازیم(که امیلی اسمش رو Habit Hooks) میذاره) اونوقت نمیشه گفت tdd مرده.
داستان هرچیه مهم اینه سازوکارها درحال تغییر هستند.
این براساس مقاله Birgitta Boeckeler تو وبلاگ مارتین فاولر بود.اما یه ویدیو از امیلی باچه دیدم که دقیقا همین مقاله رو نقد میکرد:
https://www.youtube.com/watch?v=wK5WgbqtI50
اون مقاله و این ویدیو یه جایی باهم تلاقی دارند و یه جاهایی جلوی هم وایمیستند.
اینکه به ai بگیم اول برامون تست بنویس و بعد پیاده اش کن قطعا از دید هردو ارزشی نداره و تو دنیای ai تی دی دی به این مفهوم مرده. اما اون چیزی که امیلی باچه داره بیانش میکنه اینه اگر tdd رو اون روند فکری ببینیمش که توش لیست آزمونها رو داریم(حالا به هرطریقی) و توش ریفکتورینگ داریم و براش هرنس بسازیم(که امیلی اسمش رو Habit Hooks) میذاره) اونوقت نمیشه گفت tdd مرده.
داستان هرچیه مهم اینه سازوکارها درحال تغییر هستند.
YouTube
The Last Year Has Changed Everything I Knew About TDD After 20 Years
I've been practising TDD as a software engineer for over 20 years. This last year, with AI's introduction, has changed EVERYTHING I thought I knew.
Many developers are finding that their established expertise and daily workflows are under pressure as new…
Many developers are finding that their established expertise and daily workflows are under pressure as new…
🔥1👏1
یکی از چیزهایی که ai خیلی افتضاح گند میزنه تکرار کد و نقض فاحش DRY هستش. یه جا یه متدی داری که میشه بقیه جاها استفاده اش کرد ولی یهو مدلتون تصمیم میگیره خودش دوباره اون کدها رو بنویسه. و این یکی از مرسوم ترین اتفاقات تو کثیف شدن کد توسط ai هستش.
یکی از راه هایی که deterministic هم هست و باعث سوزوندن الکی توکنهاتون م نمیشه استفاده از jscpd هستش.
این ابزار به شما میگه کجاها تو کدتون داره تکراری میشه. میتونید برای افزایش اعتمادپذیری یه مدل ارزون به عنوان سوپروایزر بذارید. ازطرفی دیگه لازم نیست کل کدبیس رو به ai بدید که ببینه مشترک داره یا نه و فقط یه مجموعه خیلی خیلی محدودتر رو بررسی میکنه
یکی از راه هایی که deterministic هم هست و باعث سوزوندن الکی توکنهاتون م نمیشه استفاده از jscpd هستش.
این ابزار به شما میگه کجاها تو کدتون داره تکراری میشه. میتونید برای افزایش اعتمادپذیری یه مدل ارزون به عنوان سوپروایزر بذارید. ازطرفی دیگه لازم نیست کل کدبیس رو به ai بدید که ببینه مشترک داره یا نه و فقط یه مجموعه خیلی خیلی محدودتر رو بررسی میکنه
👏2❤1
موضوع پیام قبلی رو تو تستها هم داریم. تستهایی مینویسیم که یه جای دیگه نوشته شده. و به مرور حجم تستها و زمان ران شدنشون خیلی سنگین میشه. از همون کتابخونه قبلی هم یمشه استفاده کرد ولی من برای این Coverage overlap رو پیشنهاد میدم. چون میبینه کدوم کدهای پروداکشن با تستهای مشابه ران میشن. و البته باز برای بهتر شدن جاج درمورد نتیجه اش بد نیست انسان و یه مدل ارزون وارد قضیه بشند.
👏2❤1👍1
یکی دیگه از رویاهامون داره به واقعیت نزدیک میشه. Reverse Engineering همیشه سخت و زمانبر بود. دانش عمیق میخواست گاها.
REA
این کارو راحت کرده. به مدل AI تون وصلش میکنید و بعد ازش میخواید اون آرتیفکتی که دارید رو براتون مهندسی معکوس کنه و توضیح بده توش چی میگذره. بعد حتی میتونید ازش بخواید که براتون کدش رو بده(کدهاش لزوما کدهای اصلی نیست بلکه از متادیتا و چیزایی که تو آرتیفکت هست استفاده میکنه تا رفتار رو با کد شبیه سازی کنه)
https://rea.tools/
REA
این کارو راحت کرده. به مدل AI تون وصلش میکنید و بعد ازش میخواید اون آرتیفکتی که دارید رو براتون مهندسی معکوس کنه و توضیح بده توش چی میگذره. بعد حتی میتونید ازش بخواید که براتون کدش رو بده(کدهاش لزوما کدهای اصلی نیست بلکه از متادیتا و چیزایی که تو آرتیفکت هست استفاده میکنه تا رفتار رو با کد شبیه سازی کنه)
https://rea.tools/
REA
REA: Reverse Engineering for Your Coding Agent
Reverse engineer apps, binaries and browser behavior with your coding agent. Follow clear guides and try interactive examples with REA.
❤4👍2
وقتی تو شرکتها تیم پلتفرم تشکیل میشه اغلب دو حالت داره. یا اون تیم پلتفرم میشه تیم دواپس(و یا حتی در بعضی موارد sys admin) و یا یه تیمی میشه که یه فریمورکی میسازه که فقط فحش و نفرین بقیه تیمها رو برای خودش میاره. یعنی تیمی که قرار بود گلوگاهها رو حذف کنه خودش شده گلوگاه.
چون یه سری فیرمورکهایی میسازند که بار شناختی افراد رو زیاد میکنند. آزادی عمل رو ازشون میگیرن. اصلا تیم پلتفرم قرار نیست گیت عبور برنامه نویسا بشه که آزادی رو ازشون بگیره. باید یه سری "محصول" ایجاد کنه که با کمترین تلاش نیازهای تیمها برطرف بشه. مثلا با یه کلیک بتونه ریپو بسازه و داکرایز کنه و یه پروژه با یه سری بیسیکها بالا بیاد و مانیتورینگش فراهم بشه و ci/cd اش درست بشه و....
یعنی بجای هفته ها معطل بودن فقط باید یه کلیک بزنی و همه چیز اتومات بشه. نه اینکه کلیک کنی و بره داخل یه صفیی و یه نفر هروقت فرصت داشت اینا رو دستی برات بسازه.یعنی در اصل Golden Path نباید تبدیل به Golden Cage بشه
این ویدیو رو برای این ساختم. که ببنیم IDP اصلا چیه. چیکار میکنه. چقدر ساده میشه ساختتش.
https://youtu.be/yOXcXR06BK0
چون یه سری فیرمورکهایی میسازند که بار شناختی افراد رو زیاد میکنند. آزادی عمل رو ازشون میگیرن. اصلا تیم پلتفرم قرار نیست گیت عبور برنامه نویسا بشه که آزادی رو ازشون بگیره. باید یه سری "محصول" ایجاد کنه که با کمترین تلاش نیازهای تیمها برطرف بشه. مثلا با یه کلیک بتونه ریپو بسازه و داکرایز کنه و یه پروژه با یه سری بیسیکها بالا بیاد و مانیتورینگش فراهم بشه و ci/cd اش درست بشه و....
یعنی بجای هفته ها معطل بودن فقط باید یه کلیک بزنی و همه چیز اتومات بشه. نه اینکه کلیک کنی و بره داخل یه صفیی و یه نفر هروقت فرصت داشت اینا رو دستی برات بسازه.یعنی در اصل Golden Path نباید تبدیل به Golden Cage بشه
این ویدیو رو برای این ساختم. که ببنیم IDP اصلا چیه. چیکار میکنه. چقدر ساده میشه ساختتش.
https://youtu.be/yOXcXR06BK0
👍1🔥1👏1
این روزا اینکه چطوری با ai صحبت کنیم شدیدا موردبحثه. یکی از قوعدی که درموردش حرف زده میشه استناداردASD-STE100 هستش که برای داکیومنت کردن قطعات حساس استفاده میشه. به درد پوزیشنهایی که توش ابتکار مهمه(مثلا طراحها) شاید کمتر بخوره ولی خوراک ما برنامه نویساست. اصولش اینه:
- جملات کوتاه: فوقش ۲۰ کلمه برای دستورالعملا و ۲۵ کلمه برای توضیحات
- یک معنی برای هر کلمه: برای هرچیز باید یه واژه مشخص داشته باشیم نه چندتا. (ینو تو ورژن آخر AgentRecall خودم هم استفاده کردم و یه دیتابیس کوچیک برای معادل سازی کلمات گذاشتم)
- جملات معلوم (Active Voice): ترجیحا مشخص باشه چه کسی چه کاری انجام میده.
- یک دستور در هر جمله: چند دستور مستقل در یه جمله ترکیب نشون.
- پاراگرافای کوتاه: هر پاراگراف فقط روی یک موضوع تمرکز کنه.
- گرامر ساده: از ساختارای پیچیده دستوری و زمان‌های غیرضروری پرهیز بشه.
- حذف ابهام: از کلمات و عبارتایی که چند برداشت دارن اجتناب بشه.
- حذف عبارتای غیرضروری: جملات مستقیم و بدون حاشیه باشن.
- استفاده از لیستای مرحله ای: عملیات پیچیده به مراحل مشخص تقسیم بشن.
- ثبات در اصطلاحات: نام قطعات، متغیرا و عملیات در تمام متن یکسان باشن.
شرطهای واضح: دقیقا مشخص بشه هر دستور در چه شرایطی اجرا میشه.
استفاده از مثال و تصویر: در صورت نیاز، برای روشنتر شدن مفاهیم.
پرهیز از اصطلاحات عامیانه و استعاره: متن باید مستقیم و قابل تفسیر باشه.
- جملات کوتاه: فوقش ۲۰ کلمه برای دستورالعملا و ۲۵ کلمه برای توضیحات
- یک معنی برای هر کلمه: برای هرچیز باید یه واژه مشخص داشته باشیم نه چندتا. (ینو تو ورژن آخر AgentRecall خودم هم استفاده کردم و یه دیتابیس کوچیک برای معادل سازی کلمات گذاشتم)
- جملات معلوم (Active Voice): ترجیحا مشخص باشه چه کسی چه کاری انجام میده.
- یک دستور در هر جمله: چند دستور مستقل در یه جمله ترکیب نشون.
- پاراگرافای کوتاه: هر پاراگراف فقط روی یک موضوع تمرکز کنه.
- گرامر ساده: از ساختارای پیچیده دستوری و زمان‌های غیرضروری پرهیز بشه.
- حذف ابهام: از کلمات و عبارتایی که چند برداشت دارن اجتناب بشه.
- حذف عبارتای غیرضروری: جملات مستقیم و بدون حاشیه باشن.
- استفاده از لیستای مرحله ای: عملیات پیچیده به مراحل مشخص تقسیم بشن.
- ثبات در اصطلاحات: نام قطعات، متغیرا و عملیات در تمام متن یکسان باشن.
شرطهای واضح: دقیقا مشخص بشه هر دستور در چه شرایطی اجرا میشه.
استفاده از مثال و تصویر: در صورت نیاز، برای روشنتر شدن مفاهیم.
پرهیز از اصطلاحات عامیانه و استعاره: متن باید مستقیم و قابل تفسیر باشه.
👏2👍1