Первые 3 месяца я кодил сам. Гуглил, читал документацию, разбирался. Медленно, но учился.

Потом кто-то из коллег показал Cursor + Claude. "Смотри, как просто! Опиши что нужно — он напишет!"

Я попробовал. Работало. Быстро. Удобно.

Через месяц я писал 80% кода через AI.

Через полгода — 95%.

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

Vibe Debugging: когда ты не понимаешь свой код

Недавно на проекте вылез баг. Критичный. Продакшн лежит.

Я открываю код. Смотрю на функцию. Она делает что-то с базой данных, кешированием, валидацией...

И я не понимаю как она работает.

Потому что я её не писал. Claude написал.

Я помню что я попросил: "Сделай систему кеширования для API с инвалидацией по времени". Он сделал. Заработало. Я замержил.

А теперь оно не работает. И я не знаю почему.

Потому что я не знаю как оно работает.

Есть термин для этого. "Vibe Debugging".

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

Ты просто... пробуешь. На вайбе. Меняешь что-то. Запускаешь. Не работает. Меняешь ещё. Опять не работает.

В итоге я скопировал функцию, отправил Claude: "Тут баг, исправь".

Он исправил. Заработало.

Я даже не знаю что было сломано.

80% российских разработчиков используют vibe coding

Это реальные данные за 2025 год (ICT.Moscow).

80%.

Это значит 8 из 10 разработчиков в России делегируют написание кода AI.

Collins Dictionary не зря выбрал этот термин словом года. Это тренд. Реальность.

Но есть обратная сторона.

Цитата эксперта:

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

Что я потерял за полтора года

Честная исповедь.

1. Я не помню синтаксис

Попроси меня сейчас написать простой цикл for в Python — я полезу в Google. Или спрошу у Claude.

Раньше я это знал наизусть. Сейчас — нет.

2. Я не понимаю алгоритмы

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

Я не знаю как. Потому что за полтора года ни разу не делал это сам.

Я попросил бы Claude. Но на собеседовании нельзя.

3. Я не читаю документацию

Зачем? Claude знает все библиотеки. Он выдаст рабочий код.

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

Сейчас я даже не знаю что там написано.

4. Я боюсь легаси-кода

Недавно попросили пофиксить баг в старом проекте. Код написали лет 5 назад, без AI.

Я смотрю на него... и не понимаю. Логика какая-то странная. Структура непривычная.

Потому что я привык к коду, который пишет Claude. А там код писали люди.

И я не умею читать человеческий код. Потому что привык к AI-коду.

Исследование: AI снижает критическое мышление

Исследование Microsoft и Университета Карнеги-Меллона показало:

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

Статья "The Widening Gap":

"Новички, полагающиеся на AI, испытывают трудности в развитии метакогнитивных навыков и сталкиваются с иллюзией компетентности."

Иллюзия компетентности. Вот оно.

Я кажусь компетентным. Потому что делаю фичи быстро. Код работает (пока Claude пишет).

Но на самом деле я некомпетентен. Потому что без Claude — беспомощен.

"Няньки искусственного интеллекта"

TechCrunch назвал нас так.

Раньше мы были разработчиками. Мы создавали код.

Теперь мы няньки. Мы присматриваем за кодом, который создаёт AI.

Разница огромная.

Разработчик:

• Понимает что делает

• Контролирует процесс

• Может объяснить решение

• Может улучшить код

Нянька:

• Просит AI что-то сделать

• Проверяет работает ли

• Если не работает — просит AI исправить

• Не понимает как это работает

Я — нянька.

Рынок труда 2025: новая реальность

Zарплаты растут:

• "Вайб-программисты" в Москве: до 140 000₽/мес

• Это как PHP-разработчик middle-уровня

Вакансий больше на 27% (с начала 2025).

Круто? Вроде да.

Но.

Gartner прогнозирует:

"80% программистов придётся прокачивать навыки работы с AI, чтобы сохранить работу."

Не навыки AI-кодинга.

