Как программировать с помощью ИИ
Давайте я начну с наиболее распространённых вопросов:
— А что, разве ИИ может написать код?
Может. Если вы взяли предметную область, которая не является вашим локальным эксклюзивом (то есть похожие задачи уже многократно были решены), и язык программирования, про который в интернетах много информации, то ИИ может написать код.
— Ну ОК, а может ли он написать код, который правильно работает? Ну, на регулярной основе, а не по чистому везению?
Может. Сейчас он даже чаще всего будет работать сразу. Иногда, правда, потребуются исправления, которые вы тоже можете предложить сделать ИИ. Но после этого скорее всего заработает. Причём меньше всего итераций нужно будет, если у вас какой-то ИИ-агент, но и в чат-ботах сейчас с этим тоже норм.
— Так что тогда, программисты, типа, больше не нужны?
А тут, знаете ли, в общем случае — хз.
Во-первых, мы не знаем, что будет с развитием ИИ через год или через два. Быть может, он уже завтра станет настолько крутым, что будет угадывать все детали с полуслова, проектировать приложение так, что ни один человек так не сможет, и тестировать его лучше, чем миллион живых тестировщиков.
А во-вторых, это зависит от уровня программиста.
Если мы рассматриваем чувака, который как-то что-то может запрограммировать, если ему рассказать все детали, а потом пристально следить за каждым действием, то таки да, время таких программистов ушло. Для такой работы сейчас гораздо выгоднее нанимать ИИ: будет гораздо быстрее, гораздо надёжнее и гораздо дешевле.
Если мы рассматриваем чувака, который обладает некоторой степенью автономности, относительно аккуратен, способен до некоторой степени разобраться с сопредельной областью и сам спроектировать фрагмент кода, который в основном будет соответствовать пожеланиям, то… и такой чувак тоже уже на грани проигрыша ИИ, если не уже за ней.
Кто тогда нужен из числа живых человеческих людей? Архитектор? Знаток технологий? Гений?
Ну, тут в одно слово не ответить.
Дело в том, что ИИ хорошо пишет код. Но при этом он пишет его плохо. И этому он научился у людей, если что — обоим двум.
Была когда-то такая идея — «энтерпрайз-программирование», заключающаяся в том, что если хорошо прописать стандарты, то программы можно будет клепать аки на конвейере. Конечно, для этого нужен квалифицированный разработчик, но его квалификация во многом сводится к тому, что он хорошо запомнил и понял сабжевые стандарты. И прилежно им следует. Тогда программа получается гладкая, предсказуемая, хорошо покрытая тестами и в основном правильно работающая.
Но плохая.
Не самая плохая из возможных — не исключено, без следования стандартам в данном случае было бы на порядки хуже, но всё равно плохая.
Почему?
Ну, потому что конвейер обладает одной большой проблемой: его тяжело модифицировать. Давайте я вам это покажу на пальцах:
Вы штамповали на конвейере девайс Икс, однако талантливый инженер придумал усовершенствование. Поэтому инженер конвейера дописал к процедуре производства ещё три действия, которые позволяют получать Икс-2 на том же конвейере. Потом был придуман Икс-3, который добавил ещё пять действий. Потом Икс-4 — он добавил двадцать одно действие. Каждый раз добавлялось всё больше действий, поскольку это не была переделка заново, это была попытка небольшой модификации того, что уже есть. Вы пытались получить Икс-2 не с чистого листа, а доработкой (переделкой, модификацией) Икс. Затем Икс-3 делали модификацией Икс-2. И так далее.
Это выглядит примерно как то, что вы выпускали пикап Тойота. Потом поставили на него пулемет. Потом обшили его бронелистами. Потом приделали вместо колёс гусеницы. Потом заменили пулемет на пушку. Получился ли у вас танк? Ну, наверное — только какой-то очень хреновый танк.
По идее, уже на этапе Икс-2 надо было считать три добавленных действия временными и параллельно заниматься переделкой всего процесса, но идеология конвейера так не может. В результате всё очень аккуратно, по процедуре, покрыто тестами, но реально это всё сильнее напоминает здание, возведённое на базе стапицот подпорок, костылей и дополнительных заклёпок.
Да, все они проверены и покрыты тестами, но на каждом следующем этапе всё тяжелее понять, как это вообще работает.
Поэтому «энтерпрайзный» код традиционно состоит из миллионов лишних строк. Хотя их можно было бы заменить тысячей содержательных, если вовремя производить замену.
Чисто для примера. У нас есть объект «человек», который содержит имя, фамилию и возраст. Если записать это на «энтерпрайз-Java», то этот объект, только что описанный одной строкой на разговорном языке, займёт несколько десятков строк. Поскольку в нём мы завели поля, определили геттеры и сеттеры, конструкторы, конвертацию в строку, hashCode и ещё чего-нибудь до кучи. Но то же самое на Scala можно записать одной строкой. Точнее, не то же самое — функциональность будет даже побольше.
В более современной Java тоже можно так. Менее лаконично, чем на Scala, но всё-таки гораздо более лаконично, чем раньше. Однако ИИ, увы, в основном смотрел на примеры в «традиционном стиле». Просто потому, что их в интернете гораздо больше. А больше их потому, что люди писали в основном так. И многие даже продолжают писать так, хотя можно уже и иначе.
Далее. Если что-то откуда-то читается, то оно ж может прочитаться с ошибкой. Начинающий разработчик просто не подумает про такой случай, но профессиональный энерпрайз-разработчик напишет перехват и логирование ошибки. Каждой ошибки. В каждом месте. Потому что логика энтерпрайз-конвейера вот такая.
И к десяткам энтерпрайз-геттеров добавятся десятки энтерпрайз-перехватов.
И ещё десятки строк в конфигах.
И ещё десятки строк для каждого из десятка других обязательных ритуалов.
Или сотни.
И код займёт тысячу строк там, где мог бы уложиться в десять при той же или даже лучшей функциональности.
И это всё, конечно, очень аккуратно, но вам теперь надо поддерживать тысячу строк, вместо десяти. И каждое дополнение тоже вписывать в тысячу. Каждый раз. И само дополнение будет занимать сотни строк вместо трёх, поскольку энтерпрайз в среднем запрещает вам переделывать всё — он предлагает вам только аккуратно дописывать в сто мест тщательно структурированный код, который, тем не менее, превращает программу в адское спагетти.
Если смотреть формально и «в моменте», то это — надёжный подход. Всё по стандартам, шаги определены, как покрывать тестами понятно, как проверять — тоже. Но в практическом плане сие — способ навсегда законсервировать то, с чего когда-то началась программа, а заодно и все подходы к программированию. И рано или поздно получить огромный кусок легаси, в который теперь уже точно невозможно что-то добавить, не отломав при этом что-то другое.
Да, есть подходы, при которых то же самое получится гораздо быстрее, но и так оно получится тоже. Ибо, чтобы так не получалось, всегда надо пытаться сократить, обобщить, улучшить глобально, сделать понятнее и, самое главное, сделать так, чтобы код в основном состоял из записанной мысли, а не из исполненных ритуалов.
Такому энтерпрайзу давно уже появились альтернативы, однако он всё ещё мэйнстрим — и именно на нём в основном обучался ИИ — как я уже сказал, потому что именно на нём в интернетах больше всего примеров.
Поэтому по умолчанию ИИ напишет вам, да, работающее, но в стиле энтерпрайза. И каждую предложенную вами модификацию тоже будет предлагать в стиле энтерпрайза. И в какой-то момент ни вы, ни ИИ уже не сможете понять, что тут происходит, а потому каждая следующая модификация станет всё более и более опасной. И многословной.
Это так из-за ИИ?
О нет, это так из-за людей: у них ведь чаще всего сейчас так же. ИИ просто у них этому научился. И у него получается не хуже, чем у этих людей. Даже аккуратнее.
И быстрее.
Поэтому с живыми человеческими программистами до полной задницы на костылях вы бы ехали год, а с ИИ вы приедете к ней за неделю, если не за два дня. Проект в этот момент — через неделю — кстати, будет работать не хуже, чем у людей через год. Но и задница в нём будет не менее полная.
Поскольку, таки да, ИИ аккуратно напишет все геттеры, перехваты ошибок и конфиги — вы ему можете даже эти детали не уточнять: он гораздо лучше начинающих программистов понимает важность всего этого в рамках энтерпрайза. Однако сейчас, как и большинство человеческих программистов, его ни в какой момент не стриггерит на мысль: «блин, чо-то тут уже до хрена повторов и бойлерплейта — надо бы всё переделать».
И, собственно, основная роль того программиста, который всё ещё нужен, вот в этом — смотреть на результаты, анализировать их и вовремя говорить: «стопэ, друг, дальше не движемся без глобальной переделки».
Ну и ещё заранее сказать: «чел, ошибки мы перехватываем где-то в одном месте, а не в каждой строке отдельно, и не try-catch, а чем-то более вменяемым». И не только сказать, но и следить, чтобы ИИ про это не забыл. И не только про это.
Хотя ИИ эти советы понимает и даже может более-менее реализовать, если ему в явном виде их вовремя озвучить, до некоторых изящных и очень абстрактных решений он сам не додумывается. Например, как и большинство программистов, он не будет изобретать локальный специализированный язык — даже тогда, когда он сократил бы код раз в сто. Нет, он будет продолжать пилить на чём есть. Как и люди в основном.
Да, так будет не «вообще, поскольку он — бездуховная железяка», а только «сейчас». Вот это самое «сейчас» тут можно добавить к каждому абзацу, и когда-нибудь оно поменяется, но пока оно не поменялось в достаточной степени.
Например, в ряде случаев ИИ может придумать ничего так специализированный язык, но он делает это только тогда, когда ему человек напрямую сказал: «а вот для этого, этого и вон того придумай язык». И ещё желательно подсказать, как именно этот язык должен выглядеть в идеале.
Тогда что получается? Такой вот не-как-все-программист не нуждается в ИИ, выдающем энтерпрайз?
О нет. Программист всё ещё может сократить время разработки в тысячу раз и при этом писать на расслабоне. Поскольку ИИ просто офигенен в объяснениях каких-то библиотек, которые программист впервые видит, в подсказках как чо сделать, и даже в написании кода или его переписывании под только что пришедшую в голову концепцию.
Без ИИ программисту бы пришлось читать мануалы и форумы пару месяцев, а ИИ пишет ему «так себе», но реализацию. По которой, как по примеру, можно понять, что и как работает в тех библиотеках и предметных областях, которые программист не особо-то встречал раньше. А поняв это, понять и как написать код с той же функциональностью, но лучше, короче и надёжнее. Сделать реализацию нескольких ключевых мест и несколько переделок, которые будут примером — теперь уже для ИИ. И сказать ИИ: «дружище, перепиши вот эту твою фигню вот так».
И ИИ перепишет.
Конечно, это тоже надо проверить. И, конечно, совершенно не обязательно, что это была последняя переделка и последняя смена концепции — скорее всего, будет дофига ещё. Но с ИИ этот программист справится за день. А без ИИ у него бы ушло несколько месяцев.
Если ИИ — это ещё и агент, а не просто чат-бот, то он, вдобавок, может помнить, о чём они с программистом говорили раньше, контексты задач, предпочтения программиста, что ещё сильнее экономит время непосредственно программиста, поскольку код ИИ будет получаться ближе к тому, что программист хочет, а объяснять детали проектов при этом придётся меньше.
Наверно, получится ещё лучше, если ИИ будет дообучаться в перерывах — хотя бы в виде LORA (микронейросеть, которая цепляется к основной), но такое я пока не имел возможности попробовать.
Однако при любом из этих раскладов не только ИИ и не только программист тут источник знаний, идей, кода и стиля, но они оба. Вдвоём они работают гораздо быстрее и выдают гораздо более хороший результат за то же время, что выдавали бы по отдельности. И они — при правильном раскладе — ещё и учатся друг у друга, чем в перспективе ещё сильнее ускоряют процесс и улучшают код.
И вот это вот дело сильно отличается от представлений о «вайб-кодинге», как о процессе, где человек в общих чертах трындит про свои невнятные желания, а ИИ фигачит код сразу в продакшн, при том, что человек этот код даже не читает.
В чистом виде «вайб-версия» на данном этапе развития хороша только в том случае, если надо сделать утилиту для локальной задачи, выполнить эту задачу и выбросить эту утилиту. Если же это что-то долгоиграющее, то в «вайб-версии» получится примерно то же, что обычно получается у людей в энтерпрайзе: поначалу работает и написано в некотором смысле аккуратно, но развивать и поддерживать в перспективе это станет невозможно, а легаси имеет все шансы затянуться на десятилетия.
Тем не менее, обратное — «ИИ хорошему программисту вообще не нужен» — тоже неверно: сколь бы крутой программист ни был, программисту сравнимой крутости, использующему ИИ, он будет прямо очень сильно сливать. И чем дальше, тем сильнее.
