ВАЙБКОДИНГ: ЗАРАБОТАЙ НА ИИ

Отсюда пароли в коде, отсутствие проверок и всё остальное, что разбирается в четырнадцатой главе.

Третье: она уверенно ошибается.

Неправильный ответ выглядит так же убедительно, как правильный. Человек в такой ситуации мнётся и говорит «наверное». Модель не мнётся никогда.

Для новичка это опаснее всего: он не может отличить уверенность от правоты, потому что у него нет своего опыта для сравнения.

Разбор 3. Парсер цен для оптовика

Задача. Отслеживать цены пяти конкурентов, чтобы не продавать дешевле, чем надо, и не выпадать из рынка.

Что собрали. Скрипт, который раз в сутки обходит пять сайтов и складывает цены в таблицу.

Сколько заняло. Один вечер, около четырёх часов.

Сколько заплатили. 12 000 ₽.

Что сломалось. Через три недели один из пяти сайтов поменял вёрстку, и скрипт начал собирать пустоту. Молча: он не сообщал об ошибке, просто писал пустые строки.

Заказчик заметил через десять дней, когда обратил внимание, что у одного конкурента цены не меняются.

Сколько стоило. 6 000 ₽ за починку. И, что дороже, десять дней решений, принятых по неполным данным.

Что надо было сделать иначе. Спросить: «как я узнаю, что скрипт перестал собирать данные?»

Это тот самый вопрос про уведомление об ошибке, которого нет в стандартном ответе. Модель добавляет проверку охотно, если попросить.

Разбор 4. Тот же парсер, собранный правильно

Что добавили бы. Проверку, что данные пришли. Уведомление в мессенджер, если сайт не ответил или ответил пустотой. Сохранение предыдущих значений, чтобы было видно, когда цифры перестали меняться.

Сколько заняло бы. Плюс полтора часа.

Сколько стоило бы. Те же 12 000 или на пару тысяч больше.

Что сломалось бы. Ровно то же самое: сайт поменял вёрстку. Разница в том, что заказчик узнал бы об этом в тот же день, а не через десять.

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

Разница в том, узнаете ли вы об этом раньше клиента.

Почему термин прижился и почему он вредит

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

Слово точное, и в этом проблема.

«Отдаёшься ощущению» описывает ровно то, что делает новичок, и ровно то, из-за чего он потом попадает к Тагиру.

Термин закрепил в головах, что это метод без понимания. Дальше логика разошлась в две стороны, и обе неверные.

Одни решили: раз без понимания, значит, это не настоящая работа и платить за неё нечего. Отсюда «вайб-кодить за семь тысяч».

Другие решили: раз без понимания, значит, понимать и не надо. Отсюда двести двадцать проектов в тетради.

Как было бы правильнее. Назвать это управлением исполнителем, который делает мгновенно и буквально. Тогда сразу понятно, что работа состоит из постановки задачи и приёмки, а не из ощущений.

Но название уже прижилось, и я им пользуюсь, чтобы книгу нашли те, кто её ищет.

Практический вывод из этого рассуждения один. Если вы представляетесь заказчику как вайб-кодер, вы сами подсказали ему, сколько это стоит.

Женя из восьмой главы это слово не употребляет вообще, хотя пользуется теми же инструментами. Алия — тоже. Тагир говорит «я чиню то, что собрали быстро», и берёт за это по три тысячи в час.

Как выглядит хороший запрос

Раз уж глава техническая, приведу единственный практический кусок, который в ней есть. Дальше книга к этому не возвращается.

Плохой запрос:

Напиши бота для записи в салон.

Получите бота. Он будет работать и сломается через пять месяцев, как у Кирилла.

Хороший запрос устроен из четырёх частей.

Первая: кто и что делает.

Салон на двух мастеров, около двадцати записей в день, клиенты записываются сами через телеграм.

Вторая: что должно происходить.

Выбор даты, времени и мастера. Занятое время не показывать. Клиент может отменить запись. Мастер видит свой день списком.

Третья, самая важная: что бывает, когда не так.

Двое выбирают одно время одновременно. Клиент отменяет за час. Мастер заболел, надо перенести весь день. Человек нажал «назад» три раза подряд.

Четвёртая: что вокруг.

Данные должны сохраняться так, чтобы не пропали при перезапуске. Ключи не в коде. Нужны логи, чтобы можно было разобраться, если что-то потерялось.

Разница в результате. По первому запросу получается то, что собрал Кирилл за выходные и чинил потом полтора года.

По второму получается то, что собрал бы Женя из разбора 2, и займёт это на два часа больше.

