Comments 85
Спасибо за подробное сравнение, с моего опыта лучше всего использовать Calude Code, сейчас используеться Sonnet 4, требует платной подписки,да. С задачами справляеться на ура, не устает, даже если долго что-то не работает. Ручное вмешательство в код не требуеться, (там TypeScript + JavaScript я их вообще не знаю). Может сам править любые файлы и запускать тесты, так что рекомендую.
Использую подписку Max, модели 4.1, начинал с 4. Могу сказать что иногда делает неплохо, но только фронт. Большинство бэкенда задач делает неоптимально, приходится переписывать 90% кода. В итоге, пришел к тому что использую его для быстрых демок, а уже полноценный код пишу самостоятельно. Но для демок очень удобно, окупается полностью. Это касательно C#. Для python дела, конечно, обстоят получше.
Почитал ваш предыдущий пост. Хочу вам сказать, что вы даже не представляете сколько на вас денег посыпется, если вы научитесь составлять описание книги по сканам в формате RUSMARC. Это, буквально, золотая жила :)
Спасибо, ознакомился (͡°͜ʖ͡°)
На картинке девочка сидит "под грибами", смотрит в одну точку и пытается решить, какой AI ей выбрать для вайб-кодинга.
Оценка 16-36 часов для полученного результата и разработчика уровня +-миддл выглядит чрезмерной. только если у него прям отсуствуют все навыки, которые перечислены ниже. Но ведь тогда это даже не джун. В остальном - интересно.
Не согласен. До появления LLM считалось, что в среднем программист Google пишет 150 строк кода в рабочий день. Не берём в расчёт html и css: только Python и JS - получается, работа на 3.5 рабочих дня.
upd: Нашёл даже ссылку на источник: https://www.quora.com/How-many-lines-of-code-get-written-at-Google-each-day
Это потому что реальными задачами он занимается очень мало времени. Остальное - споры в интернете и просмотр смешных видосиков с играми саморазвитие и организационные вопросы. В том числе из-за невозможности поймать поток. Если же его поймать, то можно кодить подряд целый день и даже больше. Но и результат будет ощутимым. Всякие хакатоны поэтому и появились - потому что на них люди реально кодят и от этого кайфуют. Когда получается что-то готовое - действительно приятно. А "в среднем программист гугла" забивает себя дешевым дофамином и делает минимум необходимого.
Мне кажется эти 150 строк, это все же работа в рамках существующей кодовой базы. Когда надо держать контекст в голове, знать "как и куда", запускать тесты отбирающие время.
В рамках вашей задачи вы создали приложение с нуля с одной интеграцией, что сильно проще, чем 150 строчек в какой-нибудь gmail внести, фуллстек мидл на фрилансе такое сделает за день.
Мне кажется эти 150 строк, это все же работа в рамках существующей кодовой базы
Вам не кажется. Просто визИИонеры и евангелИИсты живут в своем особом мире, где программист каждое утро начинает писать с нуля модный молодежный микроксервис. Каждый раз на новом стеке.
Говоря о гугле - я думаю, там невероятная и редкая удача начать писать что-то с нуля. А мне за 10 лет карьеры (не в гугле, конечно) всего 1 раз так повезло.
До появления LLM считалось, что в среднем программист Google пишет 150 строк кода в рабочий день.
Но мы-то знаем праффду!
Возможно, создатели CoPilot специально его убрали, чтобы побудить пользователей переходить на премиум модели.
Это не так. Исходники в опенсорсе, промпты можно почитать. Для GPT 4.1 там действительно есть специфические дополнительные инструкции, но они сводятся к тому, чтобы он не останавливался на каждый чих а продолжал пытаться решить задачу сам. Сложно сказать, помогают ли они - по моим наблюдениям он всё равно постоянно останавливается когда другие модели бы продолжили работу.
По статье - да, в целом всё верно. Уровень получаемого результата очень сильно зависит от того, кто пишет промпты. Ну и следующий фактор - это выбор модели, на моих задачах Claude Sonnet 4 справляется намного лучше других (правда, GPT 5 я ещё не тестировал). GPT 4.1 можно использовать только на простейших задачах, но и там с ним работать очень утомительно - постоянно приходится его "пинать" чтобы он продолжил работу.
Что до вайб-кодинга, то этот подход расширяет возможности квалифицированного разработчика: можно быстро получить прототип на знакомом ЯП чтобы оценить стоит ли вообще делать задачу/делать этим способом, плюс можно делать не очень большие проекты на незнакомом ЯП. Может есть ещё какие-то адекватные применения. Но в большинстве реальных задач даже если прототип решения накидывался вайб-кодингом дальше нужно полноценно вникнуть в абсолютно весь код (и доработать его до обычного для себя "без ИИ" уровня, не важно промптами или вручную), и, очень желательно, в тесты тоже (там нередко дичь попадается).
Для компенсации негативных эффектов вайб-кодинга очень помогает после получения рабочего решения почитать официальную доку по использованным технологиям/подходам/библиотекам и позадавать модели возникающие вопросы а-ля "а почему тут сделал так если в доке сказано что …" - это прекрасно работает даже для незнакомых ЯП. Ну и плюс надавить из общей эрудиции и знания как решаются подобные задачи в других ЯП если код где-то выглядит странно.
Для компенсации негативных эффектов вайб-кодинга очень помогает после получения рабочего решения почитать официальную доку по использованным технологиям/подходам/библиотекам и позадавать модели возникающие вопросы а-ля "а почему тут сделал так если в доке сказано что …"
Только делать это другой моделью - пусть сами друг друга погоняют. Техника давно используется в обучении нейросетей, как примеры
AlphaGo, играющий сам с собой
генераторы изображений в соревновании с распознавателями изображений
Когда я указывал ему на ошибку, вместо того чтобы внести исправления в код, он предлагал мне исправить самостоятельно
С Bitrix даже LLM связываться отказалась
ну началось.... вот откуда вы лезите (͡°͜ʖ͡°)
Bitrix не open source, поэтому модели могут прямо писать что особо не разбираются
Да там по исходникам можно вехи и моды способов разработки изучать, начиная от прямой отправки емейла из скрипта, содержащего верстку, заканчивая попыткой всё переписать на ооп, причем заметно, что начинали одни, продолдали другие, заканчивали третьи. Битрикс можно приводить в пример утверждению, что главное не код, а функциональность.
Подключите этот MCP https://context7.com/ тогда LLM будет забирать из него актуальную документацию
В компании, где я работаю, поначалу активно применяли вайб-кодинг - стильно, модно, молодежно.
Сейчас начали ограничивать его применение - выяснилось, что Джуны- вайбкодеры не растут в профессиональном плане и не могут поддерживать проект, который они сами и "написали" - они просто не понимают, как и что в нем работает(((
Вот это ключевой вопрос как мне кажется - вайбкодингом можно получить решение задачи, но ты не получишь знаний и навыков от решения этой задачи. Если задача простая - то вроде бы и не страшно, но ведь навыки для решения более сложных задач складываются постепенно из навыков решения более простых.
То есть вайб-кодинг как и любое использование ИИ хорош , если
Задачи которые ты уже умеешь решать, чтобы не тратить на них время
Задачи, которые требуют нерелевантных для тебя навыков, которые ты все равно не собираешься развивать (ну например картинку для статьи нарисовать)
Как продвинутый поисковик когда ты используешь выдачу ИИ для своего решения
А вот в зоне тех навыков которых у тебя не хватает и которые ты хочешь у себя наращивать - большой вопрос.
Если ты как джун в какой бы то ни было области решаешь все с помощью ИИ то ты не приобретаешь никаких навыков в этой области кроме навыков спрашивать у ИИ. А эти навыки простые и не дают тебе никакого преимущества, тебя может заменить любой и точно так же спрашивать у ИИ.
Причем этот эффект явно отложенный - в начале пути в любой области ты решаешь относительно простые задачи и вроде особой разницы не видно они и так простые. Но если решаешь сам то ты тренируешь свою нейронку и потом постепенно переходишь к более сложным. А если спрашиваешь ИИ то нет.
Мне кажется через несколько лет активного применения ИИ мы сможем увидеть много интересных долгосрочных эффектов такого толка.
Задачи которые ты уже умеешь решать, чтобы не тратить на них время
Теперь ты тратишь время, чтобы убедиться, что оно не наглючило!
Задачи, которые требуют нерелевантных для тебя навыков, которые ты все равно не собираешься развивать
Нет нерелевантных навыков — есть навыки, которые пока что не понадобились.
картинку для статьи нарисовать
Для этого даже специальные человеки придуманы, "художники" называются.
А нейрокартинками пока что добились только одного: моя баннерная слепота распространилась и на них.
Как продвинутый поисковик когда ты используешь выдачу ИИ для своего решения
...после чего по-прежнему тратишь время, чтобы убедиться, что оно не наглючило!
>Теперь ты тратишь время, чтобы убедиться, что оно не наглючило!
Да я бы даже согласился, сам я весьма консервативен в этом плане как и мой нынешний работодатель, но над программистом постоянно висит угроза застрять на устаревающем стеке и потерять конкурентоспособность на рынке труда. Вполне возможно, что использование ИИ станет принудительным навыком без которого тупо работу не найдешь. И сам с таким сталкивался и видел у других - ты вроде превосходно делаешь свою работу, пользователи и заказчики счастливы, задачи все решены и очень быстро и дешево, но стек тупо устаревает.
>Нет нерелевантных навыков — есть навыки, которые пока что не понадобились.
Человеческая жизнь конечна и освоить все навыки просто невозможно.
Начнете осваивать нерелевантный - значит не сможете осваивать релевантный. В частности изучение ручного рисования картинок будет вместо написания статей и разработки, а не в дополнение к ним.
>Для этого даже специальные человеки придуманы, "художники" называются.
Которые стоят неадекватных денег для многих задач, в частности создания картинки-заглушки к статье от которой все равно не надо ничего особенного.
Можно конечно заказывать ее из благотворительности, но для благотворительности есть более подходящие цели и она даже усилий таких не стоит, искать исполнителей, делать какие-то заказы - это уже усилия которые для интраверта некомфортны и могут убить все удовольствие от написания статьи.
>А нейрокартинками пока что добились только одного: моя баннерная слепота распространилась и на них.
Моя тоже, но проблема в том, что все равно остаются люди которым они нужны и таких людей достаточно много. Статья без картинки привлечет меньше внимания чем с картинкой. В нашем мире статей дикий переизбыток, даже просто читать все интересные статьи ни у кого времени нет, разница между решением читать и не читать - это случайные доли секунды и мимолетное впечатление
И это даже баннеров касается - у меня и у вас баннерная слепота, но баннеры все равно привлекают каких-то людей которые их видят, иначе никто бы не стал тратить на них деньги. Ну ладно сначала бы не стали тратить деньги те, кто их считает, а потом подтянулись бы более тупые.
Ну и не говоря уже о том, что такая баннерная слепота они вполне себе и на нарисованные художником картинки распространяется
но над программистом постоянно висит угроза застрять на устаревающем стеке и потерять конкурентоспособность на рынке труда.
Так не застревайте — учитесь!
Человеческая жизнь конечна и освоить все навыки просто невозможно.
Challenge accepted.
но баннеры все равно привлекают каких-то людей которые их видят, иначе никто бы не стал тратить на них деньги.
Вы не представляете, какое количество фигни люди делают, потому что «ну все ж так делают, а сто тысяч мух не могут ошибаться»
Теперь ты тратишь время, чтобы убедиться, что оно не наглючило
Да, но всё не так плохо. Со временем подбираются подходы, которые решают эту проблему, и, в конечном итоге, результат получаешь намного быстрее. Я вот принципиально не смотрю промежуточные результаты ИИ - пока они не пройдут все тесты и линтеры, - и одно это экономит море времени. Конечно, не всё так плоско, есть нюансы (напр. иногда ИИ начинает нести не в ту сторону, и тогда результатов не дождёшься, поэтому нужно вмешиваться и корректировать на ходу), но в целом подход рабочий. Ну и полное ревью финального результата обязательно, и если код ИИ это ревью сумел пройти, то он ничем не хуже чем любой другой код - твой собственный или твоего коллеги, - и "наглючить" он может ровно с той же вероятностью, что и ручной код прошедший ревью, тесты и линтеры.
Но правда в том, что писать свой код или вместо этого ставить задачу и потом ревьювить чужой - это совершенно разные активности. Но никто же не мешает совмещать - интересное писать или рефакторить самостоятельно, а менее интересное делегировать ИИ.
Лично для меня большой плюс - возможность при разработке сконцентрироваться на проектировании, делегировав ИИ тупой "набор" уже продуманного мной кода и решение технических проблем с падающими тестами если при продумывании что-то было упущено. Для меня разработка в таком стиле выглядит похоже на разницу между ассемблером и языками высокого уровня - как язык следующего за "высоким" уровня. И это очень круто!
ИИ - это инструмент. Молоток тоже можно использовать чтобы стало легче забивать гвозди, а можно и себе по пальцам ударить. ИИ - инструмент однозначно полезный, но вот для каких задач он (не) подходит - очень сильно зависит от использующего его человека. Ну и модели очень сильно друг от друга отличаются, в зависимости от пользователя и задачи могут (не) подойти разные модели.
пока они не пройдут все тесты и линтеры
А откуда все тесты и линтеры взялись? Ах, Вы написали?..
Проблема в том, что «ИИ» — это недетерминированный молоток.
Линтер я настроил, плюс/минус одинаково для всех проектов, в этом нет проблемы.
Тесты - обычно этот же ИИ и написал. Там бывает лажа, но, всё-равно, когда ИИ пишет и код и тесты то он сам находит и исправляет большую часть ошибок - до того, как я начну сам делать ревью кода.
Люди - это тоже недетерминированный молоток, но это же не мешает. Просто чтобы группа людей вместе успешно работала и создавала большие продукты ими нужно уметь управлять - что является совершенно отдельным навыком, не связанным с программированием. С ИИ примерно та же фигня - чтобы он успешно писал нужный код нужно научиться им управлять: подобрать подходящие процессы, ставить задачи и контролировать результат.
контролировать результат
Вот прям даже интересно: что проще — писать свой код или читать чужой?
Или иными словами:
что проще — самому проложить сантехнику и электропроводку, или расковырять пол и стены, чтобы удостовериться, что джамшуты не накосячили?
Зависит от. Я пишу на Go, язык такой, что и свой и чужой код выглядит плюс/минус одинаково. Так что конкретно мне ревьювить и потом немного порефакторить до состояния "я бы сам написал именно так" получается намного проще и быстрее.
У-у-у-у, это Вы ещё на баше не писали...
Не совсем так. Я как-то придумал задачу, выбрал библиотеки для обработки данных и для GUI. Ни того, ни другого я прежде в глаза не видел. Ну и, небольшими промптами написал за пару вечеров прогу, к которой раньше было просто боязно подступиться.
По ходу дела cursor заводил в тупик, решал одинаковые задачи разными способами и тп. Пока со всем этим разбирался, разобрался с принципами работы библиотек, вполне научился править получившуюся прогу самостоятельно.
Так что, навыки никуда не деваются.
Там можно использовать модель чуть попроще и контекст поменьше, в этом случае уже придется разбираться в структуре проекта
если к Питону добавить ИИ то это мега просто, было дело сам стоял перед выбором С или Питон
Я тоже, наверно, подхожу под классификафию "старый разработчик" - программирую с конца 80-х, со школы.
И могу сказать, что за подобным "вайб"-кодингом, скорее всего, будущее.
Формат кода уже достаточно стандартизирован, и нейросетка загоняет задачи в правильный формат - по неймингу переменных, отступам, комментариям, читаемому стилю кода.
Да, надо допиливать, но всё меньше и меньше.
Я и сам сейчас уже начинаю этим пользоваться. Какую-то отдельную процедуру я писать уже не буду. Если есть четкий вход и четко ожидаемый выход, я загоняю это в нейронку и полуцчаю результат через 1 минуту.
А так бы я лазил по stackoverflow и искал как написать, и в итоге написал бы то же самое. Но за час.
Ну и перепроверяю код: просто загоняю весь текст, и пишу "найди ошибки и оптимизируй". И иногда сетка выдает ну очень интересные решения, про которые я не знал, и писал код по старинке. Особенно связано с новым синтаксисом (например, когда сейчас на 21-ю Java переходили).
Так что вердикт - надо осваивать. Без этого п*.
Из своего небольшого опыта вайб-кодинга могу сказать, что с SQL-запросами LLM справляются довольно хорошо, там (в моём случае) экономия времени довольно большая. Скинуть DDL, объяснить что нужно на выходе и очень часто запрос с 1-3 раза получается нужный. А что-то более сложное - много нюансов может быть, которые действительно проявляются в процессе "рождения" проекта. Любая идея должна созреть в голове, оформиться. Автор правильно заметил. что многие детали проявляются постепенно, оттачиваются на месте.
Я недавно попытался поручить ИИ сварганить решение из ещё несозревшей идеи, дав референс. Какие-то файлы он выдал, но оно не работало. После нескольких правок оно заработало, но было излишне усложнено и это был по-прежнему прототип для проверки идеи. Я понял, что я буду дольше объяснять ИИ что делать и как ("исправь это, оно не работает", "ты используешь устаревший код 10-летней давности. Сделай нормально..."), чем сделаю сам.
Сам тоже работаю с SQL и хочу сказать что мне не везло, или не умею оформлять задачи по SQL для ИИ. Для составления запроса, витрины - лучше своя голова, в редких случаях голова ИИ подсказать синтаксис забытой команды.
Но ИИ в рамах SQL хорошо экономит время на создании самих DDL, DML(insert) команд когда на входе "Война и мир" и надо превратить это в структуру.
Но для языков как РНР, С++ вполне с ИИ дружу.
Вот как-то с С++ дружба не особо задаётся, оно пишет правильно (чаще всего), но, очень любит переусложнять код, мне, чаще всего добавляет кучу namespace, вместо методов класса пишет просто функции, куда передает this, вместо простого объявления массива фиксированной длины производит страшное колдунство строк на 50 с разными аллокаторами памяти.
Когда модель уже не тянет
На GPT 5 уже не упираюсь, модель не глупеет. Сделал порядка 100 запросов в одном контексте. Потом, правда, мне сессию грохнули на lmarena.ai и вся история накрылась
Хорошо, конечно, если LLM будет доступ к отладчику фронта и бэка. Но можно и просто логировать в файл пока дебаг не завезли.
qwen 3 coder наше всё) с контекстом в 1млн токенов и сохранением истории если превысили лимит за день) то можно просто подождать и продолжить.
Лимит чаще всего не наступает)
https://chat.qwen.ai
сверху переключить модель
и включать режим поиск если в коде используются какие очень новые фичи
Ошибочное определение /api/user удалено. Теперь эндпоинт реализован корректно и работает после создания Flask-приложения. Всё готово для корректной работы фронтенда.
Работал у нас полтора года назад один "джун", правда недолго, который аналогичным образом решал почти любые задачи :-)
Веб-серверы и API - это очень стандартная и распространенная задача.
Когда просишь у LLM решение простой, но малопопулярной задачи, быстрее всё напишешь сам. Потому что на составление детализированного запроса с уточнениями можно потратить кратно больше времени, чем на составление качественного ТЗ. Так что ещё и джун успеет это ТЗ реализовать, пока ты танцуешь с LLM.
Безусловно, если быстрее без ИИ - нужно делать ручками. Но часто это только кажется, что без ИИ будет быстрее - и это тоже нужно учитывать.
Что до составления качественного ТЗ, то тут я не соглашусь:
Уметь составлять качественные ТЗ - это ценный навык сам по себе. Причём в эру ИИ этот навык будет цениться намного выше, чем умение написать код ручками. Так что его качать стоит в любом случае.
С написанием ТЗ для ИИ очень неплохо помогает сам ИИ, заметно ускоряя процесс. Но - только помогает, а не заменяет.
Абсолютное большинство задач без ТЗ реализовать невозможно. Даже если это ТЗ нигде формально не записывается и окончательно формируется незадолго до того как будет завершена реализация - оно всё-равно есть. И важный момент в том, что разработать ТЗ заранее обычно в разы дешевле (по времени и усилиям), чем формировать его на ходу, в процессе работы с кодом. Поэтому для любой задачи кроме совсем тривиальных стоит начинать именно с ТЗ. А имея ТЗ проверить его адекватность как раз проще всего передав его ИИ для реализации - вся лажа в ТЗ сразу вылезет. ☺
Мне лично пока не получилось вайбкодить так, что бы выходило что то, что можно интегрировать в существующий код, программу. Или что, что можно состыковать друг с другом. Может я уже "старый", мне 54, закостенел за 30 лет программирования. :)
Да, вот такое самодостаточное, закапсулированое в себе, вроде одностраничников или как в себе серверов, выходит у ИИ вполне себе. Таким образом сделать какую то тулузу, утилиту, которая получит на вход структурированные данные и выдаст что то нужное на выходе, вполне рабочий юзкейс. Я постоянно пользуюсь. Но вот код проекта пишу сам, с помощью ИИ. Быстрее получается записать из головы сразу в код, чем сначала объяснять, что надо сделать, а потом ещё и все править. Привычка появилась, в коде написать комментарий, чего хочу, что дано, что долго выйти, ИИ лучше делает предсказания.
Да и учишься чему то новому с ИИ, если модель свежая, то частенько выдает конструкции, которые до селе не встречались, начинаешь читать доку, что бы понять.
Мне нравится.
Имхо вайб кодинг это все таки такой же неэффективный процесс сейчас, как и чисто кодинг без использования нейронок вообще.
Контекст сейчас нереально важен, на легких задачах типа "напиши мне приложение" или "сделай юнит тесты по" и так далее тот же claude code справляется почти идеально, но в рамках комплексных проектов и массивных задач не обойтись без ручных правок/изменений и написания кода самому. А если это новый функционал, нейронка даже при наличии md файлов зачастую игнорирует принятые в проекте паттерны и пишет "как сейчас модно".
В общем пока использую в таком формате:
сложные вещи пишу сам, консультируясь с нейронкой и натравливая ее после на поиск ошибок/нелогичности в архитектуре или проекте/описок и анализа на современные практики
всякие юнит тесты или "надо раскидать функционал нового хендлера на 10 других файлов" делает нейронка в терминале за пару минут
если это не пет проект аля магазин-на-диване, то обязательное построчное ревью всего кода что писала нейронка, даже если юнит и интеграционные тесты успешно проходят
Очень важно понимать, что и почему написала нейронка, зачастую она так же дает детальное объяснение, это очень важно читать и понимать, это фактически те же спеки/доки только примененные в живой пример в контексте которого вы работаете, как раз это дает знания. Если просто вайб кодить в терминале то это скорее деградация, поскольку человек не анализирует проделанную работу и не понимает как работает тот или иной кусок кода, и в случае проблемы не сможет выстроить в голове логическую цепочку для исправления этой самой проблемы.
Кстати попробуйте кодер модель https://hkunlp.github.io/blog/2025/dream-coder/ 7B, что вышла месяц назад.
..можно скачать в LM-Studio и также прикрутить к любимому редактору кода.
А то универ этих парней Huawei Noah’s Ark Lab
пару дней назад, впечатлил бенчмарком Polaris 4B среди думающих моделей.
Polaris-Coder ещё не выпустили к сожалению, но обещают скоро)
https://github.com/ChenxinAn-fdu/POLARIS
>> с 20+ летним стажем (Assembler, 1C, C/C++, Go, Pascal, Perl, PL/SQL, Python).
Вы там про Го говорите 20+? - Робби перелогинтесь пожалуйста :)
Основные проблемы кодинга в LLM это старая и слабая документация к библиотекам и апи что написано в статье. Я тоже кодил и такое заметил если LLM косячит пробовал гуглить и видел что и нагуглить решение сложно или нереально - только методом тыка. А там где нагуглить легко там и LLM хорошо справляется. Значить есть прямая зависимость. Прорыв в вайбкодинге произойдет когда те кто выпускают библиотеки и апи к ним будут делать специальную документацию для LLM и они ее смогут быстро находить и читать чтобы знать какая версия софта-апи актуально также там будет детальное описание библиотеки -с какими кодировками, типами бд, символами работает какое кол-во символов обрабатывает и многие другие нюансы и при обновление софта будет обновление этого файла что поменялось. LLM будет находить этот файл от разработчика как роботс.тхт находят поисковики и тогда косяков будет на порядок меньше. Возможно будет специально обученная LLM которая будет задавать вопросы каждому разрабу чтобы помочь сделать такую инструкцию и тестировать ее. Моя мысля такая.
Чтобы запустить сервер:
1. Установите переменную среды
BITRIX_WEBHOOKс вашим вебхуком Bitrix24
Я не удержался и спросил, как это лучше сделать? На что получил ответ, что через файл activate.bat внутри папки Scripts вашего виртуального окружения. Я имел другой опыт и спросил про него напрямую:
Какой способ предпочтительней: этот или через
launch.json?
На что модель ответила:
Оба способа рабочие, но предпочтительнее использовать
launch.jsonдля разработки в VS Code
Просто любопытно, а тут до этого было хоть забита базовая ситуация, перед этим вопросом. Ну что там установлено, на чём работает?
Мне кажется тут ии посчитал, что vs code нету, а винда есть. Значит лучше батник.
Как по мне, с вайб-кодингом все достаточно просто:
Навайбкодить можно быстро. Далее выбор за программистом:
- быстро пушим результат по принципу "х..к-х..к и в продакшен". Быстрое решение, ты у начальства на хорошем счету, но в голове остается мало. Вкладываемся в свой карьерный рост в компании.
- детально вникаем в полученный код. Сильно медленнее, начальство тоже довольно, но, хм... как-то сдержанно довольно. Вкладываемся в себя, в рост своих скиллов.
Тут нет правильного решения. Каждый решает для себя, по какой дороге он пойдет дальше.
Если код за тебя может написать LLM, то тебе явно нечего делать в программировании, иди в курьеры, там сейчас больше платят. Всё, что написано в статье напоминает явно нездоровый ананазм. Всем добра, занимайтесь парни только тем, на что вас природа назначила.
Вы пишете что ИИ пока в 2025 году не умеет делать некоторые действия (запускать код, отладка, дебаг, проверка напрямую в браузере). Но фактически нормальные ИИ агенты (не копилот) умеют это делать уже года 2. Так же они существенно улучшают промпты, добавляя туда автоматически как банальные вещи (пиши как эксперт), так и расширенный контекст, используя RAG с индексированным в векторной базе кодом. MCP тоже можно использовать, например чтобы брать дизайн напрямую из фигмы, но для отладки в браузере используются другое инструменты. Минус более продвинутых агентов - достаточно высокая цена за api доступ к LLM, так как очень высокий расход токенов (если большой проект, то за один промпт контекстное окно в 200к токенов может быть сброшено несколько раз). Так же для приемлемой генерации нужно четко прописывать правила. Плюс агентов - возможности существенно выше чем то что описано в статье. Примеры таких агентов: cline, cursor, kilo code.
фактически нормальные ИИ агенты (не копилот) умеют это делать уже года 2.
Ну когда мне уже покажут наконец что-то, написанное «нормальным ИИ агентом», что посложнее хелловорлда? Doom, на худой конец? Ну или чёрт с ним, с Doom — захудалый Zaxxon какой-нибудь? Про какую-нибудь серьёзную банковскую систему я уже молчу.
Эскпериментально установлено что "агенты" предпочитают обходить стороной баг-трекеры любого общеизвестного open source проекта, а вместо этого творить чудеса под прикрытием "NDA". Или "исключительных прав работодателя/заказчика". Или под прикрытием еще чего-то, но так, чтобы их волшебный код ни один "нео-луддит" не смог бы увидеть. Исключения - Hello World, To Do List, и такие же поделия сопоставимого уровня
Хотя казалось бы - напустили бы сэм с амодеем своих "агентов" в репозиторий Redis, к примеру. Там прямой сейчас в разделе Issues 2.2k инцидентов в статусе Открыто. Закрыли бы разом все две с лишним тысячи. Ну или не надо все, один хотя бы. Тут бы все "нео-луддиты" и треснули бы от зависти и злости. А корпоративные заказчики поувольняли бы в момент всех разработчиков, и подписались бы массово на "агентов"
Но нет. Что то мешает. Ждем-с ...
В коде, написанном ИИ ничего волшебного нет, более того он как правило заметно хуже кода, написанного сениором. Так же не всегда с первого промпта получается то что нужно. А ещё задачи нужно часто дробить и очень подробно описывать. В итоге это хорошо подходит для "проектов под NDA" так как там очень много типовых рутинных задач вроде crud либо наоборот api клиенты, верстка по фигме, юнит тесты, фичи которые делаются по одному шаблону и так далее. И тут нейронки отлично помогают. При этом сложные вещи вроде архитектуры или схемы бд для важных частей системы всё равно надо делать руками или хотя бы очень подробно описать ИИ в мелочах. А вот баги опен сорс проектов - сложные непонятные задачи, какой-то обучающей выборки у нейронки на проблемы такого рода почти нет, зато примеров crud api или стилей разных кнопочек - напротив много.
А вот баги опен сорс проектов - сложные непонятные задачи, какой-то обучающей выборки у нейронки на проблемы такого рода почти нет, зато примеров crud api или стилей разных кнопочек - напротив много
Утверждение спорное, мягко говоря. Приведу пример - перечень проектов с открытым кодом на Go, использующих Web-фреймворк Gin. Один из самых популярных, наряду с Echo, Fiber и еще парой-тройкой. HTTP API, вот это все. Попробуйте найти в этом перечне хоть что-нибудь уровнем сложнее домашней студенческой работы. Чему тут обучаться и на чем? А вот исходный код Prometheus, Grafana, etcd, istio и еще тучи вполне зрелых проектов в открытом доступе, качай и обучай. В том числе на pull request'ах, которые тот или иной инцидент закрывают. Вот инцидент, вот pull request, учись, дурак железный )) Разве нет?
задачи нужно часто дробить и очень подробно описывать.
Ну да, ну да...
Запускать браузер и самостоятельно тестировать web-приложение, правда, CoPilot пока не умеет, но такими темпами за ближайший год наверняка научится.
Cursor c MCP умеет, но криво.
Оказалось, что официальное API Bitrix24, выложенное здесь, не соответствует фактической структуре полей
JSON-ответа от сервера Bitrix24
Ну конкретно в таком кейсе GPT-5 просто сам сходил на сервер курлом
Один из симптомов, который может говорить о переполнении текущего контекста модели или о достижении пределов её возможностей, это нелепые ошибки.
4 часа вайб-кодинга
Это не вайб-кодинг, это AI-assisted кодинг. Вайб-кодинг это когда вы кода не касаетесь вообще, сосредоточившись на функциональных требованиях, а что там модель пишет, вас не касается.
А если сначала навайбкодить не глядя в код пока оно не заработает, а потом начать смотреть в код (ревью - с целью выявления проблем или просто подчистки кода) - это как называется? А если делать это на незнакомом ЯП?
Хз. Вайбкодинг, а потом обычный? :)
А если делать это на незнакомом ЯП
А познакомиться — не судьба?
А познакомиться — не судьба?
Чтобы что? ИИ даёт возможность быстро сделать какую-то мелочь на незнакомом языке. Без ИИ за это никто даже бы браться не стал - ради этой мелочи тратить время на полноценное изучение другого языка просто нет смысла. Например, я так написал плагин для KWin под KDE Plasma 6 на JS (мои собственные знания JS устарели лет на 25 примерно) и пофиксил многолетний баг в стороннем приложении открыв PR на гитхабе. Этот подход даёт новые возможности, и это - круто. А полноценно учить нужно те ЯП, которые используются в основной работе или которые нравятся.
Чтобы что?
Чтобы знать, конечно же!
ИИ даёт возможность быстро сделать какую‑то мелочь на незнакомом языке.
«Доктор, когда я делаю так (чешет левой рукой правое ухо), мне больно!» — «Больной, есть очень простое решение: не делайте так!»
Зачем Вы пишете на незнакомом языке? Пишите на знакомом!
Этот подход даёт новые возможности,
для трудно обнаруживаемых ошибок — Вы не можете с одного взгляда понять, где косяк, потому как языка не знаете.
Чтобы знать, конечно же!
У меня нет никакого желания знать JS. Скорее есть желание его вообще не знать, но увы.
Зачем Вы пишете на незнакомом языке? Пишите на знакомо
К сожалению, плагины для KWin на Go не пишут. И PR исправляющий мешающий мне баг в стороннем приложении тоже нужно делать на том языке, на котором написано это приложение, а не на том языке, которые мне нравится и который я знаю.
для трудно обнаруживаемых ошибок — Вы не можете с одного взгляда понять, где косяк, потому как языка не знаете
Это чистая правда. Но это абсолютно не важно. Потому что вторая правда в том, что половина разработчиков не знает полноценно даже те языки, на которых ежедневно пишет код на работе. Когда-то (лет 20-25 назад) мне такое казалось дикостью. Но пришлось это принять, потому что других разработчиков брать негде, а эти, в целом, с работой справляются. Так что, по факту, когда я, со своими 35+ годами опыта пишу вместе с ИИ на незнакомом мне языке, я пишу более качественный код, чем многие из тех, кто этот язык знают. Результат наверняка не идеален, но он определённо good enough. И лучше я сделаю что-то полезное так, чем не сделаю никак - и вот тут решает именно использование ИИ.
эти в целом с работой справляются.
Boeing 737 MAX согласно кивает.
Думаете, достаточно выучить хорошо язык и получится писать код без багов?
Не достаточно — но при этом необходимо.
С чего Вы так решили? Есть какие-то факты, подтверждающие эту идею?
Как думаете, какой процент разработчиков на C++ полноценно знает этот язык? Или в случае C++ корректнее говорить о таких уникумах в штуках, а не в процентах?
Как думаете, хорошо знающий язык разработчик не делает ошибок с тем же = и == просто по невнимательности? Я вот точно знаю, что делает.
Как думаете, кого-нибудь волнует, насколько хорошо знал язык разработчик, допустивший баг, из-за которого пострадали люди?
Есть ли какие-то исследования, как хорошее знание языка влияет на количество багов в релизе? И, главное, насколько именно этот фактор важен, по сравнению с другими - от выбора языка до организации процесса разработки?
Да, интуитивно может показаться, что очень важно хорошо знать используемый язык. Вам так кажется. Мне тоже когда-то так казалось. Но интуиция иногда может подводить. Масса других факторов влияет на конечный результат намного сильнее, чем глубокое знание языка отдельным разработчиком.
какая то ода собственному агрессивному невежеству
Не собственному и не агрессивному, всё ровно наоборот. Лично я по-прежнему считаю важным глубоко знать активно используемый язык и сам его знаю, но я перестал требовать такого же уровня в обязательном порядке от других разработчиков на моих проектах. Что реально необходимо в работе - они легко доучат в процессе работы (по ошибкам линтеров, тестов и во время ревью PR). А всё остальное… ну, не все фанаты программирования готовые учить это из собственного интереса и на практике есть довольно мало задач, в которых такое глубокое знание действительно необходимо. На качество финального результата, как оказалось, намного сильнее влияют совершенно другие факторы.
Вайб-кодинг глазами старого разработчика