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

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

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

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

ازشون میتونین کمک بگیرین
@jobzlingo


@codehalics | کدهالیک

یه خبر امنیتی خیلی خفن اومده: تیم Depthfirst می‌گه ایجنت امنیتی خودکارشون تونسته ۲۱ تا Zero-day توی FFmpeg پیدا کنه؛ همون FFmpeg معروفی که تقریباً همه‌جا هست، از مرورگرها و سرویس‌های استریم گرفته تا ابزارهای تبدیل و پردازش ویدئو. جذابیت ماجرا اینه که این باگ‌ها بعد از کلی بررسی امنیتی سنگین توسط تیم‌هایی مثل Google و Anthropic پیدا شدن و بعضی‌هاشون ظاهراً ۱۵ تا ۲۰ سال توی کد خوابیده بودن. از اون مهم‌تر، خروجی ایجنت فقط «احتمالاً اینجا باگه» نبوده؛ برای هر مورد ورودی قابل بازتولید ساخته که ثابت کنه مشکل واقعاً وجود داره. یکی از نمونه‌ها هم تا حد Primitive برای اجرای کد از راه دور جلو رفته؛ یعنی اگر FFmpeg یک استریم RTSP مخرب رو باز کنه، ماجرا می‌تونه جدی بشه. خلاصه اینکه AI توی امنیت داره از مرحله حرف و دمو رد می‌شه و کم‌کم وارد فاز شکار واقعی باگ‌های عمیق توی کدهای قدیمی و سخت می‌شه.

https://depthfirst.com/research/21-zero-days-in-ffmpeg

@codehalics | کدهالیک

نسخه جدید Docker Desktop 4.77 منتشر شد؛ آپدیتی که بیشتر روی پایداری، دیباگ و بهبود تجربه توسعه‌دهنده‌ها تمرکز دارد. در این نسخه امکان خروجی گرفتن از لاگ‌ها اضافه شده، جست‌وجوی لاگ‌ها قابلیت Case-sensitive گرفته، ابزارهای اصلی مثل Docker Engine، Buildx، containerd، Docker Agent و MCP Gateway آپدیت شده‌اند و نصب و آپدیت اکستنشن‌ها هم با pinned manifest digest امن‌تر شده است. در کنار این‌ها، چند باگ مهم هم در Windows و WSL رفع شده؛ از جمله مشکل گیر کردن Docker Engine در حالت Starting و مشکل خروج تمیز از برنامه در Windows Containers mode.

https://docs.docker.com/desktop/release-notes/

@codehalics | کدهالیک

یه ایده ساده ولی خیلی مهم توی طراحی محصول هست به اسم «Every Frame Perfect»؛ یعنی اگر از اپلیکیشنت در هر لحظه‌ای اسکرین‌شات بگیری، همون فریم هم باید قابل‌فهم، تمیز و منطقی باشه. نه فقط حالت نهایی صفحه، نه فقط وقتی لودینگ تموم شده، نه فقط وقتی انیمیشن کامل شده؛ حتی وسط جابه‌جایی بین دو صفحه، وسط لود شدن دیتا، وسط انیمیشن‌ها و تغییر وضعیت‌ها هم UI نباید شلخته و نصفه‌نیمه به نظر بیاد.

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

https://tonsky.me/blog/every-frame-perfect/

@codehalics | کدهالیک

این مقاله یه نکته مهم درباره کار با AI و مخصوصاً AI Coding می‌گه: خیلی به «کانتکست بزرگ» مدل‌ها اعتماد نکنین. اینکه یه مدل می‌گه ۲۰۰ هزار، یک میلیون یا حتی دو میلیون توکن کانتکست داره، الزاماً یعنی همه اون اطلاعات رو با کیفیت خوب نمی‌فهمه و نگه نمی‌داره. نویسنده می‌گه کانتکست مدل‌ها یه فضای کاملاً هوشمند و یکدست نیست؛ انگار یه بخشی ازش «منطقه باهوش»ه که مدل هنوز دقیق و تیز کار می‌کنه، ولی وقتی چت خیلی طولانی می‌شه و فایل‌ها، لاگ‌ها، تست‌ها و توضیحات زیاد واردش می‌کنی، کم‌کم وارد «منطقه کندتر و گیج‌تر» می‌شه.

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