Навыки настоящего кодинга. Потому что те, кого AI может заменить — заменят.

На собеседованиях начали спрашивать

Недавно был на собеседовании. Вопрос от тимлида:

— Ты сам пишешь код или с ChatGPT?

Я замялся. Честно сказать — звучит плохо. Соврать — палево.

Ответил:

— Использую AI как инструмент, но понимаю что делаю.

Он кивнул. Дал задачу — написать простую функцию валидации email. Без AI. Прямо при нём.

Я... справился. Еле-еле. Гуглил синтаксис регулярок. Тимлид видел это.

Офер не дали.

Теперь это тренд. Работодатели проверяют: ты программист или промптер?

Голос в пустоте: как я пытался решить проблему

Самая большая боль — написание промптов.

Когда ты объясняешь AI что нужно, ты пишешь. Много. Детально.

Мой типичный день:

• 60-80 промптов для AI

• По 300-500 символов каждый

• 15 000 - 40 000 символов текста

• 10-12 часов набора

Руки отваливаются. Запястья ноют.

Я попробовал голосовой ввод Windows (Win+H). Не работает в терминале и IDE.

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

Помогло с руками. Стало комфортнее.

Но не решило главную проблему.

Я всё равно не программист. Я всё равно только прошу AI что-то сделать.

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

Ловушка, из которой нет выхода

Вот в чём засада:

Если я перестану использовать AI → буду кодить медленнее → не буду успевать → потеряю работу.

Если продолжу использовать AI → навыки будут деградировать → в один момент не пройду собеседование → потеряю работу.

Я в ловушке.

И 80% разработчиков в России — в такой же.

Что говорят ветераны

Недавно разговаривал с сеньором, который кодит 15 лет.

— Я тоже использую AI. Но для рутины. Когда мне нужен boilerplate, CRUD, типовые вещи. AI делает быстро.

— А сложную логику?

— Сам. Потому что AI часто делает хреново. Не учитывает нюансы. Пишет неоптимально.

— Как ты понимаешь что AI сделал хреново?

— Опыт. Я знаю как должно быть. Потому что писал такое сотни раз.

Вот в чём разница.

У него есть база. Фундамент. Накопленный годами.

У меня нет базы. Потому что я с первого дня делегировал всё AI.

Я никогда не напишу сложную логику сам. Потому что у меня нет опыта.

А что если AI исчезнет?

Звучит нереально. Но представьте.

Завтра все AI-сервисы закрылись. Санкции, блокировки, что угодно.

Что будет со мной?

Я беспомощен без AI.

Я не смогу:

• Написать нормальную функцию с нуля

• Отладить сложный баг

• Оптимизировать код

• Спроектировать архитектуру

Я зависим от AI.

Как наркоман от дозы.

Исповедь

Я пишу эту статью не потому, что хочу осудить AI.

Я пишу потому, что боюсь.

Боюсь что через 5 лет окажусь никому не нужным.

Боюсь что навыки, которые я не развил, будут критичны.

Боюсь что весь мой "опыт" — это просто умение просить Claude написать код.

Paradox

Collins Dictionary назвал "vibe coding" словом года.

80% российских программистов используют AI для кода.

Зарплаты растут. Вакансий больше.

Но исследования говорят: навыки деградируют.

Работодатели начинают проверять: ты сам умеешь или только с AI?

Мы живём в эпоху парадокса.

AI делает нас продуктивнее — но беспомощнее.

AI даёт доступ к кодингу — но убивает понимание кода.

AI повышает зарплаты — но снижает ценность на рынке.

Вопрос к вам

Если вы кодите с AI:

Вы понимаете код, который он пишет?

Вы сможете пройти live coding на собеседовании без AI?

Вы сможете работать если AI завтра исчезнет?

Если хоть на один вопрос ответ "нет" — вы в той же ловушке, что и я.

P.S. Я до сих пор не починил тот баг в продакшене. Claude предложил 3 варианта исправления. Я не знаю какой правильный.

Потому что я не знаю как работает код.

