ИИ не напишет за вас: как масштабировать проект и не утонуть в нечитаемом коде

На первом курсе я разработал и опубликовал веб-сервис для психологов по поиску и анализу наиболее практичной и проверенной информации. Данный сервис получился сносным, но мне казалось, что этого недостаточно. Я подключил к разработке искусственный интеллект, не думая, что из этого может выйти в долгосрочной перспективе. По итогу сайт действительно расширился: появилась лента, которую можно было полноценно листать и оценивать публикации, можно было зарегистрироваться в виде автора. Но через месяц такого «расширения» я полностью перестал понимать код своего же проекта, потому и пришлось его закрыть. В дальнейшем провёл работу над ошибками: длительное время думал, что сделал не так, и каким образом можно было бы сделать лучше. Об этом сейчас и пойдёт речь.

Искусственный интеллект действительно стал положительным инструментом в руках умелых пользователей: теперь создавать крупные информационные проекты (будь то личные магазины или веб-блоги, приложения под какие-то личные задачи) становится обыденностью, ведь средства для разработки стали доступнее, а ЯП'ы – понятнее некуда, по сравнению с, честно говоря, совсем недавним прошлым. Такой бум не мог не ударить в голову молодому программисту-энтузиасту, что готов был ночами смотреть презентации о новых технологиях, рыться в документациях и рыскать по всеми забытым форумам в поисках ответов на все эти безумные вопросы и идеи. И вот настал момент запуска первого интернет-проекта, который срочно понадобилось масштабировать. Кто бы мог подумать, что если добавить слишком много необработанного собственным интеллектуальным видением кода, может выйти нагромождение самых разных непонятных функций, изменение которых повлечёт за собой поломку всего проекта целиком, что следовательно делает невозможным ни сортировку по разным файлам (создание понятных взаимодействий между файлами для продолжения работы над сервисом), ни добавление новых функций (как же тут добавишь?).

На самом деле проблема сия не нова, и зародилась ещё в момент, когда люди с функционального программирования перебрались на ООП. Но в эпоху нейросетей даже соблюдая принципы объектно-ориентированного программирования, разбивая на конкретные функции, можно угодить в ловушку нестандартной и неразрывной цепочки. Как в неё не попасть? В данный момент веду разработку нового проекта – средств для создания материалов, пригодных для внедрения в мои indie-games проекты. И на сей раз применяю заметно иной подход к масштабированию, о котором и пойдёт речь дальше.

Как масштабировались проекты

Всякий разработчик-авантюрист, развивающий какой бы то ни было проект, и при этом неважно, в какой конкретно сфере, будь то создание ПО, видеоигры или интернет-сервиса, сталкивается рано или поздно с ситуацией, когда индивидуальные ресурсы истощаются всё заметнее и заметнее, а кода становится всё больше и больше. Ведь расширение проекта – это что такое? Прежде всего: добавление новых функций, внедрение таковых в имеющиеся процессы при необходимости, улучшение пользовательского интерфейса (всё-таки всё делается исключительно ради положительного пользовательского опыта, не так ли?), в т.ч. добавление вызова данных функций в уже сложившийся интерфейс.

Проблема понятна: человеческий мозг – штука крайне эффективная, но мышление как процесс достаточно энергозатратен. Мозг может истощаться, требует кислорода и других питательных веществ, отдыха, а задача – т.е. расширение имеющего проекта с учётом его и без того переходящего за все грани масштаба, – наоборот, требует абсолютной концентрации и понимания, где какая функция лежит и за что ответственна в каждом отдельном процессе, вплоть до нюансов. В противном же случае код либо превратится в нечитаемую кашу, которую не разобрать уже ни тебе, ни другим программистом даже при желании, а в случае бага все твои наработки так или иначе придётся перебирать и переделывать. Гораздо проще изначально сделать нечто, не требующее... скажем, капитального ремонта и генеральной уборки в коде одновременно.

И здесь происходит развилка на две тропы: продолжать проект, но масштабировать его уже не только за счёт лишь собственных интеллектуальных средств, неминуемо начав привлекать дополнительную помощь извне, либо же пустить проект на самотёк – и захотят доблестные отдельные разработчики-энтузиасты продолжать, так и продолжат уже в своём режиме и в своих целях.

С появлением средств искусственного интеллекта мне сразу стало понятно, на кого можно спихнуть всю рутину. В целом, ИИ можно использовать как усовершенствованный поисковик – с одной лишь пометкой на полях, что каждую представленную им информацию необходимо обрабатывать через призму здравого смысла и логики. Например, если искусственный интеллект предлагает вам решение, которое можно сильно укоротить без потери жизненно важных свойств, и вы точно знаете, что это никак в будущем не помешает, вы можете совершить свои корректировки, продолжив мучить данный Т9 своими придирками (названными в обществе профессиональными рекомендациями). В общем да, нагородить машина может всякой непонятной ерунды, и если её не контролировать – проект, опять же, скатится в нечитаемую кашу!

