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

سال‌ها بود که هوش مصنوعی در کنار شما در ویرایشگر می‌نشست و حدس می‌زد مرحله بعد چیست. شما یک خط می‌نوشتید؛ او خط بعدی را پیشنهاد می‌داد. معماری، عیب‌یابی و نحو (syntax) همچنان در اختیار شما بود. آن دوران به پایان رسیده است.

ما در حال حرکت به سمت «توسعه مبتنی بر قصد» (Intent-Driven Development) هستیم. شما دیگر حلقه‌ها و دستورات شرطی را تایپ نمی‌کنید. در عوض، نتیجه‌ای را که نیاز دارید توصیف می‌کنید. یک عامل (agent) آن هدف را درک کرده، مراحل را برنامه‌ریزی می‌کند، کد را می‌نویسد، تست‌ها را اجرا می‌کند و پیش از آنکه شما نتیجه را ببینید، خطاهای خود را اصلاح می‌کند. کیبورد دیگر ابزار اصلی نیست؛ تفکر شفاف است.

پایان کدنویسی خط‌به‌خط

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

فرض کنید نیاز به یکپارچه‌سازی یک webhook پرداخت دارید. قبلاً باید route handler را می‌نوشتید، داده‌ها را parse می‌کردید، امضا را اعتبارسنجی می‌کردید، پایگاه داده را در یک transaction به‌روزرسانی می‌کردید و ایمیل رسید را در صف قرار می‌دادید. اکنون الزامات را توصیف می‌کنید: «webhook مربوط به Stripe را اعتبارسنجی کن، رویداد را به صورت ایدمپوتنت (idempotently) ثبت کن و فرآیند ارسال رسید را فعال کن. اگر نوشتن در پایگاه داده شکست خورد، عملیات را Roll back کن.» عامل، هندلر را می‌نویسد، استراتژی parsing را انتخاب می‌کند، منطق retry را ساختاردهی می‌کند و تست‌ها را تولید می‌کند. نقش شما از نویسنده به کارگردان تغییر می‌کند.

این روش تنها به این دلیل کار می‌کند که عامل به مرحله تولید کد بسنده نمی‌کند؛ بلکه وارد یک حلقه می‌شود.

درون حلقه عامل

کار اصلی دیگر تایپ کردن توسط انسان یا عیب‌یابی دستی نیست. بلکه یک چرخه فشرده بین تولید و تایید است. عامل کد را تولید می‌کند، آن را در برابر مجموعه تست‌های شما اجرا می‌کند، خروجی را می‌خواند و شکست‌ها را خودش اصلاح می‌کند. یک import فراموش‌شده، عدم تطابق نوع داده (type mismatch) یا یک assertion شکست‌خورده؛ عامل stack trace را می‌بیند، فایل را ویرایش می‌کند و مجموعه تست را دوباره اجرا می‌کند. شما در این حلقه نیستید؛ این چرخه با سرعت ماشین پیش می‌رود.

شما زمانی وارد عمل می‌شوید که خودِ حلقه از کار بیفتد. شاید عامل نتواند تضاد بین دو وابستگی (dependency) را حل کند، یا مدام کدی تولید کند که unit tests را پاس می‌کند اما قوانین تجاری سطح بالاتر را نقض می‌کند. این مرزها همان جایی هستند که قضاوت انسانی همچنان اهمیت دارد.

شغل واقعی شما: طراح محدودیت‌ها و شکارچی موارد خاص

اگر ماشین توابع را می‌نویسد، چه چیزی برای شما باقی می‌ماند؟ دو چیز، که دشوارتر از تایپ کردن syntax هستند.

اول، شما محدودیت‌هایی را می‌نویسید که عامل را در مسیر درست نگه می‌دارد. عامل دانش گسترده‌ای دارد اما درکی از محیط خاص شما ندارد. شما باید به او بگویید: «فقط از API داخلی صورت‌حساب استفاده کن، هرگز توکن‌های خام کارت را لاگ نکن و تأخیر پاسخ (latency) را زیر دویست میلی‌ثانیه نگه دار.» این مرزها، پرامپت‌های گذرا نیستند؛ بلکه مشخصاتی هستند که تعیین‌کننده موفقیت یا شکست‌اند.

