نمودار فعالیت GitHub من در سال 2025 انگار متعلق به دو توسعهدهنده متفاوت است. نیمه اول سال تقریباً خالی است. در نیمه دوم بیش از ۴۰۰۰ commit دیده میشود.
ناگهان وقت آزاد بیشتری پیدا نکرده بودم. همچنان یک شغل تماموقت را با پروژههای جانبی ترکیب میکردم. چیزی که تغییر کرد، میزان اصطکاک بین ایده و نسخهای بود که واقعاً کار میکند: شروع کردم ابزارهای AI coding را بسیار جدیتر به کار بگیرم.
البته این عدد باید دقیق تفسیر شود. تعداد commit بهتنهایی معیار بهرهوری نیست. چهار هزار commit ثابت نمیکند چهار هزار بهبود مفید انجام دادهام یا کیفیت کد بالا بوده است. چیزی که نمودار واقعاً نشان میدهد تغییر در الگوی کاری من است: نسبت به قبل با ثبات بسیار بیشتری میساختم، تکرار میکردم و پروژهها را به نسخههای قابل اجرا میرساندم.
گلوگاه واقعی انرژی لازم برای شروع بود
در side projectها بارها به یک مشکل مشابه برخوردم: اولین نسخه مفید معمولاً پشت مقدار زیادی کار روتین قرار دارد. Routing، validation، script، test، configuration و cleanup میتوانند قبل از آنکه بفهمم ایده ارزش ادامه دادن دارد، انرژی را مصرف کنند.
قبلاً وقتی اولین نسخه به چند شب setup نیاز داشت، بعضی experimentها را عقب میانداختم. ابزارهای AI coding این کار را حذف نکردند، اما هزینه first pass را پایین آوردند و رسیدن به نسخه قابل آزمایش را سریعتر کردند.
برای من مهمترین سود faster typing نبود؛ کاهش activation energy بود. ایدههای بیشتری به مرحلهای رسیدند که بتوانم دربارهشان evidence واقعی جمع کنم.
workflow من با Node.js چگونه تغییر کرد
فرایند development را با یک chat window جایگزین نکردم. در side projectهای Node.js از DeepSeek بهعنوان یک دست دوم برای کارهای محدود استفاده کردم: draft اولیه implementation، خواندن code ناآشنا، پیشنهاد test، تحلیل stack trace، تقسیم refactor بزرگ به stepهای کوچک و مرور assumptionهای deployment.
- Scaffolding: نسخه اولیه و خستهکننده handler، validation، script یا test.
- Code reading: دنبال کردن مسیر request یا value قبل از edit.
- Refactoring: تبدیل تغییر بزرگ به diffهای کوچک و قابل review.
- Debugging: ساخت چند hypothesis از logها بهجای چسبیدن به اولین توضیح.
- Verification: پیدا کردن edge case و regression پس از کار کردن happy path.
هرچه input، output، constraint و conventionهای موجود روشنتر بودند، نتیجه سریعتر قابل بررسی بود. task مبهم بیشتر جوابهایی تولید میکرد که plausible بودند اما abstraction اشتباه انتخاب میکردند.
به همین دلیل output را candidate patch میدیدم، نه پاسخ نهایی. Type checking، test، build و flow واقعی evidence بودند؛ لحن مطمئن مدل نبود.
DeepSeek کجا بیشترین کمک را کرد — و کجا نکرد
DeepSeek برای من زمانی بیشترین ارزش را داشت که مسئله programming مشخص بود و میشد چند بار سریع iterate کرد: first pass، error واقعی، scope کوچکتر و تلاش بعدی.
این را benchmark نمیدانم. مطالعه کنترلشدهای علیه همه مدلهای رقیب انجام ندادم و lineup مدلها سریع تغییر میکند. ادعای دقیقتر این است: DeepSeek آنقدر با workflow من سازگار بود که استفاده من از AI assistance بسیار پرتکرارتر شد.
وقتی function، test و error واقعی داشتم، بهترین نتیجه را میگرفتم. وقتی task به context پنهان محصول یا trade-off معماری ظریف وابسته بود، عملکرد ضعیفتر میشد و یک پاسخ روان میتوانست assumption بد را finished نشان دهد.
AI هزینه آزمایش کردن را تغییر داد
بزرگترین پیشرفت این نبود که «AI کد مینویسد، پس توسعه خودکار شده است». بسیاری از اجزای کوچک صرفاً آنقدر کمهزینه شدند که ارزش امتحان کردن پیدا کردند. قابلیتی که قبلاً setup زیادی میخواست، حالا میتوانست تا زمانی که هنوز به ایده علاقه داشتم به prototype تبدیل شود.
این تفاوت مهم است. AI هزینه رسیدن به نسخه قابل آزمایش را کم کرد، اما معماری، قضاوت محصول، deployment یا درستبودن را حذف نکرد. پیادهسازی تولیدشده هنوز ممکن است اشتباه باشد؛ build موفق ممکن است در runtime خراب شود؛ prototype deployشده هم میتواند محصول بدی باشد.
فایده عملی برای من شتاب بود. وقتی میتوانستم کل سیستم را در حال کار ببینم، ادامه دادن و اصلاح آن بسیار آسانتر میشد.
یک benchmark قویتر چه چیزهایی لازم دارد
برای benchmark قابل بازتولید باید نسخه دقیق مدلها، programming task ثابت، repository snapshot، prompt، raw output، زمان، patchهای پذیرفته و ردشده، زمان review، نتیجه test و میزان rework ثبت شود.
فقط commit کافی نیست. زمان از idea تا verified version، defect، rollback و کار بازنویسیشده هم مهم است. بدون این context، ۴۰۰۰ commit نشانه activity و تغییر رفتار است، نه proof کیفیت software.
چه چیزی برای من تغییر کرد
2025 سالی بود که دیگر هر side project را کوهی از setup نمیدیدم که باید دستی از آن بالا بروم. AI اولین نسخه قابل اجرا را آنقدر ارزان کرد که بیشتر به مرحلهای برسم که تصمیمهای واقعی محصول اهمیت پیدا میکنند.
به همین دلیل نیمه دوم نمودار GitHub من اینقدر متفاوت است. نه چون AI ساعات بیشتری به روزم اضافه کرد و نه چون هر خط تولیدشده خوب بود. اصطکاکی را کم کرد که قبلاً ایدهها را پیش از واقعی شدن از بین میبرد.
تمرکز من در 2026 بخش کمزرقوبرقتر ماجراست: بهبود workflow، سنجش جدیتر کیفیت و اطمینان از اینکه توسعه سریعتر به نرمافزار بهتر منجر میشود، نه فقط commit بیشتر.