Итого задача звучит следующим образом: задействовать свои интеллектуальные средства, финансовые возможности и средства искусственного интеллекта таким образом, чтобы можно было производить масштабирование проекта без угрозы превращения кода в непонятный, нечитаемый бред сивой кобылы. Сегодня я и поделюсь с вами информацией, которая поможет вам довести свой проект до ума не угробив при этом собственное физическое состояние. Ну и, в конце-концов, скажу как не пойти по известному сценарию «устал и забросил в долгий ящик... ой, кажется навсегда».

Нейросеть – не «Акинатор»

Звучит банально, но факт остаётся фактом: большинство из тех, кого я видел, не умеют правильно пользоваться нейросетями. Почему-то некоторое большинство решило, что усовершенствованный парсер для поиска информации (как это и нужно по-хорошему воспринимать в контексте разработки) – чудесное средство по созданию приложений из воздуха. Проблема только в том, что любое «живое» приложение – это приложение, архитектуру которого постоянно совершенствуют и улучшают до тех пор, пока все ключевые аспекты не начнут работать безотказно. Инди-разработчики, по типу того же Маркуса Персона, создателя Minecraft, могли долгие годы проводить такую работу – дописывать код, внедрять новые фичи, проще говоря, делать из наработок конечный, понятный продукт. Нейросеть же да, может создать вам пару, вероятно, хороших наработок, подсунуть пару хороших идей, но совместно с этим подкинет миллион вредных моментов, которые, если вы таковые не заметите, проникнут в проект и разбираться с ними будет очень тяжело, если не невозможно в принципе.

Проблема в том, что нейросеть лишь анализирует информацию и предлагает. Адекватный пользователь никогда не захочет построить всю бэкэнд-систему своего веб-сервиса на наработках нейросети – потому что это путь в один конец, к закрытию проекта. Я это уже проходил. В какой-то момент код получает штамп: «Нечитабелен, дальнейшее расширение невозможно». А представьте, какое лицо будет у данного горе-разработчика, если в данный же момент в консоли отобразятся миллионы ошибок, образовавшихся от незакрытых дыр? Разумеется, я уже начинаю повторяться, но просто хочу для начала внедрить понимание: расширение предполагает читабельный код и понятную структуру, чего нейросеть в контексте крупного проекта самолично обеспечить не сможет. Потому что она – анализатор данных, а не учившийся годами под конкретные задачи специалист.

Главная проблема состоит в том, что... на входе стоит неверное ТЗ. Да, техническое задание, что есть главная боль и объект всех дискуссий и споров между работодателями и программистами, теперь непреодолимая стена между грамотной структурой проекта и... и работодателями, и в т.ч. некоторыми программистами (программист – человек, разрабатывающий ПО, имею право называть их таковыми). Дело в том, что нейросеть не является «Акинатором», она не понимает и не умеет додумывать важные аспекты, основываясь на личном профессиональном опыте и видении – потому что у нейросети, как у робота, нет ни профессионального опыта, ни личного видения!

Итого мы имеем два ключевых параметра, на основе которых мы имеем право внедрять идеи нейросети в свои проекты: определение понятных целей для формирования адекватного и конкретного ТЗ, а также последующее сохранение устоявшейся структуры проекта при абсолютной читаемости, если данный код пройдёт проверку здравым смыслом и получит право на внедрение в конечный проект. И даже здесь все фишки не заканчиваются, внедрить тоже нужно уметь правильно: функции, которые определяют внутреннюю работу проекта (то, что под капотом), и функции, которые имеют прямое соприкосновение с пользовательским интерфейсом, например, могут быть совершенно в разных разделах. Перемешать их – означает устроить себе дополнительное непонимание в дальнейшем и ухудшить общую читаемость кода, структуру проекта как таковую, что делать, в общем-то, нельзя.

Вы, наверное, читаете и думаете, что я лишь о сложных и крупных проектах говорю. Хорошо, давайте приведу простой пример: у нас есть функционал, отвечающий за прорисовку карточек товара (фронтэнд), и функционал, отвечающий за заказ и отправку необходимой информации в логистические центры, которые уже обработают её в своём режиме и довезут продукт до потребителя, отправив необходимую для бухгалтерского и прочего учёта информацию обратно для дальнейшей обработки таковой специалистами (в общем-то, полноценный бэкэнд с серверной составляющей).

