Copilot با حالت Planning حالا یک هم‌معمار است!

بله، حتماً. این یک تحلیل جامع و کامل از قابلیت جدید “Planning Mode” در GitHub Copilot و پیامدهای آن برای آینده توسعه نرم‌افزار است. این مقاله، ضمن استفاده از مقاله مرجع، با اطلاعات تکمیلی و تحلیل عمیق‌تر از منابع مختلف غنی شده است.

عنوان: انقلاب خاموش در کدنویسی: چگونه Copilot با “حالت برنامه‌ریزی” از یک دستیار به یک معمار تبدیل می‌شود

مقدمه: عبور از تکمیل خودکار، ورود به عصر عاملیت (Agency)

دنیای توسعه نرم‌افزار در آستانه‌ی یک دگرگونی بنیادین قرار دارد. ابزارهایی که تا دیروز تنها به عنوان «دستیارهای کدنویسی» (Coding Assistants) شناخته می‌شدند و در بهترین حالت، خطوط بعدی کد ما را حدس می‌زدند، امروز در حال تبدیل شدن به «عامل‌های نرم‌افزاری» (Software Agents) هوشمند هستند. این عامل‌ها دیگر منتظر دستور خط‌به‌خط ما نمی‌مانند؛ آن‌ها هدف نهایی ما را درک می‌کنند، برای رسیدن به آن برنامه‌ریزی می‌کنند و اجرای آن برنامه را بر عهده می‌گیرند.

در مرکز این تحول، ابزاری قرار دارد که بیش از هر پلتفرم دیگری، نبض جامعه توسعه‌دهندگان را در دست گرفته است: GitHub Copilot. اما این Copilot، دیگر آن دستیار ساده‌ای نیست که دو سال پیش می‌شناختیم. مایکروسافت و GitHub در رویداد Build اخیر، از قابلیتی رونمایی کردند که به سادگی می‌تواند نقطه‌ی عطفی در تاریخ مهندسی نرم‌افزار باشد: “Planning Mode” (حالت برنامه‌ریزی) برای Copilot در محیط Visual Studio.

مقاله منتشر شده در DevOps.com با عنوان «Visual Studio Copilot برای وظایف پیچیده به حالت برنامه‌ریزی مجهز می‌شود»، به خوبی این خبر را پوشش داده است. اما اهمیت این خبر فراتر از یک به‌روزرسانی نرم‌افزاری ساده است. این یک تغییر پارادایم است. این اعلامیه‌ای است مبنی بر اینکه Copilot از نقش “جفت-برنامه‌نویس” (Pair Programmer) به نقش “معمار پروژه” (Project Architect) یا “مدیر فنی” (Tech Lead) ارتقا یافته است.

در این مقاله جامع، ما به کالبدشکافی عمیق این قابلیت جدید خواهیم پرداخت. ابتدا بررسی می‌کنیم که نسل اول Copilot چه محدودیت‌هایی داشت که چنین قابلیتی را ضروری می‌کرد. سپس، با استفاده از مقاله مرجع و جستجوی عمیق‌تر در اسناد مایکروسافت و تحلیل‌های کارشناسان، به این می‌پردازیم که “Planning Mode” دقیقاً چیست، چگونه کار می‌کند، و چه تفاوت اساسی با ابزارهای مشابه مانند “Copilot Workspace” دارد. در نهایت، پیامدهای عمیق این فناوری را بر چرخه‌ی عمر توسعه نرم‌افزار (SDLC)، مهارت‌های مورد نیاز توسعه‌دهندگان، و آینده‌ی خودکارسازی در DevOps تحلیل خواهیم کرد.

فصل اول: عصر معصومیت؛ محدودیت‌های نسل اول Copilot

