Наливайте кофе, насыпайте попкорн – будет познавательно и полезно.
Итак, начнем с самого начала: с основ программирования и с того, что в нем еще не удалось решить современному человечеству, и мы поймем, как нам тут поможет AI и поможет ли в принципе.
Halting problem – баги с нами до конца времен
Мы пишем программы для компьютеров, которые являются той самой “машиной Тьюринга”, для которой Алан Тьюринг еще в 1936 году строго доказал, что, простыми словами, “полностью проверить на наличие ошибок программу нельзя”.
Можно тут еще напомнить про теорему Курта Геделя о неполноте, которая “примерно” про то же самое, про рекурсии и которой была “взломана” и так и не оправилась математика.
В общем, все понимаем, проверять код чем-то на наличие ошибок и найти их все – нельзя. Возможно, в далеком будущем, настоящий, а не тот, что им сейчас называют, “AI”, поможет человечеству с преодолением halting problem… Но пока нам нужно искать другие способы и техники минимизации ошибок в разработке и использовать их все вместе, если это рентабельно. Какие?
Автоматизированные тесты
На самом деле, тесты могут быть и неавтоматизированными, но тогда их придется выполнять вручную несколько часов (а иногда дней и даже недель) после любого изменения в программе :-)
Суть проста – пока ты пишешь код, ты в контексте (тут я говорю еще про наш, человеческий контекст, а не то, что Вы подумали) и у тебя в голове вращается алгоритм. Вообще понятие “пока у тебя в голове” невероятно мощное, на нем, в том числе, основан мой любимый Python, пытающийся максимально снизить когнитивную нагрузку на человеческое внимание и сознание при написании кода. Так вот, пока разработчик в контексте, он сразу пишет и автоматические тесты к своему коду, заодно “выбрасывая” из кода то, что нельзя или трудно и дорого автоматически протестировать другим кодом (да, тут я намекаю на то, что код становится проще, архитектура прозрачнее и резко снижается число степеней свободы до уровня, который можно достаточно надежно проверить другим кодом).
Когда кода становится много, ты пишешь уже не только простые, модульные тесты, но и более “сложные” – интеграционные, которые начинают тестировать твое приложение или его модули как единое целое. Например, ты поднимаешь локальную копию AWS в виде Localstack, создаешь там s3-файлы и SQS-очереди, таблицы DynamoDB и проверяешь целиком от начала и до конца работу твоего приложения “как будто мы в продакшн”. Получается, у тебя примерно половина написанного кода занимается тестированием, а другая половина это код самого приложения, с той особенностью, что тестирующий код пишется обычно гораздо проще и быстрее.
Если вообще времени в обрез, можно написать сквозной “дымный” тест (телевизор после включения не задымился и показывает, значит все, скорее всего, хорошо, отсюда название) и запускать его после изменений в приложении. Реальность такова, что в некоторых проектах есть только такой один “дымный” тест и он очень помогает (эх, а бывает, что в проектах тестов нет вообще, и никто никого не увольняет за профессиональную некомпетентность, только странно, а почему?).
Некоторые энтузиасты еще измеряют тестовое покрытие программного проекта в разных единицах (на самом деле не особо важно в каких, хоть в мидихлорианах), но важно понимать, что 100% покрытие не гарантирует отсутствие ошибок, а только может показать их присутствие. Но польза, безусловно, есть, и при наличии циферки можно ее повышать, не понижать и даже, останься в страшном сне, прикрутить к ней KPI.
Тут главное помнить, что есть в мире самая популярная по числу инсталляций базка данных, и да, это не MySQL. И вот в ней 100% тестовое покрытие и давно и … баги все равно находят и исправляют.
В общем вывод тут краткий – тесты пишем, пишем сразу, а если протестировать просто и быстро не понятно как, у проекта проблемы с архитектурой и ее нужно пересмотреть и сделать подходящей для автоматизированного тестирования. Тесты начинают помогать, не сразу, а с ростом кодовой базы проекта, и потом вы каждый день начинаете благодарить вселенную за наличие тестов к коду и не боитесь его постоянно развивать и релизить.
И да, это, увы, не математика, это классические инженерные практики, которые работают.
Система типов – может заметно помочь снизить число ошибок в коде
Если для разработки программного проекта “сразу выбрать” (пишу, а из глаз слезы капают, особенно из левого, который подергиваться стал) язык с “хорошей” поддержкой типов и компилятором, то технических ошибок в коде будет значительно меньше. Компилятор будет помогать разработчику, и это не пустые слова – проект на Java, скажем, действительно проще поддерживать и сопровождать, чем на JavaScript. Также код после компиляции будет, как правило, работать еще и быстрее. Единственный минус тут – нужно учить людей пользоваться системой типов и читать официальную документацию к языку программирования и потратить на это несколько десятков часов.
Поэтому, если пишете на JavaScript, рассмотрите постепенный переход на TypeScript или используйте фреймворки с поддержкой типизации типа Angular. Если пишите на Python, начинайте добавлять аннотации типов и прогоняйте код через валидатор типов MyPy. Для новых проектов постарайтесь рассмотреть современные языки программирования с качественной поддержкой типов, как, например, Rust или хотя бы Kotlin.
Важно помнить, что поддержка типизации в скриптовых языках, как правило, к сожалению, “дырявая”: что MyPy, что TypeScript, оставляют многочисленные лазейки, и не трудно сделать так, чтобы код в рантайме упал с ошибкой, пропущенной “анализатором типов”. Но в любом случае наличие компилятора и/или анализатора типов и вообще любой более-менее разумной системы типов – действительно, по моему опыту, резко снижает число ошибок в программном коде (остаются, как правило, логические ошибки и совсем немного технических).
Читаемость кода – важна для развития и поддержки
Многие, думаю, видели код, который “от высокоумия” плохо читается и после созерцания его в течении получаса так и непонятно, работает он или нет, даже при наличии базовых тестов к коду. Особенно это касается реализации алгоритмов и математики, придуманной разработчиком “на ходу” и без доказательства (а что это такое, доказательство, что-то из школы?). Но самый простой пример, это когда есть сложное выражение с кучей операторов – но без скобок :-)
Так же важно тщательно продумывать названия переменных, модулей, файлов, функций, названий таблиц и колонок в БД – иногда это сложнее и строже призывает к ответственности, чем писать код. Зато в поддержке и понимании будет значительно легче в ближайшие годы.
Именно поэтому многие десятилетия создаются своды правил и пишутся хорошие книги про то, как научиться писать понимаемый мозгом при ревью код. Кстати… по поводу ревью – я стал замечать, что роль тимлида в последние годы стала опасно размываться в области границ ответственности, и тимлиды могут либо не делать ревью кода, либо делать формальное ревью, не понимая, на самом деле, код разработчика, ну как же так? Это же прямая дорога в ад, булькающий и пахнущий бульоном из тел грешников.
Фреймворки
Меня очень смущает современная тенденция тянуть в программные проекты сразу несколько фреймворков, для каждого из которых нужно прочитать 500-1000 страниц убористой документации. Особенно, когда задачу можно качественно и понятно решить в 50-100 строк кода. Особенно, когда чтобы набраться опыта даже в одном фреймворке нужны, иногда, месяцы, если не годы. Да, запуститься можно быстрее, но потом где вы найдете разработчиков, которые одновременно знают 5 больших фреймворков (и тут перед глазами внезапно появляется Claude Code, который рвется помогать, но поймешь ли ты то, что он предложит!), а еще проект нужно будет регулярно обновлять – в общем, чем больше затянуто фреймворков, тем больше становится особо сложный технический долг и усложняется поддержка.
Документация – частичка души разработчика
Всегда считал и считаю, что в документацию к программному проекту нужно вкладывать душу и сердце. Реализована смелая идея, идея на практике доказала свою жизнеспособность и помогает другим людям решать задачи – как же не похвастаться этим в подробных примерах? Документацию нужно писать людям.
Но, к сожалению, все больше и больше документации, как “говорят знакомые”, пишут уже не люди – я начал ощущать это не сразу, но ощущение совершенно четкое – читаешь, читаешь, проходят часы, дни, а внутри пустота от обилия “воды” и становится еще непонятней и запутанней, и хочется сразу открыть исходники (с искренней надеждой, что хоть там был кто-то с включенным сознанием).
AI-ассистенты – изнутри
Простой тест на адекватность – спросите у коллег, как расшифровывается аббревиатура GPT, а затем, что значит каждый термин на уровне умножения матриц и векторов и поймете, в каком буйном пире “во время чумы” находится мир. Magic forever.
Если серьезно, архитектура больших языковых моделей (LLM) – довольно примитивная: K, V, Q матрички для ускорения параллельного обучения на GPU, нелинейные преобразования, несколько слоев “этого” и много, много, МНОГО железа и электроэнергии. И да, масштабное обучение на доступной и большой бигдате.
С точки зрения последовательности шагов и окупаемости бизнес-идей и железа – все ожидаемо и разумно. А с наносимой пользой продолжим разбираться дальше. И осадочек остался-с.
Ключевой момент превращения LLM в полезный продукт
Раньше, еще лет 5-10 назад, приходилось обучать новую модель для решения новой задачи – дни, недели. И самое трудное было – достать датасет с размеченными данными для обучения (хотя бы несколько тысяч примеров), остальное решалось почти автоматически и без особых рисков.
Современные LLM, казалось бы, не нуждаются в датасете – достаточно придумать prompt и вуаля, можете решать вашу сложную задачу. Но вдруг оказалось, что написать эффективный prompt не так просто, и изменив слово или вставив в prompt запятую, можно значительно изменить или ухудшить качество решения вашей задачи. И мы видим, что снова началось движение к истокам – к машинному обучению по поиску оптимального prompt, к тому, с чего все и начиналось, к линейной алгебре и статистике.
Но, будем честны, для большинства рутинных задач можно написать prompt руками, “как для умного человека”, и это будет работать, не идеально, но рентабельно для бизнеса. И в этом как раз и случился прорыв – LLM стала отчуждаемым универсальным продуктом.
Prompt для задач программирования
Кто когда-нибудь интересовался темой создания профессиональных prompts, то видел, какие они сложные и запутанные на самом деле, и понятно, что их пишут уже не люди. И как ты докажешь, что твой prompt лучше prompt у коллеги? Да никак, ведь нужно создать датасет (дни, недели), прогнать его через ваши prompts, включить мозги, напрячь память, посчитать метрики accuracy, recall, precision, а возможно и semantic similarity и только тогда можно получить истинный ответ на вопрос, чей prompt лучше. Понятно, что этим сейчас никто в быту не утруждает себя – просто мой prompt лучше, чем у Васи.
Возникает вопрос, а не проще ли сразу написать программу на более строгом языке программирования, чем сначала писать огромный prompt на человеческом противоречивом языке, созданном не для передачи информации, а для выражения эмоций, а потом общаться с AI-ассистентом в чате, пытаясь объяснить ему, что нужно получить в итоге? Искренне считаю, что, программируя, мы сразу и создаем четкие и непротиворечивые инструкции для компьютера и не нужно делать лишнюю работу по переводу логики и математики сначала в prompt, а затем из него с потерями снова в код и еще обхаживать AI-ассистента в чате несколько часов/дней.
Но для не очень сложных задач программирования, связанных с перетасовкой форматов данных, скучным и ненавистным CRUD и работой с БД, несложной версткой, AI-ассистент работает, будем честны, достаточно хорошо (и даже лучше и быстрее многих сотрудников в офисе). По моим наблюдениям:
-
“Если попросить”, AI-ассистент пишет код заметно лучше и чище начинающего разработчика. Внимательно проверял это в Google Antigravity, Claude Code и Yandex Code Assistant с языками PHP, Python, Java Script, Type Script, Rust.
-
“Если попросить”, AI-ассистент может писать код значительно строже, с проверками и валидацией входных значений методов и функций. Это важно для улучшения качества кода.
-
“Если попросить”, AI-ассистент может перевести код на нетипизированном языке на язык с более строгой типизацией или, как минимум, добавить аннотации типов. Это важно для улучшения качества кода.
-
AI-ассистент работает значительно быстрее разработчика (на порядки). Это значит, что можно проверять одновременно несколько гипотез и выбрать самую лучшую в условиях дедлайнов. Это важно для снижения проектных рисков.
-
“Если попросить”, AI-ассистент может быстро написать unit и даже интеграционные тесты для вашего кода. А это очень важно для обеспечения качества.
-
AI-ассистент не бесплатный, нужно платить за токены (Yandex Code Assistant пока бесплатный), но если сравнить стоимость времени разработчика и стоимость AI-ассистента, то есть ощущение, что многие рутинные задачи AI-ассистент может делать сильно дешевле. А еще – стоимость токенов постоянно снижается.
-
AI-ассистент регулярно ошибается. Иногда ошибки легко увидеть при ревью, а иногда они спрятаны в глубине алгоритма. А чего удивляться то? В его память помещается всего 20-40 тысяч строк кода, а размер ядра Linux, позвольте напомнить, вмещает 40 миллионов строк. Поэтому до действительно больших и сложных проектов AI-ассистентам еще как до Луны. Но если разрабатывать систему модулями, то риски минимальны. Питер Штайнбергер даже признался, что держит размер OpenClaw таким, чтобы весь его проект помещался в “мозг” AI-ассистента – так проще и быстрее его разрабатывать.
Вы посчитали, сколько раз встретилось фраза “если попросить”? Но есть и хорошая новость, все “если попросить”, выраженные на языке “для умного человека”, можно собрать в один текстовый файл и давать на вход AI-ассистенту при разработке каждой новой программы.
Не знаю как вас, но меня не покидает мысль, что AI-ассистенты для программирования это те же самые LLM, которые в течении многих лет преподносились обществу как инструменты для обучения программированию, но только теперь стали чуточку получше. Ничего плохого в этой идее, конечно, нет – дать возможность искусственному преподавателю программирования сделать что-то более полезное, чем безуспешно объяснять “вайб-кодеру” как работает пузырьковая сортировка :-)
Надежный процесс разработки с AI-ассистентом: от начала и до конца
Итак, осознавая все, что выше, сформируем чеклист надежного и прозрачного процесса разработки с AI-ассистентом:
-
Выбираем, при возможности, язык с типизацией, такой как TypeScript, Python с аннотациями типов, PHP с аннотациями типов, Java/Kotlin/Swift, Go и, если есть возможность, язык с лучшей в отрасли строгой типизацией – Rust. И сразу планируем запускать валидатор типов после каждого изменения кода проекта. Это на порядки снизит число технических ошибок даже в коде, созданном AI-ассистентом. Не зря Claude Code пишут нейросетью на Type Script, а Codex – на Rust.
-
Устанавливаем в AI-ассистента, при необходимости, плагин для улучшенной поддержки языка программирования. Это ускорит его работу, понизит число затрачиваемых токенов и резко снизит число проб и ошибок, совершаемых AI-ассистентом (они сначала ошибаются, потом пытаются исправить свои ошибки и так по кругу, иногда бесконечному).
-
Выбираем надежные библиотеки или фреймворки для проекта, желательно с хорошим тестовым покрытием (больше 50-60%, выше – лучше) и адекватным (желательно более 1000, но иногда хорошие решения имеют и меньшее число звезд) числом звезд на GitHub. Желательно, чтобы библиотеки были на типизированных языках (см. п.1). Важно, чтобы Вы и Ваши коллеги знали эти фреймворки и библиотеки, прочитали документацию от корки до корки минимум один раз с примерами, иначе все будут делать вид, что понимают код, созданный AI-ассистентом, а на самом деле не понимать и лепить “горбатого к стенке”. Запомните негласное правило: “чем серьезнее лицо разработчика, смотрящего в код, созданный AI-ассистентом, тем меньше он его понимает”. Поэтому тестируйте знания разработчиков на знание библиотеки и фреймворка путем очного собеседования с вопросами по официальной документации.
-
Пишем unit и, если можно это сделать дешево, интеграционные тесты с помощью AI-ассистента. Обязательно делайте это – сначала разработчик пишет тест, который падает, а потом код.. К сожалению, сейчас все чаще и чаще встречаются разработчики, которые искренне, от души, не понимают, зачем нужно писать к коду автоматизированные тесты. А дальше, с развитием AI и появлением действительно полезных квантовых компьютеров (пока они экспериментальные, но активно развиваются в разных странах с активной поддержкой государств), людей с развитыми мыслительными способностями и критическим мышлением, думаю, будет, к большому сожалению и если сейчас не предпринять меры, все меньше и меньше. Люди будут, если не остановить это сейчас, постепенно превращаться в не думающие растения и внезапно придут роботы с серпами.
-
Постоянно и системно, регулярно измеряем тестовое покрытие кода. Важно понимать, что ваши тесты проверяют как минимум 60-70% кода (больше – лучше).
-
Всегда, запомните, всегда, ВСЕГДА, перед каждым коммитом, тщательно проверяем созданный AI-ассистентом код с включенным человеческим сознанием. Крутим код в голове, пока не поймем, что там нет ошибок, или глупостей, или дырок в безопасности. За код отвечает разработчик, добавляющий его в репозиторий, а не AI-ассистент. Тщательный аудит кода должен делать сначала разработчик, использующий AI-ассистента, а затем тимлид, сливающий ветку разработчика в вышестоящую ветку.
-
Если Вам лень разбираться с инструментами работы с репозиторием кода и сборки контейнеров, делегируйте это AI-ассистенту. Но я настоятельно рекомендую предварительно внимательно разобраться в этих инструментах, сначала прочитав документацию по инструменту, а потом ВО ВСЕХ КЛЮЧАХ, которые используются при работе с этими инструментами, так Вы внесете вклад в Ваш личный профессиональный уровень, а вклад в популяризацию и капитализацию Anthropic пусть сделает в этот раз кто-то другой.
-
Постарайтесь написать документацию к проекту вручную, вложив в нее душу и сердце, как и делали всегда раньше. Но в этом Вам поможет AI-ассистент, который может суммаризировать описание проекта и выделить самое главное. Тут они помогут, сомнений нет.
Искренне убежден, что ВСЕ пункты в чеклисте важны и необходимы для работающего прозрачного и надежного для бизнеса процесса разработки с AI-ассистентом. Если что-то вычеркнуть, появляются большие риски как в отношении качества, безопасности, так и читаемости кода и роста технического долга. Но, в целом, грамотно и системно выстроенный процесс выглядит вполне жизнеспособным.
Еще раз хочу подчеркнуть, что самое важное в процессе AI-разработки – это понимание каждого бита созданного кода, каждого ветвления с обязательным прокручиванием в Вашей голове и персональная ответственность за его добавление в репозиторий. Если ты чего-то не понимаешь, открой официальную документацию и найди истину, только потом добавляй созданный с помощью AI код в репозиторий – иначе сгоришь в аду, грешник, и не только ты, но и твой плагиат :-)
Другие полезные сценарии применения AI-ассистента
Вот есть у меня хобби – я изучаю английский язык много лет с преподавателями. Но нет у меня склонности к языкам, поэтому мне это дается с большим трудом и приходится потеть. Но у меня есть склонность к математике и мне гораздо проще код писать, чем не писать. А кто-то говорит на 5 языках и дико тупит при осознании логики умножения вектора на матрицу или алгоритма Merge Search. Все люди разные и у каждого свои таланты.
Давайте теперь посмотрим на возможности AI-ассистента. Он довольно неплохо, хотя с ошибками, говорит на десятке языков и также неплохо, хотя с ошибками, программирует на десятке языков программирования. Аналогичные люди встречаются или крайне редко, или уже вымерли. И стоит AI-помощник недорого. Грех не воспользоваться ситуацией и не окружить себя армией виртуальных помощников (их называют “агентами”), или хотя бы одним, не правда ли, и попробовать с его помощью решать рутинные задачки в разработке, в которых ошибка не приведет к катастрофе?
По моему личному опыту, AI-ассистент может помочь и в быстром сканировании сотен сайтов и выжимке из них ключевой информации по запросу, даже с учетом того, что он может иногда ошибаться (как и люди). Я в последнее время увлекся запуском исследований с Алисой-Плюс с запросами вида: “чем отличаются иридиевые свечи Champion от NGK”, “через сколько километров или моточасов менять машинное масло в Haval H6 и какое масло лучше лить” и мне искренне нравится качество ответов. LLM очищает найденную информацию от маркетинга и пиара, другой воды, и дает чистые, упорядоченные факты. Первое время я скрупулезно проверял первоисточники, но постепенно доверие к агентскому поиску стало возрастать, и теперь инструмент вошел в мою жизнь, и я проверяю первоисточники, тратя на это часто часы, только в высокорисковых и исключительных случаях, когда вероятность ошибки должна быть исключена. Реальная польза от AI-ассистента в поиске информации и выжимке фактов – очевидна.
Выводы
Вот мы и подошли к концу. Как Вы уже понимаете, AI-ассистенты никогда не заменят разработчиков и не нужно об этом даже думать, т.к. нет даже близко факторов, указывающих на это, мы в самом начале пути, но AI-ассистенты, несомненно, прочно войдут в нашу жизнь и будут стараться помогать нам стать лучше и заниматься более сложными, интересными и рискованными задачами, взяв малорискованную рутину на себя. Иногда, почему-то, возможно, я не прав, мне кажется, что эпоха рабовладельчества вернется, но на этот раз в виде использования AI-ассистентов. И это прекрасно – у нас появится больше свободного времени на самосовершенствование.
Нам, разработчикам, нужно продолжать развивать мозги, тренируя их через решение задач по математике, статистике, терверу, реализации алгоритмов, изучение новых, математически точных языков программирования и иностранных языков и стараться, разумеется, вести здоровый образ жизни, ибо в здоровом теле – здоровый дух.
К сожалению, “переусложненного фреймворками” кода “непонятного уровня качества” и “непонятно как, кем, с кем и под чем написанного” станет гораздо больше и существенно вырастет нагрузка не только на тестировщиков и специалистов по QA, но и на безопасников и девопсов. Предпосылок улучшения качества кода от помощи AI, к сожалению, пока нет, а вот предпосылок появления тонн чего-то вроде работающего уже, к сожалению, море.
И мы совсем забыли про вайб-кодинг – это когда продукт создает не программист, а, скажем, продакт-менеджер или маркетолог. И когда никто не заглядывает, что там “написалось внутри”. Понятно, что про halting problem “тут ваще не слышали”. Скажу так – возможность получить работающий прототип идеи за короткое время, а еще лучше – несколько работающих прототипов за дни, а не месяцы – это очень важно для развития отрасли разработки программного обеспечения, т.к. позволяет резко снизить риски развития продуктов, заглянуть в будущее и быстрее обсудить, пощупать идею и собрать объективную обратную связь. Но тут и зарыта собака – чтобы что-то попросить стоящее сделать у AI-ассистента, нужно научиться логически выстраивать собственные мысли, от простого к сложному, уметь говорить связно больше 2-3 предложений, не прерываясь на мат, не смешивая кислое с красным, а для этого придется, хотим мы этого или не хотим, продолжать еще активнее развивать собственные мозги – благо возможностей для этого сейчас предостаточно!
Всем удачи!
Автор: AlexSerbul