P.P.S. Сегодня 80% используют vibe coding. А что будет через 5 лет?

Давно наблюдаю, как коллеги и знакомые наступают на одни и те же грабли с AI. Достаточно предсказуемый цикл на мой взгляд. Сначала – неподдельный восторг от технологии. Потом первая попытка "спихнуть" на LLM реальную, сложную задачу. И почти всегда финал один: невнятный, обобщенный результат и разочарованный вердикт: "эта штука не работает" или "слишком глупо, быстрее сделать самому".

Вам это знакомо?

Этот разрыв между ожиданиями "сейчас он всё сделает за меня" и реальностью "он выдал какую-то чушь" – главная причина, почему большинство бросает попытки внедрить AI в свою работу после подобного опыта.

Но вот в чем нюанс. Проблема то не в AI. Проблема в том, что многие сейчас преподносят данную технологию в массы не с точки зрения внятного и структурного обучения, а чисто как сервис, которые якобы читает наши мысли (посмотрите любой маркетинговый видосик от крупных игроков AI). Мало кто из них говорит про такие вещи, как схемы контроля, контекст, few-shot, CoT и так далее.

Я хочу в данном материале рассказать про то, как хотя бы чуть-чуть стать ближе к предсказуемым результатам работы вашей LLM. И как я сам использую простой фреймворк из трех шагов.

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

Что у вас на входе, и что (действительно) должно быть на выходе?

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

Планирование, пожалуй, самый скучный, но самый важный этап. Прежде чем написать хоть слово в промпте, нужно четко определить две вещи:

• Input Schema: Что я даю модели? Какие у меня есть исходные данные, факты, ограничения?

• Output Schema: Что я хочу получить на выходе? И здесь нужна максимальная детализация.

Не просто "статью", а "статью на 1500 слов в формате Markdown, со структурой из заголовков H2 и H3, тремя практическими примерами и выводом в конце". Чем детальнее схема выхода, тем предсказуемее и качественнее будет результат.

Давайте разберем на простой задаче – "написать пост для социальной сети".

Плохой план: "Хочу пост про n8n".

Результат будет случайным.

Хороший план (спроектированный Input/Output):

INPUT:

• Тема: Экономия времени с помощью n8n.

• Целевая аудитория: Технические лиды, уставшие от рутины.

• Ключевая мысль: Автоматизация – это не про лень, а про высвобождение ресурсов для важных задач.

OUTPUT:

• Формат: Текст для поста в социальную сеть.

• Длина: Строго 200-250 слов (чтобы не резался под "еще").

• Структура: Цепляющий заголовок (Hook) → Описание проблемы → Наше решение → Призыв к действию (CTA).

• Тон: Уверенный, прямой, без маркетингового BS.

Уже даже с таким подходом, качество ответа LLM должно улучшится.

Также в output можно заложить более сложные вещи.

• Детальная схема на выходе (Output Schema) – ваше главное оружие против "галлюцинаций" модели. Когда вы просите сгенерировать JSON с полями {"name": "string", "revenue": "number"} или отчет со строгой структурой "Выводы, Риски, Рекомендации", вы не оставляете модели пространства для выдумки. Она вынуждена работать в рамках заданной логики, а не генерировать творческий, но оторванный от реальности текст.

• Подробнее про Structured Output и Schema-Guided Reasoning можете почитать у меня тут. Эти два подхода помогут усовершенствовать результат работы и контроль над вашей LLM на порядок.

Контекст. Чем кормить модель (и чем не стоит).

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

Контекст это не свалка документов из вашего Google Drive. Это тщательно отобранные данные, которые закрывают "пробелы в знаниях" модели о вашей специфической задаче. LLM знает общие вещи о мире, но ничего не знает о вашей компании, вашем стиле общения и вашем продукте.

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

Вот простой чек-лист, что стоит и не стоит включать в контекст:

Включать:

• Специфику вашей компании/продукта: "Мы – open-source альтернатива Zapier, наш главный плюс – self-hosting".

