دوران مهندسانی که عمدتاً ساعتها کد دستنویس تولید میکردند رو به پایان است. شرکتهای نرمافزاری باید خودشان ابزارها و پلتفرمهای توسعه بسازند تا با موج تولید کد توسط ماشینها همگام بمانند.
فرصت و مشکل تولید خودکار کد
ابزارهای مبتنی بر مدلهای زبانی کد را سریعتر تولید میکنند، اما سرعت بهتنهایی مشکل را حل نمیکند. وقتی هر تیم از صفر پرومپتها، قواعد حفاظتی و داشبوردهای پیگیری خطا را جداگانه میسازد، در عمل به پراکندگی، هزینههای عملیاتی بیشتر و کاهش کیفیت منجر میشود. قدرت مدلها بدون سازوکارهای مشترک کنترلی و حلقههای بازخورد، قابل اتکا نخواهد بود.
تغییر نقشهای مهندسی: از فرانتاند/بکاند به محصول و پلتفرم
تقسیمبندی سنتی فرانتاند/بکاند کمکم جای خود را به دو نقش میدهد: مهندس محصول که تجربهٔ کاربر و محصول نهایی را شکل میدهد، و مهندس پلتفرم که ابزارها، سرویسها و زیرساختی میسازد که تیمهای محصول با آن کار میکنند. با افزایش سهم تولید کد توسط ماشینها، تقاضا برای مهندسان پلتفرم که چرخههای تولید خودکار را طراحی، بهینه و محافظت کنند، رشد خواهد کرد.
همگرایی دو پلتفرم: تحویل و عاملمحوری
پلتفرمهای درونسازمانی تا کنون حول CI/CD، تحویل نرمافزار و Infrastructure as Code شکل میگرفتند. اکنون یک لایهٔ جدید—پلتفرم توسعهدهنده عاملمحور—ظهور کرده است که فریمورکها و مدلهای مجاز، کنترلهای هزینهٔ هوش مصنوعی و نگهبانهای عامل را مدیریت میکند. همانطور که مشاوران فناوری در ThoughtWorks اشاره کردهاند، این دو حوزه نهایتاً همگرا میشوند و مالکیت زیرساخت تحویل و قواعد حفاظتی را در یک پلتفرم یکپارچه ترکیب میکنند.
مهندسی هارنس: لایهٔ مخصوص هوش مصنوعی در پلتفرم
«هارنس» مجموعهای از حلقههای بازخورد، قواعد حفاظتی و زمینهٔ اجرایی است که عاملهای تولیدکنندهٔ کد برای کار ایمن و قابل پیشبینی به آن نیاز دارند. یک هارنس کارآمد دو هدف اصلی دارد:
- افزایش احتمال عملکرد درست عامل در بار اول،
- ایجاد مکانیسمهایی که عامل بتواند اشتباهات خود را پیش از رسیدن به بازبینی انسانی تشخیص و اصلاح کند.
ابزارهایی مانند سامانهٔ ثبت خطاهای شناختهشده میتوانند مجموعهای از قواعد ثابت را نگهداری کنند و بهصورت خودکار روی تغییرات اعمال نمایند تا تکرار خطاهای شناختهشده کاهش یابد.
ریسکها در صورت غفلت
اگر مهندسی پلتفرم برای هوش مصنوعی جدی گرفته نشود، عاملها بارها همان اشتباهات تکراری را انجام میدهند و سازمان تنها پس از وقوع مشکل متوجه خواهد شد. حتی مدلهای قدرتمند هم به قاببندی، محافظت و نظارت نیاز دارند تا عملکردشان در مقیاس قابل اتکا باشد.
گامهای عملی برای آمادهسازی سازمان
گامهای کوتاهمدت و مؤثر که سازمانها باید سریع بردارند:
- ایجاد یا تقویت تیم پلتفرم با تمرکز مشخص بر سازوکارهای عاملمحور، قوانین و مدیریت چرخهٔ تولید خودکار.
- یکسانسازی پرومپتها و نگهبانها بهجای اجازه دادن به هر تیم برای ساختن مجموعههای جداگانه از قواعد.
- استقرار ابزارهای مشاهدهپذیری و داشبورد برای رصد عملکرد عاملها، هزینهٔ مدلها و خطاهای تولیدی.
- تعریف گیتها و قواعد تست خودکار برای خروجیهای تولیدشده تا کیفیت کد تضمین شود.
- مدیریت هزینهٔ مدلها با اعمال کنترلهای مرکزی و پایش مصرف تا استفادهٔ بیرویه محدود شود.
آیندهٔ مهندسی نرمافزار
پلتفرمهای درونسازمانی که پیشتر روی CI/CD و زیرساخت کار کردهاند، اکنون باید یک لایهٔ عاملمحور اضافه کنند؛ لایهای که پرومپتها، نگهبانها، قوانین هزینه و حلقههای بازخورد را یکپارچه کند. شرکتهایی که این تبدیل را انجام میدهند نهتنها سرعت توسعه را حفظ میکنند، بلکه از هزینهٔ پراکندگی و اشکالزدایی مکرر جلوگیری خواهند کرد. نسل بعدی مهندسی ترکیب مهندسی پلتفرم با مهندسی هوش مصنوعی است؛ سازمانهایی که پلتفرم داخلی قوی میسازند کنترل، کیفیت و سرعت را همزمان خواهند داشت.
برای مرور مفاهیم پایهای مرتبط با مهندسی نرمافزار میتوانید به صفحهٔ مرجع مهندسی نرمافزار در ویکیپدیا مراجعه کنید.
