اندازه‌ی تو می‌فهمه

---

چرا این وبلاگ رو می‌نویسم؟

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

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

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

هوش مصنوعی دقیقاً اندازه‌ی خودِ تو می‌فهمه!

---

خب این یعنی چی؟

یعنی اینکه شما یه فضای حافظه از اطلاعات داری. بی‌شمار اطلاعات، همه‌شون طبقه‌بندی‌شده! تو انتخاب می‌کنی بری سمت کدوم طبقه و چی برداری.

AI هم همینه. هر چی لازم داره اون تو هست، ولی اینکه بره سراغ کدوم طبقه رو تو مشخص می‌کنی. با prompt‌ات، با کلمه‌هایی که انتخاب می‌کنی.

یه مثال ساده. این دو تا درخواست رو مقایسه کن:

الف:
یه API برای ثبت سفارش بنویس که اگه تکراری بود مشکلی پیش نیاد.

ب:
یه endpoint برای ثبت سفارش بنویس که idempotent باشه.
Idempotency-Key از هدر خونده بشه، نتیجه‌ی اولین اجرا ذخیره بشه
و درخواست تکراری همون جواب رو برگردونه، بدون اجرای دوباره.
رویداد OrderCreated هم از طریق Outbox منتشر بشه.

هر دوتا یه هدف دارن. ولی تو «الف» تصمیم‌گیری رو دادی دست مدل، و تو «ب» خودت گفتی دقیقاً کجا بره.

---

اگه آدرس غلط بدی چی میشه؟

اگه ندونی یا نتونی آدرس درست بهش بدی (به‌خاطر نداشتن آگاهی و دانش)، چند تا اتفاق پشت سر هم میفته:

1. دیتای غلط بهت میده. با کلی اعتماد به نفس، چیزی که به درد نیاز واقعیت نمی‌خوره.
2. توکن‌سوزیت بالاتر میره. چون نمی‌دونی دقیقاً چی می‌خوای، باید کلی رفت و برگشت کنی: «نه این نه، یه جور دیگه».
3. در نهایت کد کثیف تحویل می‌گیری. کدی که کار می‌کنه، ولی لایه‌هاش به هم ریخته.

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

درسته که ابزارهایی نوشته شدن که این موضوع کمتر بشه و خروجیش جهت بگیره، مثل ponytail. اما بازم این شمایی که باید از یه سری کلیدواژه استفاده کنی تا بفهمه منظورت برای این نقطه دقیقاً چی بوده.

---

تفاوت vibe coder و برنامه‌نویس

اینجاست که تفاوت بین یک vibe coder و برنامه‌نویس تازه ایجاد میشه!

این دقیقاً عینیت بخشیدن به همون جمله‌ی تیتره: اندازه‌ی تو می‌فهمه!

راه‌حلش؟ مطالعه کن تا کلیدواژه‌ها دستت بیاد. هر مفهومی که یاد می‌گیری (Outbox، Saga، Idempotency، Optimistic Concurrency) یه آدرس جدیده که قبلاً نمی‌تونستی صداش کنی.

---

۵ ساعت شده ۱ ساعت

به نظرم تو این عصر که هوش مصنوعی تو کدنویسی کار یه برنامه‌نویس ۵ ساعته رو ۱ ساعته انجام میده، مهم اینه که ما برنامه‌نویس‌ها دیگه مثل قبل به دانش کدنویسی نیاز نداریم. بلکه باید خیلی خیلی بهتر project management یاد بگیریم و بتونیم تحلیل نرم‌افزار دقیق‌تر و بهتری انجام بدیم.

چرا؟ چون همه‌ی خواسته‌هات و تحلیلت از نرم‌افزاری که می‌خوای توسعه بدی رو باید تو یه prompt بهش بدی.

پس برداشت تو از محصول تو توسعه، بازتاب مستقیم داره و خیلی بیشتر از قبل اثرگذاره. قبلاً اگه پدال گاز رو می‌چسبوندی، ۱۰ ثانیه طول می‌کشید به سرعت ۱۰۰ برسی. الان یه نیش گاز بدی ۱۰۰ رو هم رد کردی!

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

---

دو تا کتاب که پیشنهاد می‌کنم

• System Analysis and Design Methods (ویرایش ۷) نوشته‌ی Whitten و Bentley
• Why Programs Fail (ویرایش ۲) نوشته‌ی Andreas Zeller