А теперь представим, что вы, как специалист, занимающийся данным сервисом, случайно внедрите функции по прорисовке картинок на главной странице в файл с бэкендом. Если мы говорим о простом веб-сервисе, то, наверное, ничего и страшного, если у главного файла (отвечающего за главную страницу) есть прямой доступ к функциям в т.ч. и бэкэнда? Как бы ни так! При желании переделать визуал под более современные стили это будет той палкой в колёса всей компании, которая, возможно, и похоронет целый бизнес в бесконечных вливаниях в создание нового веб-сервиса! В любом случае, сервисы, которые не развиваются и отстают от конкурентов в плане дизайна, обречены. Понятное дело утрирую, конечно, из-за пары функций вряд ли весь бизнес навернётся, но с учётом накопительного эффекта данный сценарий будет становиться всё вероятнее и вероятнее. Одна ошибка кодера – это геморрой на недели, а многочисленные ошибки многих кодеров – это конец всего веб-сервиса целиком. Потому что невозможно починить то, чего не увидишь.

Проще говоря – нейросеть не есть Ванга, не нужно верить в её первые же решения как в истину в последней инстанции и единственное возможное. Решений множество, и будучи грамотным специалистом вы будете использовать средства ИИ именно как специалист, а не как ведомый ею потребитель (а привести то она никуда и не может, данная задача дана не была).

Конкретные механизмы для составления ТЗ

Данный манифест против слепого вайб-кодинга (как это сегодня называют) не может обойтись без конкретных примеров о том, как использовать представленный условиями современного мира инструментарий с большей вероятностью извлечь из данного пользу. Прежде всего поговорим о промпт-инжиниренге.

Это такой новомодный термин, который обозначает верное составление запросов для нейросетей. На самом деле я бы добавил к этому ещё и: выбор нужной нейросети, и только потом составление запроса конкретно под неё. Почему? В интернете масса информации о том, какие нейросети лучше справляются с теми или иными задачами: какая лучше генерирует код на текущий момент, а какая – лучше объясняет решение математических задач. В общем, различность задач подразумевает различность задействованных средств. Итак, если мы определились с нейросетью, то уже пришла пора составлять запрос конкретно под неё. И... нет лучшего советчика о том, как составлять наиболее грамотный промпт нейросети, чем сама же эта нейросеть (а-ля, никто не знает систему лучше, чем сама система). Стоит сделать следующим образом: спросить в 3-5 окнах и в каждом окне независимо друг от друга по-разному задать вопрос о том, как следует писать для данной ИИ промпты. Если увидите общие советы, либо рекомендации, что выходят из здравого смысла – стоит записать.

Итак, теперь у нас есть файл, в котором куча общих фраз о том, как составлять промпт. Наступил этап составления алгоритма: создаём пошаговый механизм превращения подробного текста нашей хотелки в итоговый запрос. Наверное, внимательный читатель заметит, что я акцентировал внимание на подробности. Разумеется. Каждый аспект, так или иначе задействующий общую логику (описание планируемого функционала), дополнительную логику (описание взаимодействия данной логики с другим функционалом), визуальный стиль (в том числе вместе с продумыванием методов изменения такового), должен быть подробно описан. После этого, следуя полученным правилам, составив окончательный запрос, мы можем загрузить его в нашего цифрового консультанта и получить один либо несколько примеров кода.

И тут важно! Никогда не просите у нейросети один пример решения вашей задачи, если у вас нет средств перепроверить верность (вероятность правильности, приближенная к абсолютной) выходных данных. Всегда стоит запросить от нейросети выдать несколько решений, и выбрать то, которое задействует те технологии, в которых вы понимаете или разбираетесь, чтобы доизучать, поискать информацию и грамотно внедрить выходное решение в проект. То есть действовать следует из принципа: я выберу один из многочисленных вариантов, а не возьму просто первый попавшийся.

И даже взяв код от нейросети, следует открыть его в отдельном редакторе и хотя бы бегло прочитать. Где-то подправить, где-то изменить, где-то изменить сильно. Зачем тогда нейросеть, спросите вы? А я отвечу таким образом: в случае поиска данного рода механизмов на просторах безграничного интернета, а не через ИИ-помощник, у вас с момента зарождения идеи до появления данного примера на руках прошло бы минимум несколько суток, если не неделя. Нейросеть упрощает поиск информации, частично – и анализ, но создание из выходной информации полноценного рабочего кода – в руках программиста.

Чем всё закончится

Хорошо, у нас есть инди-проект, ограниченные физические и эмоциональные ресурсы инди-авантюриста, и несколько тысяч хорошо разложенных им строчек кода (файлы имеют понятное предназначение, функции распределены верно, вызовы функций в нужных местах, каждый механизм работает). Приходит понимание, что со стороны финансов всё обстоит ограниченно – средств на аренду студии и последующий найм пары-тройки сотрудников у разработчиков не ААА-масштаба обычно нет, следовательно приходится прибегнуть к ресурсам искусственного интеллекта. Грамотный специалист тут же замечает кучу неточностей в ответах ИИ, подмечает миллион ошибок, учится писать чёткие и структурированные ТЗ, и, в общем-то, полностью погружается в полноценный менеджмент собственного проекта.

