Какие проблемы создает использование ИИ программистами
Структура статьи
Введение
Часть 1. Появился ИИ, ну и в чем проблемы? — Появились отличия в «программистах»
Часть 2. Ну поменялись программисты и что? Важен же код. — Появились отличия в коде.
Часть 3. Ну ладно, код стал хуже и что? Главное что бизнес работает. — Проблемы будут, не сомневайтесь.
Заключение
Введение
Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.
Само видео мне не очень понравилось — путанное и цикличное повествование, бессмысленная картинка большую часть времени. Но под конец автор высказал ряд мыслей, которые вдохновили меня на написание статьи. Сами мысли я повторяю в конце статьи, но вот вам таймкод.
И рассуждения я начну с вопроса — «ну и в чем проблемы?»
Часть 1. Появился ИИ, ну и в чем проблемы? — Появились отличия в «программистах»
Какие отличия у программиста с ИИ, от программиста без ИИ
Ниже уровень самостоятельных технических знаний.
Классический программист сталкиваясь с очередной проблемой проводил многочасовые дебаг сессии и решив проблему действительно начинал ее понимать.
Promt‑инженер сталкиваясь с проблемой может пойти в ChatGPT даже не прочитав сообщение об ошибке, а потом также не вчитываясь скопировать ответ от ИИ. Таким образом он сам отказывается от понимания того, с чем он работает. А еще рискует накрутить костылей на код по ходу такой разработки.Ниже уровень проектных знаний.
Классический программист — сам придумал, сам написал, сам проверил, все понял.
Prompt‑инженер тратит меньше сил и времени на создание кода, но платой за это является то, что он остается без проектных знаний —, а это то, что делает программиста создавшего проект более ценным, чем какого‑то другого случайного программиста.Ниже стремление к решению проблем.
Для классического программиста ценен не только результат — «проблема решена», но и процесс. Именно в ходе процесса решения задачи зарождается понимание взаимосвязей между теми или иными деталями применяемой технологии.
Promt‑инженер зачастую лишает себя «процесса», получая сразу результат.
Promt‑инженер сам отказывается от знаний, а значит отказывается от своей ценности как программиста.
Часть 2. Ну поменялись программисты и что? Важен же код. — Появились отличия в коде.
Почему бизнес должно волновать изменение программистов? Он же платит деньги за решение проблем, а в данном случае проблему решает код. Что там с кодом?
Обобщая до одной фразы — ИИ пишет код, который решит проблемы сейчас, но создаст проблемы в будущем.
Он учился писать код, смотря на код написанный людьми. Некачественного кода написано сильно больше, чем качественного, а потому легко догадаться каким будет то, что напишет ИИ.
А в чем заключается некачественность кода?
ИИ часто пишет непонятный код.
Кто‑то скажет: «Ну и какие проблемы? Главное чтобы работал». Дело в том, что код пишется один раз, а читается десятки и сотни: при изучении системы новым программистом, при починке багов, при добавлении новых фич в старый код — все это происходит многократно. Если программист (или ИИ) один раз написал непонятный код, то другие программисты много раз будут тратить больше времени, чем могли бы, на то чтобы этот код просто понять. Время работы программистов стоит дорого, а значит за непонятный код бизнес теряет деньги.ИИ пишет неподдающийся изменению код.
Программирование существует давно и за это время программисты успели насовершать ошибок, понять как этого избежать в будущем и сформулировать то, что они поняли в виде различных принципов (SOLID, KISS, DRY, YAGNI, принципы чистого кода, принципы чистой архитектуры итд). Почти все эти принципы нацелены в первую очередь на то, чтобы сделать код изменчивым. Почему это важно? Вот простое рассуждение из книги «Чистая архитектура»:Если код работает неправильно, но его легко менять — его легко починить.
Если код работает правильно, но его тяжело менять — он начнет работать неправильно когда поменяются бизнес требования и починить его будет тяжело.
Изменчивость кода значит, что всегда понятно, как быстро написать новый код так, чтобы не сломать старый и сохранить при этом ту изменчивость кода, которая уже есть.
Время работы программистов стоит дорого, а значит за код, который тяжело менять бизнес теряет деньги.Использование ИИ порождает diversity кода
Переводя на русский — отсутствие единообразия (не путать с однообразием). Мысль такая — «ожидается, что в одном проекте разный код, который делает похожие задачи должен быть написан похожим образом». Это позволит разобравшись в кусочке кода в одной части проекта сразу понять другие похожие на него. ИИ каждый раз генерируя код «обращается» к коду который он видел раньше —, а это код из разных проектов и от разных людей. В итоге ваш проект превратится в мешанину из всего подряд, что очевидно плохо.Если в коде мало diversity, то программист потратит меньше времени на понимание кода (по крайней мере начиная со второго раза). Время работы программистов стоит дорого, а значит за код, в котором много diversity бизнес теряет деньги.
ИИ не придерживается единой архитектуры кода.
Во всех LLM моделях используется ограниченный контекст — «только ближайший код». Это приводит к тому, что ИИ не видит всю картину проекта, и потому не может поддержать единую для всего проекта архитектуру кода. Это возвращает нас к проблемам diversity и непонятности, но по смыслу является новой проблемой. Проект перестает быть целостным — он становится набором кусочков кода. А если учесть то, что чаще всего выбранная архитектура проекта призвана решить какую‑то проблему — эта «решенная» проблема вернется в наш проект, когда ИИ напишет достаточно много кода. На этих проблемах бизнес снова будет терять деньги.
Promt‑инженер который написал некачественный код этого даже не осознает.
От написания такого кода спасают глубинное понимание, опыт и насмотренность, которые есть у классического программиста, но от которых добровольно отказался promt‑инженер в пользу скорости разработки.
Часть 3. Ну ладно, код стал хуже и что? Главное что бизнес работает. — Проблемы будут, не сомневайтесь.
ИИ позволяет молниеносно создавать прототипы — небольшие проекты, которые позволяют сразу проверить идею и привлечь реальных пользователей. Почти любой успешный проект будет стремиться к тому, чтобы вырасти — проекты написанные ИИ не являются исключением.
Ловушка плохого кода состоит в том, что его проблемы незаметны в маленьких проектах, но очень быстро всплывают в больших.
Иначе говоря: если из‑за плохого кода у вас начали появляться проблемы, то этот поезд уже не остановить — у вас на руках огромный проект из плохого кода. Не исключено, что поезд не только нельзя будет замедлить, но и хотя бы прекратить его ускорение.
Выше я уже написал, что на плохом коде бизнес теряет деньги, но не подсветил, что этот процесс имеет накопительный характер. Затраты на написание нового кода и поддержку старого растут экспоненциально.
Очень скоро бизнес оказывается в ситуации, когда внедрение новой фичи или починка очередного бага является слишком дорогой и долгой. Как следствие бизнес становится менее конкурентоспособным, теряет клиентов, теряет деньги и разоряется.
Заключение
Эта статья начинается с того, как меняются программисты и это сделано не просто так. Кажется, что единственное что важно во всем процессе программирования это то, что изначальная проблема была решена, а значит можно подумать, что результат важнее чем код, а код важнее чем программисты. На деле же во всей этой цепочке самое первое звено — программисты и это звено и является самым важным — без него все остальные рассыпаются.
Тут нет рассуждений в духе «ну это же несправедливо — почему классические программисты действительно вкладывались в свое развитие соревнуются с prompt‑инженерами и отстают» — любое рассуждение о справедливости это признание собственной неспособности приспособиться к новым условиям.
Классические программисты не «неспособны приспособиться». Они отдают приоритет процессу, а не результату, потому что это их выбор. Они повышают тем самым свою ценность, а время покажет, даст ли это им преимущество.
Написание кода это в первую очередь мыслительный процесс. Я сам неоднократно проводил много часов подряд читая код, не напечатав при этом ни одного символа. Это происходило и во время работы в Яндексе, и в различных PET‑проектах. Каждый раз я погружался в размышления не о том «как сделать так, чтобы код работал как я хочу», а о том «как сделать так, чтобы этот код был качественным». Когда же размышления приходили к какому‑то логичному итогу — я приступал к написанию кода. Этот процесс размышлений давал мне три вещи.
Во‑первых я был доволен тем, что написал.
Во‑вторых я полностью понимал написанный код.
Во‑третьих я всегда мог защитить свои решения перед коллегами и объяснить им те или иные моменты в коде.
Идея из видеоролика, которая сподвигла меня на написание статьи.
В ближайшее время прототипов станет очень много. Они будут расти и ломаться.
Спрос на хороших программистов не упадет — нужен будет кто‑то, кто будет решать проблемы возникшие из‑за плохого кода. Ближайшее десятилетие станет золотой эрой именно классических программистов. ИИ естественным образом отфильтровывает сферу от людей, которые на самом деле не хотят заниматься программированием.
Логично ожидать, что в ближайшее время снизится доверие со стороны работодателей ко всем программистам. Проблема оценки компетенций программиста на собеседовании была и раньше, а с приходом ИИ она стала еще более острой. Работодателям придется как то решать эту проблему. Возможно собеседования полностью вернутся в оффлайн формат, возможно будет более полная проверка опыта из резюме, чтобы бороться с накруткой, может будет больше секций с более тщательной проверкой знаний. Время покажет.
Может показаться, что я, как автор статьи, призываю отказаться от ИИ, но это слишком радикальная мера. ИИ это в первую очередь инструмент и любой инструмент можно применять правильно и неправильно. На мой взгляд, правильное использование ИИ сводится к двум правилам:
ИИ должен за вас делать только ту работу, которую вы и без него можете легко сделать. Такой подход позволит вам самостоятельно валидировать ответы ИИ и сразу их исправлять, если вы понимаете, что выданный код не соответствует вашим требованиям качества.
Если вы используете ИИ для решения новой для себя проблемы, то он должен помогать вам не решить проблему, а понять как эту проблему решать. Используйте его не как генератор кода, а как огромный справочник. В идеале обращаться к нему после того, как хотя бы немного почитаете документацию.
Программирование это не про работающий код.
Программирование это про понимание.