برای درک اهمیت “Planning Mode”، ابتدا باید به یاد بیاوریم که چرا به آن نیاز داشتیم. GitHub Copilot اصلی، که اکنون می‌توان آن را “Copilot کلاسیک” نامید، یک ابزار شگفت‌انگیز در “تکمیل کد” (Code Completion) بود. این ابزار بر اساس مدل‌های زبانی بزرگ (LLM) آموزش‌دیده بر روی میلیاردها خط کد عمومی، می‌توانست قطعه کدهای (snippets) بسیار دقیقی تولید کند، توابع کامل بنویسد و حتی الگوهای طراحی را بر اساس چند خط کامنت پیاده‌سازی کند.

اما این شگفتی، محدودیت‌های بزرگی داشت:

1. فقدان آگاهی از زمینه (Context Blindness): بزرگترین ضعف Copilot کلاسیک، “پنجره‌ی زمینه” (Context Window) محدود آن بود. این ابزار در بهترین حالت، تنها چند هزار توکن (معادل چند صفحه کد) را به عنوان ورودی می‌پذیرفت. این به آن معنا بود که Copilot از فایل‌هایی که در حال حاضر باز نبودند، از ساختار کلی پروژه، از وابستگی‌های بین ماژول‌ها و از منطق تجاری پنهان در سایر بخش‌های اپلیکیشن، تقریباً هیچ اطلاعی نداشت.
2. خوب برای “یک فایل”، بد برای “یک پروژه”: در نتیجه‌ی این فقدان آگاهی، Copilot برای نوشتن یک تابع مستقل عالی بود، اما برای انجام یک “کار” (Task) واقعی، فاجعه‌بار عمل می‌کرد. یک کار واقعی در مهندسی نرم‌افزار، مانند “اضافه کردن قابلیت پرداخت با پی‌پال به سبد خرید”، نیازمند تغییر در چندین فایل است:
   • تغییر در مدل داده (Database Model)
   • نوشتن یک سرویس جدید (Service Layer)
   • ایجاد یک API Endpoint جدید (Controller)
   • به‌روزرسانی رابط کاربری (UI Component)
   • نوشتن تست‌های واحد و یکپارچگی (Tests)

   Copilot کلاسیک در انجام چنین وظیفه چندلایه‌ای کاملاً ناتوان بود.

3. توهم در مقیاس بزرگ (Large-Scale Hallucination): وقتی از Copilot خواسته می‌شد کاری فراتر از دانش محدودش انجام دهد، شروع به “توهم زدن” (Hallucinate) می‌کرد. این توهمات شامل ابداع نام توابع، حدس زدن ساختارهای API، و ایجاد کدهایی بود که اگرچه به نظر منطقی می‌رسیدند، اما در چارچوب واقعی پروژه، کاملاً اشتباه بودند.

اینجا بود که توسعه‌دهندگان به یک “دیوار شناختی” برخورد کردند. Copilot بهره‌وری را در کارهای خرد به شدت افزایش داده بود، اما بار شناختی (Cognitive Load) کارهای کلان و معماری همچنان بر دوش توسعه‌دهنده بود. توسعه‌دهنده باید خود، وظیفه را به ده‌ها قطعه‌ی کوچک تقسیم می‌کرد، به فایل‌های مختلف می‌رفت، و تازه آنجا از Copilot برای تکمیل هر قطعه‌ی کوچک کمک می‌گرفت.

این دقیقاً همان نقطه‌ای است که “Planning Mode” برای پر کردن آن طراحی شده است.

فصل دوم: رونمایی از معمار؛ “Planning Mode” چیست؟

همانطور که در مقاله DevOps.com به نقل از آماندا سیلور، نایب رئیس بخش ابزارهای توسعه مایکروسافت، اشاره شده است، “Planning Mode” پاسخی به نیاز مدیریت “وظایfی بزرگ و پیچیده” است. این قابلیت، Copilot را از یک ابزار واکنشی (Reactive) به یک ابزار کنش‌گر (Proactive) تبدیل می‌کند.

