Привет, Хабр! Это моя третья статья здесь. В первой я рассказывал, как ушёл из найма во фриланс. Во второй — про методологию работы с LLM, документацию и почему это не вайбкодинг. Сегодня хочу поговорить о другом - о страхе, о зоне комфорта.
О том, почему половина комментариев под этой статьёй будет от людей, которые даже не пробовали.

1. Цифры, которые никого не убедят

Два года назад я стартовал на фрилансе с доходом 40 тысяч рублей в месяц. Сейчас — 250 тысяч - рост в 6 раз. У меня нет профильного образования — только базовые бесплатные курсы на Stepik. Я не работал в Яндексе, не писал компиляторы, не контрибьютил в опенсорс - хотя в этом направлении руки чешутся)

Я делаю телеграм-ботов, мини-аппы, ассистентов для селлеров на маркетплейсах, RAG-системы, автоматизации для бизнеса. Небольшие проекты для малого и среднего бизнеса. Не enterprise - два раза находились заказчики, которым требовался специалист моего формата - но я ними не сходился во мнениях и условиях. Наверное оно и к лучшему)

Год назад я перестал писать код руками. Совсем. И своим стажерам не рекомендую! Сначала это были итеративные исправления в файлах по каким то большим неясностям - потом я начал предоставлять все больше контекста о структуре проекта в LLM - и это было именно в чатовых версиях) А после появились Cursor, CLI. Про свою методику работы с LLM я писал в другой своей статье - поэтому тут без деталий. Тут больше философия.

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

2. Конкретные кейсы

Больше конкретики:

Ассистент для селлеров Wildberries — стоимость 350к рублей. Бот работает со складами, товарооборотом и отзывами. Присылает уведомления о новых заказах, выкупах, отменах и возвратах. Отслеживает критические остатки на складах относительно динамики продаж. Фильтрует уведомления об отзывах по количеству звёзд. Есть статистика по складам, аналитика при помощи GPT — выдаёт анализ и графики в разрезе установленного временного окн. Парсинг конкурентов по ссылке, сбор семантического ядра по описаниям товаров для дальнейшего использования в генерации своих карточек - описания и обработка фото товаров. Ну и вишенка на торте - RAG для работы с базой данных - векторизация основного Postgres.
Это не лендинг. Это система управления складом с аналитикой, интеграциями и AI-фичами.

Бот для примерки товаров — 100к рублей. Бот получает доступ к каталогу товаров с фото. Пользователь загружает своё фото, GPT валидирует фото — и при помощи Nano Banana примеряем товар. Пользователь сразу получает ссылки на маркетплейсы, плюс подбор подходящего размера исходя из заполненных данных.

Онлайн-нарды в TG Mini App — 300к рублей. Со ставками в TON и мем-коине через смарт-контракты - эскроу контракт, удерживающий банк ставки и отправляющий выйгрыш победителю с учетом комиссии владельца проекта. Да, тот самый случай, где «безумие и отвага решает», как написал один комментатор.

Прототипы каждого этапа — часто с моками — доставляю за неделю-две. Не за месяцы.
Это проекты последних 3 месяцев, код которых на 100% сгенерирован LLM. Проекты в продакшене, заказчики довольны, работаем дальше - расширение, поддержка.

3. Про факапы честно

Был один серьёзный факап, повлиявший на продакшн. Но проблема была не в LLM — в процессе.

Заказчик показал ТЗ - я обозначил цену в 400к, он сказал что дорого - можно ли что то придумать что бы сделать дешевле? Тогда я обрезал все до узкого MVP (убрал смартконтракты, мониторинг, заменил бэк с GO на TS и еще куча мелочи). И стоимость в 140к. Я не поставил чётко границы в ТЗ. Заказчик начал требовать неозвученного в начале, я начал соглашаться - ну лох, чо. Мы выбились из контекста, документация перестала быть актуальной — потому что начали надстраивать новый функционал на ещё незавершённое ядро. Поплыло и ядро, которое было сложно восстановить.
Моя ошибка — что согласился и не проставил границы. Пояснил заказчику, что не стоит так отходить от ТЗ. Разрулил, мудрость прокачал)

Были случаи, когда затягивал сроки из-за неверных инструкций для нейронок. Например, не озвучил в документации, что мы строго не трогаем старый код — только достраиваем новое. Из-за отсутствия этого ограничения поплыла старая логика, пошли циклы ошибок
Тут что важно: не давать нейронкам постоянно самим править ошибки. Необходимо вносить новый контекст самостоятельно, проверять гипотезы. В этом и отличие — не-разработчик даже не сможет предположить, где зарыта собака.

4. Что говорят скептики

Под моими статьями и в комментариях к другим постам про LLM-разработку — одни и те же аргументы. Разберу конкретные цитаты.

