«تغییر مهارت از پیاده‌سازی به تدوین نیازمندی‌ها» در توسعهٔ نرم‌افزار

تصور کنید بخواهید یک نرم‌افزار تخصصی بسازید، اما هرگز حتی یک خط کد نبینید یا ویرایش نکنید. در ۲۵ سپتامبر ۲۰۲۶، یک توسعه‌دهنده دقیقاً همین کار را کرد و یک پورتال کامل تحلیل ورزش جهت‌یابی (Orienteering) را با تکیه بر یک عامل (Agent) — شبیه به یک کارمند دیجیتال که هم فکر می‌کند و هم ابزارها را اجرا می‌کند — به طور ۱۰۰٪ خودکار ساخت. در این پروژه، سازنده صرفاً در نقش یک مدیر محصول ظاهر شد؛ او وظایف را تعریف می‌کرد و نتایج را در مرورگر می‌سنجید، بدون آنکه هرگز محیط کدنویسی را باز کند یا حتی یک بار کدها را بازبینی (Code Review) کند. او در تمام طول مسیر، حتی یک خط از کد منبع را ندید.

این اتفاق در حالی رخ می‌دهد که صنعت نرم‌افزار هنوز در حال بحث است که آیا عامل‌های هوش مصنوعی می‌توانند فراتر از اسکریپت‌های ساده، مهندسی نرم‌افزارهای پیچیده و چندمرحله‌ای را مدیریت کنند یا خیر. در حالی که بسیاری از توسعه‌دهندگان از هوش مصنوعی برای تکمیل خودکار کد (Autocomplete) یا تولید قطعات کوچک کد (Snippet) استفاده می‌کنند، این مورد یک نمونه واقعی از گردش کار کاملاً مجزا است که در آن انسان «چیستی» (What) را فراهم می‌کند و عامل، «چگونگی» (How) را مدیریت می‌کند. برای درک بهتر چالش‌های این مسیر، می‌توان به نقشه‌راه اجرای کد در برابر حدس‌های تصادفی دستیارهای هوش مصنوعی اشاره کرد که بر اهمیت ساختاردهی به پروژه برای جلوگیری از خطاهای مدل‌ها تأکید دارد.

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

خط لوله فنی و حل مسئله

این پورتال برای حل مشکل پراکندگی داده‌ها در ورزش جهت‌یابی طراحی شده است. در این ورزش، یک نقطه کنترل (CP) در واقع یک ایستگاه در مسیر مسابقه است و «اسپلیت» (Split) به زمان طی شده برای یک بخش (Leg) بین دو نقطه کنترل متوالی گفته می‌شود. طبق مستندات پروژه، این سامانه سه منبع داده کاملاً متفاوت را که در دنیای‌های متفاوتی قرار دارند، در یک مدل تحلیلی واحد ادغام می‌کند:

• نقشه‌های اسکن‌شده: فایل‌های تصویری (عکس‌ها یا اسکن‌های برگه‌هایی که مسیر مسابقه روی آن‌ها چاپ شده است) که باید برای تطبیق با مختصات جغرافیایی، همراستاسازی (Georeferenced) شوند.
• ردپاهای GPX: داده‌های خام GPS ساعت‌های ورزشی که باید به بخش‌های مجزا (شروع $\rightarrow$ CP1 $\rightarrow$ CP2 $\rightarrow$ پایان) تقسیم شوند.

• پروتکل‌های مسابقه: نتایج رسمی در قالب‌های HTML، JSON یا PDF که برای بنچ‌مارک کردن و مقایسه عملکرد ورزشکار با سایر شرکت‌کنندگان استفاده می‌شوند.

گام اول: همراستاسازی و دیجیتالی‌سازی

از آنجا که یک نقشه جهت‌یابی در اصل یک تصویر ایستا است، در حالی که ردپای GPS از مختصات جغرافیایی استفاده می‌کند، برای ترکیب این دو، نقشه باید همراستا شود. در این پورتال، کاربر تصویر را آپلود کرده و حداقل سه نقطه متناظر را روی نقشه جهت‌یابی و یک نقشه پایه معمولی علامت می‌زند. در لایه‌های داخلی، پورتال از یک تبدیل آفین (Affine Transformation) که بر اساس آن نقاط مرجع محاسبه شده است، استفاده می‌کند تا کل تصویر را به طور دقیق در جای خود قرار دهد. این رویکرد یادآور آن است که چگونه ترکیب ArcGIS و عامل‌های هوش مصنوعی توانسته‌اند نقاط کور محیطی مدل‌ها را در تحلیل‌های مکانی برطرف کنند.