Обратите внимание, из чего состоит разница. Не из технических терминов и не из хитрых формулировок. Из третьей части: перечня того, что пойдёт не так.

Эту часть невозможно написать, не зная, что бывает. И вот здесь опыт стоит денег, а умение формулировать запросы не стоит ничего: формулировке я вас только что научил за страницу, а перечень неприятностей набирается годами.

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

Где проходит граница

Вопрос, который задают чаще остальных: а что этим нельзя сделать?

Честный ответ: почти всё можно, но есть три зоны, где начинаются проблемы.

Зона первая: размер.

Пока проект помещается в вашу голову, всё идёт хорошо. Как только вы перестаёте помнить, что где лежит, начинается деградация: вы просите поменять в одном месте, ломается в другом, вы не замечаете.

Граница проходит примерно на третьем-четвёртом месяце работы над одним проектом. Не по количеству строк, а по тому моменту, когда вы открываете свой же файл и не узнаёте его.

Зона вторая: нагрузка.

Решение, которое прекрасно работает на ста записях, на сорока тысячах начинает открываться двадцать секунд. Модель об этом не предупреждает, потому что при сборке записей было три.

Это ровно то, что произошло в разборе 11: файл вырос, страница встала.

Зона третья: то, чего нет в интернете.

Модель хорошо знает распространённое и плохо редкое. Задача, похожая на тысячу других, решается прекрасно. Задача, которой ни у кого не было, решается плохо или уверенно неправильно.

Практический признак. Если по вашей задаче в интернете полно обсуждений, действуйте смело. Если вы ищете и находите три ветки форума десятилетней давности, готовьтесь к тому, что модель начнёт выдумывать.

И общее правило по всем трём зонам. Граница не в том, что модель не справится. Граница в том, что вы не заметите, что она не справилась.

Пока вы понимаете результат, вы в безопасности. Как только перестали понимать и начали доверять, вы вышли из зоны, где можно за что-то отвечать. А отвечать, как выяснится к концу книги, и есть то, за что платят.

Сколько стоит инструмент и что это меняет

Короткая арифметика, которую редко приводят.

Платная подписка на нормальный инструмент стоит около двух-трёх тысяч рублей в месяц. Для человека, который берёт хотя бы один заказ в месяц, это меньше десяти процентов дохода.

Что за эти деньги происходит с экономикой работы.

Раньше себестоимость проекта состояла из вашего времени. Сорок часов работы — сорок часов, других вариантов не было.

Теперь себестоимость состоит из вашего времени и почти бесплатного машинного. Причём машинное заменяет ту часть, которая раньше была самой долгой.

Отсюда неочевидное следствие. Раз себестоимость упала, а цена упала ещё сильнее, значит, упала не цена работы, а цена того куска работы, который заменился.

Всё остальное не подешевело ни на копейку. Разговор с заказчиком занимает столько же. Выяснение задачи занимает столько же. Внедрение и обучение людей — столько же.

Именно поэтому в книге дальше почти нет кода: подешевела ровно та часть, о которой все говорят, и не подешевело всё, о чём молчат.

Чего не стоит ждать

Три ожидания, с которыми приходят и которые не оправдываются.

«Я научусь программировать по ходу».

Не научитесь, и это нормально. Вы научитесь другому: описывать задачи и распознавать, когда результат не тот. Это отдельный навык, он полезный и он не про код.

Кирилл через полтора года работы не может написать двадцать строк без модели. При этом зарабатывает больше, чем средний джун после года курсов.

«Скоро я смогу собирать сложное».

Сможете собирать среднее. Сложное упирается не в код, а в то, что при росте системы количество связей растёт быстрее, чем ваше понимание.

Граница проходит примерно там, где вы перестаёте помнить, что где лежит. Обычно это три-четыре месяца работы над одним проектом.

«Хороший промпт решает всё».

Промпты — самая переоценённая часть темы. Разница между посредственным и отличным запросом существует, но она куда меньше разницы между человеком, который знает, о чём спросить, и человеком, который не знает.

Список из тридцати вопросов в четырнадцатой главе стоит дороже любого сборника промптов, и он не устареет со следующей моделью.

Что стоит держать в голове про инструменты

Одна страница, и книга к этой теме больше не возвращается.

Инструменты меняются каждые полгода. Всё, что я здесь назову по имени, к моменту чтения может устареть. Поэтому имён почти нет.

Принцип выбора один: берите то, что видит ваш проект целиком. Отдельное окно, куда копируют куски, работает вдвое хуже, чем инструмент, встроенный в редактор.