• Примеры вашего стиля (few-shot): "Вот 2-3 примера наших удачных постов. Пиши в таком же тоне". Это работает на порядок лучше, чем описание "пиши в дружелюбном, но экспертном стиле". Модель учится на примерах, а не на правилах.

• Ключевые факты и цифры: "У нас 500k активных пользователей". Это приземляет ответ и делает его более достоверным.

Исключать:

• Устаревшую информацию: Данные пятилетней давности о вашем продукте только запутают модель. Или что лучше, попросить модель самой найти информацию о нас в интернете (вы же знаете, что о вас пишут в интернете?).

• Противоречивые данные: "Наша аудитория – C-level директора и студенты". Определитесь.

Используйте силу негативных примеров. Вместе с "вот как надо делать" добавьте в контекст "а вот так делать НЕ надо". Например: "Мы пробовали писать в сложном корпоративном стиле и это не сработало. Избегай таких фраз: 'синергия', 'оптимизация бизнес-процессов'". Это еще точнее калибрует модель и экономит вам время на последующей редактуре.

Хороший, отфильтрованный контекст я бы оценил в 20-40% успеха. Он превращает LLM из "всезнайки интернета" в небольшого эксперта, который в курсе последних дел.

Промпт. Сборка инструкции.

Только теперь, когда у нас есть план (Output Schema) и сырье (Контекст), мы готовы писать сам промпт. Промпт по своей сути, просто контейнер, в который мы аккуратно упаковываем все наши предыдущие наработки.

Хороший промпт не похож на разговор. Он похож на конфигурационный файл или четко структурированное ТЗ.

Его анатомия проста:

• Роль: Самый простой способ задать тон. "Представь, что ты – опытный SaaS-маркетолог, который пишет для технической аудитории".

• Задача: Четкая, пошаговая инструкция, которая напрямую следует вашему Output Schema. "Напиши пост для социальной сети. Структура должна быть такой: Hook, Problem, Solution, CTA".

• Контекст и Примеры: Вставляем сюда отобранную информацию из второго шага.

• Формат и Ограничения: Перечисляем все технические требования из плана. "Длина 200-250 слов. Не использовать фразы 'революционный', 'меняющий игру'".

Рассмотрим пример.

Многие (так делают практически все, кто мало знаком с AI):

Напиши пост для Telegram про n8n.

После изучения основ и подобных материалов (к этому стоит стремится):

Разница в результате будет заметной. Но помните: первый промпт редко бывает идеальным. Относитесь к этому как к написанию кода: написали → запустили → увидели результат → поправили → запустили снова. Это нормальный итеративный процесс.

Prompt тоже можно улучшить ещё сильнее, например сделав его в формате json схемы или обвернуть в XML теги. К чему это приведёт и какие результаты может дать, можете прочитать тут. А также небольшой гайд, как можно использовать LLM для создания подобных промптов на полуавтомате.

Что ещё может улучшить ваш опыт при работе с LLM

Есть дополнительная парочка интересных техник:

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

• Всегда указывайте формат. Вместо "сделай список" пишите "выведи результат в виде нумерованного списка в Markdown". Вместо "извлеки данные" – "верни результат в формате JSON с полями name, email". Это делает вывод машиночитаемым и предсказуемым.

• Управляйте "креативностью". Если вам нужны точные факты, анализ или код, скажите модели "будь предельно точным и придерживайся только предоставленных данных". Если вам нужен брейншторм и идеи – "будь креативным, предложи 5 самых нестандартных вариантов". Это неформальный способ управлять параметром temperature под капотом модели (сейчас я про кейсы, где вам не даны тумблеры по настройки температуры вручную через UI).

Финал?

То самое чувство разочарования от работы с AI уходит в тот момент, когда вы перестаете его "просить" и начинаете им "управлять". Предложенный фреймворк – это ваш начальный пульт управления, который приближает вам контроль над этой технологией. Он не дает 100% гарантий, но покрайне мере я надеюсь, что он заложит базу и вам станет проще понимать куда двигаться дальше.

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

