تصور کنید مدیر یک بیمارستان باشید و منتظر نرمافزاری باشید که وعده داده شده بود شش ماه دیگر آماده شود، اما ناگهان محصول کامل را پس از دو هفته تحویل بگیرید. این تنها یک تخمین خوشبینانه نیست، بلکه نتیجهٔ تغییری بنیادین در نحوهٔ ساخت نرمافزار است. یک ماژول پیچیده نرمافزاری برای بیمارستان که معمولاً به شش ماه توسعه سنتی نیاز دارد، تنها در دو هفته به عنوان یک نسخه آماده بهرهبرداری (Production Build) منتشر شد. این نتیجه که در گزارشی به تاریخ ۱۵ ژوئیه ۲۰۲۶ در وبسایت dev.to به اشتراک گذاشته شد، نشاندهنده گذار از کدنویسی «کمکگرفته از هوش مصنوعی» به یک چرخه توسعه کاملاً «هوش مصنوعیمحور» (AI-Native) است.
نرمافزارهای حوزه بهداشت و درمان به دلیل ریسکهای حیاتی مربوط به ایمنی بیمار و الزامات سختگیرانه انطباق قانونی، به شدت صلب و انعطافناپذیر هستند. اکثر شرکتها با پروژههای «میدان قهوهای» (Brownfield) دستوپنجه نرم میکنند؛ یعنی کدهای قدیمی، پیچیده و نامنظمی که بهروزرسانی آنها بدون شکستن سیستمهای حیاتی، بسیار دشوار است. این پروژه خاص، مربوط به یک شرکت محصولات بهداشتی بود که در حال ساخت پلتفرمی برای بیمارستانها با تأثیرات بالینی واقعی بود. محیط پروژه بسیار چالشبرانگیز بود: یک کدبیس Brownfield، مشتریانی که پیش از این توسط پیمانکاران قبلی آسیب دیده بودند و محصولی که آنقدر پیچیده بود که ادغامهای متعدد سختافزاری را در کنار نرمافزار هسته شامل میشد.
پیش از آنکه این تیم وارد عمل شود، بیش از یک پیمانکار قبلاً از این پروژه خارج شده و حساب خود را بسته بودند. شکست این پیمانکاران به دلیل اشتباه در چشمانداز محصول نبود، بلکه به این دلیل بود که نتوانستند به طور مداوم ارزش واقعی را نشان دهند یا وعدههای خود را عملی کنند. با تکیه بر پوششهای قبلی ما درباره Vercel AI SDK 6 و منطق عاملهای هوش مصنوعی، این داستان از «حلقه تکرار» تئوریک یک عامل فراتر میرود و به کاربرد عملی هوش مصنوعی در محیطهای تولیدی قانونمند میپردازد. این رویکرد عملی در تضاد با تلاشهای متمرکز بر اتوماسیون کامل است؛ مانند آن تجربه ساختاری که در بررسی شکست مدیریت کامل یک شرکت توسط هوش مصنوعی مشاهده شد و نشان داد که غیاب نظارت انسانی در سطوح تصمیمگیرنده میتواند منجر به شکست گردد.
سازوکار توسعهٔ AI-Native
تیم مورد بحث صرفاً از یک مدل زبانی بزرگ (LLM) برای پرامپت دادن استفاده نکرد؛ بلکه یک چرخه توسعه هوش مصنوعی (ADLC) رسمی را پیادهسازی کرد. این «حفاظ» (Harness) داخلی، هر مرحله از فرآیند، از برنامهریزی اولیه تا بازبینی نهایی را هدایت میکند. این دقیقاً همان تفاوتی است که بین «پرامپت دادنهای مکرر به یک مدل و امید به بهترین نتیجه» با «اجرای تولید هوش مصنوعی از طریق یک فرآیند ساختاریافته و تکرارپذیر» وجود دارد.
بر اساس این گزارش، تیم از روز اول انتظارات جسورانهای را تعیین کرد: آنها از مدلهای Claude استفاده میکردند تا تقریباً ۷۰ تا ۸۰ درصد از کدبیس واقعی را تولید کنند. برای مشتری که شاهد وعدههای توخالی پیمانکاران قبلی بود، این یک ادعای پرریسک به نظر میرسید. با این حال، این سرعت از یک تقسیم کار بسیار خاص نشأت میگرفت:
- نقش هوش مصنوعی: مدیریت فشار مکانیکی نوشتن کدهای تکراری، کدهای Boilerplate و منطقهای استاندارد. این کار باری را که معمولاً ماهها از وقت یک مهندس ارشد را میبلعد، حذف میکند.
- نقش انسان: مدیریت ۲۰ تا ۳۰ درصد حیاتی که شامل معماری، جریانهای تصمیمگیری (Decision Workflows) و انضباط طراحی است. این دقیقاً جایی است که قضاوت مهندسی واقعی جای میگیرد.
نکته حیاتی این بود که این فرآیند توسط تجربه پشتیبانی میشد. مهندس ارشد پروژه، ۲۰ هزار ساعت تجربه کدنویسی عملی را به این پروژه آورد. این تخصص به تیم اجازه داد تا خروجیهای تولید شده توسط هوش مصنوعی را بررسی کرده و بلافاصله تشخیص دهند که جریانهای تصمیمگیری در کجا نیاز به بازسازی دارند، به جای اینکه صرفاً اولین نسخهای را که مدل تولید کرده بود، بپذیرند.
پشتهٔ فنی و سختگیریهای مهندسی
برای مدیریت پیچیدگیهای ادغام سختافزارهای بیمارستانی و محیطهای درونسازمانی (On-premise)، تیم پشته فنی (Stack) خاصی را به کار گرفت که برای پایداری و مقیاسپذیری طراحی شده بود:
- Frontend: استفاده از React برای لایه رابط کاربری وب.
- Desktop: استفاده از Electron برای محیطهای On-prem بیمارستان و اپلیکیشنهای مربوط به بخشهای مختلف (Floor Applications).
- Backend / AI: زبان Python برای پردازش دادهها و ارکستراسیون.
- Infrastructure: استفاده از AWS برای میزبانی ابری و مقیاسپذیری.
این سطح از گستردگی — که وب، دسکتاپ و ابر را شامل میشود — دقیقاً جایی است که کدهای تولید شده توسط هوش مصنوعی در صورت نبود یک فرآیند نظارتی، میتوانند به شکلی نامحسوس دچار خطا شوند. مهندس ارشد به جای پذیرش اولین خروجی هوش مصنوعی، اصول SOLID و الگوهای طراحی (Design Patterns) را اعمال کرد تا کد تولید شده را بازسازی کند. این کار باعث جلوگیری از دامهای رایج مانند الگوهای ناسازگار در سراسر کدبیس، نبود مدیریت خطاهای جامع و آسیبپذیریهای قابل بهرهبرداری شد.
تحویل و انطباق قانونی
در مدت دو هفته از شروع همکاری — دورانی که از نظر فنی هنوز مرحله «آشنایی و استقرار» (Ramp-up) محسوب میشود — تیم اولین ماژول را تحویل داد. نکته مهم این است که این خروجی یک پروتوتایپ یا دمو نبود، بلکه به عنوان یک Build کامل برای محیط تولید (Production) ارسال شد.
در کنار کدها، تیم یک مجموعه مستندات گسترده را تحویل داد که به ۹ بخش تقسیم شده بود. این مستندات به جای دنبال کردن عادتهای استاندارد مهندسی، به گونهای طراحی شده بودند که به پرسشهای خاص یک خریدار نرمافزار بیمارستانی پاسخ دهند:
۱. خلاصه مدیریتی و معماری
۲. قراردادهای نامگذاری (Naming Conventions)
۳. فلسفه طراحی (اصول غیرقابل مذاکره)
۴. اولویت اول: ایمنی بیمار (Patient Safety First)
۵. امنیت در طراحی (Security by Design)
۶. انطباق قانونی به عنوان معماری (Compliance as Architecture)
۷. معماری تابآوری (Resilience Architecture)
۸. قابلیت نگهداری بدون بدهی فنی (Maintainability Without Debt)
۹. ثبت تصمیمات، انطباق نظارتگری و نقشه راه پیادهسازی
با تعریف «ایمنی بیمار» و «امنیت» به عنوان فلسفههای طراحی غیرقابل مذاکره (به جای اینکه فقط به عنوان یادداشتی در پاورقی اضافه شوند)، تیم تضمین کرد که انطباق قانونی در تار و پود معماری سیستم بافته شود. این مستندسازی دقیق تضمین کرد که سرعت تحویل، ردپاهای بازرسی (Audit Trails) مورد نیاز برای بررسیهای نظارتی در پنج سال آینده را به خطر نیندازد.
تأثیر: از ۶ ماه به ۲ هفته
وقتی تیم رهبری، ماژول و مستندات را بررسی کرد، واکنش آنها ترکیبی از ناباوری و تعجب بود. تضاد در سرعت تحویل بسیار شدید بود:
- فرآیند سنتی: این حجم از کار با پیمانکار قبلی مشتری، ۵ تا ۶ ماه زمان میبرد.
- فرآیند AI-Native: اولین ماژول در ۲ هفته به صورت Build نهایی ارسال شد.
تأثیر عاطفی این اتفاق قابل توجه بود. مدیرعامل (CEO) چنان تحت تأثیر این نتیجه قرار گرفت که از مهندس ارشد، «راج»، خواست تا او را در آغوش بگیرد؛ واکنشی واقعی به دیدن ماهها کار مورد انتظار که در ۱۴ روز فشرده شده بود. مدیر عملیاتی (COO) خاطرنشان کرد که خیرهکنندهترین بخش، در واقع سرعت نبود، بلکه این بود که تیم به جای ساخت صرفاً «ویژگیها» (Features)، «سیستمها» (Systems) را ساخته است. به همین ترتیب، مدیر فنی (CTO) از پیشکنشی (Proactivity)، ارتباطات، پاسخگویی و تعهد تیم به استانداردهای بالای مهندسی تعریف کرد.
تفاوت AI-Native با کدنویسی گذرا (Vibe Coding)
گزارش مذکور تمایز تندی بین این رویکرد و «کدنویسی گذرا» یا Vibe Coding قائل میشود. کدنویسی گذرا شامل دادن پرامپت به یک مدل هوش مصنوعی به زبان طبیعی و منتشر کردن هر چیزی است که مدل بازمیگرداند. در حالی که این روش برای ابزارهای داخلی یا اثبات سریع یک ایده مفید است، اما از نظر ساختاری با توسعه AI-native متفاوت است.
پژوهشگران امنیتی مستند کردهاند کدهایی که توسط هوش مصنوعی تولید شده و بدون یک فرآیند بازبینی سازمانیافته منتشر میشوند، اغلب دارای موارد زیر هستند:
- آسیبپذیریهای قابل بهرهبرداری
- الگوهای ناسازگار در سراسر پروژه
- نبود مدیریت خطای مناسب
- فقدان کامل ردپاهای بازرسی (Audit Trails)
توسعه AI-native از همان آمار تولید ۷۰ تا ۸۰ درصدی کد (مشابه Vibe Coding) استفاده میکند، اما در پیادهسازی متفاوت است. این متد از یک «حفاظ» برای کنترل نحوه پرامپت دادن و بازبینی استفاده میکند، تضمین میکند که جریانهای تصمیمگیری از اصول SOLID پیروی میکنند و هر انتخاب طراحی را به ایمنی بیمار متصل میکند. کدنویسی گذرا برای «دموی جذاب» بهینهسازی شده است؛ اما توسعه AI-native برای این بهینه شده است که آیا سیستم مدتها پس از پایان دمو، همچنان ایمن، قابل بازرسی و قابل نگهداری خواهد بود یا خیر.
تحلیل: تغییر ارزش مهندسی ارشد
این مطالعه موردی یک تغییر بنیادین در ارزش یک مهندس ارشد را آشکار میکند. در مدل سنتی، ارشدیت تا حدی با توانایی نوشتن کدهای پیچیده در سرعت بالا سنجیده میشد. در دنیای AI-native، ارشدیت با توانایی «قضاوت» درباره این سنجیده میشود که کدام نسخه از کد تولید شده توسط هوش مصنوعی برای انتشار ایمن است.
برای رهبران کسبوکار، نتیجه این است که هوش مصنوعی جایگزین مهندسی نمیشود؛ بلکه «مهندسی بیشتر» را در بخشهایی که واقعاً اهمیت دارند — یعنی امنیت، ایمنی و معماری — ممکن میسازد. مزیت رقابتی دیگر در سرعت تایپ کردن نیست، بلکه در قدرت «حفاظ نظارتی» (Governance Harness) است که دور هوش مصنوعی قرار گرفته است.
باید منتظر ظهور چارچوبهای استاندارد ADLC بود، زیرا سایر صنایع قانونمند مانند فینتک (Fintech) و هوافضا نیز تلاش خواهند کرد تا چرخههای شش ماهه را بدون قربانی کردن ایمنی، به چند هفته کاهش دهند.
گفتگو