Платить стоит. Бесплатные версии заметно слабее на длинных задачах. Разница в качестве больше, чем разница в цене, и окупается первым же проектом.

Не гонитесь за новинками. Смена инструмента стоит две недели привыкания. Менять имеет смысл раз в год, а не каждый раз, когда вышло что-то громкое.

И главное. Вопрос «каким инструментом пользоваться» занимает в этой работе примерно два процента внимания. Остальные девяносто восемь — о чём спросить, что проверить и что делать, когда сломается.

Если вы ловите себя на том, что читаете сравнения инструментов дольше, чем разговариваете с заказчиками, вы занимаетесь не тем.

[ВСТАВКА АВТОРА — 2000–3000 знаков]

Что должно быть в этом слоте. Как устроена ваша работа с моделью на практике: чем пользуетесь, что отдаёте, что делаете руками.

Опорные вопросы:

• Какими инструментами пользуетесь сейчас и почему этими?

• Что вы отдаёте модели целиком, а что не отдаёте никогда?

• Сколько времени в вашем проекте занимает собственно сборка?

• Что вы делали руками год назад и перестали?

Почему сюда. Глава техническая, и без живого голоса она читается как обзор. Один абзац от практика превращает её в разговор.

Практика

Упражнение первое: сорок циклов. Соберите что-нибудь маленькое и специально сломайте пять раз. Считайте, сколько раз вам пришлось вернуться к модели. Это и есть ваш темп обучения.

Упражнение второе: три вопроса про ошибки. На следующем проекте спросите: как я узнаю, что оно сломалось? Что будет, если данные не придут? Что произойдёт при двойном нажатии?

Упражнение третье: попробуйте объяснить. Возьмите любой кусок кода, который вам дали, и объясните вслух, что он делает. Не для проверки знаний — чтобы понять, где заканчивается ваше понимание. Эта граница и есть ваш риск.

Что дальше

Инструмент разобран, и больше мы к нему не вернёмся.

Третья глава короткая и неприятная: там объясняется, что именно вы сделали в те выходные, и это не то, что вы думаете.## Сцена: Кирилл объясняет Лиане, как это работает

Она спросила через месяц после того бота, за чаем.

— Слушай, а как ты вообще это сделал? Ты же не программист.

— Ну я попросил, оно написало.

— В смысле попросил? Своими словами?

— Ага. Написал: сделай бота для записи в салон, чтобы выбирали дату и время.

Лиана посмотрела на него с выражением, которое Кирилл потом видел у каждого второго заказчика.

— То есть я могла сама?

И вот здесь важный момент, который стоит разобрать, потому что этот вопрос вам зададут обязательно.

Неправильный ответ: «нет, там всё сложно».

Он неправильный, потому что неправда, и человек это почувствует. А когда через полгода он попробует сам и у него получится, он вспомнит, что вы его обманули.

Что ответил Кирилл тогда: «ну типа да, могла».

Честно и катастрофично для бизнеса. После такого ответа человек второй раз не придёт.

Что он отвечает сейчас, через полтора года:

— Могла. Первую версию собрала бы за вечер, честно. Дальше через месяц выяснилось бы, что двоих записывает на одно время, ещё через два, что отменить запись нельзя, а в декабре оно бы просто перестало открываться. И каждый раз ты бы сидела вечер вместо работы.

— А ты это всё знаешь?

— Я это всё сломал двадцать раз на других людях.

Разница между двумя ответами. Первый защищает миф, что это сложно. Второй признаёт, что несложно, и переносит ценность туда, где она на самом деле находится.

Первый ответ через год перестанет работать. Второй будет работать всегда, потому что опирается не на незнание клиента, а на ваш опыт поломок.

И эта разница — вся книга в одном диалоге.

Глава 3. Что вы на самом деле сделали

Короткая глава с одним утверждением, которое многим не понравится.

Утверждение

Вы не написали программу. Ни одной строчки.

Вы описали задачу, а программу написала модель. Это разные действия, и путать их дорого.

Почему это важно, а не придирка к словам

От того, как вы называете сделанное, зависят три вещи.

Первое: чему вы будете учиться дальше.

Если вы считаете, что написали программу, следующий логичный шаг — учиться писать программы лучше. Вы пойдёте изучать язык, разбираться в устройстве и через полгода будете уметь то, что модель делает за минуту.

Если вы понимаете, что описали задачу, следующий шаг другой: учиться описывать задачи полнее. Это дешевле, быстрее и стоит дороже.

Второе: как вы будете объяснять свою цену.

Продавец программ конкурирует с теми, кто продаёт программы. Их много, и модель у них та же самая.