اولی بهت یاد میده چطور تحلیل کنی. دومی یاد میده وقتی یه چیزی خراب شد، چطور علتش رو پیدا کنی.

---

چطور بهترین خروجی رو برای بیزنسم بگیرم؟

چند تا پیشنهاد دارم:

۱. اول دیتابیس و روابط جدول‌ها رو خودت طراحی کن

روی کاغذ، یا با ابزار ERD تو PostgreSQL، یا Database Diagram تو SQL Server.

۲. سناریو و User Story بنویس

روی کاغذ. کاربر کجاست و چیکار می‌خواد بکنه.

۳. تصمیم‌هات رو تبدیل کن به ADR

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

# ADR-004: انتشار رویدادها با Outbox

## وضعیت
تصویب‌شده

## زمینه
انتشار مستقیم رویداد از handler، تو صورت خطا باعث ناسازگاری میشه.

## تصمیم
رویدادها تو همون تراکنش تو جدول Outbox ذخیره و توسط worker منتشر میشن.

۴. در نهایت ponytail و graphify رو نصب کن

بعد بده برات کدش رو بزنه. اما به یک شرط:

هر تسکی که می‌خوای انجام بدی، حتماً قبلش با من double check کن و تأیید منو بگیر.

اینجا شما به‌عنوان یه software engineer بهش میگی چی درسته و چی غلط. پس نقش شما تو راهبری تعیین‌کننده‌ست.

---

TODO comment؛ چرا مهمه؟

ADR حافظه‌ی تصمیم‌هاست. ولی کارهای نیمه‌تمام و مرزهایی که عمداً گذاشتی رو کجا بنویسیم؟ همون تو کد، با TODO.

برای آدم، TODO یه یادآوریه. برای AI، یه آدرس دقیقه، درست همون جایی که باید کار کنه. مدل فایل رو که باز می‌کنه، به‌جای اینکه حدس بزنه «اینجا چی ناقصه و چرا»، همون رو می‌خونه. حدس کمتر یعنی دور کمتر و توکن کمتر.

TODO خوب چه شکلیه؟

// TODO: fix this به مدل هیچی نمیگه. یه TODO خوب سه چیز میگه: چی، چرا هنوز نه، و کِی تموم حساب میشه.

// ضعیف:
// TODO: handle errors

// قوی:
// TODO(mhmdnzr): retry با exponential backoff اضافه بشه (حداکثر ۳ بار).
// چرا نه الان: منتظر تصمیم درباره‌ی rate limit تو gateway هستیم (ADR-007).
// تموم یعنی: خطای transient دوباره‌تلاش بشه، خطای validation هیچ‌وقت.
public async Task<PaymentResult> ChargeAsync(ChargeRequest request)
{
    // ...
}

چند تا قانون

1. هر TODO یه مالک و یه دلیل داشته باشه.
2. اگه نمی‌تونی بنویسی «تموم‌شده» یعنی چی، هنوز TODO نیست؛ یه سؤال تحلیلیه.
3. TODO کهنه سمّه. مدل رو گمراه می‌کنه. تو review پاکش کن یا به‌روزش کن.
4. به AI اجازه نده خودسرانه ببندتشون. همون قانون تأییده:

TODOهای این ماژول رو بخون و برام خلاصه کن.
هیچ‌کدوم رو پیاده‌سازی نکن؛ اول بگو کدوم رو پیشنهاد می‌کنی و منتظر تأیید من باش.

---

جمع‌بندی: توکن‌سوزی و کیفیت پروژه

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

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

وقتی وضوح داری، مسیر کوتاه میشه: مدل مستقیم میره سراغ طبقه‌ی درست، یه بار می‌سازه و تو فقط تأیید یا اصلاح می‌کنی.

قاعده‌ای که از همه‌ی این‌ها درمیاد:

هزینه رو از «بعد از کد» ببر به «قبل از کد».

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

من هنوز عاشق کدی هستم که خودم می‌نویسم. ولی فهمیدم شغل ما هیچ‌وقت «تایپ کردن» نبوده؛ فهمیدن بوده. و حالا که تایپ ارزون شده، ارزش فهمیدن بیشتر از همیشه خودشو نشون میده.

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

اندازه‌ی تو می‌فهمه!