“Planning Mode” یک قابلیت جدید در GitHub Copilot Chat در محیط Visual Studio است که به هوش مصنوعی اجازه می‌دهد قبل از نوشتن حتی یک خط کد، یک “نقشه‌ی راه” یا “طرح اجرایی” (Execution Plan) ایجاد کند.

فرآیند کار به این شکل است:

1. درک هدف (Intent Analysis): توسعه‌دهنده دیگر یک دستور ساده مانند “یک تابع برای مرتب‌سازی بنویس” نمی‌دهد. بلکه یک هدف سطح بالا (High-Level Goal) را مطرح می‌کند. برای مثال: “قابلیت ‘فراموشی رمز عبور’ را با استفاده از ارسال ایمیل پیاده‌سازی کن.”
2. تحلیل کل پروژه (Full Solution Analysis): اینجا جادوی واقعی اتفاق می‌افتد. Copilot به جای نگاه کردن به فایل فعلی، کل پروژه (Solution) را تحلیل می‌کند. این فرآیند احتمالاً از طریق ترکیب دو تکنیک قدرتمند انجام می‌شود:
   • درخت نحو مجرد (AST – Abstract Syntax Tree): Copilot کل کدبیس را تجزیه (Parse) می‌کند تا ساختار، روابط بین کلاس‌ها، و جریان داده را بفهمد.
   • تولید افزوده بازیابی (RAG – Retrieval-Augmented Generation): هوش مصنوعی، کدبیس پروژه را به عنوان یک پایگاه دانش محلی ایندکس می‌کند. این به آن اجازه می‌دهد تا “جستجو” کند و بفهمد که مثلاً “سرویس ایمیل” در کجای پروژه تعریف شده یا “مدل کاربر” (User Model) چه فیلدهایی دارد.
3. ایجاد طرح (Plan Generation): بر اساس هدف کاربر و تحلیل پروژه، Copilot یک طرح گام‌به‌گام دقیق ارائه می‌دهد. این طرح دیگر یک متن ساده نیست، بلکه یک لیست وظایف (Task List) ساختاریافته است که دقیقاً مشخص می‌کند:
   • “گام ۱: افزودن فیلد ResetToken به کلاس User در فایل Models/User.cs.”
   • “گام ۲: ایجاد متد GeneratePasswordResetToken در Services/AuthService.cs.”
   • “گام ۳: ایجاد یک API Endpoint جدید POST /api/auth/forgot-password در Controllers/AuthController.cs.”
   • “گام ۴: افزودن یک تست واحد جدید برای AuthService در Tests/AuthServiceTests.cs.”
4. بررسی و اصلاح توسط انسان (Human-in-the-Loop Review): این مهم‌ترین بخش است. Copilot خودسرانه عمل نمی‌کند. این طرح به توسعه‌دهنده ارائه می‌شود. توسعه‌دهنده اکنون در نقش یک “مدیر” قرار می‌گیرد. او می‌تواند:
   • طرح را تأیید کند (Approve).
   • گام‌هایی را حذف یا اضافه کند (Modify).
   • جزئیات یک گام را اصلاح کند (Edit).
   • یا کل طرح را رد کند (Reject).
5. اجرای طرح (Plan Execution): پس از تأیید توسعه‌دهنده، Copilot به صورت خودکار و هوشمند، تمام گام‌ها را اجرا می‌کند. این شامل باز کردن فایل‌های مختلف، اعمال تغییرات، و سپس بازگشت به توسعه‌دهنده برای تأیید نهایی (معمولاً از طریق یک diff view) است.

تفاوت کلیدی با Copilot Workspace:

لازم است بین “Planning Mode” در Visual Studio و “Copilot Workspace” (فضای کاری Copilot) تمایز قائل شویم. “Copilot Workspace” که به عنوان یک محیط مستقل و مبتنی بر وب معرفی شد، بیشتر بر روی فاز قبل از کدنویسی تمرکز دارد. Workspace جایی است که شما یک Issue (مسئله) از GitHub را به آن می‌دهید و هوش مصنوعی یک مشخصات فنی (Specification) و یک طرح کلی برای حل آن ارائه می‌دهد، که بعداً باید به کد تبدیل شود.

اما “Planning Mode” در Visual Studio یک ابزار در حین کدنویسی و به شدت عملیاتی است. این ابزار مستقیماً با کدبیس زنده شما کار می‌کند، فایل‌ها را می‌خواند و مستقیماً کد را تغییر می‌دهد. این یک “عامل اجرایی” (Executor Agent) است، نه فقط یک “مشاور” (Consultant).

فصل سوم: از LLM به عامل؛ کالبدشکافی فنی “Planning Mode”

مایکروسافت با معرفی “Planning Mode” نشان داد که عصر مدل‌های زبانی بزرگ (LLM) به تنهایی رو به پایان است و عصر “عامل‌های هوشمند” (AI Agents) آغاز شده است. یک LLM مانند GPT-4، یک مغز بدون دست و پا است. اما “Planning Mode” یک عامل است؛ مغزی (LLM) که به ابزارها (Tools) و حافظه (Memory) مجهز شده است.

1. معماری عامل (Agentic Architecture):

“Planning Mode” به وضوح از یک معماری عامل مانند ReAct (Reasoning + Acting) یا چارچوب‌های مشابه (مانند Semantic Kernel مایکروسافت) استفاده می‌کند.

• Reasoning (استدلال): این همان فرآیند “ایجاد طرح” است. LLM به جای تولید مستقیم کد، ابتدا “فکر می‌کند” و یک زنجیره‌ی منطقی از اقدامات (Chain of Thought) تولید می‌کند. این همان طرحی است که ما می‌بینیم.
• Acting (اقدام): این بخش حیاتی است. LLM به مجموعه‌ای از “ابزارها” یا “APIها” دسترسی دارد. این ابزارها دیگر فقط generate_code() نیستند، بلکه عبارتند از:
  • read_file(path)
  • write_file(path, content)
  • list_solution_files()
  • get_class_definition(className)
  • find_references(functionName)

وقتی ما طرح را تأیید می‌کنیم، LLM در واقع مجموعه‌ای از این ابزارها را به ترتیب فراخوانی می‌کند تا تغییرات را در سراسر پروژه اعمال کند.

2. حافظه و زمینه (Memory and Context):

همانطور که اشاره شد، کلید موفقیت این سیستم، توانایی آن در درک کل پروژه است. این کار از طریق RAG (تولید افزوده بازیابی) انجام می‌شود. Visual Studio یا یک سرویس پشتیبان، به طور مداوم کدبیس شما را “ایندکس” می‌کند. این فرآیند، کد شما را به “بردارها” (Embeddings) تبدیل می‌کند که نمایش‌های ریاضی از معنای کد هستند.

وقتی شما درخواستی مانند “اضافه کردن لاگین با گوگل” را مطرح می‌کنید، سیستم ابتدا در این پایگاه داده برداری جستجو می‌کند تا “فایل‌های مرتبط با احراز هویت” را پیدا کند. سپس این فایل‌ها را به عنوان “زمینه” (Context) به LLM می‌دهد و می‌گوید: “با توجه به این فایل‌ها، لطفاً یک طرح برای اضافه کردن لاگین گوگل ارائه بده.”

این فرآیند، مشکل “پنجره زمینه محدود” را به طور کامل حل می‌کند و به Copilot حافظه‌ای بلندمدت از کل پروژه شما می‌بخشد.

3. حلقه بازخورد انسانی (The Human-in-the-Loop):

