تصور کنید برنامهنویسی هستید که با یک ابزار جادویی، ویژگیهای پیچیده را در چند ثانیه میسازد، اما یک سال بعد متوجه میشوید هیچکس در تیم نمیداند این کدها چگونه کار میکنند. این همان تلهای است که بسیاری از تیمهای مدرن در حال سقوط در آن هستند.
در سال ۲۰۲۳، در اجلاس No Code در پاریس، یک معمار پلتفرم استدلال کرد که ساخت یک ویژگی نرمافزاری، در واقع دربارهی نوشتن کد نیست؛ بلکه دربارهی فرمولبندی (Formalization) وضعیتها، خطاها و موارد خاصی (Edge Cases) است که یک محصول را تعریف میکنند. او پدیدهای به نام Vibe-Coding (کدنویسی حسی) را نقد کرد؛ یعنی استفاده از هوش مصنوعی برای تولید انبوه کدهای خام بدون در نظر گرفتن محدودیتها. این رویکرد اگرچه صدای بلندی برای آزادی است، اما صورتحساب بلندمدت مالکیت این تصمیمات را نادیده میگیرد. این چالشها بهویژه زمانی تشدید میشوند که متغیرهای پنهان در صورتحسابهای ابزارهای بدون کد منجر به هزینههای پیشبینینشده برای سازندگان شوند. طبق تجربه این نویسنده پس از پانزده سال ساخت پلتفرمهای اپلیکیشن، سختترین بخش ساخت هر ویژگی، هرگز تبدیل ایده به کد نیست، بلکه همان فرمولبندی است که پیش از کدنویسی رخ میدهد.
این تنش در زمانی به وجود میآید که صنعت به سمت آزادی مطلق در انتخاب ابزارها حرکت میکند. برای سالها، بحث اصلی بر سر این بود که چه کسی کد را تایپ میکند، اما ظهور هوش مصنوعی مسئله را تغییر داده و اکنون سؤال این است که چه کسی مسئول فرمولبندی است. در روز اول، همه چیز سریع و رایگان به نظر میرسد، اما هزینه واقعی چارچوبهای دستساز (Custom-rolled Frameworks) در سال دوم ظاهر میشود؛ درست زمانی که تصمیمات ثبتنشده به «بدهی میراثی» (Legacy Debt) تبدیل میشوند.
هزینههای پنهان آزادی
کدنویسی حسی و کدهای خام وعده میدهند که هیچ سقفی وجود ندارد و هیچ تصمیمی برای شما از پیش گرفته نشده است. اما این به معنای آن است که تکتک فرمولبندیها تبدیل به مشکل شخصی توسعهدهنده میشود. این موارد شامل استراتژی احراز هویت، مدیریت وضعیت (State Management) — شبیه به دفترچه یادداشتی که مدل هر لحظه وضعیت برنامه را در آن ثبت میکند تا گم نشود — سیاستهای کشینگ، قراردادهای مدیریت خطا، معماری پیمایش (Navigation) و خط لولهی ساخت (Build Pipeline) است. هیچکدام از این انتخابها در واقع خودِ «محصول» نیستند، با این حال همهی آنها باید به طور مستمر نگهداری شوند.
یک تصمیم در نرمافزار، اتفاقی یکباره نیست، بلکه شبیه به یک «حق اشتراک» (Subscription) است. شما باید آن را به یاد داشته باشید، مستند کنید، در جلسات بازبینی کد دفاع کنید، برای کارکنان جدید دوباره توضیح دهید و با هر نسخهی جدید از سیستمعامل، دوباره بررسیاش کنید. وقتی یک لایه کشینگ هوشمندانه، عمرش بیشتر از کسی میشود که منطق آن را درک میکرد، یا زمانی که یک چارچوب دستساز نیاز به بهروزرسانی دارد که هرگز بودجهای برای آن پیشبینی نشده بود، در نهایت صورتحساب «آزادی مطلق» ارسال میشود.
جزئیات بارِ فرمولبندی
با تکیه بر ۱۵ سال تجربه در ساخت پلتفرمهای اپلیکیشن، توسعه حرفهای نرمافزار شامل مجموعهای از بارهای مشخص است که توسعهدهنده باید متحمل شود:
- فرمولبندی وضعیت (State Formalization): نامگذاری و تعریف دقیق وضعیتهای «در حال بارگذاری» (Loading)، «خالی» (Empty)، «خطا» (Error) و «کهنه» (Stale) برای هر ویژگی؛ برای مثال، حتی برای یک لیست ساده از آیتمها، باید تمام این وضعیتها تعریف شوند.
- مدیریت موارد خاص (Edge Case Management): تصمیمگیری درباره اینکه چه اتفاقی میافتد وقتی یک درخواست شبکه در میانه راه قطع میشود، یا زمانی که کاربر دو گزینه را به گونهای ترکیب میکند که هیچکس پیشبینی نکرده بود.
- هزینههای اشتراکی (Subscription Costs): مدیریت انتخابهای معماری که نیازمند تعهد بلندمدت و دفاع مداوم در چرخههای نگهداری و بهروزرسانی هستند.
این فلسفه با مفهوم «توکنهای نوآوری» (Innovation Tokens) که توسط Dan McKinley در تز «تکنولوژیهای کسلکننده را انتخاب کنید» (Choose Boring Technology) مطرح شد، همسو است. مککینلی استدلال کرد که هر تیم تنها حدود ۳ توکن برای انتخابهای غیر استاندارد و عجیب دارد. زیرا هر تصمیم غیرمعمول، یک تعهد نگهداری طولانیمدت ایجاد میکند و مصرف نسنجیده این توکنها منجر به هزینههای عملیاتی (Overhead) غیرقابل تحمل میشود.
میانهروی مهندسی و قانون ۱۰ درصدی
تولید کد توسط هوش مصنوعی، انباشت بدهی را تسریع میکند. AI با کاهش هزینه تولید یک تصمیم، به توسعهدهندگان اجازه میدهد سریعتر از هر زمان دیگری در تاریخ صنعت، بدهی معماری ایجاد کنند. این روند میتواند به سرعت منجر به انباشت «آشغالهای معماری» در سال ۲۰۲۶ شود، جایی که تولید انبوه کد بدون تفکر، ساختار سیستم را تخریب میکند. برای مقابله با این وضعیت، نویسنده دیدگاهی از «میانهروی مهندسی» (Engineered Middle) را پیشنهاد میکند که بر بهرهگیری از چارچوبها (Frameworks) متکی است. چارچوب در اینجا به هر ابزاری تعریف میشود که پیش از رسیدن توسعهدهنده، تصمیمات اساسی را گرفته باشد.
این رویکرد هم چارچوبهای کدنویسی (مانند Rails) و هم پلتفرمهای کامل اپلیکیشن را شامل میشود. در این پلتفرمها، الگوهایی که در هزاران اپلیکیشن تکرار شدهاند، یکبار برای همیشه فرمولبندی شدهاند. در این مدل، «قانون ۱۰ درصد» اجرا میشود:
- ۹۰ درصد: الگوهای استاندارد پروژه (مانند مدیریت حسابها، جستوجو، نوتیفیکیشنهای Push و پرداختها) را همانطور که هست به ارث میبرند؛ چراکه این بخشها سالها در محیطهای تولید واقعی مطالعه و دیباگ شدهاند.
- ۱۰ درصد: باقیماندهی واقعاً سفارشی است که توسعهدهنده توکنهای نوآوری خود را فقط در قسمتهایی هزینه میکند که هیچ پلتفرمی نمیتوانست پیشبینی کند.
دریچههای خروج و شعاع تخریب
این رویکرد «دریچههای خروج» (Escape Hatches) ایجاد میکند؛ بخشهای ویژهای که منطقهای سفارشی و Vibe-coded میتوانند در یک قاب پایدار زندگی کنند. در این حالت، چارچوب به جای اینکه تظاهر کند آن ۱۰ درصد سفارشی وجود ندارد، به توسعهدهنده نقشهای میدهد تا آگاهانه و با انتخاب خود وارد پیچیدگی شود.
این استراتژی «شعاع تخریب» (Blast Radius) شکست را محدود میکند. اگر یک بخش تولیدشده با AI ایده بدی باشد، شکست فقط محدود به همان بخش میماند و باعث کرش کردن کل اپلیکیشن نمیشود. هدف نهایی این است: «در جاهای معمولی سریع باشید و در جاهای خاص، باز و منعطف».
خط قرمز از سال ۲۰۱۱
این خط قرمز معماری از سال ۲۰۱۱ دفاع شده است: در جایی که پروژهها شبیه هم هستند سختگیرانه و دارای نظر (Opinionated) عمل کن و در جایی که متفاوتاند، باز باش. این موضع در برابر هر موجی از تغییرات، از جمله ظهور چارچوبهای هیبریدی که بیش از یک دهه به عنوان جایگزین معرفی شدند، پابرجا مانده است. در این میان، شکاف مالکیت کد در سال ۲۰۲۶ نشان میدهد که چگونه انتخاب پلتفرم میتواند بر میزان کنترل توسعهدهنده بر کد نهایی اثر بگذارد. اگرچه AI و ابزارهای هیبریدی «چگونگی» کار را تغییر میدهند، اما اقتصاد نرمافزار تغییری نکرده است: هر فرمولبندی، قیمتی دارد که باید پرداخت شود.
برای مالکان کسبوکار و توسعهدهندگان، ارثبری از یک دهه فرمولبندی در یک چارچوب، از دست دادن آزادی نیست، بلکه یک اکتساب استراتژیک است. برنده واقعی کسی نیست که بیشترین کد را تولید کند، بلکه کسی است که تعداد تصمیمات معماری منحصربهفردی را که مجبور به نگهداریشان است، به حداقل برساند. شما باید بررسی کنید که آیا استک فعلی AI شما مرزهای مشخصی ایجاد میکند یا صرفاً یک خلأ بیانتها از سفارشیسازیهای مدیریتنشده است.
برای مالکان کسبوکار و توسعهدهندگان، ارثبری از یک دهه فرمولبندی در یک چارچوب، از دست دادن آزادی نیست، بلکه یک اکتساب استراتژیک است. برنده واقعی کسی نیست که بیشترین کد را تولید کند، بلکه کسی است که تعداد تصمیمات معماری منحصربهفردی را که مجبور به نگهداریشان است، به حداقل برساند. شما باید بررسی کنید که آیا استک فعلی AI شما مرزهای مشخصی ایجاد میکند یا صرفاً یک خلأ بیانتها از سفارشیسازیهای مدیریتنشده است.
گام بعدی شما
- بررسی کنید آیا استک فعلی شما مرزهای مشخصی دارد یا صرفاً یک خلأ بیانتها از سفارشیسازیهای مدیریتنشده است.
- در پروژههای جدید، قانون ۱۰ درصد را پیاده کنید: ۹۰٪ استاندارد و ۱۰٪ نوآوری.
- برای هر بخش کد سفارشی که AI تولید میکند، یک «نقشه خروج» بنویسید تا در سال دوم هزینه نگهداری آن شما را فلج نکند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو