‏کارخونه نرم‌افزار، طراحی رو یادش رفته

نویسنده دو سال پیش از Coinbase اومده بیرون و از اون موقع نزدیک ده تا محصول ساخته؛ بعضی‌هاشون شکست خوردن و چندتاشون الان درآمد دارن. حرف اصلیش اینه که ایده software factory (یعنی تیکت می‌نویسی، ایجنت برمی‌داره و یه pull request تحویل می‌ده) خوبه، ولی تقریباً همه نسخه‌هاش طراحی رو جا می‌ندازن. یا چندتا اسکرین‌شات الهام‌بخش توی تیکت می‌ذارن، یا کلاً تصمیم ظاهر و حس محصول رو می‌سپرن به ایجنت که اونم با اعتمادبه‌نفس کامل یه چیزی تحویل می‌ده.

ایستگاه اول Linear هست، جایی که «نیت» کار ثبت می‌شه. تیکت‌ها یا دستی نوشته می‌شن (خود نویسنده، گاهی با کمک یه ایجنت برای شفاف کردن ایده) یا خودکار؛ مثلاً یه ایجنت پشتیبانی که گزارش باگ رو تیکت می‌کنه یا یه ایجنت DevOps که خرابی رو می‌بینه. قانونش اینه که هر تیکت باید دو چیز رو بگه: چرا داریم این کارو می‌کنیم و «تموم شد» یعنی چی. اگه نتونه اینو تو چند جمله بگه، هنوز آماده ساخت نیست.

ایستگاه دوم Paper هست، یه ابزار طراحی. هر کاری که بخش ظاهری یا تجربه کاربری داره، قبل از ساخت از اینجا رد می‌شه. ایجنت از طریق MCP (یعنی پروتکلی که به ایجنت اجازه می‌ده مستقیم با ابزارها کار کنه) روی بوم Paper یه نسخه اولیه می‌سازه و از design system موجود استفاده می‌کنه. بعد نویسنده خودش طرح رو بازبینی می‌کنه؛ گاهی فاصله‌ها و متن‌ها رو دستی درست می‌کنه، گاهی روی بوم کامنت می‌ذاره تا ایجنت درستش کنه. چون خروجی Paper در اصل HTML و CSS واقعیه، موقع رفتن به کد چیزی گم نمی‌شه.

ایستگاه سوم ایجنت کدنویسیه. نویسنده بیشتر از Codex استفاده می‌کنه ولی می‌گه Claude Code یا هر ایجنت دیگه‌ای هم جواب می‌ده. ایجنت تیکت و طرح رو با هم می‌گیره و بر اساس هر دو می‌سازه. به گفته خودش این همون بخشیه که همه درباره‌ش حرف می‌زنن، ولی خودش الان کمتر از همه بهش فکر می‌کنه. ایستگاه چهارم دوباره خود نویسنده‌ست که خروجی رو با چیزی که منظورش بوده مقایسه می‌کنه. اگه کد با طرح نخونه، فوراً باگ حسابش نمی‌کنه؛ گاهی ایجنت یه راه بهتر پیدا کرده و طرح آپدیت می‌شه. بعد چرخه از اول شروع می‌شه.

نویسنده یه شکاف حل‌نشده رو هم قبول داره: ایجنت تو لحظه context خوبی می‌گیره، ولی تاریخچه رو نداره. نمی‌دونه چرا یه flow امتحان شد و بعد حذف شد، آنالیتیکس دفعه قبل چی گفت، یا design system چرا این‌شکلیه. یه طراح قدیمی همه اینا رو تو ذهنش داره و قضاوتش برای همین ارزش داره. نویسنده معتقده یه جور حافظه دائمی برای تصمیم‌های محصول لازمه و هنوز کسی اینو درست حل نکرده.

نکات کلیدی:

• ورک‌فلو چهار ایستگاه داره: Linear برای تیکت، Paper برای طراحی، ایجنت کدنویسی (مثل Codex یا Claude Code) و بازبینی انسانی.
• هر تیکت باید دلیل کار و تعریف «تموم شدن» رو در چند جمله داشته باشه.
• ایجنت از طریق MCP مستقیم روی بوم Paper طراحی می‌کنه و خروجی HTML و CSS واقعیه.
• ناهماهنگی کد با طرح همیشه باگ نیست؛ گاهی طرح بر اساس کد آپدیت می‌شه.
• مشکل باز: ایجنت‌ها حافظه دائمی از تصمیم‌های قبلی محصول و داده‌های آنالیتیکس ندارن.