این شاید هوشمندانه‌ترین بخش طراحی مایکروسافت باشد. در حالی که رقبایی مانند “Devin” (که توسط Cognition Labs معرفی شد) ادعای یک “مهندس نرم‌افزار کاملاً خودکار” را داشتند، رویکرد مایکروسافت بسیار واقع‌بینانه‌تر و ایمن‌تر است.

مایکروسافت می‌داند که هوش مصنوعی هنوز و به طور مداوم اشتباه می‌کند. یک هوش مصنوعی خودکار که بدون نظارت، تغییرات بزرگی در کدبS شما ایجاد کند، یک کابوس امنیتی و پایداری است.

“Planning Mode” با قرار دادن توسعه‌دهنده در نقش “ناظر طرح” (Plan Reviewer)، بهترین‌های هر دو دنیا را ترکیب می‌کند:

• سرعت و مقیاس هوش مصنوعی: برای تجزیه و تحلیل کل پروژه و تولید سریع طرح و کد.
• قضاوت و شهود انسانی: برای تأیید صحت منطق تجاری، امنیت، و معماری طرح قبل از اجرا.

این رویکرد “انسان-در-حلقه” (HITL) نه تنها اعتماد را به شدت افزایش می‌دهد، بلکه فرآیند توسعه را به یک “همکاری” (Collaboration) واقعی بین انسان و ماشین تبدیل می‌کند، نه یک “واگذاری” (Delegation) پرخطر.

فصل چهارم: تغییر اقیانوس؛ پیامدهای “Planning Mode” برای توسعه‌دهندگان و DevOps

معرفی ابزاری که می‌تواند وظایف پیچیده و چندفایلی را برنامه‌ریزی و اجرا کند، صرفاً یک بهبود در بهره‌وری نیست؛ این یک تغییر در خودآگاهی صنعت نرم‌افزار است.

1. ارتقاء اجباری: از “کدنویس” به “معمار”

“Planning Mode” شغل توسعه‌دهنده را از بین نمی‌برد، اما آن را برای همیشه تغییر می‌دهد. ارزش یک توسعه‌دهنده به سرعت از “توانایی نوشتن کد” به “توانایی تفکر سیستمی” در حال انتقال است.

• مهارت‌های در حال افول:
  • به خاطر سپردن سینتکس‌های پیچیده.
  • نوشتن کدهای روتین و تکراری (Boilerplate).
  • جستجوی دستی در کدبیس برای یافتن فایل‌ها.
• مهارت‌های در حال صعود:
  • مهندسی اهداف (Intent Engineering): توانایی بیان یک نیاز پیچیده تجاری به زبان طبیعی و واضح برای هوش مصنوعی.
  • بررسی بحرانی (Critical Review): توانایی خواندن “طرح” تولید شده توسط هوش مصنوعی و تشخیص سریع نقص‌های معماری، حفره‌های امنیتی، و ناسازگاری‌های منطقی.
• تفکر در سطح انتزاع (Abstraction): توسعه‌دهنده کمتر درگیر جزئیات پیاده‌سازی و بیشتر درگیر “چگونگی اتصال سیستم‌ها” خواهد بود.

در واقع، Copilot توسعه‌دهنده را از “کارگر خط تولید” به “ناظر کیفیت و طراح” ارتقا می‌دهد.

2. انقلاب در چرخه‌ی عمر توسعه نرم‌افزار (SDLC)

“Planning Mode” کل چرخه SDLC را دگرگون می‌کند:

• Onboarding (ورود نیروهای جدید): یک توسعه‌دهنده‌ی تازه‌کار دیگر نیازی ندارد هفته‌ها صرف یادگیری کدبیس شود. او می‌تواند بپرسد: “من باید یک اندپوینت برای گزارش‌گیری کاربران اضافه کنم. لطفاً یک طرح برای انجام این کار در این پروژه ارائه بده.” Copilot به او یک تور کامل و عملی در مورد اینکه کدام فایل‌ها باید تغییر کنند، ارائه می‌دهد.
• Refactoring (بازآفرینی کد): کارهایی که قبلاً ماه‌ها طول می‌کشید، اکنون در چند ساعت قابل انجام است. تصور کنید دستوری مانند: “طرحی برای مهاجرت تمام دسترسی‌های پایگاه داده در این پروژه از ADO.NET به Entity Framework Core ارائه بده.” یا “طرحی برای افزودن Caching به تمام متدهای سرویس ProductService ارائه بده.” این سطح از خودکارسازی در بازآفرینی، قبلاً علمی-تخیلی محسوب می‌شد.
• Testing (تست‌نویسی): نوشتن تست‌های واحد، که اغلب توسط توسعه‌دهندگان نادیده گرفته می‌شود، می‌تواند به طور کامل خودکار شود. “طرحی برای ایجاد پوشش تست کامل (Full Test Coverage) برای کلاس AuthService ارائه بده.”
• Debugging (اشکال‌زدایی): به جای خواندن لاگ‌های خطا، توسعه‌دهنده می‌تواند بگوید: “این StackTrace خطا است. پروژه را تحلیل کن و طرحی برای رفع این باگ ارائه بده.”

3. پیامدها برای DevOps و “Devin”

معرفی “Planning Mode” یک پاسخ مستقیم و کوبنده به هیاهوی ایجاد شده توسط عامل‌های خودکاری مانند “Devin” بود. در حالی که Devin با ادعای خودکارسازی کامل، نگرانی‌هایی را در مورد جایگزینی انسان ایجاد کرد، رویکرد مایکروسافت بسیار هوشمندانه‌تر است.

“Planning Mode” نشان می‌دهد که آینده‌ی کوتاه‌مدت، “خودکارسازی کامل” نیست، بلکه “همکاری در مقیاس” (Scaled Collaboration) است.

اما این قابلیت، پتانسیل ورود به فازهای بعدی DevOps را نیز دارد:

• CI/CD هوشمند: تصور کنید بیلد (Build) شما در خط لوله CI/CD با شکست مواجه می‌شود. در آینده، به جای ارسال یک ایمیل خطا به توسعه‌دهنده، Agent می‌تواند فعال شود، خطا را تحلیل کند، طرحی برای رفع آن ایجاد کند، و آن طرح را برای بررسی به توسعه‌دهنده ارسال کند.
• IaC (زیرساخت به عنوان کد): همین منطق برنامه‌ریزی می‌تواند برای کارهای زیرساختی اعمال شود. “طرحی برای استقرار این اپلیکیشن در یک کلاستر Kubernetes جدید با سه نود و یک Load Balancer ارائه بده.”

فصل پنجم: جعبه پاندورا؛ ریسک‌ها و چالش‌های آینده

علی‌رغم تمام هیجان موجود، “Planning Mode” یک جعبه پاندورای جدید را باز می‌کند. سپردن وظایف پیچیده به هوش مصنوعی، ریسک‌های جدیدی را معرفی می‌کند که باید به طور جدی مدیریت شوند.

1. توهم در مقیاس معماری (Architectural-Scale Hallucination):

ما از توهمات در سطح خط کد (Line-Level Hallucination) نگران بودیم؛ اکنون باید نگران توهمات در سطح سیستم باشیم. اگر هوش مصنوعی یک طرح اشتباه ارائه دهد چه؟ اگر یک الگوی طراحی ضعیف را انتخاب کند؟ یا اگر یک تغییر ساده را به روشی بسیار پیچیده و ناکارآمد برنامه‌ریزی کند؟

بار مسئولیتی که اکنون بر دوش “بررسی‌کننده‌ی طرح” (انسان) قرار دارد، بسیار سنگین‌تر از قبل است. یک اشتباه در این مرحله می‌تواند به جای یک باگ ساده، منجر به بدهی فنی (Technical Debt) هنگفتی شود.

2. فرسایش مهارت (Skill Atrophy):

