به گزارش پیوست، تیم بازاریابی یکی از شرکتهای فعال در ایران در دوره جنگ و با توجه به قطعی اینترنت و از بین رفتن مسیرهای معمول ارتباط با مشتری، به فکر راه دیگری برای گرفتن سفارش انداخت. منتظر ماندن برای اینکه درخواست وارد صف تیم فنی شود، در آن شرایط چندان منطقی نبود. بنابراین تیم بازاریابی خودش دست به کار شد و در حدود سه روز رباتی برای سفارشگیری در پیامرسان بله ساخت. این ربات در دوره جنگ و تا حدود یک ماه بعد از آن، زمانی که اینترنت هنوز ثبات نداشت، برای دریافت سفارشهای واقعی استفاده شد.
فاطمه آرنواز، مدیر بازاریابی دیجیتال Active Cleaners که در حوزه خشک شویی آنلاین فعالیت میکند به پیوست میگوید کل پیادهسازی ربات سفارش گیری را تیم مارکتینگ انجام داد. کاربران قبلی و کسانی که تبلیغات مجموعه را در بله میدیدند، وارد ربات میشدند و سفارششان را ثبت میکردند. اطلاعات سفارش بعد از آن به کارشناسان عملیات میرسید و ادامه هماهنگی تلفنی انجام میشد.
اما ساختن ابزار پایان مسئله نبود. نگرانی از گمشدن داده باعث شد هر شب ساعت ۲۳:۵۹ گزارشی از تمام سفارشهای ثبتشده برای سه مدیر ارسال و دستی با تماسهای کارشناسان تطبیق داده شود.وقتی ساخت نرمافزار از تیم فنی بیرون میآید
نکته مهم این تجربه فقط سهروزه بودن ساخت ربات نیست. اتفاق مهمتر این است که مسئلهای که تا همین چند وقت پیش باید به تیم فنی سپرده میشد، این بار به دست همان تیمی حل شد که با مشکل روبهرو بود.
وایبکدینگ (Vibe Coding) بخشی از همین تغییر است؛ روشی که در آن فرد بهجای نوشتن خطبهخط کد، با زبان طبیعی خواستهاش را برای ابزار هوش مصنوعی توضیح میدهد، نتیجه را میبیند، ایرادها را میگوید و آنقدر این رفتوبرگشت را ادامه میدهد تا به چیزی برسد که کار میکند. در چنین شرایطی دیگر سازنده نرمافزار الزاماً یک توسعهدهنده حرفهای نیست و فاصله میان «من چنین ابزاری لازم دارم» و «این ابزار کار میکند» بسیار کوتاهتر شده است.
این تغییر حتی ساخت نرمافزارهایی را ممکن کرده که قرار نیست هزاران یا میلیونها کاربر داشته باشند. گاهی تنها کاربر یک نرمافزار، همان کسی است که آن را ساخته است.
ایلیا عابدینی در یادداشتی که ۱۶ تیرماه در iAct، پلتفرمی برای انتشار تجربهها و نوشتههای مرتبط با فناوری و هوش مصنوعی منتشر کرده، از تجربه ساخت یک نرمافزار کاملاً شخصی نوشته است. او میخواست هر بار که اسپرسو درست میکند، مشخصات شات از جمله میزان قهوه، زمان عصارهگیری، خروجی و نتیجهای که از نظر طعم گرفته را ثبت کند تا بتواند دفعه بعد ترکیب بهتری پیدا کند. بهجای جستوجو برای یک اپ آماده یا سپردن ایده به یک برنامهنویس، با استفاده از ابزار کدنویسی مبتنی بر هوش مصنوعی Kilo Code، اپ مورد نیاز خودش را ساخت. نسخه اول بینقص نبود و حتی تایمر درست کار نمیکرد، اما با چند رفتوبرگشت با هوش مصنوعی ایرادها را برطرف کرد و در نهایت به ابزاری رسید که اساساً برای یک کاربر ساخته شده بود: خودش.
این تجربه بهتنهایی چیزی درباره اندازه بازار وایبکدینگ نمیگوید، اما یک تغییر را بهخوبی نشان میدهد: حالا حتی مسئلهای که فقط یک نفر با آن درگیر است، ممکن است ارزش ساختن یک نرمافزار را داشته باشد.
دادههای OpenAI تصویر بزرگتری از همین جابهجایی ارائه میکند. این شرکت در پژوهشی که ۲۷ ژوئیه ۲۰۲۶ روی بیش از ۸۰۰ هزار پیام کاری کاربران ChatGPT در آمریکا منتشر کرد، گزارش داد وظایف مهندسی ۷.۴ درصد پیامهای کاربران شاغل در حوزههای دیگر را تشکیل میدهد. OpenAI این اتفاق را «task crossover» یا جابهجایی وظایف میان نقشها مینامد؛ یعنی کاری که قبلاً باید به متخصص دیگری سپرده میشد، حالا ممکن است به دست همان کسی انجام شود که به مسئله نزدیکتر است.کار میکند؛ اما میشود به آن اعتماد کرد؟
ساختن یک نسخهای که کار کند، با ساختن محصولی که بتوان به آن اعتماد کرد یکی نیست. این فاصله وقتی نرمافزار قرار است از یک تجربه شخصی فراتر برود و وارد کسبوکار شود، بیشتر خودش را نشان میدهد.
حامد شریفی، توسعهدهندهای که در حال ساخت یک پلتفرم سفارش ناهار شرکتی با استفاده گسترده از هوش مصنوعی است، به پیوست میگوید: معماری و مشخصات پروژه را خودش تعیین کرده اما طراحی و کدنویسی را تا حد زیادی به هوش مصنوعی سپرده است.
با این حال پروژه هنوز به دست کاربران واقعی نرسیده است. به گفته او، یک ماه از کار گذشته و حدود یک ماه دیگر هم باقی مانده؛ زمانی که باید صرف امنیت، تست، یکپارچهسازی، استقرار و «سختسازی» سیستم شود؛ همان کارهایی که باعث میشوند نرمافزار نه فقط در شرایط آزمایشی، بلکه هنگام مواجهه با خطا، حمله و رفتارهای پیشبینینشده کاربران هم دوام بیاورد.
مسئله امنیت این فاصله را روشنتر میکند. در پژوهش SUSVIBES حدود ۲۰۰ درخواست توسعه واقعی از پروژههای متنباز بررسی شدند؛ مسائلی که پیادهسازی انسانی آنها در گذشته سابقه ایجاد آسیبپذیری داشت. در یکی از تنظیمات این آزمایش، SWE-Agent با مدل Claude 4 Sonnet توانست در ۶۱ درصد موارد راهحلی ارائه کند که از نظر عملکردی درست بود، اما فقط ۱۰.۵ درصد کل راهحلها آزمون امنیتی همان پژوهش را هم پشت سر گذاشتند.
این نتایج را نمیتوان به همه کدهای نوشتهشده با هوش مصنوعی تعمیم داد، اما نشان میدهد کدی که درست کار میکند، لزوماً از نظر امنیت هم قابل اعتماد نیست.وقتی ابزار شخصی، مسئولیت سازمانی میشود
محمدرضا مهرآزما، مشاور امنیت اطلاعات، در پاسخ به پیوست از زاویه دیگری به همین مسئله نگاه میکند. به گفته او، وقتی ابزارهایی که خارج از چرخه رسمی IT ساخته شدهاند وارد کار واقعی یک سازمان میشوند، دیگر نمیتوان با آنها مثل یک پروژه شخصی برخورد کرد.
چنین ابزاری دستکم باید مالک مشخص داشته باشد، در فهرست داراییهای سازمان ثبت شود، تکلیف دادههایی که دریافت و نگهداری میکند روشن باشد، ارائهدهنده سرویس آن تأیید شده باشد و اطلاعات و کلیدهای دسترسی و همچنین لاگها به شکل مشخص مدیریت شوند.
اگر داده حساس وارد ابزار شود، کسی مسئول آن نباشد، رویدادها ثبت نشوند، سرویس تأییدنشدهای درگیر باشد یا ابزار مستقیماً به سامانههای عملیاتی سازمان وصل شود، به گفته مهرآزما باید استفاده از آن متوقف و دوباره بررسی شود.
در اصل ساخت نرمافزار برای افراد بیشتری ممکن شده، اما مسئولیت آن همچنان باقی است؛ اینکه چه کسی باید امنیتش را تضمین کند، خطاهایش را برطرف کند و در نهایت پاسخگوی عملکرد آن باشد.
وایبکدینگ از این منظر فقط داستان ارزانتر یا سریعتر شدن کدنویسی نیست. وقتی تیم بازاریابی، عملیات یا حتی یک فرد بتواند ابزار مورد نیازش را خودش بسازد، گلوگاه از نوشتن کد به تشخیص کیفیت منتقل میشود. چه کسی میتواند بفهمد معماری درست است؟ چه کسی دسترسی به دادهها را کنترل میکند؟ چه کسی تست مینویسد؟ اگر سرویس متصل به ابزار تغییر کرد یا چند ماه بعد بخشی از نرمافزار از کار افتاد، چه کسی باید آن را درست کند؟
ربات سفارشگیری تیم بازاریابی همین دو سوی ماجرا را در مقیاس کوچک نشان میدهد. تیم توانست در سه روز یک مسیر واقعی برای ادامه کار بسازد؛ اما برای اطمینان از اینکه سفارشی گم نمیشود، هر شب یک کنترل انسانی کنار آن گذاشت. هوش مصنوعی فاصله ایده تا نرمافزار را کوتاه کرده؛ اما فاصله نرمافزار تا اعتماد هنوز با کار دیگری پر میشود.
