شش جایی که هوش مصنوعی ایستاد و خودم ادامه دادم

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

یک مثال واقعی: سایتی که از ایران ساخته و میزبانی می‌شود

این سایت روی .NET 10 و Razor Pages ساخته شده، روی هاست اشتراکی ویندوز با Plesk و IIS اجرا می‌شود و بیشتر کدش را یک ایجنت نوشته است. تقسیم کار ساده بود: من مشخصات، قواعد و تصمیم‌ها را نوشتم؛ ایجنت پیاده‌سازی کرد، build گرفت و تست اجرا کرد.

چیزی که در هیچ آموزش وایب کدینگی نمی‌بینید این است که محیط کار شما با محیطی که مدل دربارهٔ آن خوانده فرق دارد. بخشی از مثال‌های پایین مال همین سایت است و بخشی مال پیشگامیت که با کمک هوش مصنوعی از ASP.NET MVC روی .NET 8 بازنویسی و بعد به .NET 10 منتقل شد. هر کدام از شش مورد از همین فاصله می‌آید.

۱. انتخاب approach؛ سخت‌ترین قسمت

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

ملموس‌ترین نمونه‌اش انتخاب وابستگی‌هاست. AutoMapper و MediatR که سال‌ها پیش‌فرض بی‌چون‌وچرای پروژه‌های دات‌نت بودند، از ۲۰۲۵ نسخهٔ تجاری با لایسنس گرفتند. ImageSharp هم جوری لایسنس خورده که نسخهٔ ۴ آن بدون کلید لایسنس، build حالت Release را رد می‌کند. ایجنت این‌ها را نمی‌داند؛ در کدی که دیده، این پکیج‌ها هنوز گزینهٔ طبیعی‌اند. پس با اطمینان کامل پیشنهادشان می‌دهد و شما باید جلویش را بگیرید.

در این سایت تصمیم‌ها این شد: MediatR اصلاً وارد نشد و لایه‌ها با سرویس‌های ساده نوشته شدند؛ ImageSharp روی نسخهٔ ۳ ماند و آسیب‌پذیری‌های شناخته‌شده‌اش یکی‌یکی بررسی و مهار شدند، به‌جای ارتقا به نسخه‌ای که لایسنس می‌خواهد. در پیشگامیت جواب فرق کرد: ImageSharp کنار رفت و پردازش تصویر به SkiaSharp منتقل شد. یک مسئله و دو جواب متفاوت؛ انتخاب بینشان کار من بود، نه ایجنت.

جواب جایگزین همیشه «یک پکیج دیگر» نیست. برای نگاشت شیء به DTO، چند خط کد دستی معمولاً از یک کتابخانه ساده‌تر است:

public sealed record Product(int Id, string Name, decimal Price, bool IsActive);
public sealed record ProductDto(int Id, string Name, decimal Price);

public static class ProductMappings
{
    public static ProductDto ToDto(this Product product) =>
        new(product.Id, product.Name, product.Price);
}

// استفاده:
// var dtos = products.Where(p => p.IsActive).Select(p => p.ToDto()).ToList();

نکته‌اش این است که نگاشت حالا کد معمولی است: کامپایلر اگر فیلدی جا بیفتد خطا می‌دهد، با Go to Definition پیدا می‌شود و هیچ لایسنسی پشتش نیست. برای پروژه‌ای با ده‌ها DTO، یک source generator مثل Mapperly هم گزینهٔ معقولی است؛ مهم این است که این انتخاب را شما بکنید.

۲. محدودیت‌هایی که مدل نمی‌بیند

ایجنت فرض می‌کند شبکه‌ای که در آن کار می‌کنید همان شبکه‌ای است که دربارهٔ آن خوانده. از ایران این فرض غلط است. در همین سایت، هاست به api.telegram.org دسترسی ندارد؛ پس اعلان فرم درخواست پروژه از طریق یک Cloudflare Worker می‌رود، همان Workerی که پیشگامیت هم از آن استفاده می‌کند.

ایجنت کدی می‌نویسد که طبق مستندات درست است و روی سرور به دیوار می‌خورد، و چون خطا از جنس شبکه است نه کد، ممکن است دور خودش بچرخد. راه‌حل این است که محدودیت را از اول جزو صورت‌مسئله کنید و آدرس سرویس را قابل‌تنظیم نگه دارید:

// TelegramOptions.cs
public sealed class TelegramOptions
{
    // مستقیم: https://api.telegram.org  — یا آدرس Worker/پراکسی
    public string BaseUrl { get; set; } = "https://api.telegram.org";
}
// Program.cs
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<TelegramOptions>(builder.Configuration.GetSection("Telegram"));
builder.Services.AddHttpClient("telegram", (sp, http) =>
{
    var options = sp.GetRequiredService<IOptions<TelegramOptions>>().Value;
    http.BaseAddress = new Uri(options.BaseUrl);
    http.Timeout = TimeSpan.FromSeconds(10);
});

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

۳. وقتی توکن تمام می‌شود

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

۴. وقتی اینترنت قطع می‌شود

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

۵. استقرار و دیباگ

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

۶. بازبینی

همهٔ خروجی را بازبینی کردم. این تنها مرحله‌ای است که اصلاً قابل واگذاری نیست؛ و وقتی بقیهٔ کارها سریع‌تر می‌شوند، سهمش از کل کار بیشتر می‌شود، نه کمتر. در این پروژه بخشی از بازبینی هم به تست تبدیل شد: مثلاً یک تست، build را رد می‌کند اگر ادعاهای ممنوع (مثل اسم ابزاری که هرگز در محیط تولید استفاده نکرده‌ام) وارد محتوا شوند.

مزایا و معایب این تقسیم کار

مزایا

  • سرعت نوشتن کد، اسکلت‌سازی و رفع خطای build چند برابر می‌شود.
  • وقت مهندسی جایی خرج می‌شود که قضاوت می‌خواهد: معماری، وابستگی‌ها، استقرار.
  • قواعدی که به تست تبدیل شده‌اند، هم جلوی ایجنت را می‌گیرند و هم جلوی خودتان را.

معایب

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

جمع‌بندی

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

اگر پروژه‌ای دارید که می‌خواهید سریع ولی با همین دقت ساخته شود، خدمات من را ببینید.

پرسش‌های متداول

چرا هوش مصنوعی هنوز AutoMapper یا MediatR را پیشنهاد می‌دهد؟

چون در بیشتر کدی که دیده، این‌ها پیش‌فرض اکوسیستم دات‌نت بودند. تغییر لایسنسشان در ۲۰۲۵ جدیدتر از الگوهای غالب در داده‌هایش است، پس با اطمینان پیشنهادشان می‌دهد. بررسی لایسنس هر وابستگی تازه، کار شماست.

اگر وسط کار توکن یا اینترنت تمام شود چه باید کرد؟

باید بتوانید خودتان ادامه بدهید. اگر نمی‌توانید، یعنی کد را نفهمیده‌اید. تغییرهای کوچک، کامیت‌های مکرر و یک فایل برنامه که وضعیت کار را نگه دارد، ادامه دادن را بدون ایجنت ممکن می‌کند.

کدام مرحله را نباید به هوش مصنوعی سپرد؟

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