Узнайте, почему знание конкретного стека становится менее важным, а инженерное мышление — главным преимуществом. Читайте статью и станьте востребованным разработчиком!
Долгое время я считал, что быть хорошим программистом — значит отлично знать свой стек. Я был разработчиком на Laravel, React, Node.js и Go. И в этом была доля правды. Я годами работал с Laravel и, естественно, стал быстрее решать задачи с его помощью. Я знал экосистему, типичные ошибки, пакеты, соглашения и, возможно, даже то, чего нет в документации. Мой стек стал частью моей идентичности как разработчика. Но я думаю, что ИИ постепенно меняет это.
Не потому, что фреймворки и языки программирования больше не важны. Они, очевидно, важны. А потому, что ИИ сделал переход между ними намного проще. Сегодня я могу открыть кодовую базу на языке или фреймворке, к которому не прикасался годами, или, возможно, никогда серьезно не использовал, и стать продуктивным гораздо быстрее, чем раньше. Я могу попросить ИИ объяснить структуру проекта, объяснить фрагмент кода, перевести что-то с PHP на Go, помочь написать тесты, использовать его при отладке и даже спросить, почему конкретный подход может быть плохой идеей. Это не делает меня внезапно экспертом в этой технологии, но означает, что мне не нужно тратить недели, чтобы просто освоиться и начать решать реальную проблему. И я думаю, это довольно большое изменение.
Было время, когда знание самой технологии было значительным преимуществом. Если вы знали Laravel, вам приходилось его учить. Если вы хотели изучить React, вам приходилось тратить время на понимание React. Если вы хотели работать с Kubernetes — удачи. Вы читали документацию, смотрели туториалы, создавали проекты, ломали их, чинили и постепенно накапливали опыт. Так до сих пор становятся хорошими специалистами. Но ИИ изменил точку входа. Первые часы работы с новой технологией больше не такие болезненные, как раньше. Вы можете держать ИИ рядом, и он будет объяснять все по ходу дела. Поэтому я думаю, что мы увидим больше программистов, которые становятся «бесстековыми». Не буквально бесстековыми. У нас по-прежнему будут люди, специализирующиеся на определенных технологиях. Но я думаю, что идея разработчика, определяемого в первую очередь своим стеком, станет менее важной. Вопрос будет не «Ты Laravel-разработчик или Go-разработчик?», а все чаще «Можешь ли ты решить эту проблему?» и затем «Какой способ решения лучший?».
Здесь, я думаю, становится интересно. Можно предположить, что если ИИ умеет писать код, инженерный опыт становится менее важным. Я думаю, происходит обратное. Потому что написание кода никогда не было всей работой. Представьте, что я прошу ИИ: «Создай мне платежную систему». Он, вероятно, сгенерирует удивительно хорошую отправную точку. Но что дальше? Что если платежный провайдер отправит вебхук дважды? Что если платеж прошел, но наш сервер упал до обновления базы данных? Что если клиент закроет браузер на середине платежа? Что если провайдер превысит таймаут, но платеж на самом деле прошел? Что если Redis упадет? Что если наша очередь задержится на 30 минут? Что когда у нас будет 100 000 транзакций вместо 100? Что если кто-то попытается эксплуатировать систему? Это не проблемы синтаксиса. Это инженерные проблемы. И обычно вы учитесь думать о них, потому что вас это уже обжигало. Может быть, вы выпускали что-то, что отлично работало в разработке, но развалилось в продакшене. Может быть, вы сталкивались с дублирующимися вебхуками. Может быть, у вас блокировка базы данных роняла часть приложения. Может быть, Redis исчезал в самый неподходящий момент. Может быть, вы потратили шесть часов на отладку того, что оказалось одной строкой кода. Этот опыт меняет ваше мышление. И это то, что ИИ не может просто дать вам, сгенерировав еще 500 строк кода.
Я думаю, одно из самых больших изменений, которые ИИ привносит в программирование, — это то, что качество ваших вопросов теперь важнее. Разработчик с небольшим опытом может спросить: «Напиши платежный сервис». Опытный инженер может спросить: «Спроектируй платежный сервис, который идемпотентен, обрабатывает таймауты провайдера и дублирующиеся вебхуки, поддерживает сверку и не помечает заказ как оплаченный, пока транзакция не может быть проверена». Тот же ИИ. Совершенно другой результат. Разница не обязательно в умении печатать лучшие промпты. Это понимание проблемы достаточно хорошо, чтобы знать, какие вопросы нужно задать. Это и есть инженерный опыт. И по мере того как ИИ становится лучше в написании кода, я думаю, это становится еще важнее.
Это, пожалуй, та часть, которая меня больше всего волнует. ИИ облегчает программистам возможность быть любопытными. Вам не нужно говорить: «Я PHP-разработчик, поэтому не трогаю Go». Вы можете изучить Go. Вам не нужно говорить: «Я не знаю Kubernetes, поэтому не могу понять, что здесь происходит». Вы можете разобраться. Вам не нужно тратить три дня на попытки понять незнакомую библиотеку, прежде чем внести первое изменение. Вы можете задавать вопросы во время обучения. Это означает, что программисты могут стать шире, не обязательно становясь поверхностными. Бэкенд-инженер может лучше понимать фронтенд-концепции. Фронтенд-инженер может разбираться в инфраструктуре. Веб-разработчик может исследовать распределенные системы. Тот, кто в основном работает с SQL, может начать понимать событийно-ориентированные архитектуры. Границы между дисциплинами становится легче пересекать. И я думаю, это хорошо.
Возможность использовать ИИ для генерации кода — это не то же самое, что быть инженером. Более того, я думаю, ИИ может сделать плохую инженерию более легкой в производстве. Теперь вы можете генерировать впечатляющее количество кода очень быстро. И это опасно, если вы не понимаете, что генерируете. Вы можете создать красиво структурированную систему, которая не решает реальную проблему. Вы можете внедрить ненужные микросервисы, потому что ИИ их предложил. Вы можете добавить пять уровней абстракции в простое приложение. Вы можете скопировать паттерн безопасности, который выглядит правильно, но имеет тонкую уязвимость. Вы можете сгенерировать код, который проходит ваши тесты, но все равно падает в продакшене. ИИ может сделать вас быстрее. Но он также может сделать вас быстрее неправым. Вот почему опыт важен.
Я не думаю, что будущее принадлежит программистам, знающим больше всего фреймворков. И я не думаю, что оно принадлежит программистам, знающим больше всего инструментов ИИ. Настоящее преимущество будет у инженера, который может взять запутанную проблему, понять ее, разбить на части, принять хорошие решения, использовать доступные инструменты и знать, когда эти инструменты ошибочны. ИИ снижает ценность запоминания синтаксиса. Он снижает трение при изучении новых технологий. Он снижает стоимость перехода между стеками. Но он повышает ценность того, что гораздо труднее приобрести: инженерного суждения. Вы можете спросить ИИ, как реализовать что-то. Но вам все равно нужно знать, стоит ли это реализовывать. И, возможно, именно туда движется программирование. Меньше про то, чтобы быть человеком, который знает каждый инструмент. Больше про то, чтобы быть человеком, который знает, что строить, зачем строить и что может пойти не так. Стек не исчезает. Он просто становится меньше частью идентичности. Инженер становится рвом.
Что делать прямо сейчас? Начните использовать ИИ для выхода за пределы вашего текущего стека. Выберите технологию, которую вы всегда откладывали, и попросите ИИ объяснить её основы на примерах из вашего текущего языка. Затем попробуйте решить небольшую задачу с её помощью. Также тренируйте навык постановки вопросов: вместо «напиши функцию» спрашивайте «спроектируй систему, которая учитывает сбои и крайние случаи». И помните: ИИ — это инструмент, а не замена инженерного мышления. Развивайте суждение, и вы останетесь востребованным, какой бы ни был стек.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →