پژوهش جدید: ضعف مدل‌های زبانی در تولید اسکریپت‌های بازگشتی کد

هر وصله یا پچ تولیدشده توسط هوش مصنوعی برای مسیری که طی می‌کند تست می‌شود، اما هیچ‌کس مسیری را که پشت سر می‌گذارد بررسی نمی‌کند. این نقطه کور بنیادین باعث می‌شود نشان سبز در خط لوله‌های CI، برای کدهای تولیدشده توسط مدل‌ها، یک ضمانت کاذب باشد. این موضوع در واقع تداوم همان چالشی است که در بررسی ما درباره ناکارآمدی تست‌های داخلی مخزن کد برای اعتبارسنجی وصله‌های AI به آن پرداختیم. در حالی که MonkeyCode و دیگر مدل‌های زبانی بزرگ (LLM) می‌توانند پچ‌های پیش‌رو را با اطمینان بالایی تولید کنند، آن‌ها به‌طور سیستماتیک در «قرارداد بازگشت» (Rollback Contract) شکست می‌خورند؛ یعنی توانایی بازگرداندن یک تغییر بدون تخریب داده‌هایی که پس از اعمال پچ نوشته شده‌اند. در حال حاضر، خط لوله‌های CI پچ را اعمال می‌کنند، پروب‌ها (Probes) را اجرا می‌کنند و کار را تمام‌شده می‌دانند، در حالی که مسیر بازگشت تا لحظه نیاز واقعی، هرگز تست نمی‌شود.

این عدم تقارن، گران‌ترین نقطه کور در توسعه نرم‌افزار با کمک هوش مصنوعی است. ریشه این مشکل در یک عدم تقارن بنیادین در داده‌های آموزشی است. اکثر درخواست‌های ادغام (Pull Requests) در مخازن عمومی، ویژگی‌های جدیدی اضافه می‌کنند، باگ‌ها را رفع می‌کنند یا کد را بازسازی (Refactor) می‌کنند، در حالی که کامیت‌های بازگشتی ایمن بسیار نادر هستند و معمولاً در شرایط اضطراری نوشته شده‌اند. چون مدل‌ها به ازای هر ۱۰۰ نمونه حذف ایمن یک ستون، ۱۰ هزار نمونه اضافه کردن ستون دیده‌اند، بازگشت را یک معکوس مکانیکی می‌بینند، نه یک تصمیم در چرخه حیات داده. نتیجه این است که تغییرات هوش مصنوعی به‌طور سیستماتیک «افزایشی» هستند چون این تنها الگویی است که مدل به‌خوبی می‌شناسد.

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

سه بندِ قرارداد بازگشت

برای عبور از اعتماد کورکورانه به پچ‌های هوش مصنوعی، توسعه‌دهندگان باید بازگشت را قراردادی با سه بند در نظر بگیرند که هر کدام باید جداگانه تأیید شوند:

• همگرایی ساختاری: نسخه طرح (Schema)، پیکربندی و وابستگی‌ها باید پس از اجرای بازگشت، دقیقاً با حالت پایه (Baseline) مطابقت داشته باشند. این تنها چیزی است که اجرای بدون خطای اسکریپت بازگشت در واقعیت ثابت می‌کند.
• همگرایی داده‌ای: ردیف‌ها، فایل‌ها و نشانگرهای وضعیت باید با حالت پایه یکی باشند یا تفاوت‌هایی داشته باشند که کد قدیمی بتواند به‌طور ایمن بخواند. اینجا جایی است که پچ‌های هوش مصنوعی معمولاً شکست می‌خورند چون مدل نمی‌تواند پیش‌بینی کند چه داده‌هایی بین اعمال پچ پیش‌رو و اجرای بازگشت نوشته خواهند شد.
• همگرایی رفتاری: سیستم باید پس از بازگشت، همان پروب‌ها و تست‌هایی را پاس کند که پیش از اعمال پچ پاس کرده بود. در این مرحله وابستگی‌های پنهان آشکار می‌شوند؛ کد قدیمی ممکن است فرمت‌های جدید را بدون کرش بخواند، اما داده‌ها را به‌طور خاموش تخریب کند.

گردش‌کار تأیید سفر رفت‌وبرگشت