https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows

@codehalics | کدهالیک

دیروز داشتم یه مقاله خیلی جالب روی arXiv برای دانشگاه کرونل رو می‌خوندم که استاد شریف زارچی معرفیش کرده بود توی ویدیو اخیرش درباره اینکه وقتی با مدل‌های زبانی کار می‌کنیم، «همه اطلاعات رو اول کار بدیم» بهتره یا «کم‌کم و مرحله‌به‌مرحله توضیح بدیم». نتیجه‌اش برای من خیلی مهم بود، چون دقیقاً به تجربه روزمره ما با ChatGPT و ابزارهای AI Coding ربط داره.

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

https://arxiv.org/abs/2505.06120

@codhalics | کدهالیک

تلگرام قابلیت های جدیدی به بخش فرمتینگ اضافه کرده همون بخشی که میتونی متنت بولد کنی یا مارک داون بنویسی
از الان میتونی فرمول ریاضی هم توش بنویسی و یا استراکچر بدی به پیامات یا پیام طولانی مینویسی دکمه مشاهده بیشتر برات فعال کنه تا جایی که میخوای و کلی چیز جالب دیگ

از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot

@codehalics | کدهالیک

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

@codehalics | کدهالیک

We found an outage. Our engineers are investigating… 😂

@codehalics | کدهالیک

خب درست شد سایت و حالا بیاید موشکافی کنیم که در همچین لحظاتی باید چیکار کرد!

@codehalics | کدهالیک

قبل از اینکه بریم سراغ مچ‌گیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابل‌شوتینگ (Troubleshooting) که تو تیم‌های فنی بهش میگن «تی‌شوت» (T-Shoot) کردن.

تی‌شوت کردن یعنی چی؟
تی‌شوت کردن یعنی پیدا کردنِ ریشه‌ی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشم‌بسته عمل کردن.

خیلی وقت‌ها وقتی سرور یا اپلیکیشن می‌خوابه، برنامه‌نویس‌های تازه‌کار شروع می‌کنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ری‌استارت می‌کنن. به این کار میگن Trial and Error (آزمون و خطا).

اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تی‌شوت می‌کنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:

«من حدس نمی‌زنم، من لاگ‌ها رو می‌خونم.»

در واقع، تی‌شوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگ‌های سیستم‌عامل، دیتابیس و کانتینرها، پازل‌ها رو کنار هم می‌چینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.

@codehalics | کدهالیک

سناریویی که اتفاق افتاد این بود

داستان از این قرار بود که سرور لینوکس شما که میزبان سرویس‌های حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری می‌کنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"

در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابل‌شوتینگ) بشیم و از خود سیستم‌عامل به عنوان شاهد استفاده کنیم.

@codehalics | کدهالیک

۱. بررسی تاریخچه لاگین‌ها و خاموشی‌ها (last -x)
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماه‌ها پیش بوده.

۲. مدرک سخت‌افزاری: وحشتِ سیستم‌فایل (recovering journal)
وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام می‌بنده (Unmount). ما رفتیم سراغ لاگ‌های لحظه روشن شدن سرور با دستور:
journalctl -b | grep -i "recovering journal"
چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشن‌های sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود.

۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL)
دیتابیس‌ها به شدت روی داده‌ها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس:
docker logs <container_id>
چی پیدا کردیم؟ این شاه‌بیتِ ماجرا بود! پستگرس لاگ انداخته بود که:
database system was not properly shut down; automatic recovery in progress
یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده.

۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon)
برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگ‌های سرویس داکر رو چک کردیم:
journalctl -u docker.service -b
چی پیدا کردیم؟ ده‌ها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیط‌های شبکه‌ای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زباله‌های به‌جا مونده از دفعه قبل رو دستی پاک کنه.

۵. اثبات بی‌گناهی لینوکس (رد کردن ادعای کِرَش)
برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده":

پوشه کرش‌های هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده.

تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشی‌ای در زمان قطعی پیدا نشد.

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


نتیجه این T-Shoot:
به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستم‌عامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اون‌ها رو دادن.

@codehalics | کدهالیک

راز رکورتر های قلابی توی لینکدین که این روزا حسابی زیاد شدن