«Не проверять код после LLM — это, конечно, мощно. Никакая документация не спасёт от галлюцинаций»

Галлюцинации есть. Баги есть. А у людей их нет? Разница в том, что я трачу 10% времени на генерацию кода и 90% на тестирование и отладку. Раньше эти 10% были не часами, а неделями. Документация — не защита от багов, а способ держать контекст и не уходить в циклы. Без неё LLM начинает петлять по одному и тому же переваренному болоту.

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

Но мы как раз делаем через LLM системы управления складами — для Wildberries, со статистикой, аналитикой, RAG. Всё работает. Вопрос к скептику: а вы пробовали такие проекты через LLM делать? Именно на собственном опыте?

«Ни в коем случае не доверю написание критичного проекта LLM. Ошибка может вылезти с неожиданного ракурса. Владелец понесёт серьёзные убытки»

Я еду на этой схеме уже год. Жалобы были — но все оперативно решены. Это в пределах ошибок, которые возникают и при обычной разработке. По времени и финансовому выхлопу — вижу только плюсы. Но предостережения не забуду.

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

Это не так. У меня был опыт ручной разработки, много проектов провёл и плавно перешёл к LLM. По всем показателям — времени и финансовому выхлопу — вижу только плюсы. Бот за 3 часа вместо 3-4 дней. Лендинг с бэкендом за 3 часа вместо недели. Это не теория — это моя реальность.

«Когда в команде нет осведомлённости о кодовой базе, все решения принимаются с помощью "fix it now", а архитектурой даже не пахнет — дело запахнет жареным»

Согласен. Именно поэтому AI-driven — это не значит без человека. Инженер необходим. LLM не заменит понимание архитектуры. Но станет основным инструментом. Посмотрите на динамику: в 2023-24 я ещё и думать не мог о таких вещах как Cursor и Claude Code. А что будет ещё через два года?

«Это же ненадолго. Отвыкнем вручную писать быстро»

Что значит «ненадолго»? Какой практический смысл кодить руками? Это медленнее для заказчиков — им важна скорость, это главное конкурентное преимущество. Они готовы платить больше за эту скорость.

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

5. Про стажёров

Я беру новичков с малым опытом - в первую очередь потому что у них разум не забит шаблонами, нет строгих рамок. Людей, у которых это не основная деятельность — у меня пока нет возможности полностью обеспечивать им оплату труда. Договариваюсь на условия, в которых они тратят не более 8 часов в неделю.
Созваниваюсь и показываю конкретно на примерах своих проектов, на конкретных задачах — в живом режиме — как управлять нейронками. Потом даю боевые задачи. Всегда боевые. Получаю результаты, проверяю, выявляю ошибки — и поясняю, как их не допускать. Опять же при помощи LLM.

Двух месяцев людям достаточно для приобретения самостоятельности. Чтобы я уже не тратил на них много внимания. Окупается отлично.
Один стажёр сначала отрицал использование LLM, стеснялся этого факта. Но когда показал, как работать с документацией и тестами — дело пошло. Теперь мыслит как инженер и архитектор, а не как печатная машинка для кода. Есть стажерка-студентка на профильном - им неистово вбивают в голову, что код надо писать строго руками, что все проекты заподозренные в генерации - будут откинуты. Поэтому по началу она так же скрывала этот факт, писала медленно - пока я четко не сказал: Только LLM
Теперь моя стажёрка делает лендинг с интеграцией бэкенда за 3 часа. Я просто объяснил методологию. Раньше это была неделя работы. У нее есть свободное время, на учебу и даже на сторонние проекты на фрилансе - как она атм работает -у же ее дело, но в наших проектах все делаем через нейронки.

При необходимости - я оплачиваю стажерам подписки на Cursor, или CLI - Codex или Claude Code + показываю как бесплатно настроить Gemini CLI. Сам я еду на Claude Code, иногда доплачиваю за Codex - этого достаточно.
Интересное наблюдение: затраты в месяц на LLM коррелируют с доходом) А так я трачу не более чем на 2 подписки в месяц.

6. Про страх и зону комфорта

Вот что меня реально интересует: почему люди с 10-15 годами опыта, которые видели смену технологий, фреймворков, парадигм — вдруг упираются именно здесь?

Ответ простой: страх.

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

Это некомфортно и больно. Я понимаю. Но это не повод отрицать реальность. тех кто делает все через LLM будет становиться все больше

Читаю комментарии: «да, наверное, круто, но я не рискну на своих проектах». Или «слишком дорого выйдет». Или «подождём, пока технология созреет». Или просто «с любопытством наблюдаю, жуя попкорн» (все это реальные цитаты, так же как из раздела 4 - про скептиков).