برای کاهش این ریسک‌ها، توسعه‌دهندگان باید یک «سفر رفت‌وبرگشت» (Round-trip) را روی یک سرور موقت (Disposable Server) اجرا کنند، نه روی محیط Staging. هدف شبیه‌سازی محیط تولید نیست، بلکه دادن فرصتی به پچ برای شکست ارزان‌قیمت است. این رویکرد در واقع پیاده‌سازی عملیاتی از یک ممیزی رفتاری است تا از ادغام کورکورانه کدهای AI جلوگیری شود. مدل‌های رایگان MonkeyCode می‌توانند پچ و پیش‌نویس بازگشت را در یک جلسه تولید کنند و گزینه سرور رایگان آن‌ها محیط موقت لازم برای این تست را فراهم می‌کند.

۱. ثبت حالت پایه: استخراج طرح (Schema) و ثبت تعداد ردیف‌های هر جدول. این حالت مرجعی است که بازگشت باید آن را بازیابی کند.
۲. اعمال پچ پیش‌رو: اجرای مهاجرت و سپس تأیید رفتار پیش‌رو با یک پرس‌وجوی آزمایشی (Probe Query). اگر مسیر رفت شکست بخورد، سفر رفت‌وبرگشت در همین‌جا متوقف می‌شود.
۳. شبیه‌سازی نوشتن داده‌ها پس از پچ: این مرحله حیاتی است که اغلب نادیده گرفته می‌شود. درج ردیف‌ها، به‌روزرسانی رکوردها و تغییر پیکربندی‌ها؛ یعنی هر کاری که اپلیکیشن به‌طور واقع‌بینانه پس از انتشار پچ انجام می‌دهد. این مرحله دلیل اصلی وجود داشتن بازگشت است.
۴. اجرای بازگشت: اجرای اسکریپت بازگشت دقیقاً مشابه آنچه در یک حادثه واقعی در محیط تولید اجرا می‌شود.
۵. مقایسه با حالت پایه: ابتدا بررسی همگرایی ساختاری و سپس همگرایی داده‌ای. بازگشتی که طرح را برمی‌گرداند اما ردیف‌ها را از دست می‌دهد، در قرارداد خود شکست خورده است.

اسکریپت تأیید

برای عملیاتی کردن این روند، می‌توان از یک اسکریپت الگو مبتنی بر SQLite روی هر سرور موقت استفاده کرد. این اسکریپت از یک منطق سخت‌گیرانه پیروی می‌کند: ثبت طرح و تعداد ردیف‌های پایه، اعمال مهاجرت، اجرای پروب، شبیه‌سازی نوشتن داده‌ها، اجرای بازگشت و در نهایت استفاده از diff و grep برای تأیید همگرایی.

#!/usr/bin/env bash
# roundtrip_contract.sh — verify an AI patch's undo path on a disposable server
# Usage: ./roundtrip_contract.sh <db_file> <migration.sql> <rollback.sql> <probe.sql> [writes.sql]
set -euo pipefail
DB="${1:?database file required}"
MIGRATION="${2:?migration script required}"
ROLLBACK="${3:?rollback script required}"
PROBE="${4:?probe script required}"
WRITES="${5:--}"
BASELINE="baseline_$(date +%Y%m%d_%H%M%S)"

# Step 1: capture baseline schema and row counts
sqlite3 "$DB" ".schema" > "${BASELINE}.schema"
for table in $(sqlite3 "$DB" "SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%';"); do
  echo "$table $(sqlite3 "$DB" "SELECT count(*) FROM $table;")" >> "${BASELINE}.counts"
done
echo "baseline captured"

# Step 2: apply the forward patch
sqlite3 "$DB" < "$MIGRATION"
echo "forward patch applied"

# Step 3: verify forward behavior
sqlite3 "$DB" < "$PROBE"
echo "forward probe passed"

# Step 4: simulate post-patch writes
if [ -n "$WRITES" ]; then
  sqlite3 "$DB" < "$WRITES"
  echo "post-patch writes simulated"
fi

# Step 5: execute the rollback
sqlite3 "$DB" < "$ROLLBACK"
echo "rollback executed"

# Step 6: compare schema convergence
if diff -u "${BASELINE}.schema" <(sqlite3 "$DB" ".schema") > /dev/null; then
  echo "structural=converged"
else
  echo "structural=diverged"
  diff -u "${BASELINE}.schema" <(sqlite3 "$DB" ".schema") | head -30
  exit 1
fi