یه داستان واقعی که برای یکی از دوستای منم پیش اومده، همین مدلیه: یه سری آدم میان پیام می‌دن که شما برای فلان پوزیشن خیلی فیت هستی، رزومه‌ات رو دیدیم، پروژه‌هات جذابه، بیا یه تسک کوچیک انجام بده یا این ریپو رو ببین. ظاهر ماجرا خیلی حرفه‌ای و عادیه؛ انگار داری وارد یه فرآیند جذب معمولی می‌شی. ولی مشکل از جایی شروع می‌شه که همون «تسک کوچیک» می‌تونه یه تله باشه. توی این مقاله هم دقیقاً همین اتفاق افتاده؛ به طرف یه ریپوی گیت‌هاب دادن که مثلاً بررسیش کنه، اما داخل پروژه یه بک‌دور قایم کرده بودن که با نصب dependencyها فعال می‌شده. یعنی دیگه فقط لینک ناشناس و فایل exe خطرناک نیست؛ حتی یه پروژه گیت‌هاب برای مصاحبه کاری هم می‌تونه آلوده باشه. مخصوصاً برای بچه‌های فنی، قبل از اجرای هر پروژه ناشناس، بهتره توی محیط ایزوله، VM یا کانتینر بررسیش کنن و هیچ‌وقت همین‌طوری روی سیستم اصلی npm install نزنن. اصل مقاله رو اینجا بخونید:

https://roman.pt/posts/linkedin-backdoor/

@codehalics | کدهالیک

جالبه که این دقیقاً همون چیزیه که npm توی نسخه ۱۲ داره جدی‌تر جلوش رو می‌گیره؛ یعنی دیگه قرار نیست هر dependency همین‌طوری موقع نصب، اسکریپت‌های preinstall و install و postinstall خودش رو اجرا کنه، مگر اینکه خود پروژه صراحتاً بهش اجازه داده باشه.

این مورد رو ما قبلا توی کانال بررسی کردیم که تغییرات npm 12 چیه و حتما اپدیت کنین که گیر همچین آدمای مزدوری نیوفتین !

@codehalics | کدهالیک

هر فایل، ابزار، یا نرم‌افزاری که از منبع ناشناس دریافت می‌کنید، قبل از اجرا روی سیستم اصلی‌تون، داخل یه VM تست کنید.
مثلا Virtual Machine یا همون ماشین مجازی دقیقاً برای همین ساخته شده یه محیط کاملاً ایزوله که هر اتفاقی توش بیفته، به سیستم اصلی شما آسیب نمی‌رسه. بدترین سناریو؟ فایل‌های اون VM رو پاک می‌کنید و تمام.
گزینه‌های خوبی هم در دسترس دارید:
VirtualBox — رایگان، روی ویندوز و لینوکس
UTM — گزینه عالی برای مک، مخصوصاً سیلیکون اپل

یه ایمیج ویندوز یا اوبونتو نصب کنید، هیچ اطلاعات مهمی روش نذارید، و هر چیز مشکوکی رو اول اونجا باز کنید.
چرا مهمه؟ چون یه سری فایل‌ها اطلاعاتتون رو می‌دزدن، یه سری سیستمتون رو قفل می‌کنن (باج‌افزار)، و یه سری بدون اینکه چیزی بفهمید در پس‌زمینه کار می‌کنن.
یه VM همیشگی داشته باشید یه عادت ساده که خیلی از دردسرها رو جلوگیری می‌کنه.
@codehalics | کدهالیک

یه خبر عجیب و مهم از دنیای ابزارهای برنامه‌نویسی: طبق گزارش BBC، اسپیس‌ایکس داره Cursor رو می‌خره؛ همون ادیتور هوشمندی که خیلی از دولوپرها این یکی دو سال باهاش کد زدن و عملاً تبدیل شده به یکی از جدی‌ترین ابزارهای AI coding. نکته مهم خبر فقط خود خرید نیست، اینه که ابزارهای کدنویسی با هوش مصنوعی دیگه یه فیچر خوشگل کنار IDE نیستن؛ دارن تبدیل می‌شن به دارایی استراتژیک شرکت‌های بزرگ. یعنی هر شرکتی که مدل، compute، دیتای توسعه نرم‌افزار و workflow دولوپرها رو با هم داشته باشه، می‌تونه توی موج بعدی تولید نرم‌افزار دست بالاتر رو بگیره. حالا باید دید Cursor بعد از این خرید مستقل و چندمدلی می‌مونه یا کم‌کم به سمت اکوسیستم Grok و xAI کشیده می‌شه.

