مهندسی به کمک هوش مصنوعی: سرعت بیشتر، با همان مسئولیت
ابزارهای هوش مصنوعی نوشتن کد را سریع کرده‌اند، ولی تصمیم‌گیری را نه. تیمی از این ابزارها سود می‌برد که تعریف دقیق، معماری روشن و آزمون خودکار داشته باشد. نقش انسان عوض شده، حذف نشده است.
ابزارهای هوش مصنوعی برای برنامه‌نویسی در مدت کوتاهی از یک کنجکاوی به بخشی از کار روزانه تبدیل شده‌اند. درباره‌ی آن‌ها دو روایت افراطی شنیده می‌شود: «دیگر به برنامه‌نویس نیاز نیست» و «این‌ها فقط کد بد تولید می‌کنند». هیچ‌کدام با آنچه در عمل می‌بینم جور نیست.
من ساخت محصولات را همراه تیم توسعه و با مهندسی به کمک هوش مصنوعی پیش می‌برم. این مقاله درباره‌ی این است که این روش کجا جواب می‌دهد و کجا نه.
چه چیزی عوض شده است
نوشتن کد ارزان شده است. چیزی که قبلاً یک روز طول می‌کشید، حالا می‌تواند یک ساعت طول بکشد.
اما نوشتن کد هیچ‌وقت گلوگاه اصلی نبود. گلوگاه این‌ها بودند و هستند:
- دانستن اینکه چه چیزی باید ساخته شود.
- تصمیم درباره‌ی اینکه چطور در سامانه جا بگیرد.
- اطمینان از اینکه درست کار می‌کند.
وقتی نوشتن ارزان می‌شود، ارزش این سه بیشتر می‌شود، نه کمتر.
جایی که واقعاً کمک می‌کند
- کارهای تکراری و قالبی. کدهای مشابه، تبدیل قالب‌ها، اسکلت اولیه.
- کاوش در کد ناآشنا. فهمیدن اینکه یک بخش چه می‌کند و کجاها استفاده شده است.
- نوشتن آزمون. به‌ویژه موارد مرزی که آدم یادش می‌رود.
- بازآرایی با قاعده‌ی روشن. تغییر یک الگو در ده‌ها فایل.
- مستندسازی. توضیح کد موجود.
- نمونه‌سازی سریع. امتحان کردن یک ایده پیش از تعهد به آن.
جایی که خطرناک است
- تصمیم معماری. ابزار راه‌حلی می‌دهد که کار می‌کند، نه لزوماً راه‌حلی که با بقیه‌ی سامانه جور باشد.
- امنیت. کدی که درست به نظر می‌رسد ولی اعتبارسنجی یا کنترل دسترسی را جا انداخته است.
- منطق کسب‌وکار ظریف. قاعده‌ای که فقط در ذهن کارفرماست، در هیچ کدی نیست که ابزار از آن یاد بگیرد.
- اعتماد بدون بررسی. خطرناک‌ترین حالت، پذیرفتن کدی است که خوانده نشده.
آنچه تفاوت را می‌سازد
یک ابزار، در دو تیم دو نتیجه‌ی کاملاً متفاوت می‌دهد. تفاوت در ابزار نیست؛ در چیزی است که پیش از آن وجود دارد.
تعریف دقیق
ابزار هوش مصنوعی دقیقاً همان چیزی را می‌سازد که از آن خواسته‌اید. اگر خواسته مبهم باشد، نتیجه با اطمینان کامل اشتباه است. سند نیازمندی روشن، حالا بیش از قبل اهمیت دارد.
معماری و مرزهای روشن
وقتی مرزهای سامانه مشخص باشد، می‌شود از ابزار خواست یک قطعه‌ی محدود را پشت یک قرارداد مشخص بسازد. بدون مرز، هر قطعه‌ی تولیدشده به شکل خودش به بقیه گره می‌خورد.
آزمون خودکار
آزمون تنها راه مطمئن برای این است که بفهمید کد تولیدشده واقعاً کار می‌کند. تیمی که آزمون ندارد، با ابزار هوش مصنوعی فقط سریع‌تر خطا تولید می‌کند.
بازبینی انسانی
هر تغییر باید توسط کسی خوانده شود که آن بخش را می‌فهمد. سرعت تولید نباید از سرعت بازبینی جلو بزند.
قاعده‌های کاری من
- اول طرح، بعد کد. پیش از تولید، روشن می‌شود چه چیزی و در کجای سامانه ساخته می‌شود.
- قدم‌های کوچک. تغییر کوچک قابل بازبینی است؛ تغییر هزارخطی نه.
- هر خط خوانده می‌شود.
- آزمون همراه کد. نه بعداً.
- دروازه‌ی کیفیت خودکار. بررسی نوع، قاعده‌های کدنویسی، آزمون و اسکن امنیتی پیش از هر انتشار.
- داده‌ی محرمانه بیرون نمی‌رود. کلیدها و داده‌ی کاربران هرگز به ابزار داده نمی‌شوند.
اثر بر کارفرما
- زمان کوتاه‌تر تا نسخه‌ی اول، به شرطی که تعریف روشن باشد.
- پوشش آزمون بیشتر، چون نوشتنش ارزان‌تر شده است.
- مستندات بهتر.
اما یک هشدار هم هست: سرعت تولید می‌تواند بدهی فنی را هم سریع‌تر بسازد. تیمی که بدون نظم با این ابزارها کار کند، در چند هفته کدی تولید می‌کند که هیچ‌کس آن را کامل نمی‌فهمد.
نقش انسان
کار مهندس از «نوشتن» به سمت «تعریف، تصمیم و تأیید» حرکت کرده است:
- مسئله را دقیق تعریف می‌کند.
- ساختار را طراحی می‌کند.
- خروجی را نقد می‌کند.
- مسئولیت نتیجه را می‌پذیرد.
این مهارت‌ها ارزان نشده‌اند. برعکس، کمیاب‌تر و باارزش‌تر شده‌اند.
جمع‌بندی
هوش مصنوعی ضریب است، نه جایگزین. فرایند خوب را چند برابر سریع‌تر می‌کند و فرایند بد را چند برابر خطرناک‌تر. اگر تعریف، معماری، آزمون و بازبینی سر جایشان باشند، نتیجه محصولی است که هم زودتر می‌رسد و هم سالم‌تر است.
مطلب مرتبط: امنیت از روز اول.