دوم، شما آن ده درصد از مواردی را که عامل در آن‌ها شکست می‌خورد، شکار می‌کنید. عامل‌ها مسیرهای معمول را به خوبی مدیریت می‌کنند. آن‌ها در مواجهه با race conditions ظریف، موارد خاص (edge cases) در منطق تجاری مبهم و فرض‌های امنیتی که در داده‌های آموزشی‌شان نهفته است، دچار لغزش می‌شوند. نقطه قوت شما در تشخیص رقابت بین هندلر webhook و cron job بازپرداخت، یا تشخیص این است که منطق retry تولید شده ممکن است باعث تکرار تراکنش‌ها شود. ماشین مسائل استاندارد را حل می‌کند؛ شما استثناهای خطرناک را شکار می‌کنید.

جایگزینی بازبینی کد با یک چارچوب تایید (Verification Harness)

وقتی یک عامل می‌تواند شبانه پنجاه فایل تولید کند، نمی‌توانید آن‌ها را با نگاه گذرا به diffها بررسی کنید تا ببینید «درست به نظر می‌رسند» یا خیر. حجم کار، بررسی چشمی توسط انسان را غیرممکن می‌کند. شما به یک harness نیاز دارید که خطاها را پیش از رسیدن کد به شما، شکار کند.

این چارچوب بر سه ستون استوار است:

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

خروجی‌های ساختاریافته (Structured outputs). به جای اینکه امیدوار باشید عامل یک فایل پیکربندی با ساختار درست برگرداند، قرارداد را از قبل اعمال می‌کنید. ابزارهایی مانند JSON Schema خروجی را بلافاصله اعتبارسنجی می‌کنند. اگر عامل یک فیلد مورد نیاز را حذف کند یا از نوع داده اشتباه استفاده کند، چارچوب پیش از آنکه کد با repository شما تماس پیدا کند، آن را رد می‌کند.

حفاظ‌های پویا (Dynamic guardrails). عامل نباید اجازه دسترسی آزاد برای خواندن secrets یا نوشتن در پایگاه‌های داده عملیاتی (production) را داشته باشد. چارچوب، مجوزها را به صورت پویا کنترل می‌کند و عامل را در یک محیط ایزوله (sandboxing) قرار می‌دهد تا فقط بتواند با پایگاه‌های داده تست تعیین‌شده و endpoints داخلی کار کند. شما هر خط را بازبینی نمی‌کنید؛ شما در حال حسابرسی حصاری هستید که دور عامل کشیده شده است.

When the Code Works but the Product Fails

Here is the paradox. The harness catches bad code. It cannot catch bad intent.

If your specification says, “Send a welcome email to every new user,” the agent will write clean, tested code that sends that email. It will not know you meant, “Send the welcome email only if the user verified their address, opted into marketing, and signed up during business hours in their local timezone.” The code is technically flawless and commercially dangerous.

The real risk in Intent-Driven Development is ambiguous specification. Unclear intent produces software that solves the wrong problem with textbook elegance. This is why you must treat your specifications as real assets. Version them. Review them with stakeholders. Validate them against actual workflows before the agent starts building. A prompt scribbled into a chat box is not a specification. It is a liability.

Engineering Judgment Moves Upstream

Engineering judgment is not disappearing. It is migrating to a higher altitude.

You no longer spend mental energy on how to iterate a map or structure a class hierarchy. You spend it on what the system must do under failure, what data it must never expose, and which invariants must hold across distributed services. The craft of coding is becoming the craft of requirements.

This means your specifications need the same rigor you once applied to your code. Name your constraints precisely. Define the failure modes explicitly. State the business rules as clearly as you once declared your types. The agent will handle the implementation. You must guarantee that the implementation is worth building.

Move your quality bar from the pull request to the prompt. Build the harness first. Write the specification second. Then let the machine handle the syntax while you focus on whether the problem is defined correctly and the boundaries are drawn safely.

If you want to explore the ideas behind this shift in more depth, the original discussion on Intent-Driven Development is available here. For ongoing conversations around AI-native engineering, you can also join the GyaanSetu community.