Где заканчивается прототип и начинается инженерия, почему «работает у меня» не равно «готово для бизнеса», и за что на самом деле платят опытной команде.
Коротко. Vibe coding хорош для прототипа, но в production скорость генерации кода не заменяет архитектуру, security review,тестирование, наблюдаемость и эксплуатационную ответственность
За последний год я несколько раз слышал одну и ту же формулу: «Зачем мне команда разработки? Я найду человека, который умеет хорошо промптить, он за неделю соберет продукт в Cursor/Lovable/Replit, и мы сэкономим месяцы и бюджет».
На уровне демо это часто правда. Интерфейс открывается. Регистрация работает. Кнопка отправляет запрос. В базе появляется запись. Можно снять красивое видео, показать инвестору и даже получить первые регистрации.
Проблема начинается в тот момент, когда прототип перестает быть игрушкой и становится активом компании. Когда в него приходят реальные пользователи, реальные деньги, персональные данные, интеграции, SLA, бухгалтерия, поддержка и ответственность. Здесь выясняется, что между «собрать экран» и «разработать продукт» лежит довольно большая инженерная территория.
Именно об этой территории обычно не знают люди, которые никогда не отвечали за production.
Я не против AI‑инструментов. Наоборот, мы используем их там, где они ускоряют работу: при исследовании, написании шаблонного кода, подготовке тестов, рефакторинге, поиске альтернатив, документации. Но AI‑assisted development и vibe coding не одно и то же. В первом случае инструмент ускоряет инженера. Во втором человек передает инструменту решения, которые сам не умеет проверить.
А вот это для бизнеса уже опасная разница.
1. Вайбкодинг не равен разработке с AI
Термин vibe coding в феврале 2025 года популяризировал Андрей Карпати. В исходном описании была важная деталь: разработчик перестает внимательно читать изменения, принимает сгенерированный код и двигается дальше, ориентируясь на то, что приложение визуально делает нужное [1].
С тех пор словом «вайбкодинг» начали называть почти любую разработку с LLM, и это только запутывает разговор. Если опытный разработчик попросил модель сгенерировать функцию, прочитал diff, проверил границы входных данных, написал тесты, прогнал статический анализ и понимает последствия решения, это обычная инженерная работа с более быстрым инструментом.
Vibe coding начинается там, где исчезает контроль. «Модель написала, тестовый сценарий прошел, значит можно выкатывать».
Для pet‑проекта это нормально. Для одноразового скрипта тоже. Для прототипа, который завтра можно выбросить, иногда даже идеально.
Но production‑код отличается тем, что его нельзя оценивать только по счастливому сценарию.
2. Главная ловушка: демо показывает функцию, а не систему
Некоммерческий разработчик обычно видит задачу примерно так:
«Нужно сделать форму оплаты, авторизацию и личный кабинет».
Инженер с production‑опытом слышит в этой фразе десятки дополнительных вопросов.
Что будет, если платежный провайдер ответит дважды? Что будет, если webhook придет через 40 минут? Где хранится idempotency key? Можно ли повторно списать деньги? Как разделены authentication и authorization? Кто может читать чужие объекты? Что случится при недоступности внешнего API? Есть ли retry с ограничением? Что попадет в логи? Не окажется ли там токен или персональные данные? Как откатить релиз? Как восстановить базу? Как понять, что дегра‐ дация уже началась, если пользователи еще не написали в поддержку?
На демо все эти вопросы невидимы. Кнопка нажалась, страница открылась, кажется, что продукт готов на 90 процентов.
На практике видимая функция может быть только верхушкой работы.
В production есть минимум семь слоев, которые пользователь почти не замечает: архитектура, безопасность, данные, тестирование, наблюдаемость, эксплуатация и восстановление после ошибок. Они не делают скриншот красивее, поэтому у неопытного исполнителя именно они первыми выпадают из сметы.
3. «Он же работает» не означает «он безопасен»
Один из самых неприятных эффектов генеративного кода в том, что он часто выглядит убедительно. Код компилируется, endpoint отвечает, тестовый пользователь входит в систему. Ошибка спрятана не в синтаксисе, а в модели доступа, границах доверия или нетипичном сценарии.
В исследовании Veracode 2025 GenAI Code Security Report более 100 моделей тестировали на задачах, которые можно было решить безопасным или небезопасным способом. В 45 процентах случаев сгенерированный код провалил security‑проверку и содержал обнаружимую уязвимость из классов OWASP Top 10 [2].
Есть и более жесткие академические результаты. В работе 2025 года с 200 задачами на изменение реальных open‑source проектов один из протестированных агентов в конкретной конфигурации выдавал функционально корректное решение в 61 процентах случаев, но безопасным было только 10,5 процента решений [3]. Это не означает, что «LLM пишет уязвимости в 89,5 процента случаев» вообще. Это означает более важную вещь: функциональная корректность и безопасность могут очень сильно расходиться.
Если исполнитель не умеет сам распознать insecure direct object reference, слишком широкую RLS‑политику, SSRF, race condition или неправильную проверку подписи webhook, AI не превращает его в специалиста по AppSec. Он просто помогает быстрее получить код, который человек не способен полноценно проверить.
4. Кейс с RLS: одна настройка, которую не видно в интерфейсе
Хороший пример того, почему «все работает» недостаточно, появился вокруг Lovable и Supabase.
В NVD зарегистрирован CVE-2025-48757: недостаточная Row‑Level Security в сгенерированных сайтах могла позволять удаленному неаутентифицированному пользователю читать или изменять данные в таблицах. Запись помечена как disputed, поскольку поставщик платформы указывал на ответственность владельцев приложений за защиту данных [4].
Для меня здесь интересен даже не спор о распределении ответственности. Интересен сам класс ошибки.
Supabase anon key может легитимно находиться на клиенте. Само по себе это не секрет. Безопасность строится на корректных политиках доступа к строкам. Человек без опыта легко видит «в приложении есть login» и мысленно ставит галочку «авторизация готова». Но login отвечает на вопрос «кто ты?», а RLS отвечает на вопрос «какие именно данные тебе можно читать и менять?». Это разные слои.
Внешне приложение с правильным RLS и приложение с дырявым RLS могут выглядеть абсолютно одинаково.
Вот почему security review не заменяется ручным кликом по интерфейсу.
Кстати, даже в текущей документации Lovable прямо сказано, что встроенные сканеры не гарантируют полную безопасность, а для приложений с чувствительными данными или критичной функциональностью стоит рассматривать дополнительный профессиональный security review [6]. Это здравый подход. Инструмент может ускорять, но ответственность за production никуда не исчезает.
Есть еще один показательный эпизод. В апреле 2026 года Lovable сама описала инцидент, в котором backend‑регрессия повторно открыла доступ к chat history и исходному коду публичных проектов для других авторизованных пользователей, если у них была ссылка на проект. В разборе компания отдельно признала проблему процесса: несколько валидных отчетов исследователей были закрыты на triage из‑за устаревшей внутренней документации [5]. Это полезное напоминание: безопасность продукта живет не только в коде. Нужны процессы, ownership, актуальные правила, review и корректная эскалация. Если подобные вещи требуют системной работы даже от большой платформы, странно ожидать, что одиночный исполнитель без productionпрактики закроет их автоматически.
5. Самозванец не обязательно плохо пишет код
Под «самозванцем» я здесь не имею в виду джуна. Джун внутри нормальной команды, с ревью, наставником, тестированием и понятной зоной ответственности, это обычная и здоровая часть индустрии.
Проблема начинается, когда человек без коммерческого опыта продает себя как full‑stack, архитектора, DevOps, security engineer и технического директора одновременно, потому что теперь у него есть доступ к модели, способной генерировать любой из этих артефактов.
Он может быть умным. Может очень быстро учиться. Может действительно за вечер собрать красивое приложение. Но у него нет самого дорогого ресурса инженера: прожитых последствий решений.
Коммерческий опыт дает не магическое знание синтаксиса. Он дает память о том, что бывает после запуска.
После первой миграции, которая не помещается в maintenance window. После внезапного роста очереди. После частичного отказа стороннего API. После изменения схемы данных, которое ломает старый мобильный клиент. После ситуации, когда «временный» feature flag живет два года. После восстановления бэкапа, который до аварии никто не проверял. После инцидента, где логирование есть, но нужного correlation id нет. После релиза в пятницу, который формально зеленый, но бизнес‑метрика уже падает.
Эти вещи трудно выучить по туториалам, потому что туториал почти всегда заканчивается на happy path.
6. Что обычно не попадает в «быструю разработку»
Когда случайный подрядчик обещает «сделать SaaS за две недели», я бы не спорил с оценкой по фронтенду. Я бы спросил, что именно входит в слово «сделать».
Архитектура. Не диаграмма ради диаграммы, а границы сервисов, модель данных, контракты, отказоустойчивость, стоимость изменений и понимание того, какие решения можно отложить, а какие потом будут стоить переписывания системы.
Безопасность. Threat model, секреты, права, multi‑tenancy, обработка пользовательского ввода, безопасная работа с файлами, rate limiting, защита административных функций, security headers, зависимости, аудит событий.
Тестирование. Unit‑тесты являются только одним уровнем. Нужны интеграционные сценарии, контрактные тесты, проверки миграций, негативные кейсы, регрессия, smoke после деплоя. Для части систем нужны нагрузочные и fault‑тесты.
Инфраструктура. CI/CD, окружения, конфигурация, секреты, IaC, мониторинг, алерты, резервные копии, процедуры восстановления, rollback, доступы. «Задеплоил на Vercel» может быть хорошим решением, но это не эксплуатационная стратегия само по себе.
Наблюдаемость. Логи, метрики и трассировка должны отвечать на вопросы бизнеса и эксплуатации. Сколько запросов падает? Где растет latency? Какой внешний сервис деградирует? Какая версия клиента создает ошибки? Сколько денег мы теряем прямо сейчас?
Поддерживаемость. Документация, соглашения, контроль зависимостей, понятная структура, ownership, code review. Код должен быть читаем не только моделью, которая его сгенерировала сегодня, но и инженером, который будет чинить его через год в 03:00.
Экономика. Иногда «быстро» означает очень дорогую инфраструктуру, лишние API‑вызовы или архитектуру, стоимость которой растет быстрее выручки. Production‑разработка включает инженерную экономику, а не только feature velocity.
7. Почему дешевый исполнитель часто оказывается дорогим
В начале проекта стоимость ошибки низкая. Схему можно поменять за час. API можно переименовать. Таблицу можно удалить.
После запуска ошибка обрастает данными, интеграциями, мобильными версиями, клиентскими сценариями, договорами и ожиданиями пользователей. То, что на первой неделе стоило два часа инженерной работы, через полгода может потребовать миграцию, период совместимости двух протоколов, ночное переключение и ручную проверку данных.
Поэтому цена подрядчика и стоимость разработки не одно и то же.
Самый дорогой сценарий, который мы видим на рынке, выглядит так:
Компания экономит и отдает MVP человеку, который умеет быстро генерировать функциональность.
MVP начинает продаваться, значит «подход доказал эффективность».
В продукт добавляют еще 20 процентов функций поверх случайных решений
Появляются утечки, нестабильность, проблемы с производительностью или невозможность нормально развивать систему.
Приходит опытная команда и выясняет, что исправлять по месту дороже, чем часть системы переписать.
Компания платит второй раз, только теперь еще под давлением работающего бизнеса.
Проблема не в том, что первый исполнитель «плохо написал React». Проблема в том, что он принимал архитектурные и эксплуатационные решения, не зная, что именно решает.
8. AI усиливает компетентность, но усиливает и незнание
Мне нравится сравнение с мощным электроинструментом. Профессионал сделает с ним больше и быстрее. Человек без подготовки тоже сделает больше и быстрее, включая ошибки.
LLM резко снижает стоимость получения правдоподобного ответа. Но не снижает стоимость проверки этого ответа.
Иногда проверка дороже генерации на порядок. Модель за 20 секунд создаст Terraform, OAuth flow, миграцию и webhook handler. Чтобы убедиться, что все четыре фрагмента безопасны, совместимы с инфраструктурой, не ломают обратную совместимость и корректно ведут себя при сбоях, нужен специалист, который понимает предметную область.
Поэтому главный вопрос сегодня не «использует ли подрядчик AI?». Почти наверняка использует.
Главный вопрос: «Кто отвечает за решения, которые AI предложил, и достаточно ли у этого человека опыта, чтобы сказать модели нет?»
9. Чем отличается команда с коммерческим опытом
У нас довольно консервативное отношение к слову «готово».
Готово, это не когда задача закрыта в трекере. Готово, это когда решение понятно, проверяемо, наблюдаемо, разворачивается повторяемо, имеет предсказуемые failure modes и не превращает следующую задачу в раскопки.
Специалисты нашей команды имеют профильное образование и более 10 лет коммерческого опыта разработки. Проектами такого уровня мы занимаемся более 5 лет. Работаем в том числе с крупнейшими компаниями: как консультанты, как команда full cycle development и как инженерное усиление на отдельных направлениях.
Full cycle для нас означает не «мы умеем и фронтенд, и бэкенд». Это ответственность за жизненный цикл решения.
На старте это discovery, декомпозиция бизнес‑задачи, аудит ограничений, архитектура и выбор технологий без моды ради моды.
В разработке это backend, frontend, mobile при необходимости, интеграции, данные, тестирование, DevOps/DevSecOps, CI/CD, инфраструктура и security‑практики.
Перед запуском это нагрузка, observability, планы миграции, rollback, резервное копирование, контроль доступов и проверка критичных пользовательских сценариев.
После запуска это эксплуатация, мониторинг, оптимизация, разбор инцидентов, развитие архитектуры, модернизация legacy, технический аудит и консультации команды заказчика.
Иногда клиенту не нужна full‑cycle команда. Нужен архитектурный review, независимый аудит кода, помощь с производительностью, DevOps, security, сложная интеграция или технический due diligence перед инвестиционным решением. Это тоже нормальный формат. Смысл зрелой команды не в том, чтобы продать максимальное количество разработчиков, а в том, чтобы правильно закрыть инженерный риск.
10. «Мы беремся за проекты любой сложности» не означает «обещаем всё»
Фраза «проекты любой сложности» легко звучит как маркетинг, поэтому поясню, что я под ней понимаю.
Сложный проект, это не обязательно миллион строк кода. Иногда сложность находится в требованиях по доступности. Иногда в legacy без документации. Иногда в высокой нагрузке, сложной математике, интеграциях с закрытыми системами, жестких требованиях к данным, миграции без остановки бизнеса или необходимости встроиться в процессы большой компании.
Опытная команда не обещает решить такую задачу «с одного промпта». Она умеет разложить неизвестность на проверяемые части, провести исследование, сделать proof of concept там, где он нужен, зафиксировать риски, выбрать архитектурный компромисс и довести систему до эксплуатации.
Чем сложнее проект, тем меньше ценность человека, который быстро производит код, и тем выше ценность людей, которые умеют принимать решения при неполной информации
11. Когда вайбкодинг, наоборот, отличная идея
Чтобы не превращать текст в борьбу с прогрессом, зафиксирую: vibe coding бывает очень полезен.
Я спокойно использовал бы его для одноразового прототипа, внутренней утилиты без чувствительных данных, проверки продуктовой гипотезы, визуального концепта, маленького скрипта, который легко проверить вручную, или pet‑проекта, где цена ошибки нулевая.
Порог меняется, когда появляется хотя бы один из факторов:
персональные или финансовые данные;
деньги и платежные сценарии;
несколько ролей и сложная модель доступа;
B2B‑интеграции;
обязательства по доступности;
высокая нагрузка;
регуляторные требования;
бизнес зависит от корректности данных;
продукт должен жить и развиваться несколько лет;
стоимость простоя или утечки измеряется не стоимостью хостинга.
В этот момент «собрать» уже недостаточно. Нужно проектировать, проверять и отвечать за результат.
12. Как проверить подрядчика до того, как он получит ваш production
Я бы задал потенциальной команде несколько вопросов. Не про список технологий, а про ответственность.
Кто принимает архитектурные решения и как они документируются? Как устроен code review? Какие тесты обязательны перед релизом? Как проверяется модель авторизации? Где хранятся секреты? Как устроены окружения? Можно ли воспроизвести инфраструктуру? Что происходит при неуспешной миграции? Есть ли rollback? Как проверяется восстановление из резервной копии? Какие метрики и алерты появятся до запуска? Кто разбирает инцидент? Как вы передадите проект другой команде, если сотрудничество закончится?
Если в ответ звучит только «мы быстро пишем на Next.js, Supabase и AI», вы уже получили важную информацию.
Если подрядчик способен обсуждать trade‑offs, failure modes, эксплуатацию, безопасность и стоимость владения еще до того, как написал первую строчку, это гораздо более здоровый сигнал.
Вместо вывода
Вайбкодинг сделал разработку доступнее. Это хорошо. Он позволяет быстрее проверять идеи и сокращает рутину даже в профессиональных командах.
Но он же создал новый тип ложной уверенности: если человек способен получить работающий интерфейс, кажется, что он способен построить работающий бизнес‑продукт.
Это разные компетенции.
Для компании код не является конечным результатом. Конечный результат, это система, которая сохраняет данные, выдерживает нагрузку, ограничивает доступ, переживает ошибки, обновляется без лотереи, диагностируется при сбоях и остается развиваемой через год.
Именно поэтому я бы не отдавал production случайному человеку только потому, что он эффектно демонстрирует скорость с AI. Скорость имеет ценность только тогда, когда рядом есть инженерная ответственность.
Мы используем современные инструменты, включая AI, но не передаем им ответственность за решения. Ее несут специалисты с профильным образованием, более чем 10-летним коммерческим опытом и практикой сложных проектов на протяжении более 5 лет. От консультации и технического аудита до full cycle development и дальнейшей эксплуатации, мы берем на себя не только создание фич, но и инженерные последствия того, что создаем.
В production именно это обычно и отличает «приложение работает» от «на продукт можно положиться».
Источники и материалы
[1] Simon Willison, цитата Андрея Карпати о vibe coding, 6 февраля 2025
[2] Veracode, 2025 GenAI Code Security Report
[5] Lovable, Our response to the April 2026 incident
[6] Lovable Documentation, Security overview
Комментарии (145)
Vicollel
27.08.2026 12:52Те кто вайбкодит для продакшена никогда до продакшена его не доводят. Точнее доводят, но это продакшен только де-юре - сервис просто выложен в интернет, не более. То есть продакшен трафика там не будет никогда.
Но зарабатывать на этом можно, на уровне средней зарплаты квалифицированного специалиста, условно 200-300к личного дохода. Но опять же, даже столько на этом зарабатывают единицы, потому что до вайбкодинга они не умели ничего, с приходом вайбкодинга они лишь научились вайбкодить, потому что это легко, но и трафик привлечь они не смогут - нет соответствующих личностных качеств. Такие люди даже оферту составить не могут, я уж не говорю про открытие фирмы и всего что из этого вытекает.
А те, у кого эти качества есть, зарабатывают столько и без вайб кодинга, вайбкодинг лишь сокращает их расходы на никудышных ленивых фрилансеров и увеличивает доходы. Но это актуально только для фирм до 100 млн оборотки в год. А меньшим фирмам зачастую достаточно таблицы в гугл доках/таблицах. Я знаю предприятия с оборотом 1 ярд+, которые из цифрового вели только 1с для бухгалтерии.
CrashLogger
27.08.2026 12:52предприятия с оборотом 1 ярд+
Это какой-нибудь завод, наверное. Малый бизнес сейчас без цифровых сервисов даже не взлетит. Все продажи идут через соцсети и маркетплейсы. Даже если это просто банальная торговля - то все равно нужна CRM, аналитика, маркетинг. Другое дело, что никто не будет разрабатывать все это себе сам - просто купят готовые решения.
Laaladar
27.08.2026 12:52По моему скромному мнению вайб-кодинг - это песочница, которая отлично подходит студентам или любителям DIY, которым надо воплотить прикольную идею.
Хочу сделать маме бот, который будет выдавать ей сколько каких удобрений надо тому или иному сорту огурцов!
Один вечер и проектик готов.
Студент-аналитик, который будет писать такой ботик для бабушки, быстро обнаружит,
что бабушка показала ботик соседке, и та теперь палит, что посадила ее соседка.
Что нужен инструмент добавления новых сортов плодово-овощных культур в БД
Что заложенные в схему БД параметры не универсальны, и надо что-то придумать
Что детали, пропущенные на этапе конвертирования, неприятно удивят стоимостью фиксов и рефакторинга, если студент юзает платные модели
И т.д и т.п.
Ясное дело, что рынок фриланса заполонили вайб-кодеры, но как будто говнокодеров в этой куче всегда было много.
ИИ не заменит инженерный опыт, но позволит его быстро приобрести, если студенту нравится создавать рабочий продукт и критично к нему подходить.
konst90
27.08.2026 12:52Ясное дело, что рынок фриланса заполонили вайб-кодеры, но как будто говнокодеров в этой куче всегда было много.
На мой взгляд, лучшее про вайбкодинг написано лет тридцать назад:
Если к попе присобачить сопроцессор фирмы Крэй -
Можно гадить в два сортира в сорок тысяч раз быстрей!
Conditus
27.08.2026 12:52Как интересный прецедент - коллега родственника в госухе делает ML платформу на чистом вайбкодинге. Обложился тестами, скилами, прочитал тонну гайдов по промпт инжинирингу, короче до зубов вооружился. Сам чел не технический, но очень целеустремлённый с "роем агентов"
И самое смешное (и грустное), что это детище достаточно скоро будет в общем доступе ака гос сервис
Mr_Cheater
27.08.2026 12:52Ну так это гос.контора. Вы там ожидали иного?
0hrenet
27.08.2026 12:52Сегодня госуха это единственное пристанище для грамотных толковых инженеров, выперднутых из современного айти пусто[со]звонами-смузихлёбами, аджайлами и 100 этапными собесами в стиле бега с препятствиями вприсядку.
Так что я бы советовал не скабрезничать, а наоборот присмотреться прислушаться.CrashLogger
27.08.2026 12:52Госуха - это унылое болото, где главный скилл - это умение лизать жопу начальства. Инженеру, если он хоть что-то из себя представляет в профессиональном плане, делать там нечего.
0hrenet
27.08.2026 12:52Так было лет 10 назад. Сейчас, как ни парадоксально, всё поменялось местами. Разве что, лизать жопу в негосухе называют софтскиллами. А в госухе от тебя требуется лишь бы делал своё дело - там уже свыклись что за столь мелкий прайс требовать что-то ещё это уже слишком.
randomsimplenumber
27.08.2026 12:52в госухе от тебя требуется лишь бы делал своё дело
Нам умные не нужны. Нам нужны верные.
0hrenet
27.08.2026 12:52Нам умные не нужны. Нам нужны верные.
Совершенно верно! Сейчас в негосухах умные не нужны, сейчас в негосухах нужны вовлечённые. Т.е. верные и преданные как собаки.
randomsimplenumber
27.08.2026 12:52Умные спрашивают про деньги сначала.
0hrenet
27.08.2026 12:52Толку спрашивать? В современном айти толковому инженеру путь к деньгам заказан. Если только по блату и связям удастся пролезть. Но если их не оказалось, то ой.
Wesha
27.08.2026 12:52Нам умные не нужны. Нам нужны верные.
Мне вот просто интересно — а кто такие «вы»?
randomsimplenumber
27.08.2026 12:52(Ц) забыл ;)
Не хотите заодно поинтересоваться, откуда вдруг изрядное количество толковых инженеров? ;)
Wesha
27.08.2026 12:52откуда вдруг изрядное количество толковых инженеров? ;)
Кормить надо лучше — они и не улетят!
AlekseyPraskovin
27.08.2026 12:52И самое смешное (и грустное), что это детище достаточно скоро будет в общем доступе ака гос сервис
И чем это будет отличаться от типичного госсервиса, который написал студент за миску каши после того как по тендеру был выбран самый дешевый подрядчик (по закону), потом он передал заказ субподрядчику, тот еще одному субу?
Conditus
27.08.2026 12:52Студент за миску каши получит опыт, который потом докрутит, переиспользует и будет готовый блестящий джун+ только с завода. Особенно если дойдет до прода. И всё это под тяжбой ответственности
Здесь же все риски, ответственность за сервис лежат на клоде, который в момент Х опять снесет бэкапы и мы получим ещё одну статью про плохого
мальчикаИИ. А чел либо сольётся ака эт не я же - машина, либо за эту разработку такую премию дадут... Вин вин, получается)
Dhwtj
27.08.2026 12:52платформу на чистом вайбкодинге. Обложился тестами
По моему опыту такое только с UI модулем прокатит и то если упадёт - не жалко. Всю бизнес логику и безопасность надо вычитывать, а лучше проектировать самому и давать LLM только по мелочи
Wesha
27.08.2026 12:52Студент-аналитик, который будет писать такой ботик для бабушки, быстро обнаружит,
что бабушка показала ботик соседке, и та теперь палит, что посадила ее соседка.
Это ещё спасибо, если он на следующие выходные не обнаружит, что его бабушка улучшила оливковую заправку чесноком... В общем, нет у него больше бабушки.
Ndochp
27.08.2026 12:52Ну вообще говоря хранение чищенного чеснока в сливочном масле - давний рецепт времен до холодильников. Мыть надо наверное лучше было зубчики.
Alsig
27.08.2026 12:52Если есть опыт с ассемблером, то подскажите, можно ли получить программу от ИИ, которая будет работать на 90% без сильных действий со стороны человека?
Сам знаю, что скетчи сиподобные ИИ пишет хорошо, а вот с ассемблером у меня не вышло, кроме как примитивов вроде чтения порта и записи в память. Но вместе готовое не выдал.
Dhwtj
27.08.2026 12:52Если есть среда тестирования где бы llm гонял тесты, а задача имеет четкие критерии проверяемом, то не сложно
alcotel
27.08.2026 12:52Если совсем лень думать, то у нейросетки бы и спросили, как лучше сделать. А это не сложная вещь:
Задаём нейросетке задачу - написать программу на Си.
Компилируем Си в асм.
Профит
ksbes
27.08.2026 12:52Во-первых - это совсем другая задача, во-вторых - не во всякий асм из С можно компилировать (хотя это и экзотика)
Alsig
27.08.2026 12:52Разные подходы делал, результат на уровне нуля. Дипсик сам признался, что для 8085 база мала и проще самому изучить тему.
UFO_01
27.08.2026 12:52А зачем вам асм? По моему опыту, асм применяют только в следующих случаях:
Под платформу нет C. Значит это экзотика, и с асм вам тут llm не особо поможет.
Нужна супер скорость, которую не достичь на C, вплоть до тактов. llm вам тут опять-таки не помощник, потому что на каждой платформе есть своя специфика. Если конечно не брать крайне популярные древние компы, но для таких обычно пишут по фану и смысла использовать llm нет.
Какие-то нестандартные фичи вроде математики у dspic, тут вам llm тоже не особо поможет.
Поддержка супер древнего проекта на асм. Опять-таки, llm тут не особо поможет если сами в асм не алё. Код вам объяснят, но вот новый будет добавляться ошибками.
Лучше спросите у нейронки нужен ли вам вообще ассемблер.
Alsig
27.08.2026 12:52У меня оборудование на пса1 а там или дос на машинах того времени или асм. Я в нём не очень хорошо соображаю. Часть функций приходится выносить на внешнее железо. А программу переделывать с заплатками.
Gagydzer
27.08.2026 12:52Не знаю о каком вайбкодинге вы говорите. Я лично построил себе такой агентный флоу, который меня гоняет по кругу уже второй день, потому что в тех правилах, которые я ему задал для фичи, он видит противоречия и отказывается продолжать, пока все не будет уточнения всех деталей
lampslave
27.08.2026 12:52С уточнениями *всех* деталей объем спецификаций, тз и прочих описаний будет в лучшем случае равен объёму генерируемого кода, а то и превысит его. И очень сильно подозреваю, что читать и проверять все эти детали никто не будет, максимум по одному предложению из абзаца. А то, что описанное тз не имеет противоречий, ещё не говорит о его правильности.
Wesha
27.08.2026 12:52С уточнениями всех деталей объем спецификаций, тз и прочих описаний будет в лучшем случае равен объёму генерируемого кода, а то и превысит его
Скрытый комикс
vikarti
27.08.2026 12:52Возможно тут дело в том что которые я ему задал - есть понимание ЧТО надо задать.
Wesha
27.08.2026 12:52есть понимание ЧТО надо задать.
В том-то и дело...
Шагая от звезды к звезде, Лек подошел к Ответчику, положил его на ладонь и поднес к глазам.
— Значит, ты — Ответчик.
— Да, — отозвался Ответчик.
— Тогда скажи мне, — попросил Лек, устраиваясь поудобнее в промежутке между звездами. — Что я есть?
— Частность, — сказал Ответчик. — Проявление.
— Задача мне подобных — собирать багрянец и сгребать его в кучу. Каково истинное значение этого?
— Это нужно для Реальности — сообщил Ответчик.
— Что такое Реальность?
— Частность…Проявление.Лек продолжал задавать вопросы, но Ответчик не мог ответить на них. Конечно он знал, что такое багрянец и для чего предназначена куча. Но объяснение таилось в большем объяснении. Лек не владел теми категориями знаний, через которые Ответчик смог бы ему доступно ответить. И тем не менее Ответчик мог бы объяснить... если бы Лек правильно формулировал вопросы и в правильной очередности.
Наконец Лек презрительно усмехнулся и ушел, стремительно шагая в межзвездном пространстве.
Один на планете, Ответчик ждал тех, кто придет к нему за ответами. Вселенная? Жизнь? Смерть? Багрянец? Восемнадцать?
Ответчик знает на эти вопросы ответы. Но чтобы дать ответ, ему требовался верно сформулированный вопрос. А чтобы верно сформулировать вопрос, нужно знать бОльшую часть ответа...
Kot_na_klaviature
27.08.2026 12:52Статью похоже тоже навайбкодили
smovdir
27.08.2026 12:52От менторства - кровь из глаз льется. Когда, "гуру разработки, сеньер" пролил свет, на то, что вайбкодинг это смертный грех и анальные кары - неотвратимы, пришлось листать сразу в коменты... Ноль статей, ноль опыта и кармы, seo пустышки
Nytoshnaya_Satoshi
27.08.2026 12:52Стыдно признаться, но в статьях про вайбкодинг я обычно сразу иду в комментарии:)
SumQuiSum
27.08.2026 12:52Итого: всё упирается только в опыт - тот у кого его нет будет этот упомянутый хепи сценарий реализовывать. А тот у кого 20+ лет опыта будет вайбкодить как опытный - фронт, бэк, контент, диз, дир, бух, маркет и пр пр. Дело не в вайб кодинге, а в опыте всего бизнес стека.
SDWa
27.08.2026 12:52Да, вот только непонятно, откуда в будущем возьмётся этот опыт у сегодняшних джунов, если они только вайбкодят. Процентов 10 будут копать и разбираться и в итоге станут сеньорами. А остальные не будут напрягаться и так и останутся джунами. В итоге средний уровень компетентности в айти упадёт.
BugM
27.08.2026 12:52. Процентов 10 будут копать и разбираться и в итоге станут сеньорами
Зря вы думаете что раньше конверсия была больше. Пусть даже до 2 процентов упадет. Все равно нормально.
Almaz-kh
27.08.2026 12:52раньше конверсия создавалсь естественным отсевом посредством усложнения задач и повышения требований к опыту по мере карьерного роста. если раньше условные 10% из 100 преобретали релевантный опыт, то теперь это будет дай бог те же 10% от 10%. просто человек так устроен. какой-то средний студент не будет париться и осваивать в деталях инструмент, если можно просто наговорить чату гпт и тот выдаст результат похожий на правду. при том, что весь мир вокруг втирает как это круто, когда при помощи нейросетки можно быть профи в любой области ничего для этого не делая.
напомню, что там сказал один из боссов нейросетевого рынка (Сэм Альтман). что нейросети должны стать как комунальная услуга для каждого. и это очень плохой посыл, как по мне. я не имею ни малейшего желания видить нейросети в списке обязательного ресурса, без которого нельзя жить.
BugM
27.08.2026 12:52Проблема обучения понятна и существует. Она есть не только в разработке, а везде. Нейронка в любой сфере для любой учебной задачи выдаст ответ лучше и быстрее чем тот кто учиться. Что с этим делать и к чему это приведет непонятно.
Я про тех кто уже отучился до уровня типичного джуна. ВУЗ и пару стажировок за еду уже прошел и обладает типичными для этого этапа знаниями.
Almaz-kh
27.08.2026 12:52согласен, проблема обучения касается не только IT. и универы уже начинают запрещать применение иишки в обучении, но тут есть большая проблема. как такой запрет реализовать. процесс обучения в вышке во многом строится на развитии логических навыков и проработки причино-следственных связей в области обучения. а ИИ выдаёт готовый ответ и никаких связей человеку строить не позволяет (да-да, можно попросить ии объяснить как она пришла к некому выводу, но положа руку на сердце сколько студентов будут эту функцию юзать). и с этим же нюансов связано падение проф уровня тех, кто юзает иишки. по факту механизм памяти человека весьма слабенький. и знания нужно постоянно подкреплять и применять напрямую, иначе они уходят.
для меня в этом породокс применения ии. с одной стороны ты можешь обратится к ней по вопросу, который знаешь, но долго или влом думать. и тогда постепенно теряешь свои собственные навыки. с другой стороны ты можешь спросить то, что не знаешь. но ты не поймёшь, если ии звиздит. я хз как решить данный парадокс.
Wesha
27.08.2026 12:52непонятно, откуда в будущем возьмётся этот опыт у сегодняшних джунов, если они только вайбкодят.
Фантасты и это предвидели
— Теперь-то я это понимаю, — сказал Джордж, — до того ясно, что только удивляюсь, каким я был слепым. В конце концов, кто изобретает новые модели механизмов, для которых нужны новые модели специалистов? Кто, например, изобрел спектрограф Бимена? По-видимому, человек по имени Бимен. Но он не мог получить образование через зарядку, иначе ему не удалось бы продвинуться вперед.
— Совершенно верно.
— А кто создает образовательные ленты? Специалисты по производству лент? А кто же тогда создает ленты для их обучения? Специалисты более высокой квалификации? А кто создает ленты... Ты понимаешь, что я хочу сказать. Где-то должен быть конец. Где-то должны быть мужчины и женщины, способные к самостоятельному мышлению.
— Ты прав, Джордж.
Джордж откинулся на подушки и устремил взгляд в пространство. На какой-то миг в его глазах мелькнула тень былого беспокойства.
— Почему мне не сказали об этом с самого начала?
— К сожалению, это невозможно, — ответил Омани. — А так мы были бы избавлены от множества хлопот. Мы [...] не умеем определять, способен ли человек к творческому мышлению. Это слишком тонкая вещь. У нас есть несколько простейших способов, позволяющих распознавать тех, кто, быть может, обладает такого рода талантом. [...] Их приходится примерно один на десять тысяч. В День образования этих людей проверяют снова, и в девяти случаях из десяти оказывается, что произошла ошибка. Тех, кто остается, посылают в такие заведения, как это.
— Но почему нельзя сказать людям, что один из... из ста тысяч попадает в такое заведение? — спросил Джордж. — Тогда тем, с кем это случается, было бы легче.
— Вам ничего нельзя объяснить. В том-то и дело. Ведь в этом заключается последнее испытание. Даже после отсева в День образования девять человек из десяти, попавших сюда, оказываются не совсем подходящими для творчества, и нет такого прибора, который помог бы нам выделить из этой десятки того единственного, кто нам нужен. Десятый должен доказать это сам.
— Каким образом?
— Мы помещаем вас сюда, в приют для слабоумных, и тот, кто не желает смириться с этим, и есть человек, которого мы ищем. Быть может, это жестокий метод, но он себя оправдывает. Нельзя же сказать человеку: «Ты можешь творить. Так давай, твори». Гораздо вернее подождать, пока он сам не скажет: «Я могу творить, и я буду творить, хотите вы этого или нет». Есть около десяти тысяч людей, подобных тебе, Джордж, и от них зависит технический прогресс полутора тысяч миров. Мы не можем позволить себе потерять хотя бы одного из них или тратить усилия на того, кто не вполне отвечает необходимым требованиям.
Gromilo
27.08.2026 12:52Вайбкодинг предполагает, что мы не смотрим в код.
Я пока могу писать в стиле "человек в цикле", получается быстрее чем без ии. Но я постоянно обнаруживаю какую-то дичь в коде, которую не знаю как исправить на уровне промтинга. Например, нужно было сделать атомное обновление счётчка, аля
Insert 1 on conflict count+1, далее прошу нейронку написать как такое сделать без косяков, она пишет, всё правильно пишет, что характерно. Далее прошу закодить по этой спеке: кодит с косяком. Ну как так кто? Потом бы нашлось на ревью, но всё-равно.У меня хорошо работает цикл, когда агент по шагам реализует задачу, я читаю что он там сделал и уточняю своё собственное понимание. И следующий шаг может быть уже не таким как я его планировал до этого.
А как писать не заглядывая в код - хз. Вайбкодишь, вроде всё хорошо, работает, заглядываешь в код - "мать моя женщина!". Может не заглядывать и нормально всё будет?
Kot_na_klaviature
27.08.2026 12:52Может не заглядывать и нормально всё будет?
Ллм продолжит копировать свои плохие паттерны, ухудшая поддерживаемость, пока не начнет путаться в своей лапше - исправлять одно и ломать другое, оставлять дыры в безопасности и производительности.
Gromilo
27.08.2026 12:52Вопрос в том, когда это наступит. Возможно 99% проектов не достигнуть этой стадии. А может начнём дробить, чтобы сервисы были поменьше. Где-то я это уже видел...
У нас тут шутят: микросервис - это сервис, который можно переписать за 1 контекстное окно.
Kot_na_klaviature
27.08.2026 12:52Да сразу и наступит, если следить. Ллм постоянно тупит ошибается итд. Многие надеятся на субагентов и правила, но ллм легко игнорирует эти правила (все последние модели) и субагенты чтото найдут, в чем то переусердствуют чтото не найдут итд Короче без качественного долгого ревью в больших проектах работать нельзя, вайбкодинг с закрытыми глазами - только для маленьких заач и проектиков уровня "сайтик статей без посетителей". Ну т.е. 99% проектов вайбкодеров
Kot_na_klaviature
27.08.2026 12:52Вчера дал задачу GPT 5.6 sol создать апи ресурсы для моделей и прокинуть на фронт. Вроде тупее и шаблонней задачи не придумать. В правилах подробно с примерами написано как создавать ресурсы, ларавел буст подключен с документацией. Все равно надублировала полей и насоздавала запросов в цикле. Да, там запросы неочевидные - она вызывала правила из политик и там внутри по цепочке были запросы, но так в том и соль, что продумать и обойти качественно этот момент. И вот здесь у ллм беда сразу.
Kot_na_klaviature
27.08.2026 12:52Вот только что задача написать тест. Создала приватный метод и там
$this->logPath = storage_path(...);
и в каждом блин тесте вызывает этот метод. Хотя пропиши ты его в сетапе и обращайся. И вот такая тупость постоянно. Вроде исправляется за секунду, но раздражает.
пс пошел дальше смотреть - и опять дубликаты кода везде, хотя у меня в правилах по 300 раз написано что запрещено и как можно не дублировать. Но это походу не лечится..
funca
27.08.2026 12:52У нее задача продавать токены, что противоречит вашей - генерировать минимальный код без дубликатов. Поэтому она сначала пишет по-своему, а потом переписывает по-вашему. Все счастливы.
Advixum
27.08.2026 12:52Вот всю обнаруженную дичь вносшь в системный промт. На сравнении видно очень явно. Например, нейронка накодила очень тяжёлый поход в БД в цикле, потому что это приводит к достижению результата. Добавляешь в системный промт, что так делать не надо (опционально дописать, как делать надо). Откатываешь изменения, повторяешь запрос, получаешь оптимальный код. Так твой системный промт будет постепенно обрастать жирком.
Gromilo
27.08.2026 12:52Системный промт сдохнет.
Я каждый день правлю какое-то количество косяков и они не обобщаются. То что обобщалось - уже в правилах.
rdy88
27.08.2026 12:52Мой опыт в ИТ весьма поверхностный: собирал сайты на готовых шаблонах, немного знаком с HTML и CSS. При этом у меня всегда было множество идей, способных решать реальные проблемы людей и приносить деньги. Раньше они просто угасали в голове из-за отсутствия бюджетов на разработку. Сейчас всё изменилось: по вечерам я спокойно воплощаю свои задумки. Людям это нужно, они готовы за это платить (пока суммы небольшие, но это вопрос масштабирования и охватов). Возражения по поводу безопасности звучат странно — почему я не могу спросить у ИИ о возможных рисках и протестировать свое приложение? У меня уже три работающих проекта, приносящих доход. Я довел их до идеала и устранил все баги исключительно при поддержке ИИ. По сути, нейросети созданы для тех, кто умеет генерировать ценные идеи, но не владеет программированием, или для тех, кто хочет делиться знаниями, но испытывает трудности с оформлением текста. А те, кто утверждает, что ИИ — это инструмент исключительно для MVP, просто находятся в агонии. Они чувствуют, что легкая прибыль ускользает и дальше придется конкурировать за счет реальной ценности, а не просто написания кода.
sidorovkv
27.08.2026 12:52Дружище, а как ты можешь оценивать качество решений в своих трёх продуктах если ты не программист? Что есть идеал? Современные модели конечно хорошо пишут шаблонизируемый код, но запутать их всё ещё просто. И если ты не можешь проверить, что моделька там написала, то ты просто надеешься на лучшее. А надежда на лучшее это не про инженерию. Так что ты и дальше можешь делать свои небольшие сервисы. Если они действительно приносят пользу в своей узкой нише, то вполне могут генерировать прибыль. Но как только ты вступишь на территорию серьезных дядей, о которой писал автор, то тут ты поймёшь, что твои утилитки это маленькие камушки на фоне горных массивов. Ты очень верно подметил - у тебя нет реального продуктового опыта. Поэтому ты и не знаешь с какими громадами приходится работать людям в крупных компаниях. Так что зарабатывай на своих маленьких сервисах и не рассказывай о том в чем не смыслишь.
AlekseyPraskovin
27.08.2026 12:52Дружище, а как ты можешь оценивать качество решений в своих трёх продуктах если ты не программист?
Вот это гейткипинг... Да легко он может. Приложение работает? Бабки приносит? Не падает? Отличное приложение.
А все фантазии про "а вот взломают", "а вот бекдор"... Знаете, когда это происходит в реальном продукте, программист резко несется к столу, где лежат 3 конверта. А если не видно разницы - зачем платить больше?
asdadn
27.08.2026 12:52Слово "гейткипинг" превратилось в эвфемизм для наличия стандартов.
AlekseyPraskovin
27.08.2026 12:52Причем тут стандарты? Когда человек заявляет, что другой человек не может оценивать собственное приложение только потому, что он не программист?
Ndochp
27.08.2026 12:52Да, человек не может оценить собственное приложение [с точки зрения безопасности] если он не специалист [по безопасности]. Особенно ярко это видно, например, в приложениях по криптографии, где разработчик реализует какие-то свои идеи. Ну то есть он оценивает как почти прорыв, пишет статью на Хабр, где ему комментаторы долго и с удовольствием поясняют с примерами, где он не прав. То, что человек программист - не спасает.
UFO_01
27.08.2026 12:52Да какая разница, главный вопрос в том какие риски для него несёт тот факт что он не может оценить собственное приложение. А он не может, точно так же как я не могу понять чем мерс лучше китайца - компетенции нет.
С одной стороны можно бабки просадить на программистов, которые могут воспользоваться твоей неосведомлённостью. Всё-таки разработка не может длиться бесконечно, на поддержку людей надо куда меньше, а кушать хочется. И всё ещё получить такое же непонятное как написанное и работающее нечто, которое выдаст и нейронка. Так зачем переплачивать?
А вот если нам надо точно знать что будет на выходе, тут уже в дело вступают разные ухищрения со стороны бизнеса. Собственно поэтому во главе скажем rohde & schwarz стоят инженеры, а не менеджеры.
Wesha
27.08.2026 12:52я не могу понять чем мерс лучше китайца
Как не можете? Содержанием понтов на килограмм сухого веса, конечно же!
Almaz-kh
27.08.2026 12:52я в своей жизни видел 2 случая, когда приложение работало, деньги приносило. а потом взлом и огромные потери бабок за 1 день, отключение функционала и дорогостоящие доработки, которые долго игнорились, хоть и были очевидно необходимы. справедливости ради отмечу, что это было до эры ИИ.
кстати, аргументация бизнесов там была такая же "приложение работает? бабки приносит? ну и нефиг моросить". правда после взлома резко сменилась аргументация на "а чо вы раньше ничего не сделали"
AlekseyPraskovin
27.08.2026 12:52справедливости ради отмечу, что это было до эры ИИ
О чем я и говорю. Что с кожаными на разработке ровно те же проблемы. Так может дело не в том, кто разрабатывает, а в том, кто (и как) задачи ставит? Да не, бред какой-то...
правда после взлома резко сменилась аргументация на "а чо вы раньше ничего не сделали"
И что на это ответили настоящие программисты?
Almaz-kh
27.08.2026 12:52я и не отрицаю, что проблемы были и раньше, но теперь генерация проблемного кода стала проще и быстрее, что статистически не может не повысить кол-во связанных с этим проблем. при этом повального роста удачных бтзнес решений я не наблюдаю. вайбкодят обычно что-то донелья стандартное и виданное много раз. + код теперь может генерить тот, кто его не понимает. а значит о проблеме он узнает весьма поздно. в проектах с небольшим бюджетом и малыми рисками - это норм. но для проектов имеющих большие финансовые риски лучше так не делать. и тут в дело вступает другая проблема. вайбкодинг навязывается в крупных компаниях. притом бизнесу, который и так иногда не хочет брать риски по безопасности и архе на себя.
настоящие программисты подняли переписку за последние 2 года и показали, что уже 2 года говорят о рисках, но им не давали денег на их устранение и админ ресурсом засовывали их мнение подальше, чтоб не мешало делать инновационные супер продукты за недорого. и сейчас с ИИ я наблюдаю новую волну аналогичных решений. и снова все будут радоваться и в воздух чепчики бросать, пока что-то серьёзно не крякнется. а после снова будет цикл поиска виноватых. благо в цикле вайбкодинга всегда проще найти виноватого. тот прогер от которого компания требовала вайбкодить и кодить быстрее как раз подходит как козёл отпущения. с фига ли он всё трижды не перепроверил.
Wesha
27.08.2026 12:52> правда после взлома резко сменилась аргументация на "а чо вы раньше ничего не сделали"
И что на это ответили настоящие программисты?
«А мы вас предупреждали, и хотели сделать — но, между прочим, это вы нам не разрешили.»
UFO_01
27.08.2026 12:52TL;DR Не стоит грести всё под одну гребёнку, сложность разработки относительно объёма и уровня безопасности растёт экспоненциально. Если для вас это гейткипинг, что ж, сочувствуем всем селом.
В целом я согласен, но тут есть один тонкий момент. Чувак пилит сайтики чисто для себя, которые скорее всего решают какие-то конкретные проблемы людей. На такое и раньше сажали макак на аутсорсе, проверяли лишь бы работало, а всё упиралось только в то, что макаки хотят побольше денег. Какая-то там безопасность она и не упёрлась, кто будет взламывать сайт на котором 3 калеки сидит.
А вот когда бизнес строится на безопасности и отказоустойчивости, то за 3 конвертиками и бежать не надо в случае чего. Программист гарантирует что с такой-то вероятностью всё будет ок, и может это доказать, если вас это устраивает - все дальнейшие риски на вас. Написать as is и думать что мы в шоколаде увы не получится, куда подальше пошлют. А что там нейронка гарантирует? Что содержимое может быть неточным?
Другое дело что многие умники как раз из-за того, что их результат оценить не могут, искусственно раздували и бюджет и функционал пуская пыль в глаза, но я сам такое не особо одобряю.
Меня кстати иногда спрашивают, мол как же так, почему программистов которые пишут супер ответственные вещи не сажают из-за каких-то инцидентов. А всё очень просто, в таких сферах пока не докажешь что достигнут требуемый уровень безопасности, тебя на рынок просто не пустят. Если всё доказано и этот уровень устраивает покупателя - все риски на нём.
AlekseyPraskovin
27.08.2026 12:52Программист гарантирует что с такой-то вероятностью всё будет ок, и может это доказать
Но чтобы проверить это доказательство, заказчику нужно быть программистом. Хм, чую где-то подвох, но где...
ksbes
27.08.2026 12:52Подвох в системе репутации. В том числе и ситемы иерархической репутации - когда за программиста ручается его начальник, который куда ближе к программированию.
UFO_01
27.08.2026 12:52Ну какая репутация, вы о чём вообще. У заказчика есть требования, как вы будете выполнять - не его забота. У вас есть обязательства, если заказчик не удосужился проверить их исполнение - его проблема. Всё. Во внутренней разработке то же самое, если вы не в состоянии контролировать процесс, это ваша проблема и недоработка. И потом не удивляйтесь что вас налюбливают как хотят.
А то все хотят тех кто с репутацией, а как видят ценник, так сразу в лице меняются. Я имею в виду реальную репутацию, а не чей-то брат сват друг, и не списочек из 100500 фирм которым вы забор красили на вашем сайтике.
UFO_01
27.08.2026 12:52Для таких вещей и существует верификация, валидация, сертификация и независимый аудит, помимо аудита со стороны заказчика. Джентльмены друг другу на слово не верят.
Для любителей говорить "А вот ФСБ виндоус сертифицировало!!!", да, было такое, на самый низший уровень, из разряда "ну оно там следит, данные сливает, если вы юзверь без допуска - пользуйтесь".
Wesha
27.08.2026 12:52чтобы проверить это доказательство, заказчику нужно быть программистом
Компании, чьим бизнесом является аудит чужих решений? Не слышали!
funca
27.08.2026 12:52Большинство аудитов чужих решений кода вообще ни как не касаются - являясь сугубо бумажной историей в поддержку маркетинга. А те, что касаются, по факту оказываются чьим-то пресейлом в надежде отжать заказ у конкурента. Ну либо стоят как звездолет.
Wesha
27.08.2026 12:52Ну либо стоят как звездолет.
А что Вы думали — счастья, всем, бесплатно?
Ну то есть Иван Иваныч хочет сэкономить (на коде, аудите и пр.) — а потом жалуется «а почему меня взломали??»
Каждый — сам кузнечик своего (не)счастья.
Almaz-kh
27.08.2026 12:52самое забавное в заказчиках/покупателях - это то, что все риски они на себя берут ровно до того момента, пока эти риски не срабатывают. как только риск срабатывает начинают винить сотрудников, исполнителей, бога и отечество. и начинаются диалоги типа "да, мы были согласны с риском, но мыж не думали, что это прям реально риск такой есть, чините всё бесплатно"
UFO_01
27.08.2026 12:52Это всё решается очень просто. Вот договор, вот предупреждение, вот заключение, вот раздел об ответственности сторон, вот ваша подпись. Хотите оспорить - идите в суд. Не хотите - выдвигайте замечания, если прописано в договоре, исправим, если нет, вот чек на доработку.
Almaz-kh
27.08.2026 12:52в большинстве случаев это именно так, но если заказчик полезет в бутылку и пойдет судится, то всегда почему-то в таких документах находится двусмысленность. и суды отнимают много времени. экспертизы и всякое прочее нехорошее. победитель будет прав, проигравший будет жить.
UFO_01
27.08.2026 12:52Опять-таки, если вы допустили что в договоре есть лазейка и двойное чтение, это ваша проблема и кто-то плохо выполняет домашнее задание. И если вы заранее подготовили весь пакет документов, все претензии как правило решаются в досудебном порядке. Почему-то я вот ни разу не видел чтобы в документах находили двусмысленность, хотя претензии и инциденты были, куда же без этого. Всё разруливалось согласно договору и причина устранялась.
sidorovkv
27.08.2026 12:52Ты забываешь, про то что итеративная разработка ведёт к накоплению тех долга. Сегодня агент внёс один косяк, завтра другой, послезавтра третий. Через неделю ты даёшь ему задачу, он смотрит как подобное было реализовано до этого и думает: "Хм, а в этом проекте можно писать вообще как хочешь, стейкхолдеру плевать на качество кода". И пишет все хуже и хуже и хуже. И вот через энное количество итераций, он уже пишет только костыли. Ведь ты не способен оценить как он пишет код. А так как тесты пишет тоже он, то и тесты проходят. Да, есть всякие методики как плясать с бубном, чтобы нейросеть выдала вменяемый результат. Но в конечном счёте это работает только с какими-нибудь небольшими утилитами или микро-saas. Так что мне не нужно заниматься гейткипингом, с этим и современные модели не плохо справляются.
amazingname
27.08.2026 12:52почему я не могу спросить у ИИ о возможных рисках и протестировать свое приложение
Можете. Если писать приложение для себя а не как фрилансер на продажу, то по моему мнению вайбкодинг вполне эффективен. Но конечно же здесь важно кто и как пишет. Раньше для получения работающего продукта нужно было иметь специфический склад ума и навыки. Сейчас достаточно быть просто умным.
Раньше плохой программист мог накодить для себя или для заказчика ужасный падучий не сопровождаемый продукт. С вайбкодингом то же самое - если человек не умеет делать работу вдумчиво и хорошо, то ничего путного он не запустит.
Сам я программист, перестал писать код руками уже с пол-года. Но я вижу как толковые люди без способностей к программированию проходят тот же путь что я, и ухватывают как создать продукт с AI не хуже меня. Я могу создавать гораздо более сложные системы чем вайбкодеры не программисты, это да. Но когда сложность всего продукта не так уж высока, между нами не так много разницы. Разве что, я сразу понимаю что делает агент, а вайбкодет пытает его несколько дней, пока не запомнит термины, не получит в разжеванном виде концепции и так далее.
amazingname
27.08.2026 12:52По сути, нейросети созданы для тех, кто умеет генерировать ценные идеи, но не владеет программированием, или для тех, кто хочет делиться знаниями, но испытывает трудности с оформлением текста.
Вообще, программирующие нейросити созданы профессиональными программистами на базе профессионального кода для решения задач профессионального программирования. То что они же позволяют создавать продукты и без опыта разработки - это побочный эффект которого никто намеренно не добивался.
Wesha
27.08.2026 12:52Вообще, программирующие нейросити созданы профессиональными программистами на базе профессионального кода для решения задач профессионального программирования. То что они же позволяют создавать продукты и без опыта разработки - это побочный эффект которого никто намеренно не добивался.
Вообще-то программирующие нейросети созданы профессиональными программистами на базе кода, напылесошенного по всему Интернету — в первую очередь Stack overflow (иными словами, соответствующего какачества) — для решения задач
продажи этого слонаутолщения кошельков Альтмана, Карпатого и пр.There, FTFY.
amazingname
27.08.2026 12:52Инженеры того же антропик для утолщения кошельков (подставить имя владельца) сами пользовались своим продуктом для разработки и интерактивно его улучшали. Из чего следует мой выше приведенный вывод.
verls
27.08.2026 12:52У "инженеров Антропика" самые большие контекстные окна, размером с датацентр. Обычным смертным столько не нальют либо это будет стоить сверхмного денег.
Kwentin3
27.08.2026 12:52Читается немного как: «Да, экскаватор действительно копает в десять раз быстрее. Но ведь траншею всё равно надо правильно разметить, проверить грунт, соблюдать технику безопасности и потом обслуживать. Поэтому количество землекопов и смету сокращать ни в коем случае нельзя».
С большинством перечисленных инженерных рисков спорить бессмысленно — security, тесты, observability, backup, rollback и архитектура действительно нужны. Но из факта, что эти работы нужны, совершенно не следует, что на них по-прежнему требуется прежний объём человеко-часов и прежний ФОТ.
Более того, автор сам пишет, что AI уже ускоряет исследование, написание тестов, рефакторинг, документацию и генерацию кода. Но почему-то экономический вывод из этого делается удивительно односторонний: производительность выросла, инструменты стали мощнее, значительная часть рутины автоматизируется — а смета опытной команды, видимо, является фундаментальной физической константой.
Особенно красиво, что в статье есть отдельный пункт про «инженерную экономику», но применяется она в основном к инфраструктуре заказчика. До экономики собственного ФОТ этот принцип почему-то не доезжает.
Поэтому проблема здесь, кажется, не в тезисе «вайбкодинг ≠ зрелая инженерия» — это банально верно. Интереснее другой вопрос: если опытный инженер с AI теперь способен за то же время проверить и реализовать существенно больше, почему заказчик должен продолжать оплачивать организационную структуру и трудозатраты эпохи до AI?
Вот на этот вопрос хотелось бы увидеть цифры, а не очередной рассказ о том, насколько сложен production.
sidorovkv
27.08.2026 12:52Я не увидел в их статье что-то против сокращения команды. Идея скорее в том, что не надо думать, что с большим проектом может справится один человек с туманным опытом. И в этом есть своя правда.
randomsimplenumber
27.08.2026 12:52почему заказчик должен продолжать оплачивать организационную структуру и трудозатраты эпохи до AI?
Он и раньше ничего не должен, кроме денег. Как с исполнителем договорились - так и платит. А как там у исполнителя устроено - лично Торвальдс код пишет, или волшебные гномики - его не должно волновать.
Almaz-kh
27.08.2026 12:52большой вопрос в том, насколько верно утверждение "опытный инженер способен реализовать больше за то же время". и применимо ли это утверждение к любому проекту? а может мы заигрались в самообман? может время не экономится (судя по жалобам сотрудников крупных компаний)? может падает качество конечного продукта? может повальная выкатка сырых продуктов на рынок негативно на него влияет? эти проблемы ведь не вчера появились и внедрение ИИ их усугубило. но только теперь это подаётся как некая норма рынка. продуктовые команды и раньше были помешаны на выкатке нового без окончательной проработки старого. и ситуация стала хуже с внедрением AI в массы. и проблема даже близко не в технологии. технология хорошая. проблема в том, что применяют её как попало.
p.s. у меня в последнее время потрясающие калейдоскопы диалогов в командах.
-надо сделать поиск в базе знаний через нейросеть, вон команда 66 сделала, при помощи нейросети можно достать что угодно теперь
- зачем нам это? недостаточно впилить поиск в базу знаний. нужно поддерживать актуальность базы знаний, а на это тупо нет ресурсов, вы же уволили всех. плюс база знаний разграничена по административным правам. часть страниц нельзя смотреть, если нет определенных доступов. это связано с безопасностью. и для кого это?
- для онбординга, дадим всем доступ всюду
- как часто бывает онбординг? вы осознаете сколько ресурсов нужно тратить на поддержку этой базы и нужно сломать текущие правила доступа к чувствительным данным, что очень рискованно
- не важно как часто. все проблемы решаемы. не понимаю почему вы противитесь прогрессу. нейросети - это уже наша новая реальность.
p.p.s. и вот я как идиот сижу в ситуации, когда меня принимают за какого-то лудита. моя специализация - это проектировать то, что будет деньги приносить и покрывать потребности клиента, а я должен лезть в заведомо мертворожденнное нечто, потому что его можно вайбкодить.
Wesha
27.08.2026 12:52опытный инженер способен реализовать больше за то же время
Ви так говорите, как будто это что-то хорошее
UFO_01
27.08.2026 12:52Не совсем верное сравнение, потому что на малую траншею всё ещё выгоднее нанять землекопов, а не гнать экскаватор, плюс экскаватор может сделать то, что не могут землекопы. Корректнее будет взять сравнение ну скажем с прозой. Донцова сколько угодно может писать свои романы, Шекспиром она от этого не станет. Другое дело что большинству и Донцовой достаточно. Вот с ПО так же.
Кстати, насчёт ФОТ. Есть такой парадокс Джевонса, который гласит что повышение эффективности ведёт только к увеличению потребления ресурса. Просто потому что вместе с эффективностью растут аппетиты, что мы и наблюдали в разработке начиная с 80-х годов, но касается это не только разработки понятное дело.
ksbes
27.08.2026 12:52Парадокс Джевонса работает только если есть что копать, если есть почти необозримый резерв для экстенсивного развития. Т.е. , возвращаясь к оригнальному парадоксу - возрастанию потребления угля паровыми машинами при повышении их эффективности - если все шахты уже прокопаны и все железные дороги уже проложены и все заводу уже построены, то парадокс не возникнет. Так собственно было с печально известными ткачами: заворачивать себя в ещё несколько слоёв шерсти никто не будет, рынок насыщен, неэффективным - надо уйти.
И честно - я не могу сказать какая из ситуаций сейчас в ИТ. Готовы ли обмазываться новыми слоями софта или уже присытились цунами информации?
funca
27.08.2026 12:52Разработка большой доли софта мотивируется оптимизацией. То есть жадностью. А она безгранична. ИИ меняет ладшафт требуемых компетенций. Но саму индустрию с рынка он не выкинет.
sidorovkv
27.08.2026 12:52Я думаю, что комментатор выше имел ввиду, что не совсем понятно, внедрение ИИ создаст ещё больше потребность в профессионалах, потому что даже сложная разработка станет доступна тем кто раньше и на простую не мог денег наскрести. Или же инструменты ИИ разовьются таким образом, что закроют полностью потребность низа рынка, а наверху останется немного разработчиков, способных хорошо координировать агентов. И рациональное зерно тут есть.
UFO_01
27.08.2026 12:52Понятное дело что у всего есть предел. И вот как раз с ПО всё не так однозначно, сферы для расширения есть и их много, но они как правило не в потребительском секторе, и всё как всегда упирается в деньги. Ну и плюсом задачи там требуют совершенно другого уровня компетенции. И некоторые вещи просто дешевле делать по-старинке и их автоматизировать бессмысленно.
Одно точно, нас ждут весёлые времена. И скорее всего не в лучшую сторону.
Wesha
27.08.2026 12:52экскаватор может сделать то, что не могут землекопы
Например, сломать столб или провалиться сквозь крышу!
funca
27.08.2026 12:52AI‑assisted development и vibe coding не одно и то же. В первом случае инструмент ускоряет инженера. Во втором человек передает инструменту решения, которые сам не умеет проверить.
Хорошо сказано. Фишка ещё в том, умеет-ли заказчик (я так понял речь о заказной разработке) сам проверять. А так же способен-ли он в принципе осознать зачем ему пытаются продать еще что-то сверху кроме полезной функционмльности.
Мне на практике встречались две крайности. Одни реально не понимают - как правило это их первый проект. Другие хитрят, умалчивая о подводной части айсберга НФР, что потом развести на неоплачивыемые доработки, как нечто само собой разумеющееся. Интересно как у вас?
mixsture
27.08.2026 12:52когда прототип перестает быть игрушкой и становится активом компании. Когда в него приходят реальные пользователи, реальные деньги, персональные данные, интеграции, SLA, бухгалтерия, поддержка и ответственность.
я для себя пришел к очень простому разделению. Когда мы на стадии MVP - все затраты - это лишь код, наша система состоит из одного лишь кода. Когда мы перешли в реальную эксплуатацию, у нас начинают накапливаться данные, их стоимость начинает расти. И когда стоимость данных перевешивает стоимость кода - можно говорить, что мы перешли в enterprise.
Вот первая стадия отлично ложится на вайбкодинг из-за почти нулевых потерь при потере данных. Вайбкодинг дает (условно) шанс уничтожения данных 10%? Да и фиг с ним, у нас только тестовые, заново загрузим.
Но это становится неприемлемо дорогим на второй стадии. И тут подходит AI-augmentation (который выше назвали AI‑assisted development) - т.е. некая совместная работа человека и ИИ - это может быть “помощник думания”, “более продвинутый поиск по документации” и до “кодер, но с обязательным и пристальным ревью человека”. Общая цель - удержать шанс уничтожения данных околонулевым.
Akanameis
27.08.2026 12:52Сейчас нам расскажут за что можно и нужно получать килорубли, а ламеры с вайбкодингом будут нищими.
sidorovkv
27.08.2026 12:52Ну по сути так и будет. Развитие нейросетей ведь не только даёт возможность балбесам без образования и опыта делать вид, что они синьеры-помидоры. Оно ещё даёт возможность пользователям самим напрямую взаимодействовать с нейросетями. И получать результат без прослойки, которая и сама не очень то шарит, что там внутри творится.
rdy88
27.08.2026 12:52Через несколько лет 90% сегодняшних образованных синьоров-помидоров поедут развозить заказы на самокатах, потому что их исключительное право писать код стало никому не нужно. Привыкайте к новой реальности
becefi
27.08.2026 12:5290% может и поедут. 10% останутся, т.к. сеньор-помидор с ИИ - гораздо эффективнее, чем профан с ИИ. Привыкайте к тому, что ИИ у всех одинаковый, и опытный разработчик с его помощью, будет в 100 раз эффективнее и быстрее, чем вы.
0hrenet
27.08.2026 12:5290% может и поедут. 10% останутся,
И главное каждый уверен что он точно войдёт в эти 10%, а 90% это кто-то другие.
randomsimplenumber
27.08.2026 12:52Футурология бессердечная щука. Дедушка помнит, когда появились Delphi с VBA, и каждый пользователь мог навайбкодить себе калькулятор, или базу данных. Ух, как тогда 90% программистов на ассемблере побежали развозить заказы...
0hrenet
27.08.2026 12:52Ну таки кто продолжал ваять на ассемблере "потому что компилятор дичь выдаёт" - те и правда далеко не уехали. А кто побыстренькому формошлёпил что просил бизнес, и плевать что экзешник выходит на мегабайты - обзаводились своим жильём без ипотек.
История повторяется по спирали.
Wesha
27.08.2026 12:52появились Delphi с VBA, и каждый пользователь мог навайбкодить себе калькулятор, или базу данных.
(Характерным жестом поправляя очки на носу:) Намыши́ть!
randomsimplenumber
27.08.2026 12:52Ну да, ну да.. раньше в бухгалтерии 20 человек сидело с гроссбухами и арифмометрами. Им дали вычислительную машину, которая сосчитает всю ихнюю работу за пару секунд. Сколько сейчас в бухгалтерии работы осталось?
0hrenet
27.08.2026 12:52Нисколько. Сейчас у мелких фирмёшек бухгалтерия на аутсорсе. А раньше да, свои бухи, свои админы.
Vicollel
27.08.2026 12:52У нынешних синторов нет исключительного права писать код, такое право есть у всех, и оно есть у каждого, просто кто-то этого не умеет, в том числе и вы.
Я понимаю ваше злорадство - синьоры много зарабатывают благодаря своим знаниям, как вам кажется, незаслуженно, а вы так не можете. Но, к сожалению, с приходом вайбкодинга вы зарабатывать много всё равно не начнете. И, хотя для вас главное не самому зарабатывать достойно, а чтобы сосед тоже зарабатывал мало, поверьте - синьоры продолжат зарабатывать хорошие деньги, просто задачи изменятся.
sidorovkv
27.08.2026 12:52Понимаешь в чем дело образованный синьор-помидор всегда будет эффективнее в разработке, чем вайбкодер. Так что если 90% синьоров поедут развозить заказы, то это это будет значить, что 100% вайбкодеров уже давно их развозят.
Слышал когда-нибудь про парадокс Джевонса? Есть не нулевая вероятность, что на такой ресурс как опытный программист, которого раньше себе могли позволить только средние и крупные компании, спрос станет только выше, когда он станет доступен малым компаниям и частным лицам.
Sony_py
27.08.2026 12:52Я такого рода статьи называю «байт-статьями»: берётся громкая и актуальная тема, вокруг неё создаётся конфликт, а затем на протяжении нескольких экранов доказывается очевидное.
Пока вы рассказываете, насколько опасен vibe coding, индустрия использует LLM ровно там, где они дают максимальный экономический эффект: быстро собрать MVP, проверить гипотезу, получить первые данные от пользователей и понять, стоит ли вообще инвестировать месяцы разработки в продукт.
И самое интересное - автор статьи в итоге сам с этим соглашается: vibe coding хорош для прототипов и проверки продуктовых гипотез. То есть спор в значительной степени создаётся искусственно.
Главная подмена здесь в другом. Проблема «человек не понимает архитектуру, безопасность, авторизацию, БД и эксплуатацию, но выкатывает код в production» существовала задолго до Cursor, Claude и ChatGPT. До LLM точно так же существовали джуны, copy-paste development, Stack Overflow driven development, кривые WordPress-плагины, подрядчики за три копейки и проекты без тестов, мониторинга и backup strategy.
LLM эту проблему не создала. Она лишь увеличила скорость, с которой человек способен как писать хороший код, так и совершать ошибки.
Поэтому противопоставление «vibe coding против настоящей инженерии» выглядит странно. Это вообще разные оси. Можно написать ужасный production вручную, а можно с помощью LLM построить вполне нормальную систему, если решения принимает человек, который понимает архитектуру, security, данные и эксплуатацию.
Более того, утверждение о том, что быстро созданный MVP якобы потом обязательно превращается в дорогостоящую проблему, тоже слишком категорично. Цель MVP зачастую вообще не в том, чтобы стать фундаментом системы на следующие десять лет. Его задача -максимально дёшево ответить на вопрос: «Это кому-нибудь нужно?»
Если гипотеза умерла - отлично, вы потеряли неделю, а не шесть месяцев работы команды.
Если гипотеза подтвердилась - дальше уже принимается инженерное решение: что оставить, что переписать, где провести аудит, где добавить тестирование, observability, security review и нормальную инфраструктуру.
И это может оказаться значительно дешевле, чем сначала полгода строить «правильную production-архитектуру», а потом обнаружить, что продукт никому не нужен.
Ну и отдельный штрих: примерно с середины статьи внезапно выясняется, что авторская компания как раз умеет делать всё то, чего якобы не хватает несчастному vibe coder'у: 10+ лет опыта, full cycle, security review, DevOps, аудит и прочий полный набор.
Совпадение? не думаю.
Само по себе наличие рекламы не делает аргументы ложными. Но когда сначала долго объясняют, насколько опасно делать продукт без «взрослой инженерии», а затем оказывается, что эту самую «взрослую инженерию» тебе готовы продать, статья начинает восприниматься уже немного иначе.
Поэтому реальная формула намного скучнее заголовка:
LLM не отменяет инженерную компетентность. Но инженерная компетентность совершенно не требует отказаться от LLM.
А «не отдавайте production человеку, который не понимает, что делает» - это хороший совет. Просто к vibe coding он имеет гораздо меньше отношения, чем пытается показать статья.
igorevsiev
27.08.2026 12:52Да, к тому же странно противопоставлять одно с другим
Инженерию ПО и MVP. Что важнее?
Это как бороться что важнее маркетинг или производство..
Здесь смешивается и то и другое..
amazingname
27.08.2026 12:52Есть и более жесткие академические результаты. В работе 2025 года с 200 задачами на изменение реальных open‑source проектов один из протестированных агентов в конкретной конфигурации выдавал функционально корректное решение в 61 процентах случаев, но безопасным было только 10,5 процента решений [3]. Это не означает, что «LLM пишет уязвимости в 89,5 процента случаев» вообще. Это означает более важную вещь: функциональная корректность и безопасность могут очень сильно расходиться.
На этом можно вопрос с этой статьей закрыть. В 2025 лучшем случае они могли тестировать Opus 4.5. А после этого был кардинально более сильный Opus 4.6, порвавший его Opus 4.7, пробивший все потолки Opus 4.8 а потом Opus 5, который изумляет как количеством сжираемых токенов так и способностью предусмотреть вообще все. Ах да... забыли про фейбл. Ну и как известно, антропик, OpenAI и Google распустили коллектив, раздали инвестиции на благотоворительность и остановили разработку моделей.
Кто принимает архитектурные решения и как они документируются? Как устроен code review? Какие тесты обязательны перед релизом? Как проверяется модель авторизации? Где хранятся секреты? Как устроены окружения? Можно ли воспроизвести инфраструктуру? Что происходит при неуспешной миграции? Есть ли rollback? Как проверяется восстановление из резервной копии? Какие метрики и алерты появятся до запуска? Кто разбирает инцидент? Как вы передадите проект другой команде, если сотрудничество закончится?
Вайбкодер прочитал вашу статью, загрузил ее в агента и попросил ответить на все эти вопросы и устранить все подобные пробелы. Что дальше?
«Зачем мне команда разработки? Я найду человека, который умеет хорошо промптить, он за неделю соберет продукт в Cursor/Lovable/Replit, и мы сэкономим месяцы и бюджет».
А что мешает найти вайбкодера с хорошим продуктовым опытом?
Zx2001
27.08.2026 12:52Вайбкодер прочитал вашу статью, загрузил ее в агента и попросил ответить на все эти вопросы и устранить все подобные пробелы.
The seam is load-bearing. Root cause: the asserted refusal survived a premise which restated (c) deliberately - (phase 1.B). The pre-fix is outright byte-identical (c). Nothing carves-out mutation-checked levers, they are falsified empirically. Want me to test the mirror-alias invariant directly?
(Или аналог на русском). Сидит такой вайбкодер: - ну навeрное да: делай без ошибок.
amazingname
27.08.2026 12:52Это если вайбкодер вчера из колхоза приехал. А если он хотя-бы 15 летний балбес, играющий в Майнкрафт, то он пишет - погодь, ты по простому мне объясняя что мы имеем, что с этим можно делать и какие последствия будут. И через часик глядишь, решения есть и не такие уж плохие.
ximera405
27.08.2026 12:52А что мешает найти вайбкодера с хорошим продуктовым опытом?
Именно в этом и кроется проблема - работодатели в 90% случаев не разбираются в том, кто и что из себя представляет. А вайбкодеры без бекграунда вероятнее всего предложат цену значительно ниже за работу
microtheft
27.08.2026 12:52Было кейнсианство, потом неокейнсианство, теперь эникейнсианство...есть что-то в этом от религии...
Dhwtj
Ну так демо по определению только для демонстрации happy path
Dmitry_604
На демо могут просить показать разные сценарии,. У нас например частенько записываются новые задачи именно на демо. Можно сказать недотестировано да - но это взяглд с третьей стороны получается
Dhwtj
В любом случае демонстрируется крайне ограниченный набор сценариев