Продавец понимания задачи конкурирует с теми, кто понимает задачу. Их мало, и седьмая глава показывает, насколько: пять процентов рынка против восьмидесяти.

Третье: за что вы сможете отвечать.

Нельзя отвечать за то, чего не понимаешь. Кирилл не мог объяснить, что происходит в третьей функции его бота, и потому не мог обещать, что она не сломается.

А вот за то, что бот записывает не больше одного человека на одно время, он отвечать может: это его решение, а не машинное.

Три слова, которыми люди описывают одно и то же

Проще всего показать разницу на том, как один и тот же вечер описывают трое.

Первый: «я написал бота».

Так говорит человек, который считает своей работой код. Дальше разговор с заказчиком идёт про код: на чём написано, сколько строк, а можно ли то же самое, но дешевле.

Второй: «я собрал бота».

Чуть честнее. Слово «собрал» признаёт, что детали были готовые. Но предмет разговора всё тот же: бот.

Третий: «я разобрался, как у вас устроена запись, и убрал из неё то место, где терялись клиенты».

Это описание той же работы, только названы не детали, а результат.

Проверьте на себе. Возьмите последнее, что вы сделали, и опишите тремя способами.

Что вы заметите. Третий вариант труднее всего произнести, потому что для него нужно знать, что у заказчика было до вас.

И вот тут собака зарыта. Люди говорят «написал бота» не из скромности и не по привычке.

Они говорят так, потому что про бота знают всё, а про дело заказчика — ничего.

Разница в словах — следствие разницы в том, что человек выяснил. Двадцатая глава целиком про то, как это выясняют, и стоит она в книге далеко не случайно: без первых девятнадцати глав она читается как советы по вежливости.

Почему это не переименование

Первое возражение, которое возникает: вы предлагаете то же самое называть красивее.

Нет, и вот проверка.

Возьмите любое из трёх описаний и попробуйте по нему назвать цену.

«Написал бота». Цена определяется тем, сколько берут другие за бота. Открываете биржу, смотрите, называете чуть меньше.

«Убрал место, где терялись клиенты». Цена определяется тем, сколько стоили заказчику потерянные клиенты.

Это не два способа сказать. Это два способа считать.

И считают они принципиально разное. В первом случае вашу цену назначает рынок исполнителей, во втором — экономика заказчика.

Разница на конкретных числах. Бот для записи на бирже стоит от трёх до двенадцати тысяч. Один потерянный клиент в салоне, который ходит раз в месяц по две с половиной тысячи, стоит за год тридцать тысяч.

Двадцать девятый разбор в двадцатой главе показывает эту разницу целиком: пять тысяч и сто девяносто за работу одной сложности в один и тот же день.

Что было на самом деле в те выходные

Разложим шестнадцать часов Кирилла по тому, что он делал.

Придумывал, что должно происходить. Выбор даты, времени, мастера. Никто ему этого не подсказывал: он представил себе клиентку с телефоном и решил, в каком порядке она будет нажимать.

Это заняло минут двадцать и было единственной творческой частью тех выходных. Всё остальное время он проверял и переспрашивал.

Замечал, что получилось не то. Бот записывал на прошлую неделю. Модель не считала это ошибкой: её никто не просил ограничивать даты. Заметил человек.

Это заняло часов десять из шестнадцати. Смотреть, тыкать, обнаруживать.

Объяснял заново. Оставшиеся часы.

Ноль часов он писал код.

Шестнадцать часов работы, из которых ни один не был тем, чем эту работу принято называть. И три тысячи рублей на выходе, назначенные по цене того, чего он не делал.

Кто на самом деле написал ваш проект

Вопрос звучит как философский, а ответ на него практический и касается денег.

Формально код написала модель. Вы нажимали «принять».

Но модель не выбирала, что бот спрашивает первым: услугу или время. Не решала, можно ли записаться на сегодня за час до приёма. Не думала, что делать, если мастер заболел.

Все эти решения принял человек, и в них вся программа и состоит.

Как это проверить. Возьмите два бота для записи, собранных двумя разными людьми по одному и тому же запросу.

Код будет похож процентов на семьдесят: модель одна.

Работать они будут по-разному, потому что решения разные.

У одного нельзя записаться на занятое время. У другого можно, и в двадцать четвёртом разборе видно, чем это кончается: две записи к одному инструктору и администратор, заведшая параллельно тетрадь.

Разница не в коде. Разница в том, что первый задал себе вопрос «а если двое нажмут одновременно», а второй не задал.

Отсюда вывод, который стоит записать.

