Уже давно практикую это дело, пока можно сказать новый зверь и никто толком не знает шо оно такое.
Сразу оговорюсь, самый лучший такой кодогенератор из проверенных GPT o3. Обычная GPT5 подходит только для простых случаев, поэтому когда что-то нужно сделать — то задаю именно o3 через https://platform.openai.com/ И тут вроде и то и другое чат — но одно выдает смех и фигню а другое что-то более-менее осмысленное. После этого другие использовать не хочется, хотя, возможно, платные от других производителей тоже норм., но все-же не проверишь. Бесплатные фигню выдают.
Далее из интересного. Есть вещи, которые вроде бы не сложные — но оно не может делать никоим образом. А именно — не умеет строить объектные модели для той или иной задачи. К примеру была задача сделать кодогенератор по WSDL (на Dart, для которого нет готового). Задачу разбиваем на две — парсинг в объектную модель и потом генерация из объектной модели. Оно смогло построить и парсинг и кодогенератор — но не смогло объектную модель никоим образом, хотя вроде бы с нашей гуманоидной точки зрения это самое простое
Т.е. нужно принять что есть вещи, которые легко даются нам — но не достижимы для LLM. Т.е. оно попытается сделать — но выдаст фигню
Лучше всего оно умеет дополнять — т.е. пишите некий скелет с пустыми функциями, в функциях комментариями пишите что нужно — оно генерит.
Далее, код генерится "одноразовый", скажем так. Оно может работать, как вот парсинг — но будет сделано на сложных регулярных выражениях, там где можно сделать намного проще. Т.е. часто имеет смысл стратегия черного ящика — чтобы вам не поплохело — лучше не заглядывать в код. Если одноразово он свою задачу выполнил — то ОК, что еще нужно.
Размер кода — около 500 строк еще норм, дальше начинаются проблемы. По этому разбиваете на независимые куски с четко оговоренными интерфейсами взаимодействия и оно еще более-менее напишет. Т.е. нужно уменьшать связность.
=сначала спроси у GPT=
Re: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Shmj, Вы писали:
S>Уже давно практикую это дело, пока можно сказать новый зверь и никто толком не знает шо оно такое.
Вот я совсем не знаю, что это такое.
И вообще, есть мнение, что ИИ будет занимать руководящие должности. Потому что давно известно: кто не умеет работать, идёт руководить. Написать бумажку с распоряжением: надо такую свистелку фичу гораздо проще. И ответственности никакой.
Но закончиться это может так, как показано в старом фильме "Отроки во Вселенной". Или в "Миссия невыполнима-8", там что-то про ИИ, захватывающий власть, насколько я помню.
Re: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Shmj, Вы писали:
S>Размер кода — около 500 строк еще норм, дальше начинаются проблемы. По этому разбиваете на независимые куски с четко оговоренными интерфейсами взаимодействия и оно еще более-менее напишет. Т.е. нужно уменьшать связность.
Играюсь в этом плане с Дипсиком. Вполне справляется неплохо писать маленькие кусочки кода до 50 строк при очень ясной и четкой постановке задачи. Но требует, чтобы ты был по уровню программирования и понимания решения задача прилично выше его.
В этом случае тупое написание частей кода можно скинуть на него.
Если твоей квалификации не хватает в какой-то задаче, то что с дипсиком, что без него получишь фигню.
В общем, как помощник — написать какую простую функцию от отличен, для остального не годится.
Re[2]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Privalov, Вы писали:
P>И вообще, есть мнение, что ИИ будет занимать руководящие должности. Потому что давно известно: кто не умеет работать, идёт руководить. Написать бумажку с распоряжением: надо такую свистелку фичу гораздо проще. И ответственности никакой.
Вот как раз нет. Руководить вроде легко — но для него недостижимо. Это как я описал пример создания объектной модели — вроде фигня, ничего вычислять не нужно — но нужна точность и понимание для чего ты это делаешь. Оно такого не может
Так что руководители как раз не будут заменены, особенно если они рискуют своими деньгами.
=сначала спроси у GPT=
Re[3]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Privalov, Вы писали:
P>>Потому что давно известно: кто не умеет работать, идёт руководить.
S>Вот как раз нет. Руководить вроде легко — но для него недостижимо.
А кто и руководить не умеет, идёт преподавать.
Re[2]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Privalov, Вы писали:
P>И вообще, есть мнение, что ИИ будет занимать руководящие должности. Потому что давно известно: кто не умеет работать, идёт руководить. Написать бумажку с распоряжением: надо такую свистелку фичу гораздо проще. И ответственности никакой.
Вообще то работа именно руководящей должности — это не писать бумажки с распоряжениями. А в первую очередь убедить вышестоящих что все идет хорошо и нужно увеличить финансирование. Если случился какой косяк, то объяснить, почему это нормально. Выбить бешенный раздутейший бюджет, набрать народу черти сколько. Основной навык — убеждать других. Причем не словами, а интонацией и харизмой! Одни и те же слова, одни и те же аргументы — в одном случае будут восприняты вышестоящими, в другом случае нет. И обязательно словами — если написать письмо, оно не будет даже прочитано, нужно именно словами. У руководящих должностей основная работа — это совещания. Во вторых — это заполнение отчетов. И только в третьих это кого то там пинать из подчиненных, чаще всего особо подчиненных то пинать и не требуется, а требуется пинать кого то из соседних отделов из за которых все стоит и все заблокировано.
А бюрократии и маразмов нет только на начальном этапе в стартапах. Там зачастую и начальства как такового нет, есть коллективные брейнштормы и все такое, да и вообще народу минимум, правда есть те, кто рискуют своими деньгами лично — они конечно начальники, ибо выбивают финансирование, зачастую из своего кармана, но они могут кодить наравне со всеми. Если стартап выстрелил — появляется бюрократия, контроль доступа, безопасность, отдельные девопсы, юристы, менеджеры по закупкам и т.д. Чем крупнее контора, тем больше там бюрократии, и как только появляются деньги — появляется бюрократия!
Re: Про вайбкодинг - пределы, применимость, ограничения
Почти каждый сеньор-инженер, которого я знаю, пишет очень мало кода. Вместо них этот код пишут модели вроде Claude 4.5 Sonnet, GPT-5, GPT-5-Codex и Cheetah.
Это новое. Очень новое. Шесть месяцев назад так не было.
Всё поменялось с выходом Claude Sonnet 4 в мае. От «это ерунда» к «это довольно хорошо». А с Sonnet 4.5 и GPT-5-Codex за последний месяц — к «это действительно удивительно».
Это не «вайб-кодеры» на X, которые кричат «жесть» и «геймченджер», потому что можно получить «приложение» за один промпт. Это серьёзные инженеры с 10–20 годами опыта. И они поставляют продакшен-код, почти не написав его сами.
Полгода назад ИИ писал так плохо, что хотелось выбросить ноутбук. Только недавно всё изменилось. Но изменилось.
Любой инженер, который утверждает, что ИИ не умеет писать код или делает только мусор, держится за старое мышление. Это уже неверно. Это не значит, что новички не продолжают заливать ерунду в репозитории. Но опытные разработчики могут теперь делать настоящий, рабочий код с этими моделями.
В марте 2025 Дарио Амодеи, CEO Anthropic, сказал, что через 3–6 месяцев ИИ будет писать 90% кода. Многие спорили. Я тоже.
Оказалось — он был прав.
И одновременно неправ.
Прав, потому что ИИ пишет 70–100% кода за меня и многих других. Неправ, потому что без человека в цикле это не работает.
То есть: мы просто говорим машине, что хотим, уходим, возвращаемся — и бац, готовое приложение? Такого нет. Это фантазия.
Несмотря на хайп Маска о «10% шанса на AGI» у Grok 5, нет ни одной модели, которая близка. Хоть 200K, хоть миллион GPU — с текущей архитектурой результата не будет: != AGI.
Главная причина: даже если модели станут умнее, они не магия. Машина не знает, что такое «хорошее приложение». Это знаешь только ты.
Без тебя эти боты бесполезны. Без людей они сходят с рельс и проваливаются. Но с хорошо продуманным планом, над которым я работаю с командой и моделью, они могут за полчаса написать отличный код.
Вот такой парадокс: одновременно потрясающе и глупо.
Я видел, как GPT-5-Codex два часа пишет по моему плану, чинит ошибки, запускает тесты — а потом делает глупость, на которую не способен новичок.
Мой любимый пример: я строил клон Deep Research на TypeScript. Мой тестовый запрос был про «велотренажёры под столом в Европе». После часов работы он решил, что это главная цель всего приложения, и захардкодил этот запрос навсегда.
Я закричал на него капсом и откатил коммит.
Да, две вещи могут быть правдой одновременно. Андрей Карпати сказал, что сегодняшние агенты — мусор, и настоящие появятся через десятилетие. Я согласен. Нам нужна новая архитектура и новый подход.
Но всё равно — у нас уже есть маленькие «джинны», которые пишут 70–100% кода. Это всё ещё круто и полезно, даже если иногда бесит.
Стоит ли бояться за работу? Это же «делает большую часть»?
Нет.
Потому что разработка — это 90% думать и 10% писать. С одной стороны, ИИ пишет почти всё. С другой — он пишет 0%, потому что без моих объяснений он не знает что и зачем строить.
И наблюдать за ним нужно внимательно — иначе он накосячит.
Иногда я чувствую себя как «страхующий водитель» в автопилоте: почти уснул, всё выглядит супер… и вдруг — резкий уход в стену.
Но параллельно — они очень хорошие. И становятся лучше. Поэтому сеньоры превращаются в «вайб-инженеров»: составляют планы, а ИИ работает, пока они пьют кофе.
Если это пугает — не нужно.
Это повод радоваться. Ты и твоя команда скоро сможете делать больше с меньшими ресурсами. Маленькие команды — большие проекты — быстрее.
Я со многими пунктами согласен, в частности:
— AI стал реально полезен начиная примерно с весны этого года.
— Стал полезен начиная с Claude 4, текущие модели которые не являются бредо-генераторами это Claude 4.5 и GPT5-Codex, меньшее производит больше шума чем реальной работы.
— Полезен только в "агентском" режиме, с полным доступом к коду и теми же инструментам что и разработчик (консоль, IDE, доступ к интернету — чтобы он мог искать и читать документацию — как минимум). Веб-интерфейс (чат) — игрушка.
Из практики
— реализация фичи на 1500 строк и 40 файлов вполне себе работает
— Обнаглел до того что простые задачи из Jira/Devops стал ему давать тупо по номеру тикета, он сам их читает, фиксит, и закрывает (комментируя для тестирования как сделано).
Для сложных задач не работает, нужно направлять.
— Как правило не работает для фич, которые я сам не знаю как сделать (требующих какого-то исследования).
То есть, если мне допустим ясно, как задачу делать, или ее можно сделать "по аналогии", можно отдавать ИИ.
Если нет — у него так же будут проблемы.
Здравствуйте, Shmj, Вы писали:
S>Вот как раз нет. Руководить вроде легко — но для него недостижимо.
Вполне достижимо. Всё что делают большинство руководителей — выдают команду что-то сделать, и потом иногда спрашивают, как оно продвигается. Нормальных управленцев я за всю жизнь видел нескольких всего. так что ИИ на месте начальника уровня выше тимлида — самое место. тимлиды пока ещё должны разбираться в технических вопросах, а у ИИ с этим проблемы.
S>Это как я описал пример создания объектной модели — вроде фигня, ничего вычислять не нужно — но нужна точность и понимание для чего ты это делаешь. Оно такого не может
Объектную модель создают специально обученные люди по заданию руководства.
S>Так что руководители как раз не будут заменены, особенно если они рискуют своими деньгами.
Видел я массовые сокращения в ИТ-конторах. Почему-то увольняют спецов, а управленцев оставляют.
Re[3]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, elmal, Вы писали:
E>Вообще то работа именно руководящей должности — это не писать бумажки с распоряжениями. А в первую очередь убедить вышестоящих что все идет хорошо и нужно увеличить финансирование.
Да-да, помню. Просит меня начальник посмотреть, будет ли работать некая фича. Я полдня ставлю эксперименты, читаю доки, вижу, работать будет. Показываю начальнику. Он тут же докладывает наверх: есть работающая программа, выполняющая то, что требовалось.
E>Если случился какой косяк, то объяснить, почему это нормально. Выбить бешенный раздутейший бюджет, набрать народу черти сколько.
Видел и такое. А потом пришёл новый генеральный директор и разогнал всю эту толпу. Причём сократил в основном спецов, а управленцев оставил.
E>Основной навык — убеждать других. Причем не словами, а интонацией и харизмой!
Именно это и делают большинство начальников. Но при этом они совершенно забывают о подчинённых. некоторые даже todo-листы не ведут. И когда им сверху прилетает какой-то вопрос, они начинают среди подчинённых выяснять, кто им занимается. Часто такой стиль руководства приводит к тому, что у одного разработчика пять срочных заданий, а его сосед груши околачивает.
E>А бюрократии и маразмов нет только на начальном этапе в стартапах.
Должен заметить, что бюрократия — весьма полезный инструмент в долгоиграющих проектах. Но нужно помнить:, главная часть всякого инструмента есть голова его владельца.
Re[4]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Privalov, Вы писали:
P>Видел и такое. А потом пришёл новый генеральный директор и разогнал всю эту толпу. Причём сократил в основном спецов, а управленцев оставил.
Ну это стандартно.
P>Именно это и делают большинство начальников. Но при этом они совершенно забывают о подчинённых. некоторые даже todo-листы не ведут. И когда им сверху прилетает какой-то вопрос, они начинают среди подчинённых выяснять, кто им занимается. Часто такой стиль руководства приводит к тому, что у одного разработчика пять срочных заданий, а его сосед груши околачивает.
Ну, к счастью всеж работаю с теми, кто покомпетентней и кто в курсах чем кто занимается, и даже представляет что там внутри проекта. Один хрен же отчеты регулярно писать нужно кто чем занимался за неделю и что конкретно сделал.
P>Должен заметить, что бюрократия — весьма полезный инструмент в долгоиграющих проектах. Но нужно помнить:, главная часть всякого инструмента есть голова его владельца.
В какой то мере если только, например если ведется документирование решений, где объяснено почему это сделано. И то, это в идеале, чаще всего с документированием хрень и лучшая документация это комментарии в коде, все остальное в лучшем случае давно устарело. Как только идет разрастание компании — туши свет. На одного разработчика 5 начальников, иерархия черти какая, сплошные совещания, планирования, взаимодействие отделов, при этом у совсем вышестоящих фокус внимания вообще на конкретный проект минимальный, у него таких проектов до черта и что там в реальности представляет мало, волнует только отношение доходов и расходов. Становится все жутко неповоротливым. Практически кстати нерешаемая проблема — бардак идет во всех крупных компаниях, в результате часто стартапы их обгоняют. Правда потом если стартапы хорошо выстреливают и сами становятся крупной компанией, неповоротливыми становятся уже они.
Но я о другом. Какой искусственный интеллект сможет заменить именно начальника? Нет, отчеты, я верю, что он напишет. Но как он будет убеждать увеличить финансирование и как будет покрывать косяки, которые были вызваны в том числе и неверной постановкой задачи? Биг боссы непосредственно письменные отчеты не читают, им нужно чтоб им все объяснили устно и лично!
Re[2]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, elmal, Вы писали:
E>Ну это стандартно.
Ну да, сегодня продаются проекты, которыми никто и не думал заниматься. Не часто, но случается и такое. Напланируют, а потом вспоминают, что исполнять некому.
E>Ну, к счастью всеж работаю с теми, кто покомпетентней и кто в курсах чем кто занимается, и даже представляет что там внутри проекта. Один хрен же отчеты регулярно писать нужно кто чем занимался за неделю и что конкретно сделал.
А я нарывался и на таких, кто не в курсах. А как они отчёты писали, не знаю. Да и не моё это дело.
E>В какой то мере если только, например если ведется документирование решений, где объяснено почему это сделано.
В прошлом проекте у нас вообще что-то по типу Вики было сделано. Но писали туда не кто и как попало. Всё-таки масштабы проекта позволяли.
E>И то, это в идеале, чаще всего с документированием хрень и лучшая документация это комментарии в коде, все остальное в лучшем случае давно устарело.
Это случается, часто не хватает времени править документацию. Так-то даже форматирование иногда спасает. Была у нас в проекте одна программа, которую если IDE отформатирует по правилам, сразу переставала быть понятной.
E>Как только идет разрастание компании — туши свет. На одного разработчика 5 начальников,
5 — это до хрена. У нас в прошлом проекте, мы как-то подсчитали, было всего 4.5 начальника в среднем на одного разработчика.
E>Но я о другом. Какой искусственный интеллект сможет заменить именно начальника?
Будет работать в сторону подчинённых. Инструкцию "разобраться и доложить" и ей подобные он вполне может выдать. зато у человека освободится время на разговоры с заказчиком и на вытягивание из него денег.
Re[3]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Qt-Coder, Вы писали:
QC>Это шикарно, я считаю. Но сегодня ему что-то не очень удается продуктивно поработать, видимо рабочая суббота сказывается.
Всё так. Поэтому и написал выше, "чтобы ты был по уровню программирования и понимания решения задача прилично выше его.
В этом случае тупое написание частей кода можно скинуть на него."
Фактически он заменяет такого очень тупого джуна, но и очень послушного.
Пока же даже не заменит не тупого джуна.
За долгие рабочие годы я могу вспомнить только 3 настолько тупых джунов на фоне сотен не таких тупых.
Re: Про вайбкодинг - пределы, применимость, ограничения
Bootstrap
за одну итерацию я получил такое
с работающей регистрацией и логином
более менее работающем базовым функционалом, ну и всей структурой проекта
неплохая замена классическим бутстрапам
запрос с моей стороны минимальный но двухэтапный, пара фраз с чатгпт и запрос на создание ТЗ для курсора
Re[2]: Про вайбкодинг - пределы, применимость, ограничения
bnk>- Обнаглел до того что простые задачи из Jira/Devops стал ему давать тупо по номеру тикета, он сам их читает, фиксит, и закрывает (комментируя для тестирования как сделано). bnk>Для сложных задач не работает, нужно направлять.
это базовый функционал или сторонние интеграции?
Re: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Shmj, Вы писали:
S>Далее из интересного. Есть вещи, которые вроде бы не сложные — но оно не может делать никоим образом. А именно — не умеет строить объектные модели для той или иной задачи. К примеру была задача сделать кодогенератор по WSDL (на Dart, для которого нет готового). Задачу разбиваем на две — парсинг в объектную модель и потом генерация из объектной модели. Оно смогло построить и парсинг и кодогенератор — но не смогло объектную модель никоим образом, хотя вроде бы с нашей гуманоидной точки зрения это самое простое
Не знаю, что у вас не выходим, мне агент выдает все, что надо
Пишете конкретные задачи, а не "сделай все что надо" и будет щасте
Объектную модель, к слову, лучше таки самому описывать, а агенту отдавать рутинные повторяющиеся задачи, которые легко просмотреть
Re[3]: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, bnk, Вы писали:
bnk>>- Обнаглел до того что простые задачи из Jira/Devops стал ему давать тупо по номеру тикета, он сам их читает, фиксит, и закрывает (комментируя для тестирования как сделано). bnk>>Для сложных задач не работает, нужно направлять.
M>это базовый функционал или сторонние интеграции?
Здравствуйте, Privalov, Вы писали:
P>В прошлом проекте у нас вообще что-то по типу Вики было сделано. Но писали туда не кто и как попало. Всё-таки масштабы проекта позволяли.
Ну, всякие вики это на деле стандарт. Но на деле — идет текучка в том числе и руководства, новый оказывается не в курсах и т.д что там и почему, на документирование времени нет и начинается.
P>Будет работать в сторону подчинённых. Инструкцию "разобраться и доложить" и ей подобные он вполне может выдать. зато у человека освободится время на разговоры с заказчиком и на вытягивание из него денег.
Во всех местах, где доводилось — начальник всегда работал в интересах подчиненных. Основная задача — максимально избавить непосредственных исполнителей от бюрократии. Так или иначе это пытаются делать вообще все без исключения, ибо работать то кто то должен. Но чем больше становится контора, тем больше становится согласований, взаимодействий с другими отделами. Доходит до маразма, причем с ростом компании маразмы идут сверху. Изначально допустим у всех до всего был доступ, разработчик мог поправить любой деплой, и время на настройку CI для полностью нового проекта занимало час, вместе с созданием макета нового проекта. Потом появляется отдельный товарищ который следит за этим с особым рвением, но он относится к тому же самому проекту и сидит рядом, постоянно доступен, а если что, его любой может подменить. А потом рост компании, для девопсов отдельный отдел, девопсы отвечают вообще за сотни проектов, при этом секьюрити и все такое, у разработчиков все права отнимают. И настройка нового проекта — месяц. Периодически все ломается. Если нужно что поправить, все через девопса. А он может заболеть, свалить в отпуск, быть перегружен на других проектах. И бывает лютейший писец, когда на дев стенде не получается разработчику перед своим отпуском выложить фичу чтоб проверить, ибо девопса нет, ему не согласовали часы, а так он занят на других проектах, а стандартный пайплайн сломался какого то хрена на стороне, за которую отвечают девопсы, и хрен что выложишь. И все, работа парализована. Плюс девопсы все в мыле, у них проектов под сотню на человека, постоянные авралы.
И вот в реальности начальство нужно именно чтоб не допускать подобный дурдом, чтоб когда из за подобных инициатив все блокируется — вопить на всю контору до самого верха, вынося всем мозг! Достав всех так, что ему дают особые полномочия в виде исключения, в результате чего работа не блокируется никогда. Такое начальство никакие нейросетки никогда не заменят. И такое начальство в интересах собственника конторы, но зачастую руководители пониже собственника делают все, чтобы вот таких изжить, и поставить на место тех, кто бучу не наводит относительно того, сколько времени и денег просираются впустую.
