هر چند ماه یکبار، یک مدل هوش مصنوعی جدید معرفی میشود که وعده میدهد توسعه نرمافزار را متحول خواهد کرد.
مدلها سریعتر میشوند.
پنجرههای Context بزرگتر میشوند.
تولید کد دقیقتر میشود.
اما یک مشکل همچنان پابرجاست.
هر گفتگوی جدید، از صفر شروع میشود.
امروزه دستیارهای هوش مصنوعی فوقالعاده توانمند شدهاند.
آنها میتوانند معماری سیستمهای توزیعشده را طراحی کنند، کوئریهای دیتابیس را بهینه کنند، API طراحی کنند، Pull Requestها را بررسی کنند، تست بنویسند و حتی هزاران خط کد قابل استفاده در محیط Production تولید کنند.
اما تقریباً همه آنها یک محدودیت مشترک دارند:
آنها پروژه نرمافزاری را به خاطر نمیسپارند.
نه آنگونه که یک تیم مهندسی به خاطر میسپارد.
وقتی انسانها روی یک پروژه کار میکنند، در طول ماهها یا سالها دانشی جمعآوری میشود که بخشی از هویت پروژه است.
مثل اینکه:
چرا این تصمیم معماری گرفته شد؟
چه راهکارهایی بررسی و رد شدند؟
چرا ساختار فعلی دیتابیس انتخاب شد؟
چه بدهیهای فنی عمداً پذیرفته شدهاند؟
چه محدودیتهایی در آینده باید برطرف شوند؟
این دانش، بخشی از پروژه است.
اما هوش مصنوعی معمولاً آن را حفظ نمیکند.
در نتیجه، در هر جلسه باید دوباره همان اطلاعات را به آن منتقل کنیم.
در واقع، ما بارها و بارها هزینه بازسازی دانشی را پرداخت میکنیم که قبلاً تولید شده است.
بسیاری تصور میکنند راهحل این مشکل، افزایش اندازه Context است.
در نگاه اول منطقی به نظر میرسد.
اگر مدل بتواند کل مخزن پروژه را بخواند، پس همه چیز را میفهمد.
اما در عمل، این رویکرد مشکلات جدیدی ایجاد میکند.
بارگذاری کل پروژه برای هر درخواست:
هزینه پردازش را افزایش میدهد.
مصرف Token را بالا میبرد.
پاسخدهی را کندتر میکند.
و مهمتر از همه، مدل را مجبور میکند حجم زیادی اطلاعات غیرمرتبط را پردازش کند.
فرض کنید فقط میخواهید یک باگ در سیستم احراز هویت را برطرف کنید.
آیا واقعاً لازم است مدل همزمان سیستم پرداخت، ماژول گزارشگیری، تنظیمات CI/CD و تاریخچه تصمیمات سایر بخشها را نیز دوباره بخواند؟
انسانها اینگونه کار نمیکنند.
هوش مصنوعی هم نباید اینگونه کار کند.
فرض کنید یک مهندس ارشد استخدام کردهاید که بعد از هر جلسه، همه چیز را فراموش میکند.
هر صبح باید دوباره برایش توضیح دهید:
معماری پروژه
استانداردهای برنامهنویسی
روند استقرار
تصمیمات قبلی
محدودیتهای شناختهشده
برنامه آینده پروژه
بعد از مدتی متوجه میشوید زمان بیشتری صرف توضیح دادن میکنید تا توسعه دادن.
این دقیقاً شبیه نحوه استفاده فعلی ما از هوش مصنوعی است.
به جای اینکه پروژه را یک سیستم زنده و در حال تکامل ببینیم، هر گفتگو را یک جلسه کاملاً مستقل فرض میکنیم.
نتیجه چیزی جز اتلاف زمان و تکرار نیست.
سیستمعامل سختافزار را مدیریت میکند.
Git کد منبع را مدیریت میکند.
پایگاه داده اطلاعات را مدیریت میکند.
اما چه چیزی همکاری بین هوش مصنوعی و پروژه را مدیریت میکند؟
تقریباً هیچ چیز.
امروزه بیشتر ابزارهای AI صرفاً بر پایه Prompt Engineering کار میکنند.
Prompt مهم است.
اما Prompt، معماری نیست.
یک پروژه نرمافزاری به چیزی فراتر نیاز دارد:
حافظه پایدار
استانداردهای مهندسی
Workflow
قوانین معماری
Checkpoint
وضعیت پروژه
گراف دانش
ثبت تصمیمات معماری (ADR)
به بیان دیگر،
به یک سیستمعامل نیاز دارد.
فرض کنید هر بار که هوش مصنوعی کاری را شروع میکند، ابتدا از خودش بپرسد:
«برای انجام این کار دقیقاً چه اطلاعاتی لازم دارم؟»
به جای بارگذاری هزاران فایل، فقط اطلاعات مرتبط را میخواند:
قوانین مهندسی
مستندات همان ماژول
تصمیمات معماری مرتبط
وضعیت فعلی پروژه
Workflow همان وظیفه
نه بیشتر.
بعد از پایان کار نیز فقط کد تولید نمیکند.
بلکه:
مستندات را بهروزرسانی میکند.
حافظه پروژه را تکمیل میکند.
Checkpoint جدید ثبت میکند.
تصمیمات جدید را ذخیره میکند.
ارتباطات موجود در Knowledge Graph را بهروزرسانی میکند.
در نتیجه، جلسه بعدی از صفر شروع نمیشود.
بلکه از همان نقطه ادامه پیدا میکند.
اکثر ابزارهای فعلی برای مدیریت گفتگو طراحی شدهاند.
اما توسعه نرمافزار به تداوم نیاز دارد.
گفتگو فقط به سؤال پاسخ میدهد.
اما یک جلسه مهندسی، پروژه را تکامل میدهد.
هر وظیفهای که انجام میشود باید اثری ماندگار در پروژه باقی بگذارد؛ اثری که هم انسانها و هم هوش مصنوعی بتوانند در آینده آن را درک کنند.
امروز ممکن است بهترین مدل ChatGPT باشد.
فردا شاید Codex، Claude یا مدل دیگری جای آن را بگیرد.
اگر دانش پروژه وابسته به یک مدل خاص باشد، با هر تغییر فناوری مجبور به مهاجرت خواهیم شد.
اما اگر خود Repository مالک دانش پروژه باشد، هر مدل هوش مصنوعی میتواند از همان دانش استفاده کند.
دانش پروژه باید متعلق به مخزن باشد، نه به مدل هوش مصنوعی.
سالهاست از خودمان میپرسیم:
«چگونه هوش مصنوعی کد بیشتری بنویسد؟»
اما شاید سؤال درست این باشد:
«چگونه هوش مصنوعی بتواند مانند یک مهندس نرمافزار واقعی فکر کند؟»
نوشتن کد تنها بخش کوچکی از مهندسی نرمافزار است.
بخش مهمتر شامل:
تصمیمگیری
مستندسازی
حفظ دانش
تحلیل Trade-offها
حفظ یکپارچگی معماری
برنامهریزی برای آینده
بدون این موارد، فقط سرعت تولید بدهی فنی را افزایش دادهایم.
همین نگاه باعث شد پروژهای را با نام AIOS (AI Operating System for Software Engineering) آغاز کنم.
هدف AIOS ساخت یک مدل هوش مصنوعی جدید نیست.
هدف ساخت یک Wrapper دیگر هم نیست.
حتی مجموعهای از Promptها هم نیست.
AIOS تلاشی است برای پاسخ به یک سؤال ساده:
اگر Repository بتواند تمام دانشی را که یک مهندس برای ادامه پروژه نیاز دارد در خودش نگه دارد، چه اتفاقی میافتد؟
نه فقط کد.
بلکه:
حافظه
استانداردها
Workflowها
وضعیت پروژه
تصمیمات معماری
Checkpointها
ارتباطات میان بخشهای مختلف پروژه
همه چیز برای اینکه هوش مصنوعی بتواند پروژه را ادامه دهد، نه اینکه هر بار دوباره آن را کشف کند.
بدون شک مدلهای هوش مصنوعی هر روز بهتر خواهند شد.
اما به نظر من، جهش بزرگ بعدی از خود مدلها نخواهد آمد.
بلکه از سیستمهایی خواهد آمد که بتوانند این مدلها را در قالب یک فرآیند مهندسی واقعی به کار بگیرند.
آینده توسعه نرمافزار با هوش مصنوعی، فقط به مدلهای هوشمندتر وابسته نیست.
بلکه به پروژههایی وابسته است که بتوانند به خاطر بسپارند.
شاید سالها تلاش کردهایم به هوش مصنوعی یاد بدهیم چگونه کد بنویسد.
حالا وقت آن رسیده که به پروژههای نرمافزاری یاد بدهیم چگونه با هوش مصنوعی زندگی کنند.
AIOS یک پروژه متنباز است و این مقاله تنها بخشی از ایده اصلی آن را معرفی میکند.
اگر علاقهمند هستید معماری پروژه، سیستم حافظه پایدار، Workflowهای مهندسی، استانداردها و ساختار AIOS را بررسی کنید یا در توسعه آن مشارکت داشته باشید، میتوانید از مخزن GitHub پروژه بازدید کنید:
https://github.com/arvinlp/AI-Operating-System-for-Software-Engineering
از پیشنهادها، نقدها، Issueها و Pull Requestهای شما استقبال میکنم. هدف AIOS ساخت زیرساختی عملی برای توسعه نرمافزار مبتنی بر هوش مصنوعی است؛ زیرساختی که مستقل از هر مدل یا شرکت ارائهدهنده هوش مصنوعی باشد و بتواند پروژهها را در مقیاس ماهها و سالها همراهی کند.