1. Начинайте с плана, а не с идей

Планирование — основа. Все об этом говорят, но мало кто делает. а зря :(

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

👉Ошибка новичков — начинать с креативов.
👉Правильный подход — идти от цифр.

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

ВАЖНО: гипотезы нужно считать с поправкой на их реальную срабатываемость. Если вы знаете, что из трёх идей выстреливает только одна, то чтобы закрыть «дыру» в $200k, нужно планировать тестов минимум на $600k.

2. Синхронизируйте маркетинг и продажи

Маркетинг без сейлзов не работает. Бесполезно гнать сотни лидов, если отдел продаж не готов их переварить.

Учитывайте обе стороны:

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

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

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

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

📲Амит продюссирует

3. Держите план «Б»

Маркетинг никогда не идёт ровно. Провалы бывают у всех. Главное — быть готовыми и не паниковать в конце месяца. Что держать в запасе:

• усиление коммуникаций по базе,

• пакетные скидки и акции (лучше согласовать заранее),

• дополнительный бюджет на проверенные каналы,

• перераспределение фокуса на то, что уже показывает результат.

Так вы превращаете «пожар» в управляемый процесс.

4. Внедрите ежедневный контроль

Без контроля любая система рассыпается. У нас в команде каждый день проходят короткие 30-минутные встречи, где смотрим:

• какие метрики были вчера,

• не выросла ли стоимость лида,

• что тормозит воронку,

• где узкие места.

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

В канале я делюсь шаблонами таких встреч — берите и внедряйте👇

📲Амит продюссирует

5. Учитесь и зовите умных людей

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

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

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

6. Обучайте команду правильно мыслить

Большинство специалистов умеют «жать кнопки», но не умеют думать как стратеги. Поэтому нужно учить следующему:

• Не трогать то, что работает. Если канал стабильно даёт результат, не нужно его передёргивать каждый день.

• Смотреть на рынок. Большинство идей уже где-то работают — просто подсмотрите и адаптируйте.

• Честно репортить. Важно говорить не только про успехи, но и про факапы.

• Пылесосить практики. Чем больше вы общаетесь с рынком, тем меньше тратите времени на изобретение велосипеда.

• Мышление через цифры. Любое действие = причина + результат + вероятность + ресурсы. Если человек этого не понимает, он будет сливать бюджет.

***

На этом пока всё. Если статья была полезна — дайте знать реакцией или комментарием.

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

📲Амит продюссирует

Длинная история, как мне сказали поражения мозга.
Стоит ли уезжать..только, чтобы посмотреть мир и приобрести опыт жизни. А старость лучше жить среди своих, дома и стены греют, а ты уже совсем один и следующий в очереди к истине, и вокруг - свои, свое детство, юность, воспоминания.
Мне повезло. Я посмотрела мир, может малую его часть, но мне этого хватило, чтобы остаться в гнезде и утеплиться. Не скучно. В борьбе за жизнь, я приобрела самодостаточность. Это - самое главное. Тут много составляющих. И здоровый пофигизм на мнения, на перемены, и опыт, определённый уровень эмоционального состояния, не мешающий, а помогающий жить. Знания, чтобы не скучно.
Адреналина во мне всегда было с избытком, мама называла меня " вечным двигателем", а знакомые удивлялись откуда во мне столько жизни. Меня " перло" ото всего. Повезло? Да. Были мечты...сначала материальные, потом эмоциональные. Например, увидеть цунами. Я смотрела видео преследователей цунами и у меня свербило. Мне опять повезло, что я жила рядом с океаном, рассказ был бы смешным, но длинным, поэтому из него вынесу последнее предложение : я увидела Бога в данной стихии Природы. Увидела что то подобное как в видео, но не близко в круизе. Все блевали, а мне нужны были чистые от соли иллюминаторы. На круизном корабле как то спокойно. Он как жилое здание, предназначенное для такой воды. Мой ребёнок видел именно такое, по роду занятий. Наверное, данные картины добавили ему мужества. Не удивительно. И веру в Бога.