Что же теперь? Теперь же нужна структура внутренней работы. Нужен понятный механизм, который разработчик будет проворачивать изо дня в день не напрягаясь: оформить ТЗ по таким-то принципам и шаблону, получить и отсортировать ответы одного или нескольких ИИ, подправить их и подумать над местом для дальнейшего внедрения и, возможно на следующий день, само внедрение нового функционала в существующий проект. Код чист, логика совершенна, структура проекта не пострадала, а новый функционал – появился! Идеально, не правда ли? Есть лишь одна проблема – рано или поздно масштабировать становиться нечего.

Допустим, у вас бизнес среднего масштаба, есть свой веб-сервис, и вы не хотели бы выходить на более крупные рынки. Заняли себе спокойно нишу и сидите в ней, горя не видите. Зачем и куда масштабировать? Раз в полгода допиливать мелкие аспекты, раз в год-два – переписывать дизайн некоторых объектов для презентабельного общего вида. Либо же вы разработчик open source ПО или видеоигры. Ваш проект имеет весь тот функционал, который вы и планировали добавить, а аудитория запросто разбирается в вашем коде и дополняет функционал/делает модификации по необходимости. И программировать, собственно, давно уже устали. Куда дальше?

Никуда. Сегодняшние технические средства позволяют отойти гораздо дальше на этапе индивидуальной разработки, чем это сделал тот же Маркус Персон с Minecraft. Если бы в его время был ИИ, разработка надоела бы ему гораздо позже (при условии адекватного использования данной технологии, в чём, по крайней мере я, не сомневаюсь). Но в любом случае, разработка рано или поздно надоест. Пройдя этот путь можно сделать лишь одно: ещё раз убедиться в исправности работы всех основных систем и передать проект либо в руки сообществу, либо в руки компании, имеющей как ресурсы, так и людей...

Но давайте не будем о грустном? Каждая новая видеоигра, приложение или даже веб-сервис – это отдельные кирпичики в огромном цифровом пространстве, цифровом следе человечества даже можно сказать. Люди сначала придумали, как машина может считать с помощью двоичного кода, после спроектировали низкоуровневые Ассемблеры, после собрали операционные системы и первые приложения на более высокоуровневых языках (по типу C), разработали на базе компилируемых ЯП и интерпретируемые, с более удобным и понятным синтаксисом, а следовательно – большими возможностями для дальнейшего творчества. Всё это – творчество! Видеоигра Minecraft была основана на Infiniminer и наработках Нотча, но именно Minecraft задала тон всему раннему YouTube, а YouTube получил первую столь массовую огласку именно благодаря зародившемуся на этой базе формату летсплеев. Каждый элемент сети связан между собой, потому это и сеть.

Понижение порога входа

Поговорим об общем беспокойстве. Слышал много раз мнение, что ИИ создал условия для понижения порога входа в программирование. Во-первых, с каких пор это плохая новость? Распространение Python тоже заметно понизило порог входа в IT-сектор, так как изначальный C – гораздо менее читабелен, что факт. Да, у C есть свои преимущества, и я рад видеть, когда люди помимо Python начинают изучать и какой-либо другой ЯП, будь то C или Java, но так или иначе понижение порога входа – это означает создание условий для расширения сообщества. Библиотеки, плагины, свободное ПО – всё это будет расширяться за счёт новых программистов, будут появляться новые системы, новые алгоритмы, будут создаваться новые проекты и развиваться новые идеи. Неизвестность, разумеется, пугает, но давайте не будем относиться к этому как к изначально чему-то плохому. Конечно, исключительный вайб-кодинг приводит только к созданию нечитаемого кода, как я сегодня уже разъяснил. Но ведь все с чего-то начинали, и, возможно, каждый новичок рано или поздно пойдёт дальше в этом пути. Разве ваши программы были поначалу идеальными?

Понижение порога входа – естественный процесс. Программисты на Ассемблере дали базу для программистов на C, а те в свою очередь – для программистов на интуитивно понятных языках программирования, читающихся буквально как английский язык (Python, Ruby). Теперь нейросети позволяют создать своё простое приложение любому, это верно, но чтобы расширять созданные проекты и дополнять их – придётся погружаться в язык программирования, на котором данный проект написан (веб-проекты на JS, десктоп и мобильные на Java, например). А текущие специалисты получили прекрасный инструмент для интеграции новых фишек в свой код. Главное, не путать молоток и руку, и всё будет нормально.