تیم‌ها سرعت ابزار ایجنتی را می‌خواهند بدون اینکه هر عوض شدن زمینه را به یک پلتفرم میزبانی‌شده بفرستند. برای همین گردش کار local-first وسوسه‌کننده است، مخصوصاً برای کدنویسی، تحلیل، و کار عملیاتی داخلی. گیر کار این است که راحتی زود به امنیت، یکدستی، و تکرارپذیری می‌خورد.
درد در تیم واقعی سریع دیده می‌شود. روی قابلیت اطمینان، توجه توسعه‌دهنده، هزینه، و اعتماد به محصول اثر می‌گذارد. اگر نتوانی بگویی ایجنت کدام پوشه را می‌بیند و کدام دستور را حق دارد بزند، «محلی» فقط یعنی حادثه روی لپ‌تاپ کسی اتفاق می‌افتد، نه اینکه داده از ساختمان خارج نشده.
کی ساختنش می‌ارزد
وقتی این الگو را برمی‌دارم که تیم گردش کار تکراری دارد، موفقیت را می‌تواند تعریف کند، و از اول به نگهداری اهمیت می‌دهد. اگر کاربرد هنوز مبهم است، محدوده را تنگ کن. سیستم بزرگ دور مسئله حل‌نشده نساز.
سریع‌ترین مسیر معمولاً یک گردش کار تیز است با مرز محکم، ورودی صریح، و تعریف روشن از «به اندازه کافی خوب» برای نسخه اول. اگر برای تیم می‌ساختم از همین پایه شروع می‌کردم: محدوده صریح فضای کار، مجوز روشن ابزار، اجرای دستور قابل حسابرسی، و تفکیک ساده بین اکتشاف فقط‌خواندنی و عمل نوشتنی. این قیدها سیستم را امن‌تر می‌کنند بدون اینکه مزیت را بکشند.
محلی بودن بهانه حذف بازبینی نیست. یعنی زمینه پیش‌فرض روی دیسک تیم است، نه اینکه هر توسعه‌دهنده سیاست جدا داشته باشد. همان قرارداد باید در ریپو باشد تا ماشین همکار بعدی رفتار دیگری نسازد.
مرز را قبل از کد بنویس
کار را در یک جمله بنویس. شکل ورودی را مشخص کن. بگو خروجی باید چه شکلی باشد. ساده به نظر می‌رسد، ولی جلوی رانش معماری را می‌گیرد چون بقیه سیستم دور قرارداد پایدار طراحی می‌شود نه دور حس.
همان‌جا تصمیم بگیر کدام بخش مال مدل است و کدام در کد عادی اپ می‌ماند. هرچه گردش کار مهم‌تر شود این تفکیک ارزشمندتر است. اگر به صورتحساب، مجوز، داده پروداکشن، یا گذار وضعیت قابل دیدن کاربر می‌خوری، آن بخش با اعتبار سخت در اپ بماند. AI را جایی بگذار که کار مبهم است. پیامد را به اپ بسپار.
برای ایجنت روی لپ‌تاپ، «داده پروداکشن» شامل فایل env، کلید، و دامپ محلی پایگاه هم هست. محدوده فضای کار را طوری بنویس که این مسیرها پیش‌فرض بیرون باشند. اگر مدل باید برای یک کار استثنا ببیندشان، همان استثنا در لاگ بیاید، نه اینکه کل خانه توسعه‌دهنده فضای کار باشد.
پیاده‌سازی که واقعاً فرق می‌کند
گردش کار را دور قابل بازبینی بودن بچین. ایجنت باید به ترتیبی نگاه کند، پیشنهاد دهد، ویرایش کند، و تأیید کند که انسان بتواند دنبال کند. خروجی باید راحت diff شود. دستور باید دیده شود. فرض باید روی سطح بیاید، نه اینکه داخل رد اجرایی قایم شود که هیچ‌کس نمی‌خواند.
مسیر کد را عمداً کسل نگه دار. یک مسیر API تمیز، صف وقتی کار ناهم‌زمان است، اعتبار خروجی تایپ‌دار، و لاگ دور گام گران یا شکست‌خیز معمولاً بیشتر از یک لایه ارکستراسیون زیرک دیگر می‌ارزند. نسخه اول باید بتواند صادقانه شکست بخورد: حالت ناقص روشن، خطای قابل بازیابی، و مسیر موفقیت باریک. وانمود خودمختاری قبل از اینکه سیستم این اعتبار را گرفته باشد، اعتماد را یک‌جا می‌سوزاند.
سطح یکپارچه‌سازی را اول کوچک نگه دار. یک فایل‌سیستم، یک پوسته، و چند فراهم‌کننده زمینه محدود معمولاً دورتر از انتظار می‌روند. قابلیت بیشتر را فقط وقتی اضافه کن که تیم فهمیده اهرم واقعی کجاست و ریسک واقعی کجا زندگی می‌کند.
پروداکشن که آموزش‌ها جا می‌اندازند
تلاش دوباره، مهلت، صف، محدودیت نرخ، متریک، دید پشتیبانی، و جمله‌ای که تیم بتواند با آن رفتار ناقص را توضیح دهد. اگر گردش کار می‌تواند کند، گران، یا ناهماهنگ شود، قبل از اولین استفاده واقعی بگو چطور مهارش می‌کنی. آموزش مسیر خوشحال کافی نیست.
سه اشتباه رایج را می‌شناسم. اول، بزرگ ساختن نسخه اول چون «بعداً لازم می‌شود». دوم، تعریف نکردن موفقیت: اگر کسی نداند کیفیت خروجی، تأخیر، و قابلیت اطمینان قابل قبول چیست، قضاوت منصفانه ممکن نیست و فیچر هدف متحرک می‌شود. سوم، نادیده گرفتن دست انسان. حتی جریان خیلی خودکار به نقطه بازبینی، فرض قابل دیدن، و زمینه محصول نیاز دارد تا هم‌تیمی بدون مهندسی معکوس کل سیستم دخالت کند.
از یک کاربرد محدود شروع کن و قرارداد خروجی را صریح کن. نتیجه را قبل از اینکه کد بعدی به آن تکیه کند اعتبار کن. حداقل مشاهده را برای تأخیر، شکست، و هزینه همان گردش کار بگذار. به کاربر واقعی فقط وقتی نشان بده که می‌دانی وقتی کمی خراب شد چه شکلی است.
ایجنت local-first وقتی ارزش دارد که همکار منضبط داخل گردش کار باشد، نه مهمان خودمختار که در لپ‌تاپ پرسه می‌زند. اگر بعد از خاموش کردن ابزار هنوز بتوانی بگویی کدام تصمیم مال انسان ماند، مرز را درست کشیده‌ای.
محلی بودن را با سیاست مشترک عوض نکن
وسوسه این است که هر توسعه‌دهنده پروفایل خودش را داشته باشد: یکی شبکه را باز می‌گذارد، یکی کل دیسک را فضای کار می‌کند، یکی تأیید نوشتن را خاموش می‌کند چون «فقط روی شاخه خودم است». این دیگر local-first نیست. این چند محصول روی یک اسم است. قرارداد محدوده، فهرست دستور مجاز، و فرق خواندن و نوشتن باید در ریپو باشد و در بازبینی بیاید. تنظیم محلی فقط می‌تواند سخت‌گیرانه‌تر باشد، نه شل‌تر.
دستور پوسته را مثل ابزار بنویس، نه مثل رشته آزاد. اگر مدل می‌تواند هر دستوری را پیشنهاد کند، انسان باید قبل از اجرا همان رشته را ببیند و بتواند رد کند. اجرای خودکار فقط برای فهرست کوتاه و از قبل شناخته‌شده قابل دفاع است، آن هم وقتی خروجی‌اش مخرب نیست. نصب بسته، مهاجرت پایگاه، و هر چیزی که به شبکه یا به اعتبارنامه می‌خورد در آن فهرست جا نمی‌شود.
زمینه را از ریپو مرحله‌ای بیاور. فایل مرتبط با کار، نه درخت کامل. راز را حتی اگر روی لپ‌تاپ است وارد زمینه نکن. اگر مدل برای توضیح یک باگ به متغیر محیط نیاز دارد، مقدار را با مقدار پوشانده‌شده جایگزین کن و شکل کلید را بده، نه خود کلید را. این کار کسل است و دقیقاً همان چیزی است که آموزش‌های «کل پروژه را به مدل بده» جا می‌اندازند.
تکرارپذیری یعنی هم‌تیمی دیگر، روی ماشین دیگر، با همان قرارداد به نتیجه قابل مقایسه برسد. لازم نیست diff بیت‌به‌بیت یکی باشد. لازم است محدوده فایل و نوع دستور یکی بماند. اگر نماند، گردش کار هنوز به حال‌وهوای یک لپ‌تاپ وابسته است. آن را محلی ننام. آن را شخصی بنام و تا وقتی شخصی است به تیم نده.