لینک خبر: https://www.bbc.com/news/articles/cvgd5g7d7gyo


@codehalics | کدهالیک

کلا عمو ماسک بر خلاف عمو بابک سمت هر چیزی رفته چندین پله بهترش کرده بنظرم اولین قدمش برای رقابت با دنیای Claude Code و AntiGravity و این چیزا اینه که بره یه چیز قدرتمند و خفنی مثل کرسر رو بخره و قطعا مدلای Grok طی چندین ماه آینده حرف های زیادی روی برنامه نویسی هم دارن و تجربه نشون داده که عمو ماسک همیشه تسهیل گری کرده که یه چیزی بیشتر دیده بشه با اینکه عقاید گاها چپ گرایانه ای هم از خودش بروز میده ولی من امیدوارم که یه تکونی به قیمت گذاری های آنتروپیک و اینا میده چون الان واقعا GROK هیچ حرفی توی برنامه نویسی و کد زدن واقعا نداره بیشتر بخاطر داشتن دیتای توییتر میتونه راجب اتفاقات روز و تحلیل روزمره و اینا کمک کنه
@codehalics | کدهالیک

اگه Mac بی‌کار با چیپ Apple Silicon دارید، می‌تونید به استخر darkbloom اضافه کنید تا به صورت encrypt شده مدل‌های اُپن سورس روش ران بشه و ازش درآمد ماهیانه داشته باشید. مثلا Macbook با چیپ M1 Pro و 32 گیگ رم، اگه مدل Gemma 4 رو ۲۴ روز در ماه ران کنه، حدود ۹۰ دلار پاداش می‌گیرید! بچه‌هایی که کریپتویی هستن شاید شرکت پشت سرش به اسم EigenLayer واسشون آشنا باشه! جدیدا هم با OpenRouter برای ساپلای کردن inference قرارداد بستن!
darkbloom.dev

Amir

@codehalics | کدهالیک

ورسل یه فریم‌ورک جدید معرفی کرده به اسم Eve؛ خلاصه‌اش اینه که می‌خواد برای ساخت AI Agent همون کاری رو بکنه که Next.js برای ساخت وب‌اپ کرد. یعنی به‌جای اینکه هر تیم از صفر بیاد برای ایجنتش کلی چیز تکراری بسازه، مثل اتصال به ابزارها، اجرای امن کد، مدیریت پرامپت، لاگ و تریس، Approval انسانی، تست و دیپلوی، Eve این زیرساخت‌ها رو آماده می‌ده. توی Eve یه ایجنت عملاً یه پوشه‌ست؛ یه فایل برای مدل، یه فایل برای دستورالعمل‌ها، یه فولدر برای ابزارها، یکی برای skillها، یکی برای subagentها، یکی برای کانال‌هایی مثل Slack و Telegram و GitHub.

نیازش هم دقیقاً از اینجا میاد که ساختن Agent واقعی فقط این نیست که یه LLM صدا بزنی و بگی فلان کار رو بکن. وقتی Agent قراره توی محصول واقعی کار کنه، باید وسط کار کرش نکنه، بتونه چند ساعت یا چند روز یه فرآیند رو ادامه بده، برای کارهای حساس از آدم تأیید بگیره، کدی که تولید می‌کنه رو توی محیط امن اجرا کنه، به سرویس‌هایی مثل GitHub، Slack، Snowflake، Notion و Linear وصل بشه و بشه فهمید دقیقاً چه کاری کرده و کجا اشتباه کرده. Eve می‌خواد این تکه‌های پراکنده رو تبدیل کنه به یه فریم‌ورک استاندارد برای ساخت Agentهای Production-ready. خلاصه اگر قبلاً هر تیم داشت Agent خودش رو با چسب و سیم می‌ساخت، Vercel می‌گه بیاید از این به بعد براش اسکلت و معماری درست داشته باشیم.

https://vercel.com/blog/introducing-eve

@codehalics | کدهالیک

ایران درست میشه
وضعیت ایران :

@codehalics | کدهالیک