پس از تراز شدن، کاربر روی نقطه شروع، تک‌تک نقاط کنترل (CP) و نقطه پایان در تصویر کلیک می‌کند. هر کلیک به مختصات جغرافیایی تبدیل می‌شود. در این مرحله، ورودی یک عکس است و خروجی، یک مسیر دیجیتال با توالی مشخص از نقاط کنترل است. جالب است که رابط کاربری برای این فرآیند به زبان روسی طراحی شده است.

گام دوم: تقسیم خودکار GPX

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

این فرآیند، نقاط خام GPS را به نتایج ورزشی تبدیل می‌کند. هر بخش (Leg) حاصل شامل موارد زیر است:

• یک نقطه شروع و پایان
• زمان کل برای آن بخش
• طول واقعی مسیر طی شده
• سرعت (Pace)

به نقل از سازنده پروژه، چون GPS کامل نیست و نقاط ممکن است در برخی شروع‌ها دچار انحراف (Drift) شوند و لحظه دقیق عبور از یک CP همیشه به درستی شناسایی نشود، عامل یک ابزار اصلاح دستی برای نشانگرها (Markers) پیاده‌سازی کرد. اتوماسیون بخش اعظم کار را انجام می‌دهد، اما انسان می‌تواند جاهایی را که داده‌های واقعی نامنظم هستند، اصلاح کند.

گام سوم: معیار «رهبر ایده‌آل»

وارد کردن پروتکل‌های رسمی به دلیل نبود یک فرمت استاندارد واحد، دشوار بود. عامل برای این کار واردکننده‌هایی (Importers) ساخت تا بتواند چندین منبع و نسخه‌های مختلف HTML، JSON و PDF را تجزیه (Parse) کند. سیستم باید برای موارد خاص، از جمله شروع‌های چندروزه، مسابقات امدادی (Relays) و سایر فرمت‌های رقابتی تطبیق داده می‌شد. توسعه‌دهنده اشاره می‌کند که حتی یک تغییر کوچک در یک وب‌سایت خارجی می‌تواند باعث خرابی یک واردکننده خاص شود، که این بهای ادغام با فرمت‌های خارجی است.

به جای مقایسه ورزشکار با برنده کلی مسابقه — که ممکن است او هم در جایی دچار اشتباه شده باشد — پورتال یک «رهبر ایده‌آل» (Ideal Leader) مصنوعی می‌سازد. این بنچ‌مارک از طریق بررسی جداگانه هر اسپلیت و یافتن شرکت‌کننده‌ای که بهترین زمان را در آن بخش خاص ثبت کرده است، assembled می‌شود. یعنی ممکن است یک نفر در بخش اول سریع‌ترین باشد، شخص دیگری در بخش دوم و نفر سومی در بخش سوم. رهبر ایده‌آل ترکیبی از بهترین اسپلیت‌هایی است که در کل مسیر توسط هر کسی ثبت شده است.

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

گام چهارم: تحلیل عمیق و مربیگری AI

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

با باز کردن یک اسپلیت خاص، صفحه تغییر می‌کند. پورتال فقط بخشی از نقشه را که مربوط به آن Leg است جدا کرده و ردپای واقعی GPS را به همراه یک خط مستقیم بین دو نقطه کنترل نشان می‌دهد. همچنین یک نمودار سرعت (Pace Chart) را فقط برای همان بخش رسم می‌کند.

به عنوان مثال، اگر خط مستقیم بین دو کنترل ۳۰۰ متر باشد اما ردپای واقعی ۸۲۰ متر باشد، این موضوع کاربر را ترغیب می‌کند تا انتخاب مسیر را با دقت بررسی کند. اگرچه خط مستقیم اغلب به دلیل وجود باتلاق‌ها، حصارها یا مناطق غیرقابل عبور غیرممکن است، اما چنین شکاف بزرگی یک خطای احتمالی را برجسته می‌کند.