Это не анализ рисков. Это рационализация страха. Диванная аналитика от тех, кто не пробовал, но уже знает, что не сработает. У меня не было выбора. Нет образования, нет связей, нет страховки в виде оклада. Мне нужно было просто делать. Брать и делать - и оно получилось)

Люди развиваются линейно. Год опыта, два года опыта, десять лет опыта. Постепенно, предсказуемо, по накатанной. Например - ставить цель - читать на 1 книгу в месяц больше, чем в прошлый, повышать доход на 50к в год - это все примеры линейного развития. Дело в том, что линейное развитие упирается в физические пределы - тогда и приходил пора менять подходы, системы - увеличивать надо не количество, а качество.
Мир же развивается экспоненциально. Три года назад ChatGPT писал однострочные функции на Python. Два года назад — редактировал большие файлы и находил ошибки. Сейчас — Claude Code, Cursor, Codex. Целые системы за часы.

Вдумайтесь в эту динамику. Три года. Не тридцать, не десять. Три.

Раньше программисты были теми, кто тянул этот экспоненциальный рост. Люди создавали технологии, которые меняли мир. Теперь появилась технология, от которой мы рискуем отстать. Это не угроза — это смена парадигмы.
Человек, который развивается линейно в экспоненциальном мире — деградирует относительно этого мира. Не потому что тупой. Просто мир ускоряется быстрее, чем он успевает. Если человек развивается в одном темпе с миром - он идет в ногу со временем - но даже это -"Стоять на месте" - относительно окружающей среды)

7. Про отношение

За границей AI-assisted development — уже не философия и не эксперимент, а предмет исследований, отчётов и денег.

Не «кажется, что стало быстрее», а измеряют секундомером.

Например:

• В рандомизированных исследованиях (RCT) с участием десятков инженеров использование LLM-ассистентов давало ускорение выполнения задач на ~20–30% по времени. Не «джуны», не «пет-проекты», а реальные инженеры с контрольной группой.

• Анализ реальных репозиториев GitHub показал рост продуктивности на 6–10%, ускорение онбординга и обмена знаниями внутри команд — именно там, где раньше всё упиралось в контекст и документацию.

• Консалтинговые отчёты (McKinsey, Atlassian) говорят о 2× ускорении типовых задач и экономии 10+ часов в неделю на разработчика — и это уже на уровне компаний, а не энтузиастов.

• Есть и неудобная правда: в отдельных экспериментах опытные разработчики действительно становились медленнее, если использовали LLM как «автопилот». Но ключевой вывод этих исследований не в том, что LLM вредны — а в том, что они усиливают процесс, а не заменяют мышление. Без архитектуры и границ — да, будет хуже.

И вот тут важный момент.
За границей из этого делают вывод:

нужно менять процесс, роли и требования к инженеру.

У нас — делают другой вывод:

«значит, технология сырая, подождём».

Anthropic, OpenAI, Google прямо говорят: LLM — это новый базовый инструмент разработчика, как IDE или Git. Стартапы строят продукты сразу с расчётом на AI-first workflow. Компании переписывают внутренние гайды, меняют подходы к документации, к ревью, к декомпозиции задач.

У нас — холивары в комментариях.

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

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

8. Что остаётся за инженером

Важный момент, чтобы не было иллюзий.

LLM не заменяет понимание. Надо знать, что такое клиент-серверная архитектура. Что такое HTTP-запросы. Как работают базы данных. Что такое микросервисы. Почему одно решение лучше другого. Без этого — никакой Claude не поможет. Он усилитель, не замена. Армия джунов, которой нужен архитектор. Экспертиза никуда не делась. Она сместилась. Теперь главный навык — работа с контекстом, документация, проектирование. Умение держать в голове систему целиком и декомпозировать её на управляемые куски.

Так то по мне - это сложнее, чем писать код руками)
Серьёзно. Требует постоянной концентрации, контроля, понимания что происходит под капотом. Не поддаваться соблазну пустить на самотёк решение ошибки, не прописать четкие ограничения для конкретного проекта. Как говорит мой знакомый - "голова как дом советов". Это становится основным требованием.

AI-driven — это не «без человека». Инженер необходим. Просто LLM становится основным инструментом. Смена парадигмы инструментов - не сингулярность.
Не будет волшебных палочек. Не будет AGI, который всё сделает за вас (ну в ближайшей реальности). Но будет инструмент, который уже сейчас необходим для освоения - потому что это основной инструмент уже наступившего будущего.

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

Я не агитирую. Не продаю курсы. Не говорю, что мой путь — единственный.
Я просто делаю. Показываю результаты. Пишу об этом.
Мир не ждёт. Он никогда не ждал.

Если интересна методология — в прошлой статье я подробно разобрал работу с документацией, TDD и управление контекстом. Если интересна предыстория — в первой статье про уход из найма во фриланс.

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