قبل از شروع، یک نکته مهم: هیچ چکلیست جهانشمولی برای AI-Ready شدن وجود ندارد.
ℹ️ اگر حوصله خوندن ندارید، مستقیم برید سراغ آخر متن که نسخه فشرده چکلیست رو گذاشتم.
برای نوشتن چکلیست باید دقت کنیم که حتی چیزی مثل Git که امروز تقریباً بدیهی به نظر میرسه، الزاماً برای همه بهترین انتخاب نیست. هنوز شرکتهایی هستند که بنا به تاریخچه، محدودیتها یا نیازهاشون از SVN، Mercurial یا ابزارهای دیگری استفاده میکنن. پس حتی چکلیستی که بگه «ریپازیتوری رو با Git محیا کن» هم نباید چشمبسته و بدون اطلاع دنبال کرد!
پس این مطلب هم نسخه قطعی نیست؛ جهانشمول نیست. بیشتر مجموعهای از سؤالهاست که میتونید ازش کمک بگیرید تا نسبت به مقدمات و زیرساختهای استفاده از AI در تیم، ایده داشته باشید و چیزی از صفر تا صدش، بسته به نیازتون استفاده شه؛ ولی بخش خوبی از موضوعاتی که باید نسبت بهشون پاسخ داشته باشید، اینجاست. ممکنه بعضی از موارد برای شما حیاتی باشن و بعضی کاملاً بیربط؛ بسته به سایز تیم و سازمان و نوع پروژهها و…
قبل از رفتن سراغ AI، لطفا برای چند دقیقه اصلاً AI رو فراموش کنیم.
مسئله جدید نیست، بلکه مصرفکننده عوض شده
فرض کنید سال ۲۰۲۱ است. یه Developer یه Ticket رو باید به انجام برسونه،اول باید بفهمه چه چیزی باید ساخته بشه، کدهای مرتبط با تغییر رو پیدا کنه، سابقه تغییرات مشابه یا پیادهسازی اولیه رو پیدا کنه، قواعد و شیوهنامههای تیم رو بدونه، تغییرات رو پیادهسازی کنه، تست کنه، PR بسازه، Review بگیره و در نهایت تغییر وارد فاز Stage یا Production بشه.
بعد هم باید بتونیم بفهمیم:
Ticket → Branch → Commit → PR/MR → Build → Release → Deployment
چه ارتباطی با هم داشتن (یعنی از کامیت بفهمیم تیکت چی بوده؛ از تیکت بفهمیم کامیت و PR و نسخه Release چی بوده). هیچکدوم از این مسائل با ChatGPT به وجود نیومدن.
قبلاً اگه Ticket ناقص بود، Developer از Product Manager سؤال میکرد. اگه معماری مستند نبود، از Senior تیم میپرسید. اگه نمیدونست یه سرویس چجوری Build میشه، توی مسنجر شرکت به یکی پیام میداد.
یعنی انسان با سؤالکردن، تجربه، حدس و Tribal Knowledge، سوراخهای فرایندی رو پر میکرد. ولی حالا فقط مصرفکننده جدیدی وارد این سیستم شده: Agent. پس شاید بخش بزرگی از AI Readiness اصلاً مسئله AI نباشه. و شاید داره میزان بلوغ مهندسی ما رو اندازه میگیره.
انجامدهنده که قبلاً نون میخورد تا جون بگیره کد بنویسه عوض شده، برق و اینترنت میخوره تا کار کنه. بقیه چیزها هنوز سر جاشه!
یه نکته دیگه قبل از شروع: این ۱۰ تا سؤال هموزن نیستن. اگه بخوام رک باشم، اگه جواب بند ۱ و ۴ رو «نه» بدید، بقیهی لیست عملاً تزئینیه؛ چون Agentتون حتی نمیدونه باید از کجا شروع کنه یا با چه سبکی بنویسه. پس این رو یه چکلیست موازی نبینید، یه توالی نسبی ببینید.
۱. آیا Agent میتونه از روی Ticket کار رو شروع کنه؟
یکی از قدیمیترین مشکلات تیمهای توسعه نرمافزار، شفاف نبودن Request هاست. مهم نیست Ticket رو Product Manager نوشته، Developer نوشته، AI ساخته یا از صفحه حوادث روزنامه با قیچی بریدهاید! سؤال اینه که آیا چیزی که تحویل Developer یا Agent میدید واقعاً قابل اجراست؟
چک کنید:
- آیا Ticketها تا حد معقول Atomic هستن؟
- آیا مسئله دقیقاً مشخصه؟
- آیا Acceptance Criteria واضح و قابل بررسیه؟
- آیا Dependencyها مشخصاند؟
- آیا لینک Design، Documentation، API Contract یا Context لازم وجود داره؟
- آیا Agent به تمام این منابع دسترسی داره؟
- آیا ساختار Ticket توسط یک Skill مشترک و نسخهبندیشده تعریف شده؟
اگر برای نوشتن Ticket استاندارد دارید ولی فقط توی ذهن چند نفر است، از دید Agent عملاً استاندارد ندارید. استانداردهاتون رو باید به ایجنت یاد بدید؛ هم برای ساختن تیکت؛ هم برای خوندن و انجام دادنشون.
یه مثال بزنم که دستتون بیاد چی میگم:
Ticket بد: «باگ لاگین رو فیکس کن.»
Ticket قابلاجرا برای Agent: «وقتی کاربر با ایمیل حاوی uppercase لاگین میکنه، ۴۰۱ میگیره. علتش احتمالاً عدم Normalize شدن ایمیل قبل از مقایسه توی AuthService.Login هست (فایل مرتبط: auth/service.go). Acceptance: لاگین با هر Case ایمیل باید موفق بشه، تست واحد برای اینکیس اضافه بشه.»
فرقش رو میبینید؟ اولی به یه انسان با تجربه و Tribal Knowledge نیاز داره که بفهمه «باگ لاگین» یعنی چی. دومی رو هرکسی «انسان یا Agent»، میتونه بدون سؤالپرسیدن از کسی شروع کنه.
۲. آیا PR/MR واقعاً توضیح میده که چه تغییری وارد سیستم میشه؟
PR صرفاً ظرفی برای Diff نیست. عنوانی مثل: fix stuff برای انسان هم غیرقابلفهم است و طبیعتاً برای Agent تقریباً بیارزش. PR/MR باید بتونه به راحتی توضیح بده:
چه چیزی تغییر کرده؟ چرا؟ مربوط به کدوم مسئله است؟ چجوری تست شده؟ چه ریسکی دارد؟ و…
پس بپرسید:
- آیا Title فرمت مشخصی داره؟
- آیا Description ساختار مشخصی داره؟
- آیا Ticket مرتبط به PR لینک میشه و دسترسی پیمایش بین PR و تیکت برقراره؟
- آیا بخشهایی مثل What، Why، Testing، Risk یا Migration مشخص شدن؟
- آیا Commit Messageها Convention مشخصی دارن؟
- آیا Agent میدونه چه زمانی باید PR ایجاد کنه؟
- آیا این قواعد در یک Skill مشترک، نسخهدهی شده و قابل دسترسی توسط همهی تیم، تعریف شدهاند یا هرکسی Prompt خودش رو داره؟
اگه Agent امروز از روی حدس PR بنویسه و فردا از روی یک Prompt دیگه، خیلی زود Repository تبدیل به مجموعهای از سبکهای مختلف میشه که خود AI رو هم گیج میکنه و درگیر اشتباهات متعدد.
۳. آیا Agent مدل Source Control شما رو میشناسه؟
گفتن اینکه «ما Git داریم» کافی نیست. Agent باید بدونه شما چجوری از Git استفاده میکنین. GitFlow دارین؟ GitHub Flow؟ Trunk-Based Development؟ مدل اختصاصی خودتون؟
باید روشن باشه:
- Branch از کجا ساخته میشه؟
- Naming Convention چیه؟
- Direct Commit روی چه Branchهایی ممنوعه؟
- Merge میکنید، Squash میکنید یا Rebase؟
- Hotfix چه فرایندی داره؟
- Release Branch دارید یا نه؟
- Commit Message چه فرمتی داره؟
- Generated Code باید Commit بشه یا نه؟
اینها نباید موقع اولین Pull Request تولیدشده توسط AI کشف بشن. شما قبلش باید تعیین تکلیف کنید. ولو به کمک AI برای استفاده توسط AI، ولی باید شفاف بشه.
۴. آیا قبل از اولین خط کد AI، قواعد مهندسی رو براش شفاف کردید؟
اگه سه تا Developer بدون هیچ توافقی شروع به کدنویسی کنن، احتمالاً سه سبک مختلف تولید میشه. با Agent هم اتفاق متفاوتی نمیافته. قبل از اینکه اولین کد تولید بشه باید مشخص بشه:
- Naming Convention چیه؟
- ساختار پروژه چیه؟
- Dependencyها چجوری مدیریت میشن؟
- Error Handling چجوری باید باشه؟
- Logging چه استانداردی داره؟
- چه Architectural Patternهایی مجاز یا ترجیح داده میشون؟
- چه چیزهایی نباید انجام بشن؟
- Unit Test و Integration Test چه استانداردی دارن؟
- چه Libraryهایی ترجیح داده میشون یا ممنوعاند؟
من کاری ندارم Coding Guideline را از Microsoft گرفتهاید، Google نوشته، از یک کتاب برداشتهاید یا اونقدر خفن هستید که خودتون ساخته باشید؛ یا از خونهی مارتینفولر دزدیدید! یا از AI برای تولیدش کمک گرفتید. مهم اینه که شیوهنامه داشته باشید و ای Agent اون رو به خوبی بلد باشه. و مهمتر اینکه این دانش نباید توی Prompt شخصی پنج تا Developer مختلف کپی شده باشه.
اگه از Skill استفاده میکنید، Skill باید Owner، Version، محل انتشار مشخص و فرایند Update داشته باشه و همه Agentها باید تضمینشده به آخرین نسخه دسترسی داشته باشن.
۵. آیا زنجیره تغییرات قابل ردیابیه؟
یه Ticket رو تصادفی انتخاب کنید و این مسیر رو طی کنیدد:
Ticket → Branch → Commit → PR → Build → Release → Deployment
حالا برعکس حرکت کنید:
Production Deployment → Release → Build → PR → Commit → Ticket
اگه وسط مسیر مجبور شدید از یک نفر سؤال کنید که «این Release دقیقاً مربوط به چی بود؟»، مشکل فقط برای AI نیست. Ticketing، Source Control، CI/CD و Documentation تا حد ممکن باید به همدیگه متصل باشن.
این مسئله قبل از موج Generative AI هم وجود داشت. امروز فقط اهمیتش بیشتر شده چون Agent نمیتونه هر ده دقیقه از کنار دستیش سؤال کنه که «حاجی این Commit مال کدوم Ticket بود؟» و یادمون نره که گاهی ایجنت شروع میکنه به حدس زدن و مزخرف تولید کردن!
۶. آیا Build و Test برای ماشین قابل اجراست؟
Documentationای که میگه یا در عمل اینجوریه که: برای Build شدن پروژه از علی بپرسید، یه تنظیمی روی لپتاپش داره. احتمالاً نشونه خوبی نیست.
Agent باید بتونه بفهمه:
- پروژه چجوری Build میشه؟
- Testها چجوری اجرا میشن؟
- Environment موردنیاز چیه و چجوریه؟
- Dependencyها چجوری بالا میان؟ خصوصا توی سرویسهای توزیعشده یا مایکروسرویسها.
- Test Data از کجا میاد؟
- Migrationها چجوری اجرا میشن؟
- چه Quality Gateهایی باید Pass بشن؟
هرچی فرایند Build و Test قابل تکرارتر و ماشینیتر باشه، Agent هم قابلاعتمادتر میشه. اگه Agent کد تولید کنه ولی نتونه صحتش رو مستقلاً بررسی کنه، شما فقط Code Generator خریدید، نه یه Agent مهندسی.
۷. آیا Agent میتونه Context رو پیدا کنه؟
یکی از کارهایی که Developerهای قدیمی تیم خیلی خوب انجام میدن اینه که میدونن اطلاعات کجاست. Architecture Decision کجای Confluence است، Contract فلان API توی کدوم Repository است، Business Rule داخل کدوم Google Doc قدیمیه و دلیل عجیب یه if رو هم فقط خسرو توی تیم میدونه!
برای انسان هم چنین وضعیتی خوب نیست. برای Agent ای بسا بدتر.
بپرسید:
- Architecture Documentation کجاست؟
- ADRها قابل دسترسیاند؟
- Domain Terminology تعریف شده؟
- Ownership سرویسها مشخصه؟
- API Contractها قابل کشفاند؟
- Agent اجازه دسترسی به منابع موردنیازش رو داره؟
- اطلاعات/کدهای منقضی مشخص یا حذف میشن/شدن؟
Documentation داشتن، با قابل کشف بودن Documentation یکی نیست.
۸. Agent دقیقاً به چه چیزهایی اجازه دسترسی داره؟
Agentی که فقط Repository رو میخونه با Agentی که میتونه Branch بسازه، Pipeline اجرا کنه، Infrastructure تغییر بده و Deployment انجام بده، یکی نیست.
باید مشخص باشه:
- چه Repositoryهایی قابل دسترسیاند؟
- Read یا Write؟
- چه Commands یا Tools مُجازن؟
- Secretsها چجوری مدیریت میشن؟
- Production Data قابل مشاهده است؟
- PII چطور محافظت میشه؟
- چه Actionهایی Human Approval میخوان؟
- فعالیت Agentها باید Audit بشن؟ اگه آره، چجوری؟
- آیا محتوایی که Agent بهعنوان Context میخونه (Ticket، کامنت PR، داکیومنت) میتونه منبع دستور مخفی/مخرب (prompt injection) باشه؟
دسترسی دادن بیش از حد، راحته و البته خیلی خیلی خطرناک و پرریسک. طراحی Least Privilege برای Agentها از همون اول خیلی ارزونتر از اصلاح اونها در آینده است.
این آخری رو دستکم نگیرید. Agent شما هرچی میخونه رو، حداقل تا حدی، به چشم دستور نگاه میکنه. یعنی یه Ticket یا یه کامنت PR که یه نفر (یا یه چیز) داخلش نوشته «ignore previous instructions and…» دیگه فقط یه شوخی بد نیست، یه سطح حملهست. (بیشتر بخونید؛ قبلا نوشتم)
۹. آیا هزینه AI بخشی از معماری شماست؟
Token هم Resource است. اگر Usage رو اندازه نمیگیرید، Budget ندارید و Model Selection مشخص نیست، Cost Management شما احتمالاً چیزی شبیه این میشه:
دوشنبه تا چهارشنبه با بهترین مدل کار میکنیم، پنجشنبه Budget تموم میشه و نصف Feature باقیمانده رو با هر چیزی که ارزونتره جمع میکنیم!
باید بدونید:
- مصرف هر تیم چقدره؟
- مصرف هر Repository یا Workflow چقدره؟
- کدوم Task واقعاً به مدل گرونتر نیاز داره؟
- چه زمانی مدل ارزونتر کافیه؟
- Budget Alert دارید؟
- Cost per Task یا Cost per PR رو اندازه میگیرید؟
- اگه Provider یا Model در دسترس نبود، Fallback Policy چیه؟
- آیا تغییر مدل میتونه Quality Gateها رو تغییر بده؟
Model Routing و Token Budget دیگه فقط مسائل مالی نیستن. بخشی از معماری سیستم توسعهاند. و خوشحال نباشیم که کارها «فقط سریعتر» انجام میشه؛ یه وقت دیدید چیزی که سریع انجام میشه ولی خرجش بیشتر از دخلش است؛ مشکلساز بشه!
۱۰. آیا اصلاً میدونید AI داره کمک میکنه یا نه؟
بند قبل پرسیدم چقدر خرج میکنید؛ این بند میپرسم چی گیرتون میاد؟این دو تا به صورت جدا از هم، بیمعنیان؛ Cost per Task که در بند ۹ اندازه گرفتید، فقط کنار Outcome این بند معنی پیدا میکنه. وگرنه فقط میدونید چقدر خرج کردید، نه اینکه ارزیده یا نه.
پس «تعداد خطوط کد تولیدشده توسط AI» تقریباً Metric بیارزشی هستن. چیزی که اهمیت داره Outcome است.
مثلاً:
- Lead Time کمتر شده؟
- PRها سریعتر Merge میشن؟
- Rework بیشتر شده یا کمتر؟
- Defect Rate تغییر کرده؟
- Review Time چه شده؟
- Rollback بیشتر شده؟
- Developer چند درصد خروجی Agent رو دوباره مینویسه؟ (چه خودش؛ چه مجدداً با ایجنت)
- هزینه AI برای هر Change چقدره؟
- چه نوع Taskهایی بیشترین Success Rate رو دارن؟
اینها اسم رمز نیستن، اسمشون DORA Metrics هست (اگر آشنا نیستید این مطلبم رو بخونید) خبر خوب اینه که لازم نیست از صفر Metric اختراع کنید؛ خبر بد اینه که اگه همین چهارتا رو هم امروز اندازه نمیگیرید، اضافهکردن AI فقط یه عدد ناشناختهی دیگه به یه سیستم بدون Baseline اضافه میکنه.
ممکنه Agent روزانه هزاران خط کد تولید کنه و در عمل بهرهوری تیم پایین اومده باشه. چیزی رو که اندازه نمیگیرید، نمیتونید بهبود بدید!
۱۱. آیا Skillهای شما هم Software هستن؟
اگر قراره تا Agent براساس Skillهای سازمان شما کار کنه، خود Skill هم دیگه یه فایل متنی تزئینی نیست.
باید بپرسید:
چه کسی Owner اون است؟ چه زمانی تغییر کرده؟ کدوم Version استفاده میشه؟ چه کسی Review کرده؟ چطور منتشر میشه؟ چطور مطمئن بشیم که همه به آخرین نسخه دسترسی دارن؟
اگه Architecture Guidelines، Ticket Rules، PR Convention و Coding Standards رو به Agent دادیم، اینها عملاً بخشی از Engineering Platform ما شدن.
و باید تقریباً با همون جدیتی مدیریت بشن که Code رو مدیریت میکنیم/میکردیم.
حرف آخر
شاید بهترین راه برای AI-Ready شدن این نباشه که بپرسیم:
«چه ابزار AI دیگهای باید بخریم؟»
سؤال بهتر شاید این باشه که:
«اگه فردا یه مهندس بسیار سریع، بسیار مطیع و بدون هیچ Tribal Knowledgeی وارد تیم بشه، آیا سیستم مهندسی ما اونقدر شفاف هست که بتونه درست کار کنه؟»
اگر جواب مثبت باشه، احتمالاً بخش بزرگی از مسیر AI Readiness رو قبلاً طی کردهاید.
ولی اگه جواب منفی باشه، AI احتمالاً مشکل رو ایجاد نکرده؛ فقط اون رو خیلی واضحتر کرده!
نسخهی فشرده، برای وقتی حوصلهی خوندن کل متن رو ندارید
حقتونه، من هم اگه جای شما بودم شاید اول میرفتم سراغ همین. جلوی هر بندی که جوابتون «نه» یا «نمیدونم» بود، خط نکشید؛ همونجا رو نشون کنید، چون احتمالاً نقطهی شروع واقعیِ شماست، نه آخر مسیر:
☐ Agent میتونه فقط از روی متن Ticket، بدون حدسزدن، کار رو شروع کنه؟
☐ PR/MR شما برای یه غریبه هم بهاندازهی کافی قابلفهمه؟
☐ مدل Branching و Commit Conventionتون جایی مکتوبه، نه فقط توی ذهن یه نفر؟
☐ قبل از اولین خط کد AI، قواعد مهندسیتون رو بهش گفتید؟
☐ میتونید یه Ticket رو تا Deployment، و برعکس، ردیابی کنید بدون اینکه از کسی سؤال کنید؟
☐ Build و Testتون کاملاً ماشینیه، یا هنوز یهجاهاییش دست حسن و خسرو است؟
☐ Agent میدونه Context لازم رو از کجا پیدا کنه؟
☐ دقیقاً میدونید Agent به چی دسترسی داره و به چی نه؟
☐ مصرف Tokenتون رو اندازه میگیرید، یا فقط پنجشنبهها میفهمید Budget تموم شده؟
☐ یه Outcome Metric دارید که نشون بده AI واقعاً کمک میکنه، نه فقط خط کد بیشتر تولید میکنه؟
☐ Skillهاتون Owner، Version و فرایند انتشار دارن؟
اگه بیشتر از سهتا رو تیک نزدید، خبر بد اینه که مشکل شما AI نیست.