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