خطر واقعی و بلندمدت، “فرسایش مهارت” است. وقتی هوش مصنوعی همیشه کارهای پیچیده را انجام می‌دهد، آیا نسل بعدی توسعه‌دهندگان هرگز یاد خواهند گرفت که چگونه این کارها را خودشان انجام دهند؟ اگر یک توسعه‌دهنده جوان هرگز مجبور نباشد با چالش‌های یکپارچه‌سازی چند سیستم دست و پنجه نرم کند، آیا شهود و تجربه‌ی لازم برای تشخیص یک “طرح بد” از یک “طرح خوب” را به دست خواهد آورد؟

این یک چالش بزرگ برای آموزش و مربی‌گری در تیم‌های نرم‌افزاری ایجاد خواهد کرد.

3. ریسک‌های امنیتی و مالکیت معنوی (Security & IP Risks):

برای اینکه “Planning Mode” کار کند، باید به کل کدبیس شما دسترسی داشته باشد، آن را بخواند، تحلیل کند و به سرورهای مایکروسافت ارسال کند (هرچند که ادعا می‌شود این داده‌ها برای آموزش مدل‌های عمومی استفاده نمی‌شوند).

این سطح از دسترسی، نگرانی‌های امنیتی و مالکیت معنوی (IP) بزرگی را برای شرکت‌ها، به ویژه در صنایع حساس مانند مالی، نظامی و بهداشتی، ایجاد می‌کند. یک اشتباه در پیکربندی می‌تواند منجر به درز حساس‌ترین دارایی‌های یک شرکت شود.

علاوه بر این، اگر هوش مصنوعی “طرحی” برای افزودن یک قابلیت ارائه دهد، آیا آن طرح شامل ملاحظات امنیتی لازم (مانند اعتبارسنجی ورودی، جلوگیری از SQL Injection و …) خواهد بود؟ اعتماد کورکورانه به این طرح‌ها می‌تواند حفره‌های امنیتی جدیدی را در مقیاس وسیع ایجاد کند.

نتیجه‌گیری: توسعه‌دهنده نمرده است؛ او ارتقا یافته است

رونمایی از “Planning Mode” برای GitHub Copilot در Visual Studio، صرفاً معرفی یک قابلیت جدید نیست؛ این یک بیانیه در مورد آینده‌ی خلاقیت و مهندسی است. این پایان کار “جفت-برنامه‌نویس” و آغاز کار “تیم-معماری” (Architect-Team) متشکل از انسان و هوش مصنوعی است.

مایکروسافت با این حرکت نشان داد که مسیر آینده، نه حذف انسان، بلکه توانمندسازی او با ابزارهایی است که سطح انتزاع کاری او را بالاتر می‌برند. ما در حال ورود به عصری هستیم که در آن، ارزش یک مهندس نرم‌افزار دیگر با تعداد خط کدی که می‌نویسد سنجیده نمی‌شود، بلکه با کیفیت “اهدافی” که تعریف می‌کند و دقت “بررسی‌هایی” که انجام می‌دهد، سنجیده می‌شود.

“Planning Mode” بار شناختی عظیم “چگونه” (How) را از دوش توسعه‌دهنده برمی‌دارد و به او اجازه می‌دهد تا بر روی “چرا” (Why) تمرکز کند. این ابزار، کارهای خسته‌کننده‌ی مهندسی نرم‌افزار (Refactoring, Boilerplate, Debugging) را خودکار می‌کند تا توسعه‌دهندگان بتوانند به کارهای لذت‌بخش آن (Problem Solving, Design, Innovation) بپردازند.

آینده‌ی توسعه نرم‌افزار، نه نبرد “انسان در مقابل ماشین”، بلکه سمفونی “انسان به همراه ماشین” خواهد بود. و در این سمفونی، توسعه‌دهنده دیگر نوازنده‌ی ویولن نیست؛ او اکنون رهبر ارکستر است.