Программу пишет тот, кто принимает решения. Код набирает тот, кто быстрее.

Последние два года эти двое разошлись. Раньше это был один человек, и потому их не различали.

Что теперь считается ошибкой

Полезно посмотреть, как изменилось само понятие ошибки.

Раньше ошибка была технической. Опечатка, неверный тип, забытая проверка. Она либо ломала программу сразу, либо вылезала на тестах.

Сейчас технических ошибок стало заметно меньше. Модель не делает опечаток и почти не путает синтаксис.

Зато выросла вторая категория, и она хуже. Ошибка в задании.

Как она выглядит. Программа работает ровно так, как вы попросили. Просто попросили вы не то.

Три примера из этой книги.

Бот записывает на прошедшую дату, потому что ограничить даты никто не просил.

Бот принимает заявки и открывает соединение с таблицей на каждую, потому что про двести заявок в час речи не было.

Форма показывает «спасибо, мы свяжемся» и не отправляет письма, потому что проверять отправку никто не просил.

Общее у всех трёх. Ни одну нельзя назвать ошибкой кода. Все три — ошибки в описании задачи, и все три обошлись дороже, чем любая опечатка.

Что из этого следует. Ловить их нельзя тем способом, которым ловят технические. Компилятор про них молчит, модель про них не спрашивает.

Ловит их только человек, и только тот, который представляет себе, что будет происходить в реальной жизни.

Это и есть та работа, которую вы делали шестнадцать часов и назвали «написал бота».

Как называется эта работа

Плохо называется, и в этом часть проблемы.

Ближе всего — то, что в больших компаниях делает системный аналитик: превращает «нам надо навести порядок» в перечень того, что должно происходить, включая случаи, когда всё пошло не так.

Восемь лет эта работа считалась вспомогательной. Настоящей работой считалось программирование, потому что оно было узким местом.

Узкое место переехало, а привычка называть главным программирование осталась.

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

Разбор 5. Три часа, которые изменили проект

Небольшой разбор, зато показательный.

Задача. Магазин автозапчастей, нужен калькулятор доставки на сайте.

Что собрали. Форму: вводишь адрес, получаешь стоимость.

Сколько заняло. Два часа.

Сколько заплатили. 8 000 ₽.

Что сломалось. Ничего. Калькулятор работал идеально.

Через месяц заказчик сказал, что стало хуже: заявок меньше, чем было без калькулятора.

Что выяснилось. Люди вводили адрес, видели стоимость доставки и уходили. Раньше они писали в чат, и там менеджер успевал сказать, что при заказе от пяти тысяч доставка бесплатная.

Калькулятор честно показывал цифру и убивал разговор.

Сколько стоило. Три часа на переделку: добавили строку про бесплатную доставку и кнопку «спросить менеджера». Бесплатно, потому что исполнителю было стыдно.

Что надо было сделать иначе. Спросить: а что сейчас происходит, когда человек спрашивает про доставку?

Один вопрос, тридцать секунд. Он бы вскрыл, что калькулятор решает не ту задачу.

Почему этот разбор здесь. Код был безупречен. Задача была понята неправильно, и никакое качество кода этого не спасает.

Проверка: опишите свой проект без слова «сделал»

Упражнение, которое многое показывает за минуту.

Возьмите последний проект и опишите его, не употребляя глаголы «сделал», «написал», «настроил», «разработал».

У большинства получается ступор. Оказывается, вся история проекта в голове хранится как перечень того, что вы делали, и больше там ничего нет.

Как выглядит описание, когда получается.

У неё уходил весь день на переписку с клиентами. Теперь клиенты записываются сами, а она смотрит в телефон два раза в день.

Ни одного слова про работу. Только про то, что изменилось у человека.

Зачем это нужно. Ровно так надо разговаривать с заказчиками, и этому посвящена четвёртая часть книги. Но начинается всё раньше: с того, как вы сами про себя думаете.

Человек, который держит в голове перечень своих действий, будет продавать действия. Человек, который держит изменения в чужой жизни, будет продавать изменения.

Разница в голове появляется раньше разницы в цене.

Ещё одно, о чём стоит сказать в этой главе

Есть неприятное следствие из всего сказанного, и честнее назвать его сразу.

Если ваша ценность в понимании задачи, то ваш заказчик может понять её сам.

Владелец студии маникюра знает про свой день больше, чем любой исполнитель. Если он потратит вечер и сядет разбираться, что должно происходить при отмене записи, он справится не хуже вас.

Это правда, и это уже происходит: часть заказчиков собирает себе инструменты сама.