کد فقط خروجی نبود، جای فکر کردن ما بود
خلاصهٔ کاملتر
نوشته با یه حس آشنا شروع میشه: مدلهای زبانی مثل جادو کد تولید میکنن، ولی هرچی بیشتر فشار میآری، کمتر حس جادو داره. به گفتهٔ نویسنده حتی وسواسیترین آدمها هم آخرش دارن «اسلاپ» تولید میکنن. جواب رایج اینه که ایجنتهای بیشتری رو موازی راه بندازی، اونم تو کل تیم — و نتیجهش ۵۰ تا پولریکوئست تلنبارشدهست که باید ریویو کنی. اون وقت باید انتخاب کنی: یا خودت گلوگاه باشی، یا سرسری تأیید کنی و رد شی.
برای اینکه بفهمیم چی گم شده، نویسنده «فلوی قدیمی» رو مرور میکنه. اول تحقیق و پلن: این تیکه کجای کدبیس و محصول میشینه، چی از قبل هست، چه کامپوننتی رو میشه دوباره استفاده کرد. بعد یه کامپوننت استاب میزنی، یه جا رندرش میکنی، سراغ داکیومنتها میری، یه نمونه پیدا میکنی، تصویرها رو میذاری سر جاشون و تو سایت نگاهش میکنی.
نکتهٔ اصلی همینجاست: اون کار فقط «کد نوشتن» نبود. داشتیم مسئله رو کاوش میکردیم، تصمیم میگرفتیم، فهممون از کدبیس رو جلو میبردیم و با همتیمیها مسئله حل میکردیم. کد مدیومِ فکر کردنمون بود و همزمان با فکرمون از حالت مبهم به حالت شفاف و ریزدانه میرسید.
با این حال نویسنده تأکید میکنه که قرار نیست به اون روزها برگردیم و اصلاً هم نباید. به باور اون فلو دوباره برمیگرده، به شرطی که ورکفلوی جدید رو پیدا کنیم و ابزارش رو بسازیم — همونطور که IDEها چند دهه وقت داشتن روش قبلی رو صیقل بدن.
بعد یه مرور تاریخی میآد: اول دستور یه سوراخ فیزیکی روی کارت پانچ بود، بعد اسمبلی اومد که به جای سوراخ کلمه بنویسیم، بعد کامپایلرها اومدن و یه خط فورترن یا C جای یه صفحه اسمبلی رو گرفت. زبانهای اسکریپتی حسابوکتاب حافظه و تایپ رو برداشتن و کتابخونهها و فریمورکها اجازه دادن کل زیرسیستمها رو قرض بگیریم. هر بار جزئیات بیشتری رو به یه مترجم سپردیم و صرفهجوییش رو خرج جاهطلبی بیشتر کردیم.
ادعای مرکزی مقاله اینه که قدم بعدی رو نصفهنیمه برداشتیم. با اینکه میتونیم کد رو تو هر مدیومی که بهمون میخوره هدایت کنیم، هنوز داریم با پرامپت کار میکنیم و کد خام ریویو میکنیم؛ چیزی که با چشم قابل وارسی نیست. زوم که بیرون میزنی به کد ناخوانا میرسی، پس باز یه ایجنت دیگه رو میندازی به جون ریویو.
نویسنده میگه مدلهای امروزی از دل تحقیقات مدلسازی زبان و ترجمهٔ ماشینی دراومدن و میتونن کد رو به هر مدیومی و برعکس ترجمه کنن. تلاشهای قبلی مثل UML و no-code بیشتر به این دلیل شکست خوردن که چیزی اونها رو همگام نگه نمیداشت و سطح ویرایش نبودن؛ هر ترجمه باید دستی انجام میشد. حالا این محدودیت برداشته شده.
پیشنهاد عملی مقاله در قالب چند سؤاله: چی میشه اگه ایجنتها بهمحض شروع کار برامون یه وایتبورد یا پلیگراند اختصاصی بسازن، با پنل جدا برای هر وجهی که میخوایم صیقلش بدیم؟ شاید اصلاً لازم نباشه از کد شروع کنیم و بشه با تصویر یا پروتوتایپ تا رسیدن به جهت نهایی جلو رفت. نویسنده یه دموی ساده هم گذاشته و آخرش هشدار میده: اگه از هوش مصنوعی فقط بهعنوان راهی سریعتر برای ویرایش کد استفاده کنیم، شهود و نقشهٔ ذهنی و همراستایی تیم رو از دست میدیم.
نکات کلیدی:
- مشکل اصلی سرعت تولید کد نیست، از بین رفتن حلقهٔ کوتاه «بنویس، ببین، تصمیم بگیر»ه
- کد علاوه بر خروجی، مدیومی بود که توش فکر میکردیم و فهممون از مبهم به شفاف میرسید
- تاریخ برنامهنویسی یعنی سپردن تدریجی جزئیات به یه مترجم؛ قدم فعلی نصفهنیمه برداشته شده
- UML و no-code شکست خوردن چون همگام نمیموندن و سطح ویرایشپذیر نبودن
- راه پیش رو ابزاریه که کار رو تو مدیوم دلخواه آدم ممکن کنه، نه برگشت به روش قدیمی