# Step 7: compare row counts
for table in $(sqlite3 "$DB" "SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%';"); do
  count=$(sqlite3 "$DB" "SELECT count(*) FROM $table;")
  baseline_count=$(grep "^$table " "${BASELINE}.counts" | awk '{print $2}')
  if [ "$count" != "$baseline_count" ]; then
    echo "data=diverged table=$table baseline=$baseline_count current=$count"
    exit 1
  fi
done
echo "data=converged"
echo "verdict=rollback_contract_holds"

مدیریت شکست‌های عینی

تصور کنید یک مهاجرت، ستونی به نام status اضافه می‌کند. اگر در مرحله شبیه‌سازی، ردیفی با مقدار status='active' درج شود و اسکریپت بازگشت صرفاً ستون را حذف کند، اسکریپت خطای data=diverged می‌دهد چون تعداد ردیف‌ها با حالت پایه متفاوت است.

راهکار این نیست که شبیه‌سازی نوشتن را حذف کنیم؛ بلکه راهکار این است که بازگشت را طوری بازطراحی کنیم که داده‌ها را حفظ کند. برای مثال، توسعه‌دهنده باید بازگشت را به‌گونه‌ای تغییر دهد که پیش از حذف ستون، داده‌های آن را در یک جدول سایه (Shadow Table) کپی کند تا چرخه حیات داده‌ها حفظ شود.

تحلیل نتایج

هنگام تحلیل نتایج یک سفر رفت‌وبرگشت، ترکیب نتایج همگرایی، اقدام بعدی را تعیین می‌کند:

• ساختاری + داده‌ای + رفتاری: مسیر بازگشت صادقانه است. پچ را ادغام کنید و اسکریپت بازگشت را نگه دارید.
• فقط ساختاری: بازگشت شکل را برمی‌گرداند اما محتوا را نه. پیش از ادغام، بازگشت را بازطراحی کنید.
• هیچ‌کدام: اسکریپت بازگشت یک تخیل است. تا زمانی که مسیر بازگشت واقعی نشود، هرگز ادغام نکنید.
• شکست رفتاری: کد قدیمی نمی‌تواند وضعیت بازیابی‌شده را بخواند. یک لایه سازگاری اضافه کنید یا از بازگشت صرف‌نظر کنید.

چه زمانی این روند را نادیده بگیریم؟

این سخت‌گیری برای همه تیم‌ها لازم نیست. گردش‌کار سفر رفت‌وبرگشت برای موارد زیر ضروری نیست:

• تیم‌هایی که از ذخیره‌سازهای داده‌ای Append-only استفاده می‌کنند.
• محیط‌هایی که در آن‌ها هرگز عملیات بازگشت (Rollback) انجام نمی‌شود.
• گردش‌کارهای با قابلیت‌های ساده‌ی بازسازی از منبع (Rebuild-from-source).

برای بقیه، بازگشت‌های تولیدشده توسط هوش مصنوعی باید با همان تردیدی نگریسته شوند که به خودِ پچ‌ها نگاه می‌کنیم. استفاده از یک سرور موقت — مانند گزینه‌های رایگان MonkeyCode — محیطی کم‌هزینه است تا انسان‌ها را مجبور کند پیش از وقوع یک حادثه، به مسیر بازگشت فکر کنند. این تغییر در تمرینات، نقش توسعه‌دهنده را از «بازبین کد» به «تأییدکننده قراردادها» تغییر می‌دهد. این رویکرد می‌پذیرد که مدل تنها به سمت تست‌هایی حرکت می‌کند که در پرامپت ارائه شده‌اند، بنابراین پروب‌های خارجی و نادیده، تنها دروازه قابل اعتماد برای استقرار در محیط تولید هستند.

افشای رابطه: این مقاله به عنوان بخشی از فعالیت‌های معرفی محصول MonkeyCode تهیه شده است.

گام بعدی شما

• اسکریپت‌های بازگشت فعلی خود را با یک تست ساده‌ی «نوشتن داده پس از پچ» به چالش بکشید.
• برای تست‌های سریع، از محیط‌های ایزوله و موقت (Disposable) به‌جای محیط Staging استفاده کنید.
• در پرامپت‌های خود به مدل تأکید کنید که بازگشت را بر اساس «چرخه حیات داده» طراحی کند، نه صرفاً معکوس کردن دستورات SQL.

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