Forwarded from Go Casts | Systems & Agents 🚀
مارتین فاولر یه مطلب نوشته به اسم «I don't like LLMs».
فاولر قبول داره که این ابزارها کار میکنن. حتی از Jessica Kerr نقل میکنه که استفاده نکردن ازشون غیرمسئولانهست. مشکلش با کاراییشون نیست، با رفتارشونه. میگه ادای آدم رو درمیارن، و تازه ادای آدمی رو که اگه واقعی بود باهاش رفیق نمیشد. وقتی یه چیزی رو نمیدونن با همون اطمینانی که جواب درست میدن سرهمش میکنن، و اشتباهشون رو که بگی یه عذرخواهی سرسری میکنن و میرن سراغ جواب بعدی.
لینک مطلبش رو گذاشتم، تمایل داشتید بخونید:
https://martinfowler.com/articles/2026-dont-like-llms.html
@gocasts
فاولر قبول داره که این ابزارها کار میکنن. حتی از Jessica Kerr نقل میکنه که استفاده نکردن ازشون غیرمسئولانهست. مشکلش با کاراییشون نیست، با رفتارشونه. میگه ادای آدم رو درمیارن، و تازه ادای آدمی رو که اگه واقعی بود باهاش رفیق نمیشد. وقتی یه چیزی رو نمیدونن با همون اطمینانی که جواب درست میدن سرهمش میکنن، و اشتباهشون رو که بگی یه عذرخواهی سرسری میکنن و میرن سراغ جواب بعدی.
لینک مطلبش رو گذاشتم، تمایل داشتید بخونید:
https://martinfowler.com/articles/2026-dont-like-llms.html
@gocasts
martinfowler.com
I don't like LLMs
a short post
Forwarded from .NET Internals
همینه!
به نظرم AI میتونه همه چی بزنه و اینکه 'چی' بزنه نیاز به وقت و زمان داره.
این نکته خیلی مهمه، الان متاسفانه یه جوی شده که آقا با AI بزن بره اینکه کاری نداره.
برای من AI تونسته بین 50 تا 60 درصد سرعت توسعه بیشتر کرده و زمان تحویل رو کمتر.
نکته: تولید کد شاید 99 درصد سریع تر شده ولی اینکه قبلش فک کنی پلن کنی و بعدش چک کنی تست کنی بفهمی هنوز زمان میگیره.
برای شما چند درصد تونسته کمک کنه؟
به نظرم AI میتونه همه چی بزنه و اینکه 'چی' بزنه نیاز به وقت و زمان داره.
این نکته خیلی مهمه، الان متاسفانه یه جوی شده که آقا با AI بزن بره اینکه کاری نداره.
برای من AI تونسته بین 50 تا 60 درصد سرعت توسعه بیشتر کرده و زمان تحویل رو کمتر.
نکته: تولید کد شاید 99 درصد سریع تر شده ولی اینکه قبلش فک کنی پلن کنی و بعدش چک کنی تست کنی بفهمی هنوز زمان میگیره.
برای شما چند درصد تونسته کمک کنه؟
به عنوان یک معلم، یادگیری برای من امیده،
به عنوان یک پدر، یادگیری برای من مسیر نجات فرزندم از جهله،
و به عنوان یک انسان، یادگیری برای من حق طبیعیه که نباید به خاطر جبر جغرافیایی از کسی گرفته بشه.
در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه.
ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید :
https://mehr.digikala.com/madrese-besaz/
@learning_with_m
به عنوان یک پدر، یادگیری برای من مسیر نجات فرزندم از جهله،
و به عنوان یک انسان، یادگیری برای من حق طبیعیه که نباید به خاطر جبر جغرافیایی از کسی گرفته بشه.
در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه.
ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید :
https://mehr.digikala.com/madrese-besaz/
@learning_with_m
دیجیکالامهر
دیجیکالامهر، مهری که لبخند میسازد
در دیجیکالامهر به سادگیِ یه خرید و با چند کلیک، میتونی کالاهای مورد نیاز مؤسسههای خیریه رو بهشون اهدا کنی تا به بهترین شکل به دست نیازمندان برسه.
Forwarded from .NET Internals
آندری کارپتی (Andrej Karpathy) یه توییت جالب زده در مورد اینکه با قویتر شدن LLMها، کار اصلی ما دیگه تولید محتوا نیست، بلکه فهمیدن و نظارت روی خروجیهاشون میشه. یعنی مدلها دارن بیشتر و بیشتر کار سنگین رو خودشون انجام میدن و ما باید بریم سمت لایههای بالاتر و بفهمیم واقعاً چی دارن میگن.
چند تا ترفند باحال و عملی پیشنهاد داده که من هم کمکم دارم امتحانشون میکنم:
نوشتن با ASD-STE100: بگید مدل مطلب رو با زبان کنترلشده ASD-STE100 بنویسه. این استاندارد اصلش برای مستندات نگهداری هواپیما و تجهیزات هوافضا طراحی شده و قوانین خیلی سختگیرانهای داره (جملههای کوتاه، فعلهای مشخص، دیکشنری محدود، بدون ابهام و استعارههای پیچیده). نتیجهش اینه که متن خیلی تمیز، مستقیم و خوانا میشه. اگر خیلی خشک شد، میتونید بگید «۸۰ درصد نزدیک به ASD-STE100» تا یه کم نرمترش کنه. برای توضیحهای فنی و پیچیده عالیه، چون مغزتون کمتر خسته میشه.
نمودار و دیاگرام به جای متن: به جاش مستقیم ازش بخواید دیاگرام، flowchart یا mermaid یا تصویر مفهومی بسازه. مغز ما اطلاعات بصری رو خیلی سریعتر پردازش میکنه و پارس کردنش راحتتره. مخصوصاً وقتی موضوع پیچیده باشه، یه دیاگرام خوب میتونه کل ایده رو در چند ثانیه منتقل کنه، در حالی که متن ممکنه چند پاراگراف طول بکشه.
خروجی به صورت HTML: بگید خروجی رو به صورت HTML کامل بده. مدلهای جدید واقعاً تو فرانتاند قوی شدن و میتونن صفحههای وب قشنگ، اینتراکتیو، با انیمیشن و استایل مدرن بسازن. به جای یه متن خشک، یه تجربهی تعاملی میگیرید که میتونید روش کلیک کنید، اسکرول کنید یا حتی چیزایی رو تست کنید. برای فهمیدن مفاهیم پیچیده خیلی کمککنندهست.
ویدیوهای explainer سفارشی (بهترینش اینه!): کارپتی میگه بیشتر از همه به این فرمت امیدواره. از مدل بخواید یه ویدیوی کامل و اختصاصی به سبک 3Blue1Brown بسازه (همون انیمیشنهای ریاضی و مفهومی تمیز و قشنگ). میتونید بگید از API کی ElevenLabs برای narration استفاده کنه یا جایگزینهای رایگان/لوکال پیدا کنه. اینطوری برای هر موضوعی که بخواید، یه ویدیوی آموزشی شخصیسازیشده میسازید که قبلاً ساختنش زمان و هزینهی دیوانهکنندهای داشت.خلاصهش
اینه که هوش مصنوعی داره انقدر زیاد و ارزون میشه که میتونیم ازش artifactهای بزرگ و دورریختنی بسازیم (وباپ، ویدیو، دیاگرامهای پیچیده و غیره) که قبلاً اصلاً بهصرفه نبود. کار ما داره میره به لایههای بالاتر abstraction و oversight، و جالب اینجاست که خود LLMها میتونن تو همین بخش هم کمکمون کنن.
به نظرم خیلی نکتهی درستیه، مخصوصاً برای ما که هر روز با اینا کار میکنیم. حتماً امتحان کنید و نتیجهش رو بگید 🔥
پ.ن: آندری کارپتی یکی از استادای واقعی و پیشگامهای حوزه LLM و deep learning حساب میشه. قبلاً مدیر AI تسلا بوده، از بنیانگذاران اولیه OpenAI، و یکی از بهترینها در توضیح شفاف و عمیق مفاهیم هوش مصنوعیه. وقتی حرف میزنه، معمولاً ارزش گوش دادن داره.
لینک توییت:
https://x.com/karpathy/status/2105819303471976479
چند تا ترفند باحال و عملی پیشنهاد داده که من هم کمکم دارم امتحانشون میکنم:
نوشتن با ASD-STE100: بگید مدل مطلب رو با زبان کنترلشده ASD-STE100 بنویسه. این استاندارد اصلش برای مستندات نگهداری هواپیما و تجهیزات هوافضا طراحی شده و قوانین خیلی سختگیرانهای داره (جملههای کوتاه، فعلهای مشخص، دیکشنری محدود، بدون ابهام و استعارههای پیچیده). نتیجهش اینه که متن خیلی تمیز، مستقیم و خوانا میشه. اگر خیلی خشک شد، میتونید بگید «۸۰ درصد نزدیک به ASD-STE100» تا یه کم نرمترش کنه. برای توضیحهای فنی و پیچیده عالیه، چون مغزتون کمتر خسته میشه.
نمودار و دیاگرام به جای متن: به جاش مستقیم ازش بخواید دیاگرام، flowchart یا mermaid یا تصویر مفهومی بسازه. مغز ما اطلاعات بصری رو خیلی سریعتر پردازش میکنه و پارس کردنش راحتتره. مخصوصاً وقتی موضوع پیچیده باشه، یه دیاگرام خوب میتونه کل ایده رو در چند ثانیه منتقل کنه، در حالی که متن ممکنه چند پاراگراف طول بکشه.
خروجی به صورت HTML: بگید خروجی رو به صورت HTML کامل بده. مدلهای جدید واقعاً تو فرانتاند قوی شدن و میتونن صفحههای وب قشنگ، اینتراکتیو، با انیمیشن و استایل مدرن بسازن. به جای یه متن خشک، یه تجربهی تعاملی میگیرید که میتونید روش کلیک کنید، اسکرول کنید یا حتی چیزایی رو تست کنید. برای فهمیدن مفاهیم پیچیده خیلی کمککنندهست.
ویدیوهای explainer سفارشی (بهترینش اینه!): کارپتی میگه بیشتر از همه به این فرمت امیدواره. از مدل بخواید یه ویدیوی کامل و اختصاصی به سبک 3Blue1Brown بسازه (همون انیمیشنهای ریاضی و مفهومی تمیز و قشنگ). میتونید بگید از API کی ElevenLabs برای narration استفاده کنه یا جایگزینهای رایگان/لوکال پیدا کنه. اینطوری برای هر موضوعی که بخواید، یه ویدیوی آموزشی شخصیسازیشده میسازید که قبلاً ساختنش زمان و هزینهی دیوانهکنندهای داشت.خلاصهش
اینه که هوش مصنوعی داره انقدر زیاد و ارزون میشه که میتونیم ازش artifactهای بزرگ و دورریختنی بسازیم (وباپ، ویدیو، دیاگرامهای پیچیده و غیره) که قبلاً اصلاً بهصرفه نبود. کار ما داره میره به لایههای بالاتر abstraction و oversight، و جالب اینجاست که خود LLMها میتونن تو همین بخش هم کمکمون کنن.
به نظرم خیلی نکتهی درستیه، مخصوصاً برای ما که هر روز با اینا کار میکنیم. حتماً امتحان کنید و نتیجهش رو بگید 🔥
پ.ن: آندری کارپتی یکی از استادای واقعی و پیشگامهای حوزه LLM و deep learning حساب میشه. قبلاً مدیر AI تسلا بوده، از بنیانگذاران اولیه OpenAI، و یکی از بهترینها در توضیح شفاف و عمیق مفاهیم هوش مصنوعیه. وقتی حرف میزنه، معمولاً ارزش گوش دادن داره.
لینک توییت:
https://x.com/karpathy/status/2105819303471976479
X (formerly Twitter)
Andrej Karpathy (@karpathy) on X
We'll be spending a lot more time trying to understand the outputs of language models. A few thoughts, tips & tricks:
Writing. Something I've had success with: Ask your LLM to explain something i…
Writing. Something I've had success with: Ask your LLM to explain something i…
Forwarded from iCodeNext
قسمت اول از طراحی سیستم ورک فلو انجین - چیزی شبیه به n8n
توی این جلسه سعی میکنیم، یه ورک فلو انجین طراحی کنیم.
بیشتر تمرکز بر دیزاین کردن یه ورک فلو انجین به صورت داینامیک هست.
🚨 به علت اینکه ثبت نام محدود هست و کسیکه رجیستر میکنه و حضور پیدا نمیکنه در جلسات، تصمیم بر این شد که مبلغی رو برای ورودی و ثبت نام در نظر بگیریم. چنانچه شما مطمئن هستید که در جلسات شرکت میکنید ثبت نام انجام بدید.
ساعت و روز : چهارشنبه 15 مهر ماه، ساعت 8.30 دقیقه صبح به وقت تهران
مدت زمان جلسه : 2 ساعت
نیازمندی : چنانچه میخواهید در مباحث شرکت کنید، حتما لب تاب و دسترسی به هوش مصنوعی داشته باشید.
جلسات رکورد میشود : خیر
لینک ثبت نام:
https://luma.com/yx4w1imq
راهنمایی ثبت نام:
1- در ابتدا روی لینک کلیک نمایید، اطلاعات واریز در توضیحات هست.
2- واریز رو انجام بدید، و بعد نیازی به ارسال فیش و یا چیزی نیست، در زمان ثبت نام گزینه ی " واریز کرده ام " رو انتخاب کنید.
3- چنانچه در گروه وی آی پی هستید، میتونید پرداخت نکنید و گزینه ی وی آی پی رو انتخاب کنید.
4- منتظر تایید باشید تا لینک جلسه برای شما ارسال شود.
توی این جلسه سعی میکنیم، یه ورک فلو انجین طراحی کنیم.
بیشتر تمرکز بر دیزاین کردن یه ورک فلو انجین به صورت داینامیک هست.
🚨 به علت اینکه ثبت نام محدود هست و کسیکه رجیستر میکنه و حضور پیدا نمیکنه در جلسات، تصمیم بر این شد که مبلغی رو برای ورودی و ثبت نام در نظر بگیریم. چنانچه شما مطمئن هستید که در جلسات شرکت میکنید ثبت نام انجام بدید.
ساعت و روز : چهارشنبه 15 مهر ماه، ساعت 8.30 دقیقه صبح به وقت تهران
مدت زمان جلسه : 2 ساعت
نیازمندی : چنانچه میخواهید در مباحث شرکت کنید، حتما لب تاب و دسترسی به هوش مصنوعی داشته باشید.
جلسات رکورد میشود : خیر
لینک ثبت نام:
https://luma.com/yx4w1imq
راهنمایی ثبت نام:
1- در ابتدا روی لینک کلیک نمایید، اطلاعات واریز در توضیحات هست.
2- واریز رو انجام بدید، و بعد نیازی به ارسال فیش و یا چیزی نیست، در زمان ثبت نام گزینه ی " واریز کرده ام " رو انتخاب کنید.
3- چنانچه در گروه وی آی پی هستید، میتونید پرداخت نکنید و گزینه ی وی آی پی رو انتخاب کنید.
4- منتظر تایید باشید تا لینک جلسه برای شما ارسال شود.
Forwarded from .NET Internals
سلام به همگی
با Rookery آشنا بشید: از Issue تا Pull Request!
چند وقتیه دارم روی Rookery کار میکنم. یه GitHub Appه که یه Issue رو برمیداره و تا یه Draft PR آماده جلو میبره. قبل از اینکه حتی یه خط کد نوشته بشه، شما پلن رو تأیید میکنید. الان هم بالا اومده و میتونید امتحانش کنید
https://rookery.run
🚀 شروع کار
1️⃣ GitHub App Rookery رو روی ریپوهاتون نصب کنید.
2️⃣ با اکانت GitHub وارد پرتال بشید.
3️⃣ کلید API خودتون (Anthropic، DeepSeek یا GLM) رو توی صفحهی Keys اضافه کنید. کلیدها رمزنگاریشده ذخیره میشن و دیگه هیچجا نمایش داده نمیشن 🔒
🔄 از Issue تا PR
🏷️ لیبل
📝 Rookery یه پلن و لیست تسک مینویسه. اگه جایی ابهام داشته باشه، همونجا زیر Issue ازتون میپرسه.
✅ کامنت
⚙️ تسکها رو یکییکی انجام میده. برای هر تسک یه سشن تازه باز میکنه و بعد از هر کدوم commit میکنه.
🔍 آخر کار یه ایجنت ریویوئر نتیجه رو چک میکنه، و شما یه Draft PR تحویل میگیرید که پلن، تصمیمها و ریویو همه توشه.
👀 ریویوی PR هر وقت خواستید
روی هر PR که خواستید
🛠️ پشت صحنه
هارنس ما Claude Codeه. هر مرحله، CLI ِ
🎁 جایزه: به ۳ نفر که Rookery رو امتحان کنن و نظرشون رو همینجا کامنت کنن، اعتبار رایگان میدم تا بدون اضافه کردن کلید API خودشون ازش استفاده کنن 😉
لطفا به اشتراک بذارید و کمک کنید بهترش کنم.
با Rookery آشنا بشید: از Issue تا Pull Request!
چند وقتیه دارم روی Rookery کار میکنم. یه GitHub Appه که یه Issue رو برمیداره و تا یه Draft PR آماده جلو میبره. قبل از اینکه حتی یه خط کد نوشته بشه، شما پلن رو تأیید میکنید. الان هم بالا اومده و میتونید امتحانش کنید
https://rookery.run
🚀 شروع کار
1️⃣ GitHub App Rookery رو روی ریپوهاتون نصب کنید.
2️⃣ با اکانت GitHub وارد پرتال بشید.
3️⃣ کلید API خودتون (Anthropic، DeepSeek یا GLM) رو توی صفحهی Keys اضافه کنید. کلیدها رمزنگاریشده ذخیره میشن و دیگه هیچجا نمایش داده نمیشن 🔒
🔄 از Issue تا PR
🏷️ لیبل
rookery:trigger رو به Issue بزنید.📝 Rookery یه پلن و لیست تسک مینویسه. اگه جایی ابهام داشته باشه، همونجا زیر Issue ازتون میپرسه.
✅ کامنت
approve بذارید. فقط کسایی که دسترسی write دارن میتونن تأیید کنن، و پرتال هم دکمهی approve نداره.⚙️ تسکها رو یکییکی انجام میده. برای هر تسک یه سشن تازه باز میکنه و بعد از هر کدوم commit میکنه.
🔍 آخر کار یه ایجنت ریویوئر نتیجه رو چک میکنه، و شما یه Draft PR تحویل میگیرید که پلن، تصمیمها و ریویو همه توشه.
👀 ریویوی PR هر وقت خواستید
روی هر PR که خواستید
@rookery-agent رو منشن کنید، یا لیبل ریویو رو بزنید، یه جدول خلاصه با یافتهها و نتیجهی نهایی تحویل میگیرید.🛠️ پشت صحنه
هارنس ما Claude Codeه. هر مرحله، CLI ِ
claude رو توی یه git worktree جدا اجرا میکنه. با قوانین سفتوسخت deny، ایجنت نه میتونه push کنه و نه به GitHub دسترسی داره. همهی commitها، pushها و PRها رو خود Rookery انجام میده.🎁 جایزه: به ۳ نفر که Rookery رو امتحان کنن و نظرشون رو همینجا کامنت کنن، اعتبار رایگان میدم تا بدون اضافه کردن کلید API خودشون ازش استفاده کنن 😉
لطفا به اشتراک بذارید و کمک کنید بهترش کنم.
rookery.run
Rookery — agents that work your issue queue
Label a GitHub issue. Rookery plans it, waits for your approval, works through the tasks one at a time, and opens a draft pull request.
This media is not supported in your browser
VIEW IN TELEGRAM
سلام.
اول فکر کردم شوخیه و با AI درست شده.
بعد دیدم نه واقعیه. توی این سن ایشون داره در مورد یک مبحث خیلی مهم صحبت میکنه و بعد روزانه درگیر اینم که ای بابا، دیگه برنامه نویس ها تموم شدن و AI فلان و بهمان.
اول فکر کردم شوخیه و با AI درست شده.
بعد دیدم نه واقعیه. توی این سن ایشون داره در مورد یک مبحث خیلی مهم صحبت میکنه و بعد روزانه درگیر اینم که ای بابا، دیگه برنامه نویس ها تموم شدن و AI فلان و بهمان.
Forwarded from TechTube 𝕏 تک توب
مارگارت همیلتون یکی از پیشگامان مهندسی نرم افزار چند روز پیش در سن 90 سالگی درگذشت.
خانم همیلتون دانشمند علوم کامپیوتر در دانشگاه MIT بود که در دهه 1960 میلادی مسئولیت هدایت تیم توسعه نرم افزار پرواز ماموریت اپولوی ناسا رو دست گرفت و در نهایت منجر به اولین فرود انسان روی ماه در تاریخ شد.
ایشون از افرادی بود که به رواج اصطلاح مهندسی نرمافزار کمک کرد و تأکید داشت که ساخت نرم افزار صرفا نوشتن کد نیست، بلکه نرم افزار به طراحی سیستم، ازمایش، مدیریت خطا و تضمین قابلیت اطمینان نیاز داره.
🔎 mit
📍 @TechTube
خانم همیلتون دانشمند علوم کامپیوتر در دانشگاه MIT بود که در دهه 1960 میلادی مسئولیت هدایت تیم توسعه نرم افزار پرواز ماموریت اپولوی ناسا رو دست گرفت و در نهایت منجر به اولین فرود انسان روی ماه در تاریخ شد.
ایشون از افرادی بود که به رواج اصطلاح مهندسی نرمافزار کمک کرد و تأکید داشت که ساخت نرم افزار صرفا نوشتن کد نیست، بلکه نرم افزار به طراحی سیستم، ازمایش، مدیریت خطا و تضمین قابلیت اطمینان نیاز داره.
🔎 mit
📍 @TechTube
سلام.
ما یک پوزیشن Software Engineer در دیجی کالا ادز داریم که می خوایم با یک Staff Engineer پرش کنیم.
کاری که قراره بکنید روی سیستم های پر تراکنش(حدود 50 میلیون درخواست در روز) کار کنید که برای سازمان بسیار مهم و با ارزشه.
تمرکز این فرد روی بازطراحی و بهبود این سرویس ها و توسعه اونهاست.
پس، اگر روی golang متخصص هستید و بیشتر از ۸ سال سابقه کار دارید، خوشحال میشم بهم پیام بدید و یا از طریق این لینک اپلای کنید.
#استخدام
#جذب
ما یک پوزیشن Software Engineer در دیجی کالا ادز داریم که می خوایم با یک Staff Engineer پرش کنیم.
کاری که قراره بکنید روی سیستم های پر تراکنش(حدود 50 میلیون درخواست در روز) کار کنید که برای سازمان بسیار مهم و با ارزشه.
تمرکز این فرد روی بازطراحی و بهبود این سرویس ها و توسعه اونهاست.
پس، اگر روی golang متخصص هستید و بیشتر از ۸ سال سابقه کار دارید، خوشحال میشم بهم پیام بدید و یا از طریق این لینک اپلای کنید.
#استخدام
#جذب
جابینجا، شغلی رویایی خود را پیدا کنید
استخدام Senior Software Engineer | Ads Services در دیجیکالا | جابینجا
استخدام برای فرصت شغلی Senior Software Engineer | Ads Services در Digikala,
Design and implement software on top of Supernova. Demonstrate ownership and accountabilit...
Design and implement software on top of Supernova. Demonstrate ownership and accountabilit...
Forwarded from .NET Internals
به نظرم این پروژه واقعاً ارزش بررسی داره: https://github.com/morluto/rea
چیزی که در مورد REA برام جالبه، رویکردش به ترکیب مهندسی معکوس با ایجنتهای هوش مصنوعیه. ایده اینه که بهجای محدود موندن به تحلیل کد منبع، امکان بررسی رفتار و ساختار اپلیکیشنها، حتی در سطح باینری، فراهم بشه تا ایجنت بتونه با تکیه بر شواهد به درک عمیقتری از نحوه عملکرد سیستم برسه و در مسیر بازپیادهسازی قابلیتهای اون کمک کنه.
به نظرم این دقیقاً یکی از حوزههاییه که ترکیب AI و مهندسی نرمافزار میتونه تأثیر جدی بذاره؛ جایی که ایجنت صرفاً کد تولید نمیکنه، بلکه باید تحلیل کنه، فرضیه بسازه، شواهد رو بررسی کنه و بر اساس اونها به راهحل برسه.
فکر میکنم ارزش اصلی چنین پروژههایی در حرکت از تولید صرف کد به سمت درک و تحلیل سیستمهای پیچیدهست. قطعاً بررسی معماری و قابلیتهای REA میتونه دید جالبی نسبت به آیندهی AI-assisted reverse engineering بده.
قبلا میگفتیم همه محصولات یه کپی چینی دارن الان در حوزه نرم افزار هم داره ابن اتفاق میفته (نمونش مثلا PhotoCraft یکی اومده کلا فتوشاپ رو از اول نوشته و اپن سورس کرده!)
چیزی که در مورد REA برام جالبه، رویکردش به ترکیب مهندسی معکوس با ایجنتهای هوش مصنوعیه. ایده اینه که بهجای محدود موندن به تحلیل کد منبع، امکان بررسی رفتار و ساختار اپلیکیشنها، حتی در سطح باینری، فراهم بشه تا ایجنت بتونه با تکیه بر شواهد به درک عمیقتری از نحوه عملکرد سیستم برسه و در مسیر بازپیادهسازی قابلیتهای اون کمک کنه.
به نظرم این دقیقاً یکی از حوزههاییه که ترکیب AI و مهندسی نرمافزار میتونه تأثیر جدی بذاره؛ جایی که ایجنت صرفاً کد تولید نمیکنه، بلکه باید تحلیل کنه، فرضیه بسازه، شواهد رو بررسی کنه و بر اساس اونها به راهحل برسه.
فکر میکنم ارزش اصلی چنین پروژههایی در حرکت از تولید صرف کد به سمت درک و تحلیل سیستمهای پیچیدهست. قطعاً بررسی معماری و قابلیتهای REA میتونه دید جالبی نسبت به آیندهی AI-assisted reverse engineering بده.
قبلا میگفتیم همه محصولات یه کپی چینی دارن الان در حوزه نرم افزار هم داره ابن اتفاق میفته (نمونش مثلا PhotoCraft یکی اومده کلا فتوشاپ رو از اول نوشته و اپن سورس کرده!)
GitHub
GitHub - morluto/rea: Reverse engineer anything with agents, from app behavior down to native binaries.
Reverse engineer anything with agents, from app behavior down to native binaries. - morluto/rea
Forwarded from Product Drafts
یه رفتار خیلی سمی وجود داره که احتمالا همهمون یه جایی تجربهش کردیم. اینکه یکی نقطه ضعفی از یه نفر پیدا میکنه و از اون به بعد مدام همون نقطه رو هدف میگیره. انگار که پیدا کردن یه نقطه ضعف، فرصتی برای ضربه زدنه.
اما به نظرم اون طرف این ماجرا خیلی مهمتره، بهخصوص وقتی مدیر باشی.
اینکه بتونی نقطه ضعف آدمها رو بشناسی، اما به جای استفاده ازشون، مراقبشون باشی. حتی مهمتر اینکه حواست باشه بقیه هم از اون نقطه ضعف برای آسیب زدن بهشون استفاده نکنن.
به نظرم یکی از انسانیترین کارهایی که میتونیم برای آدمهای اطرافمون انجام بدیم همینه. اینکه بدونیم کجا آسیبپذیرن و درست همونجا مراقبشون باشیم.
شاید مدیریت خوب فقط به این نباشه که چقدر به رشد آدمها کمک میکنیم، گاهی به اینه که چقدر مراقب آسیبپذیریهاشون هستیم.
اما به نظرم اون طرف این ماجرا خیلی مهمتره، بهخصوص وقتی مدیر باشی.
اینکه بتونی نقطه ضعف آدمها رو بشناسی، اما به جای استفاده ازشون، مراقبشون باشی. حتی مهمتر اینکه حواست باشه بقیه هم از اون نقطه ضعف برای آسیب زدن بهشون استفاده نکنن.
به نظرم یکی از انسانیترین کارهایی که میتونیم برای آدمهای اطرافمون انجام بدیم همینه. اینکه بدونیم کجا آسیبپذیرن و درست همونجا مراقبشون باشیم.
شاید مدیریت خوب فقط به این نباشه که چقدر به رشد آدمها کمک میکنیم، گاهی به اینه که چقدر مراقب آسیبپذیریهاشون هستیم.
Forwarded from شبگفتار
امشب با احمد سجادیان عزیز از آلمان درباره شرایط کاری و انعطاف و ... بین کارمند و بیزنس ها گپ میزنیم
ساعت شروع برنامه : 22:30
مسیر ورود به برنامه : Shabgoftar.ir
همزمان با صحبت های مجری و میهمان شما هم می تونید از طریق بخش گفتگو سایت نظراتتون رو در لحظه با ما در میون بگذارید.
پیشاپیش از همراهی تون سپاس گزاریم
#گزارش_کار #شبگفتار
ساعت شروع برنامه : 22:30
مسیر ورود به برنامه : Shabgoftar.ir
همزمان با صحبت های مجری و میهمان شما هم می تونید از طریق بخش گفتگو سایت نظراتتون رو در لحظه با ما در میون بگذارید.
پیشاپیش از همراهی تون سپاس گزاریم
#گزارش_کار #شبگفتار
Forwarded from tech-afternoon (Amin Mesbahi)
فرض کنین یه پروژه نرمافزاری بزرگ دارین و بهجای اینکه یه ایجنت رو مأمور Refactoring کنین، تصمیم میگیرین ۲۰ تا ایجنت رو همزمان به کار بگیرین؛ ۵ تا برای refactoring، پنجتا هم برای پیدا کردن و رفع Bug، پنجتا برای نوشتن تست و پنجتای دیگه هم برای امتحان کردن روشهای مختلف بهینهسازی performance. خب؟
روی کاغذ خوبه؛ ولی یه مشکل اساسی داریم: هر Agent برای کارش به سورسکد پروژه، dependencyها و یه محیط اجرایی مستقل نیاز داره.
راهحلهای دوران پیشاهوشواره (ماقبل AI) مثل git تا حد خوبی این نیاز رو برطرف میکنن، ولی وقتی تعداد Agentها به دهها یا صدها برسه، مدیریت این محیطها، نگهداری فایلهای تکراری، آمادهسازی dependencyها و هماهنگی تغییرات، خودش تبدیل به یه چالش جدی میشه.
مثلاً وقتی یه پروژه با سورسکد ۱۰۰ گیگابایتی دارین؛ چرا باید برای هر Agent یک کپی جداگانه از همهچیز داشته باشین؟ از طرفی هم نمیشه همه از یه نسخه مشترک استفاده کنن و فقط تغییرات خودشون رو مستقل نگه دارن؟
دلیل پیدایش پروژه متنباز LayerFS همین مسئله بود! ایده اصلیش Ephemeral Workspaces, Durable Shared History است؛ یعنی محیطهای کاری موقت، با تاریخچه تغییرات ماندگار و مشترک.
به زبون ساده، هر ایجنت یه workspace مستقل داره، بدون اینکه لازم باشه همه فایلها و dependencyهای پروژه براش کپی بشن. همه از یه پایه مشترک استفاده میکنن و فقط تغییرات اختصاصی خودشون رو نگه میدارن.
قابلیت جذابترش اینکه تغییرات میتونن بهصورت checkpoint ثبت بشن. فرض کنین یه ایجنت برای refactoring چهار مرحله جلو رفته، ولی توی مرحله چهارم به بنبست رسیده. میشه از مرحله دوم یه branch جدید ساخت و به چند ایجنت دیگه سپرد تا مسیرهای متفاوتی رو امتحان کنن.
حتی میشه ۵۰ تا ایجنت رو روی ۵۰ راهحل متفاوت برای یه مسئله به کار گرفت، بعد خروجیها رو تست و مقایسه کرد و بهترین گزینه رو انتخاب کرد. البته انتخاب بهترین راهحل کار خود LayerFS نیست؛ این زیرساخت فقط اجرای چنین الگویی رو سادهتر میکنه.
از نظر فنی هم پروژه با ترکیبی از تکنیکهای شناختهشده و حتی قدیمی مثل Copy-on-Write، Content-Addressed Storage و SQLite پیادهسازی شده و ادعاهای جالبی درباره کاهش مصرف استورج و زمان آمادهسازی Workspaceها داره.
البته هنوز محدودیتهایی هم داره، مثل محدودیت اشتراک Store بین ماشینهای مستقل، یا مدیریت Conflictهای منطقی و بعضی ملاحظات مربوط به Durability.
بنابراین فعلاً نباید بهش بهعنوان «امروزه، عصر، عسر LayerFS است و هر کس بلد نباشه یا استفاده نکنه، ابله است» نگاه کنیم.
💡 اما به نظرم نکته مهمتر از خود LayerFS؛ مسئلهایه که داره حل میکنه.
ما داریم به سمتی میریم که توسعه نرمافزار لزوماً به معنی همکاری یه برنامهنویس با یه ایجنت نیست. ممکنه به معنی اجرای دهها یا صدها ایجنت باشه که همزمان فرضیههای مختلف رو امتحان میکنن، شکست میخورن، به عقب برمیگردن و مسیرهای جدیدی رو پیش میگیرن.
برای چنین آیندهای، فقط مدلهای هوشمندتر کافی نیستن. به زیرساختهایی نیاز داریم که این شکل از توسعه رو از نظر هزینه، سرعت، مدیریت state و قابلیت ردیابی عملی کنن.
و LayerFS قرار نیست ایجنتها رو باهوشتر کنه؛ میخواد کاری کنه که بتونیم تعداد خیلی بیشتری از اونها رو به شکل مؤثر، کنار هم به کار بگیریم و هزینه منابع رو در سطح استورج و زمان، کنترل کنیم.
و شاید این بخشِ کمتر دیدهشده یا کمتر پرداختهشدهای از تحول AI-Native Software Engineering باشه: تحول توی زیرساخت توسعه، نه صرفاً ابزار تولید کد یا حتی محصول.
🔗 وبسایتش
🔗 سورسکدش
Please open Telegram to view this post
VIEW IN TELEGRAM
LayerFS
LayerFS: the filesystem for AI coding agents
LayerFS is an open-source (MIT) filesystem for AI coding agents: each tool call gets a complete, writable Workspace over shared history.
Forwarded from مسعود بیگی (مسعود بیگی)
بچه ها این کتاب Data-intensive (فعلا رایگانه و اشتراک نمیخواد) رو یه گوشی بدین، ببینین خوبه کتاب های فنی این شکلی رو خلاصه صوتی بسازیم ؟
مخصوصا شما حسن جان
https://shabgoftar.ir/programs/book-summaries/designing-data-intensive-applications/
مخصوصا شما حسن جان
https://shabgoftar.ir/programs/book-summaries/designing-data-intensive-applications/
Forwarded from .NET Fun
یادش بخیر…
یه زمانی غرق بحثهای تکنیکال بودیم.
مینشستیم بحث میکردیم که چرا GC نمیاد LOH رو Compact کنه!
سر پارتیشنبندیهای کافکا و انواعواقسام Partition Assignment حرف میزدیم.
سر روشهای مختلف پیادهسازی Idempotency با هم بحث میکردیم، گاهی حتی دعوامون میشد!
الان اما همهچی شده AI.
گاهی فکر میکنم همونطور که ما آخرین نسلی بودیم که توی کوچهخیابون بازی میکردیم، شاید آخرین نسلی هم باشیم که از ساعتها بحث و کلنجار رفتن سر جزئیات تکنیکال، از خودِ تکنولوژی و از یاد گرفتن چیزهای جدید لذت میبردیم.
انگار یه چیزی از لذت مهندسی نرمافزار، وسط این همه هیاهوی AI مرد...
یه زمانی غرق بحثهای تکنیکال بودیم.
مینشستیم بحث میکردیم که چرا GC نمیاد LOH رو Compact کنه!
سر پارتیشنبندیهای کافکا و انواعواقسام Partition Assignment حرف میزدیم.
سر روشهای مختلف پیادهسازی Idempotency با هم بحث میکردیم، گاهی حتی دعوامون میشد!
الان اما همهچی شده AI.
گاهی فکر میکنم همونطور که ما آخرین نسلی بودیم که توی کوچهخیابون بازی میکردیم، شاید آخرین نسلی هم باشیم که از ساعتها بحث و کلنجار رفتن سر جزئیات تکنیکال، از خودِ تکنولوژی و از یاد گرفتن چیزهای جدید لذت میبردیم.
انگار یه چیزی از لذت مهندسی نرمافزار، وسط این همه هیاهوی AI مرد...