https://virgool.ir/feed/@farziinبرنامه‌نویس، یک عدد عاشق کتابfa2026-11-11 16:25:25https://files.virgool.ir/upload/users/26198/avatar/XPnj1F.jpeghttps://virgool.ir/@farziinhttps://virgool.ir/@farziin/چرا-در-عصر-هوش-مصنوعی-فهمیدن-به-یک-گلوگاه-تبدیل-شده-است-۵-درس-از-جفری-لیت-wvmltttuxekpوقتی کدها بیشتر از توان خواندن ما تولید می‌شوندما در حال ورود به دورانی هستیم که ایجنت‌های هوش مصنوعی (AI Agents) قادرند به سادگی پول‌ریکوئست‌های (PR) ۵۰ هزار خطی تولید کنند. جفری لیت، طراح-مهندس ارشد در Notion، در کنفرانس اخیر AI Engineer صحبت خود را با یک پرسش جنجالی شروع کرد: «آیا در دنیای امروز، هنوز لازم است انسان بفهمد کد چگونه کار می‌کند؟» او با شوخ‌طبعی به «سوگیری انتخاب» (Selection Bias) در آن سالن اشاره کرد؛ چرا که مخاطبان او مهندسانی بودند که ذاتاً به نقش انسان در طراحی اهمیت می‌دهند. اما واقعیت این است که ما با یک بحران جدی روبرو هستیم: کدها با سرعتی تولید می‌شوند که فراتر از توان پردازش مغز ماست. در این میان، چالش اصلی دیگر «نوشتن» نیست، بلکه عقب نماندن از درکِ خروجی‌های انبوهی است که توسط هوش مصنوعی ایجاد می‌شود.بدهی شناختی: هزینه‌ی پنهانِ Vibe Coding اصطلاح "Vibe Coding" این روزها در دنیای فناوری بسیار شنیده می‌شود؛ حالتی که در آن شما با تکیه بر هوش مصنوعی و بر اساس یک «حس کلی»، کدها را کنار هم می‌چینید و سیستم هم به ظاهر کار می‌کند. اما جفری لیت هشدار می‌دهد که این رویکرد منجر به «بدهی شناختی» (Cognitive Debt) می‌شود.بدهی شناختی از بدهی فنی (Technical Debt) خطرناک‌تر است. در بدهی فنی، ساختار کد ضعیف است اما شما هنوز می‌دانید چه اتفاقی در حال رخ دادن است؛ در حالی که در بدهی شناختی، درک شما از سیستم تحلیل می‌رود. «فهمیدن» در واقع سوختِ اصلی برای برداشتن قدم‌های خلاقانه بعدی است. وقتی این بدهی زیاد شود، شما توانایی مشارکت فعال در پروژه را از دست می‌دهید.«زمانی می‌رسد که متوجه می‌شوید هیچ ایده‌ای ندارید در لایه‌های زیرین چه می‌گذرد و عملاً دیگر نمی‌توانید در پروژه مشارکت کنید؛ چرا که بدهی شناختی شما از حد مجاز فراتر رفته است.»تغییر پارادایم: فهمیدن برای مشارکت، نه فقط برای تأییدبسیاری تصور می‌کنند ما باید کد را بفهمیم تا فقط «صحت» (Correctness) آن را چک کنیم. اما حقیقت این است که هوش مصنوعی در بررسی صحت کدها (تطبیق با مستندات یا تست‌ها) روز به روز قوی‌تر می‌شود و نقش انسان در این بخش در حال کم‌رنگ شدن است.تفاوت بنیادین در اینجاست:بررسی صحت (Correctness Checking): یک تصمیم صفر و یکی (تأیید یا رد) که هوش مصنوعی در آن عالی عمل می‌کند.فهمیدن برای مشارکت (Understanding to Participate): ایجاد «ساختارهای مفهومی غنی» در ذهن که به مهندس اجازه می‌دهد ایده‌های جدید خلق کند و به صورت سیال، جهش‌های خلاقانه داشته باشد.بدون فهم عمیق، شما صرفاً اپراتوری هستید که دکمه تایید را فشار می‌دهد، نه سازنده‌ای که آینده پروژه را ترسیم می‌کند.تکنیک اول: تبدیلِ Diffهای خشک کد به مستندات آموزشی شخصی‌سازی شدهیکی از روش‌های جفری لیت برای مقابله با شکاف درک، استفاده از ابزار "Explain Diff" است. هوش مصنوعی می‌تواند به جای نشان دادن تغییرات خام فایل‌ها (Code Diff)، یک «برنامه درسی شخصی‌سازی شده» برای آن تغییر ایجاد کند:پیش‌زمینه (Background): سیستم قبل از این تغییر دقیقاً چگونه کار می‌کرد؟شهود قبل از جزئیات (Intuition before details): هدف مفهومی چیست؟ مثلاً در پروژه «باغ ذن» (Zen Garden)، هدف تغییر نمای بازی از بالا به پایین به ایزومتریک با ترفندهای ۲ بعدی بود.فیگورهای تعاملی (Interactive Figures): هوش مصنوعی می‌تواند ابزارهای بصری کوچکی بسازد که در آن بتوانید با کشیدن سنگ‌ها در محیط بازی، تغییرات لحظه‌ای مختصات و لایه‌های Z را حس کنید.کدنویسی ادیبانه (Literate Code): ارائه کد به همراه توضیحات روایی و داستانی (توضیح کد به زبان روایی) که منطق تغییرات را بازگو می‌کند.تکنیک دوم: آزمون‌ها، تنظیم‌کننده‌های سرعتِ یادگیریخواندن به تنهایی معمولاً منجر به «توهمِ فهمیدن» می‌شود. جفری لیت با الهام از مقاله‌ی معروف اندی ماتوشاک و مایکل نیلسن با عنوان "Books don't work"، از ایده «تکرار فاصله‌دار» (Spaced Repetition) استفاده می‌کند.او از ایجنت هوش مصنوعی می‌خواهد که در انتهای هر توضیح کد، یک کویز تعاملی شامل ۵ سوال با درجه سختی متوسط طراحی کند. این آزمون‌ها مانند یک «تنظیم‌کننده سرعت» عمل می‌کنند تا مطمئن شوید با سرعتِ «تأیید کردن» پیش نمی‌روید، بلکه با سرعتِ «یادگیری» حرکت می‌کنید. قانون طلایی: هیچ کدی برای بازبینی (Review) به تیم ارسال نمی‌شود، مگر اینکه برنامه‌نویس بتواند در آزمونِ ساخته شده توسط ایجنت، نمره قبولی بگیرد.تکنیک سوم: میکرو-ورلدها و بازگشت به رویای آلن کیمفهوم «میکرو-ورلدها» (Micro-worlds) ریشه در ایده «مات‌لند» (Mathland) سیمور پاپرت دارد؛ محیطی که در آن یادگیری مفاهیم، مثل یادگیری زبان در یک کشور غریبه، به‌صورت غریزی اتفاق می‌افتد.جفری لیت نشان داد که چگونه هوش مصنوعی می‌تواند «رابط‌های کاربری موقت» (Ephemeral UI) یا دیباگرهای بصری خاص بسازد. او برای درک بهتر یک مفسر زبان پرولوگ (Prolog)، از هوش مصنوعی خواست ابزاری بسازد که وضعیت داخلی سیستم را در هر گام روی یک تایم‌لاین بصری نمایش دهد. این دقیقاً تحقق رویای آلن کی است که کامپیوتر را ابزاری برای ارتقای توانمندی‌های فکری انسان می‌دید، نه جایگزینی برای آن.قدرت‌مندتر شدن انسان، نه حذف او از چرخهما در دورانی هستیم که تولید کد تقریباً «رایگان» شده است. در این بازارِ فراوانی، ما باید «ثروت» خود را به جای تولید کد بیشتر، صرفِ «فهمِ عمیق‌تر» کنیم. هوش مصنوعی نباید ما را از چرخه خارج کند، بلکه باید با ساختن ابزارهای آموزشی، شبیه‌سازها و محیط‌های تعاملی، ما را عمیق‌تر از همیشه در مرکز چرخه خلاقیت قرار دهد.در دنیایی که نوشتن کد دیگر مزیتی محسوب نمی‌شود، شما چگونه از ابزارهای هوش مصنوعی برای ارتقای درک و خلاقیت خود استفاده می‌کنید؟ آیا از سرعتِ هوش مصنوعی برای فرار از یادگیری استفاده می‌کنید، یا برای عمیق‌تر شدن در قلب سیستم؟فرزینفرزینThu, 27 Aug 2026 09:23:05 +0330https://virgool.ir/@farziin/چرا-رویکرد-specs-to-code-معمولاً-شکست-می-خورد-نگاهی-به-workflow-مت-پاوکاک-برای-توسعه-نرم-افزار-با-هوش-مصنوعی-iqo7lsueigxzاگر مدتی با ابزارهایی مثل ChatGPT، Claude یا Gemini کدنویسی کرده باشید، احتمالاً این تجربه برایتان آشناست: یک پرامپت طولانی و دقیق می‌نویسید، همه نیازمندی‌ها را توضیح می‌دهید و انتظار دارید در چند دقیقه یک قابلیت کامل تحویل بگیرید. اما نتیجه معمولاً آن چیزی نیست که انتظارش را داشتید. بخشی از کد درست است، بخشی دیگر با معماری پروژه هم‌خوانی ندارد، چند تصمیم اشتباه گرفته شده و هرچه گفتگو جلوتر می‌رود، احساس می‌کنید مدل بیشتر از قبل مسیر را گم می‌کند.مت پاوکاک (Matt Pocock) در کارگاه Workflow for AI Coding معتقد است مشکل از مدل‌ها نیست؛ مشکل از روشی است که ما با آن‌ها کار می‌کنیم. از نگاه او، هوش مصنوعی پارادایم جدیدی برای مهندسی نرم‌افزار نساخته است؛ بلکه باعث شده اهمیت همان اصول قدیمی مهندسی نرم‌افزار بیشتر از قبل شود.در واقع، تمام Workflow پیشنهادی او بر یک ایده ساده بنا شده است:مدل‌های زبانی حافظه و مدل ذهنی پایدار ندارند. آن‌ها فقط Context فعلی را می‌بینند. بنابراین اگر Context را درست مدیریت نکنیم، کیفیت خروجی به‌تدریج افت می‌کند.تقریباً تمام پیشنهادهای پاوکاک را می‌توان نتیجه همین محدودیت دانست.۱. قبل از نوشتن کد، روی درک مسئله توافق کنیدیکی از رایج‌ترین اشتباهات، استفاده از رویکرد Specs to Code است؛ یعنی یک سند طولانی از نیازمندی‌ها را به مدل بدهیم و از آن بخواهیم مستقیماً کد تولید کند.در نگاه اول این روش منطقی به نظر می‌رسد، اما معمولاً نتیجه خوبی ندارد. دلیلش این است که مطمئن نیستیم مدل مسئله را دقیقاً همان‌طور که ما در ذهن داریم فهمیده باشد. اگر برداشت اولیه اشتباه باشد، تمام کدی که بعداً تولید می‌شود نیز بر همان برداشت اشتباه بنا خواهد شد.به همین دلیل پاوکاک از روشی به نام Grill Me استفاده می‌کند.در این روش، به جای اینکه مدل فوراً کدنویسی را شروع کند، از او می‌خواهیم ابتدا ما را «سؤال‌پیچ» کند. هر ابهامی را پیدا کند، فرضیاتش را بیان کند، سناریوهای مختلف را بررسی کند و حتی مسئله را با زبان خودش توضیح دهد. هدف این نیست که چند سؤال بپرسد؛ هدف این است که انسان و مدل به یک تصویر مشترک از مسئله برسند.تا زمانی که این درک مشترک (Shared Understanding) شکل نگرفته، هنوز زمان مناسبی برای نوشتن کد نیست.۲. درک مشترک را به یک مرجع تبدیل کنیدوقتی انسان و مدل به درک مشترکی از مسئله رسیدند، نباید آن را فقط در تاریخچه چت رها کرد.پاوکاک پیشنهاد می‌کند این توافق در قالب یک PRD (Product Requirements Document) ثبت شود. منظور او یک سند طولانی و رسمی نیست؛ بلکه سندی است که هدف پروژه، محدودیت‌ها، رفتار مورد انتظار سیستم و تصمیم‌های مهم را ثبت می‌کند تا بعداً هم انسان و هم هوش مصنوعی بتوانند به آن مراجعه کنند.به این ترتیب، هر بار لازم نیست همه چیز را دوباره توضیح بدهید و احتمال تغییر تدریجی برداشت مدل نیز کمتر می‌شود.۳. پروژه را به برش‌های عمودی تقسیم کنید، نه لایه‌های افقیبعد از مشخص شدن مقصد، نوبت اجرای پروژه است.اینجا یکی دیگر از اشتباهات رایج رخ می‌دهد. بسیاری از ما پروژه را به شکل افقی پیش می‌بریم؛ ابتدا دیتابیس، سپس API، بعد رابط کاربری و در نهایت اتصال همه آن‌ها به یکدیگر.مشکل این روش این است که ممکن است ساعت‌ها یا حتی روزها کد بنویسید، بدون اینکه بتوانید یک قابلیت کامل را اجرا و ارزیابی کنید.پاوکاک پیشنهاد می‌کند پروژه را به Vertical Slice یا Tracer Bullet تقسیم کنیم.یعنی هر مرحله، یک قابلیت کوچک اما کامل را از ابتدا تا انتها پیاده‌سازی کنیم؛ از رابط کاربری گرفته تا منطق برنامه و پایگاه داده. این کار دو مزیت مهم دارد: اول اینکه خیلی زود متوجه می‌شوید آیا مسیر درستی را انتخاب کرده‌اید یا نه، و دوم اینکه هر وظیفه برای هوش مصنوعی کوچک‌تر و متمرکزتر می‌شود. هرچه Context محدودتر باشد، احتمال انحراف مدل نیز کمتر خواهد بود.۴. اگر می‌خواهید بخشی از کار را به AI بسپارید، تست‌ها باید راهنما باشندیکی از ایده‌های جالب پاوکاک این است که فرآیند توسعه را به دو شیفت تقسیم می‌کند.در Day Shift، انسان درباره طراحی، معماری و تصمیم‌های مهم فکر می‌کند. در Night Shift، هوش مصنوعی یا Agentها وظایف مشخصی را که از قبل تعریف شده‌اند انجام می‌دهند؛ حتی زمانی که شما پشت سیستم نیستید.اما این مدل فقط زمانی قابل اعتماد است که پروژه تست‌های خوبی داشته باشد.از نگاه پاوکاک، تست‌ها فقط ابزاری برای پیدا کردن باگ نیستند؛ آن‌ها نقش قطب‌نما را برای هوش مصنوعی بازی می‌کنند. مدل از روی تست‌ها متوجه می‌شود رفتار صحیح سیستم چیست و آیا تغییری که ایجاد کرده، قابل قبول است یا نه.به همین دلیل او روی توسعه تست‌محور (TDD) تأکید می‌کند. در این رویکرد، مدل ابتدا تست را می‌بیند، سپس کد را برای عبور از آن تست می‌نویسد و در پایان کد را بازآرایی می‌کند. این چرخه باعث می‌شود حتی در اجرای خودکار نیز احتمال انحراف کمتر شود.۵. معماری خوب، فقط برای انسان‌ها نیستیکی از بخش‌های جذاب این کارگاه، ارجاع پاوکاک به کتاب Philosophy of Software Design است.او توضیح می‌دهد که معماری خوب فقط به توسعه‌دهندگان کمک نمی‌کند؛ بلکه کار هوش مصنوعی را هم ساده‌تر می‌کند.به‌جای اینکه سیستم از تعداد زیادی ماژول کوچک با مسئولیت‌های پراکنده تشکیل شده باشد، بهتر است از Deep Modules استفاده کنیم؛ ماژول‌هایی که رابط ساده‌ای دارند اما پیچیدگی داخلی را درون خود پنهان کرده‌اند.برای مثال، ممکن است فقط یک متد به نام processPayment() داشته باشید، اما تمام جزئیات مربوط به اعتبارسنجی، ثبت لاگ، مدیریت خطا، تلاش مجدد و ارتباط با درگاه پرداخت در داخل همان ماژول مدیریت شود.در این حالت، انسان و هوش مصنوعی هر دو فقط با یک Interface ساده سروکار دارند و لازم نیست هم‌زمان ده‌ها جزئیات مختلف را در ذهن نگه دارند. این دقیقاً همان چیزی است که مدیریت Context را آسان‌تر می‌کند.۶. در نهایت، چیزی باقی می‌ماند که قابل واگذاری نیستبا وجود تمام پیشرفت‌های هوش مصنوعی، پاوکاک معتقد است آخرین مرحله توسعه همچنان باید در اختیار انسان باقی بماند.او این بخش را Taste می‌نامد.ممکن است همه تست‌ها سبز باشند و هیچ خطای فنی وجود نداشته باشد، اما هنوز سؤال‌های مهمی باقی می‌ماند:آیا این API واقعاً طراحی خوبی دارد؟آیا نام‌گذاری‌ها واضح و قابل فهم هستند؟آیا این تجربه کاربری لذت‌بخش است؟آیا این راه‌حل همان چیزی است که اگر یک سال دیگر به پروژه برگردیم، هنوز از آن دفاع خواهیم کرد؟این‌ها سؤال‌هایی هستند که پاسخشان فقط از روی تست‌ها به دست نمی‌آید. اینجا تجربه، سلیقه و قضاوت مهندسی انسان وارد میدان می‌شود.جمع‌بندیشاید مهم‌ترین نکته‌ای که از این کارگاه می‌توان یاد گرفت این باشد که استفاده حرفه‌ای از هوش مصنوعی، بیش از آنکه به نوشتن پرامپت‌های پیچیده وابسته باشد، به مدیریت صحیح Context وابسته است.وقتی مسئله را به‌درستی درک می‌کنیم، آن را مستند می‌کنیم، پروژه را به بخش‌های کوچک‌تر تقسیم می‌کنیم، تست‌های قابل اعتماد می‌نویسیم و معماری مناسبی طراحی می‌کنیم، هوش مصنوعی به ابزاری بسیار قدرتمند تبدیل می‌شود.اما اگر انتظار داشته باشیم با یک پرامپت چندصفحه‌ای تمام پروژه را به مدل بسپاریم، معمولاً نتیجه چیزی نخواهد بود جز کدی که در ظاهر کار می‌کند، اما در عمل نگهداری و توسعه آن دشوار است.شاید به همین دلیل باشد که پاوکاک در پایان کارگاه می‌گوید آینده مهندسی نرم‌افزار کمتر درباره «کدنویسی بیشتر» است و بیشتر درباره «تصمیم‌های بهتر» خواهد بود؛ تصمیم‌هایی که هنوز مسئولیت آن‌ها بر عهده انسان است.فرزینفرزینTue, 11 Aug 2026 10:42:41 +0330