برای ارائه بازخورد کیفی، پورتال یک بسته محتوایی (Context Package) خاص برای مدل Claude آماده می‌کند. سیستم کل پایگاه داده را نمی‌فرستد، بلکه موارد زیر را آماده می‌کند:

• یک فایل PNG از دقیقاً همان بخشی از نقشه که روی صفحه نمایش داده شده (شامل ردپا و نقاط کنترل)
• پارامترهای عددی آن اسپلیت
• یک پرامپت (Prompt) اختصاصی

مدل Claude از طریق خط فرمان (CLI) اجرا می‌شود تا مشکلات نحوه طی کردن آن بخش را شناسایی کرده و توصیه‌هایی ارائه دهد. رابط کاربری و پاسخ مربی AI به زبان روسی است.

گام پنجم: شناسایی الگوهای آماری

یک اسپلیت بد می‌تواند یک اتفاق تصادفی باشد. برای یافتن مشکلات سیستماتیک، پورتال از تحلیل تک‌مسابقه به سمت آمارهای بلندمدت حرکت می‌کند.

• سمت چپ: پورتال صفّی از اسپلیت‌های مشکل‌دار را نگه می‌دارد که هنوز ارزش تحلیل دارند (بخش‌هایی با شکاف محسوس و سرعت پایین).
• سمت راست: دلایل مشکلات تحلیل‌شده در طول زمان انباشته می‌شوند.

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

فرآیند توسعه و تغییر پارادایم

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

از طریق این فرآیند، ویژگی‌های زیر گام‌به‌گام ظاهر شدند:

• همراستاسازی نقشه و تقسیم GPX
• وارد کردن پروتکل‌ها و مقایسه اسپلیت‌ها
• کارت تحلیل و طبقه‌بندی علت خطاها
• داشبورد و دستیار هوش مصنوعی

برای تضمین پایداری، عامل تست‌های خودکاری را پیاده‌سازی کرد. یک اجرای کامل تست روی وضعیت فعلی پروژه، ۱۰۹ تست پاس شده را نشان داد که قابلیت اطمینان سیستم را از بیرون تأیید کرد. معیار پذیرش توسعه‌دهنده، یک محصول فعال و کاربردی بود، نه کیفیت داخلی کد.

این پروژه نشان می‌دهد که برای دسته‌ای از اپلیکیشن‌ها، گلوگاه دیگر توانایی نوشتن کد نیست، بلکه توانایی تعریف یک محصول کاربردی است. نقش توسعه‌دهنده از یک مهندس به یک «معمار نیازمندی‌های با دقت بالا» (High-fidelity Requirements Architect) تغییر کرده است. سؤال اصلی دیگر این نیست که «چگونه این را پیاده کنم؟» بلکه این است که «بعداً چه چیزی باید پیاده شود؟»

با این حال، پروژه یک محدودیت بحرانی را نیز آشکار می‌کند: هوش مصنوعی می‌تواند یک مشکل را تشخیص دهد، اما هنوز نمی‌تواند عنصر رفتاری انسان را حل کند. در حالی که پورتال می‌تواند الگوی «سرعت پایین» را شناسایی کند، توسعه‌دهنده هنوز پاسخ مناسبی برای این ندارد که چه اقدام تمرینی باید در پی آن بیاید. او هنوز نمی‌تواند تعیین کند چگونه توصیه‌های AI را به یک تمرین خاص تبدیل کند یا تأیید کند که آیا آن تمرین در چند هفته بعد مشکل را کاهش داده است یا خیر.

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

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

برای بررسی پیاده‌سازی، این پروژه به صورت متن‌باز (Open Source) در گیت‌هاب با نام 'orienteering' در دسترس است. مطالعه موردی کامل در hram.github.io/en/articles/orienteering موجود است.

گام بعدی شما

• اگر مدیر محصول یا ایده‌پرداز هستید، تمرکز خود را از یادگیری سینتکس زبان‌های برنامه‌نویسی به یادگیری «مدل‌سازی دقیق فرآیندها» تغییر دهید.
• ابزارهای عامل‌محور را برای اتوماسیون وظایفی امتحان کنید که نیاز به ترکیب چندین منبع داده (مانند PDF و API) دارند.
• برای بررسی کد این پروژه، مخزن open source آن را در گیت‌هاب با نام 'orienteering' دنبال کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.