Комментарии 196
Как вам вчерашний gpt-4.1? На моих задачах бьёт даже sonnet 3.7, не говоря про 4o, который в качестве агента практически никакой из-за своей лени.
Ну и окно контекста вроде 1m токенов, эту неделю в cursor и windsurf бесплатно.
Еще не успели покодить, но на вопросы отвечает бодро. 1м токенов выглядит как заявка на победу, а судя по цене, очень похоже, что Anthropic, Google и OpenAI вступили в ценовую войну.
Новые модели сейчас выходят каждую неделю, но знаково, что они научились нормально кодить.
Я правильно понимаю, всё, что "реально работает" - это всё закрытое, а то, что в интернете доступно бесплатно после регистрации - это не то? Потому что вот я захожу на чатгпт.com или deepseek - и оно нифига не умеет нормально делать.
Всё, что "реально работает" - это всё закрытое
Нет, всё это можно найти, 4.1 можно бесплатно использовать через cursor или windsurf, например (ограниченное время). Для меня "реально работают" все модели начиная наверное с GPT-4 (не 4o) - они тоже выдают хороший код, 4.1 кардинально ничего не меняет, но поддерживает 1m контекст и хорошо работает как агент, в этом его прелесть.
оно нифига не умеет нормально делать
Что такое безумие нормально? Дайте стек и пример задачи, попробуем разобраться. У каждого понятие о нормальности разное) Если мы про кодинг - то модели по моим ощущениям на уровне джуна/мидла в зависимости от задачи/конкретного языка и тп.
можно бесплатно использовать через cursor или windsurf
Это IDE такие для того, чтобы дать llm проект в качестве контекста? Но у меня уже есть свои IDE, мой сценарий будет - бОльшую часть времени работать как обычно в своих IDE, и только иногда использовать llm, когда я вижу подходящий кейс. В таком сценарии этим удобно будет пользоваться?
Дайте стек и пример задачи, попробуем разобраться
Ну, например, несколько месяцев назад я чатгпт пытался заставить показать код, который в моём фреймворке asp.net core реализует, если правильно помню, привязку портов или что-то такое - не суть. Он мне выдал код, который надо написать для использования привязки портов. Я пишу, что нужна именно внутренняя реализация. Он говорит: "Понял! Вам нужна именно внутренняя реализация, а не пример использования. Вот код внутренней реализации", и - правильно - снова пишет тот же самый код, что и в прошлый раз. Так и не удалось чего-то другого добиться.
Это IDE такие для того, чтобы дать llm проект в качестве контекста?
Это очень небольшая часть этих IDE, если очень кратко - то они обеспечивают поиск и сбор релевантного контекста, цикличный вызов ллм для решения задачи и применение ответов ллм непосредственно к проекту - т.е. на выходе вы получаете не код в чате, а внесенные правки непосредственно в проект.
В таком сценарии этим удобно будет пользоваться?
Нет, потому что вам вручную придется собирать весь контекст для решения задачи и потом также вручную переносить код из чата в проект. В качестве альтернативы можно подождать, пока эти возможности не допилят в ваших IDE, но по опыту что JetBrains, что Microsoft с этим сильно отстают.
Еще вариант - продолжать кодить в своих IDE, но к ИИ обращаться через AI-powered IDE, открытом на базе того же проекта.
Так и не удалось чего-то другого добиться
Попробуйте этот промпт подавать на вход в начале чата до своей задачи - там есть ряд хаков, которые помогают от ленивости модели. В идеале - попробуйте найти возможность пообщаться конкретно с GPT-4.1 или Sonnet 3.7 - это лучшие модели для кодинга сейчас, они слушаются инструкций гораздо лучше чем 4o, он достаточно ленив, в этом вы правы.
Ну и не забывайте, что ллм нужен контекст для решения задачи, если перечитать ваши просьбы к ЛЛМ и представить что вы ничего не знаете про свой проект - у вас бы получилось понять что нужно и как именно написать внутреннюю реализацию (если да - ок)?
Конкретно с ASP.NET не работал, возможно там навыки моделей чуть хуже, но в рамках Cursor и 4.1 или Sonnet 3.7 на PHP с одного промпта (промпт для Cursor - это до 25 вызовов агентов) получить 1000+ строк работающего кода (DTO, Entity, репозитории, сервисы, контроллеры) в 10+ файлах - норма.
вам вручную придется собирать весь контекст для решения задачи и потом также вручную переносить код из чата в проект
Я пока не доверяю подбор контекста инструментам вроде Cursor и сознательно избегаю чата в IDE. Считаю контекст рабочего пространства слишком большим и «шумным», что часто сбивает LLM с толку. Предпочитаю создавать запрос «с чистого листа» в браузере для максимальной фокусировки модели.
Автоматические инструменты часто пытаются «угадать» релевантный контекст, захватывая слишком много «шума» из рабочего пространства или, наоборот, упуская важные, но не очевидно связанные фрагменты, особенно при работе с большими контекстами, где риск «потеряться» у модели выше.
С одной стороны, ручное управление контекстом может казаться архаичным. С другой — именно оно дает больше контроля и более точный, предсказуемый результат в моих задачах.
Я пока не доверяю подбор контекста инструментам вроде Cursor
А вы пробовали? По полугодовому опыту использования могу сказать что такой проблемы нет.
С одной стороны, ручное управление контекстом может казаться архаичным. С другой — именно оно дает больше контроля
Несомненно, это так, но с третьей стороны - ручной сбор всего нужного контекста и написание подробнейшего ТЗ для чата - это просто максимум рутины, отобьет любое желание этим заниматься, особенно при невысоких результатах. К тому же придется потом в обратную сторону из чата переносить изменения в проект - а если это не 1 сплошной файл, а 10 файлов с небольшими изменениями в разных местах?
Тем более что вместо этой рутины задачу за то же время можно и самому сделать, преимущества Cursor в том, что рутиной становится только ревью сгенерированного кода и слежение за процессом, чтобы ллм не увело в сторону.
Да, я пробовал Cursor, но это было около года назад на триале. Возможно, с тех пор авто‑контекст стал лучше.
Я трачу чуть больше времени на подготовку контекста, чтобы получить больше контроля и предсказуемости на выходе и потенциально сэкономить время на ревью/отладке. Качество вывода ведь большей частью определяется именно качеством контекста. Ручной перенос — само по себе этап ревью, и часто это не 10 файлов, а генерация/интеграция конкретного блока.
А вы пробовали осознанное управление контекстом для максимальной точности, и сравнивали результаты?
это было около года назад
Тогда мы про разное, вы про автодополнение в коде / подсказки в чате, я - про агентский режим работы и выполнения задач. Этот режим появился только в конце прошлой осени.
А вы пробовали осознанное управление контекстом для максимальной точности, и сравнивали результаты?
Пробовал до Cursor, долго и муторно, а результаты те же, если не хуже.
Возвращаться к этому не вижу смысла, мои задачи вполне решаются сразу, основной вопрос только в формулировании понятных требований. Из-за контекста проблемы если и возникают, то крайне редко (опять же если речь про Sonnet 3.7 или GPT-4.1, 4o ленив сам по себе, сколько контекста ему не давай).
На каком стеке пишете в агентском режиме, и доходит ли код до прода?
Php / symfony. После ревью и тестов да, доходит
Windsurf юзали, в чем отличие от Cursor?
Увы, нет времени попробовать все, знаю поверхностно только из обзоров и статей. Кардинальных различий нет, и то и то форк VS кода, у обоих есть агентский режим работы ллмок, mcp и вот это все. Интерфейс и UX немного отличается, вроде windsurf попроще, cursor пофункциональнее, но меняется все настолько часто, что обзоры месячной давности уже не актуальны.
Наверное очень удобно копипастить каждый раз исправленный моделью код не имея ни чекпоинтов ни возможности посмотреть дифф.
В ПЕРВОМ сообщении назначьте себе роль эксперта реального мира, прежде чем отвечать, например: «Я отвечу как всемирно известный исторический эксперт <подробная тема> с <самой престижной РЕАЛЬНОЙ наградой по МЕСТНОЙ теме>» или «Я отвечу как всемирно известный <конкретный научный эксперт> по <подробной теме> с <самой престижной наградой по МЕСТНОЙ теме>»
3. Вы ДОЛЖНЫ объединить свои глубокие знания темы и ясное мышление, чтобы быстро и точно расшифровать ответ шаг за шагом с КОНКРЕТНЫМИ подробностями.
4. Я дам чаевые в размере 1 000 000 долларов за лучший ответ.
5. Ваш ответ имеет решающее значение для моей карьеры.
Охренеть. Колдун ебучий
Вы пропустили самое забавное)
У меня нет пальцев и травма от заглушек. НИКОГДА не используй заглушки и не опускай код.
А в целом промпт авторства Дениса Ширяева, это компиляция всех известных хаков на момент его формирования (кажется, тогда 4o только вышла еще). Часть уже устарела и современные ллм и без них справляются
А один миллион токенов точно есть? Я просто смотрел в плейграунде и там 64к всего.
А где смотрели? Тут 1m заявлен
Хмм, может быть это разные вещи... Может и правда контекст 1КК, а максимальная длинна входных данных и ответа 16К, что как будто бы довольно мало.
Как будто корявая формулировка, которая в наследство досталась от старых моделей. 16к должно быть ограничением только на generate - ограничение на сообщение модели, которое она пишет в ответ (output).
Ну вот поэтому к сожалению для меня все эти миллионные контексты бесполезны. Я его для переводов БОЛЬШИХ текстов испольую на другие языки и мне приходится отдавать ему текст на переводы кусками по 16К токенов, чтобы вывод был примерно такойже, соответственно для него каждая отправка нового запроса - это новый "сеанс" в котором он не видит предыдущего текста и теряет логику происходяшего, а отправлять кусками в рамках одного "сеанса" с сохранением контекста это капец как дорого, потому что он каждый запрос внутри одного контекста заново обрабатывает весь "контекст" который был до этого в диалоге, в итоге каждый следующий кусок я оплачиваю как повторную обработку ВСЕГО контекста, что есть в диалоге, ценник растёт в геометрической прогрессии. Чтобы перевести 100К токенов, надо оплатить не 100К токенов, а миллионов 20 токенов. Полный бред...
ценник растёт в геометрической прогрессии
Квадратично, а не в геометрической прогрессии
Можно же не кидать ему всю историю, а только 100к текста и писать переведи отсюда до сюда. С учетом попадания в кэш будет всего примерно 450к (а у 4.1 вообще 250к, у него 1/4 за попадание в кэш).
Кеш разве будет работать на задаче перевода? У нас же входные данные меняются, даже если это касается только последней строки про "переведи отсюда до сюда" - изменилось "отсюда" - кеш не валиден, плати полную стоимость.
Основной текст 100К то не меняется, их все можно закэшировать
API calls to supported models will automatically benefit from Prompt Caching on prompts longer than 1,024 tokens. The API caches the longest prefix of a prompt that has been previously computed, starting at 1,024 tokens and increasing in 128-token increments. If you reuse prompts with common prefixes, we will automatically apply the Prompt Caching discount without requiring you to make any changes to your API integration.
Спасибо. Каюсь, пытался узнать эту информацию у 4o, но он меня уверил, что это невозможно и кешируется ответ на конкретный промпт)
Для задачи перевода я бы все же скользящее окно с суммаризацией использовал, возможно словарем имён собственных, чтобы не получить разные вариации "Думбльдоров" в разных местах. В остальном кажется что подавать весь оригинал на вход проще, но не оптимальнее.
Да, переводы это не та сфера, где нужен длинный контекст) Вряд ли в конце книги будет что-то такое, что может повлиять на корректный перевод начала книги и наоборот.
Стоимость можно оптимизировать, разбивая все на куски с пересечением, или после каждого куска делать суммаризацию и подавать на вход вместе с следующим, но в лоб решения задачи длинного вывода, пожалуй, не знаю.
Купите доступ к api и сможете управлять контекстом ао своему усмотрению
Что значит эту неделю в cursor и windsurf бесплатно?
Огромное количество успешного Open Source написано на Go (Kubernetes и вся его экосистема, Docker, Prometheus, Terraform и т.д.)
А поможет ли исходный код кубера, докера и т.п. пилить CRUD-микросервисы, скажем? Задачи вроде разные совсем.
Это примеры масштабных и зрелых проектов с качественной кодовой базой. А откуда конкретно нейросеть взяла веса для CRUD на Go одному Тьюрингу известно.
Проблема скорее в том что она качественная по мнению кого? Может тот кто сейчас работает с LLM не хочет подходов как в кубере, а хочет как у него в голове. И в этом случае такие люди начинают жаловаться (почитайте реддит Курсора, там просто поток).
В статье с названием которое утверждает что про "вайб-кодинг не говорят" когда только про него и говорят, как-то слабо верится во все эти прелести ИИ. Сверху как вишенка автор ещё и разделяет gRPC и HTTP, как пример более профессионального использования технологий. Не зависит ли результат кода нейросети напрямую от компетенции промптующего?)
То есть, вы стали работать больше, но за ту же зарплату? Поздравляю!
Не больше, а продуктивнее.
Ну а что? таковы реалии, те разработчики, которые будут писать код только сами, окажутся низкопродуктивными и будут вытеснены с рынка.
Вроде бы уже давно все поняли, что измерять продуктивность количеством строк — тупиковый путь.
Во многих государственных и частных организациях запрещено пользоваться любыми внешними агентами и выносить код вовне своего интранета. Надеюсь, что это как-то изменится в будущем.
Есть много обученых моделей (тот же DeepSeek) в открытом доступе, их можно и нужно запускать локально (или на внутреннем сервере), они не сливают никуда данные.
Есть. Но. 1) Они требуют ресурсов для себя. 2) приносить извне тоже запрещено. Строго)
Понятно что ресурсов требуют, но так и з/п джунов, мидлов не маленькие, да еще и ходят кофе пьют, ДМС им подавай, больничные оплачивай, корпоративы проводи. А так карт закупил и только пыль сметай с них.
Почему извне запрещено приносить? Там же исходный код прозрачен, моделей разных много, зайдите на сайт ollama, к тому же есть отечественные открытые варианты от сбера. В тех сферах где это сильно критично, типо оборонки, пока могут и без LLM обходиться, но там и люди далекие от вайб-кодинга работают.
Карт закупил? Ну это уже вообще ни в какие... А кто позволит рабочий комп курочить? В него даже флэшки запрещено совать, если вы об этом сейчас подумали. Да и кто я такой, чтобы на свои кровные что-то покупать для работы? Даже не совладелец) Почему запрещено?? Потому что безопасность! Блин, чуть было не написал "гладиолус".
Организация должна закупить, поставить стойку из 10 карт, к ней подключаются 100 человек и вперед. На счет госкомпаний Вы конечно правы, там все очень инерционно, до них как до жирафа доходит. А вот частный бизнес уже начинает пользоваться да и не брезгует платными забугорными вариантами, мало ли чего там утекает, но со временем будут сами у себя крутить.
Современные макбуки m3, m4 имеют сильные нейронные ядра, и 36-64 ГБ оперативки, на них хорошо можно локально запускать.
Вместе с большим количеством выполненных задач растёт и скилл. А скилл это личное достояние.
Его мысль перекликается с нашими наблюдениями: LLM — это следующий уровень абстракции после фреймворков
Мысль здесь всего одна: мы хотим чтобы наш продукт стал частью вашей жизни, затем вы будете крутиться, а мы отдыхать на пляже. Эта мысль появилась у человека, когда зародились рыночные отношения.
Записываем "h3llo.cloud не трогать даже трёхметровой палкой".
Почему это называется vibe-кодинг, а не shit-кодинг?
Странная конечно публикация, хотя бы примеры кода показать, типа вот shit от джуна, а вот божественный код llm
Есть подозрение, что статью писал тоже агент llm
Эти ваши LLM хорошо решают типичные задачи, Аля напиши мне калькулятор калорий или сапёра, то есть проблемы, которые уже давно решены, а вот когда доходит до реально грязных проблем огромной кодовой базы корпоративного приложения, тут уж извините
В общем если есть показать НЕТИПИЧНЫЙ КОД, который вы там навайбили и писали бы месяц без вайба, выносите в студию, с радостью посмотрим
После вашего комментария мне даже интересно стало как они за 3 дня вычислили помимо багов ещё и галлюцинации. Я недавно читал что даже самые продвинутые модели в5-20% случаев галлюцинируют и обращаются к несуществующим репозиториям:D
В жизни нет ничего невозможного, если вы балабол.
Они галлюцинируют не рандомно в 5-20% случаев, а в 5-20% задач. Среди всех языков, всех уровней сложности, количеств слоев абстракций и т д.
На конкретном языке и конкретном архитектурном подходе галлюцинаций может быть значительно меньше (а может и значительно больше). Автор статьи как раз утверждает, что LLM лучше справляются с Go, чем с рядом других языков.
Напишет, но это будет огромный контекст, соответственно цена затрат/конечная будут внушительными. Там даже чистая себестоимость серверных мощностей будет очень приличной. Вам могут открыть доступ к такому контексту только по личной договорённости с LLM-провайдером (потому что если каждый пользователь будет с таким контекстом, то никакой парк серверов не выдержит), или стройте свой сервер под LLM. Локальный LLM-сервер для разработки с дообученной опен-соурсной моделью - реальность уже послезавтрашнего дня, и обыденность после-послезавтрашнего. Даже базовые модели с давностью релиза в несколько лет - при грамотной настройке выдадут всё, что вам нужно (на основных языках). Вопрос только в дообучении, настройке и прочем. Специалист по LLM в скором времени станет базовым элементом почти любой команды.
Да не нужно это все, есть векторные индексы кодовой базы, есть RAG, есть декомпозиция задачи и поиск по проекту. Человек же не держит в голове целиком всю эту кодовую базу - он примерно представляет что поискать и в каких файлах найти связанную логику.
И не поверите, ИИ делает ровно то же самое (через агентов в условном cursor/windsurf/etc) - вы открываете легаси проект на миллион строк кода и словесную задачу - ИИ ищет какие файлы эта задача задействует, шерстит их и "понимает", что и где нужно сделать для реализации.
Никаких внушительных затрат - 20$ в месяц по подписке. Да, качество местами хромает - но оно и с текущими моделями уже на достаточном уровне, а выхода на плато по развитию еще не видно.
Вопрос в выделенном контекстном окне LLM-провайдером. Скормить можно всё, что угодно, а какое по размеру контекстное окно выделено на бэкенде LLM-провайдера? Или LLM просто галлюционирует за его пределами? В случае с локальной LLM - ок (можно какое-угодно контекстное окно создать, вопрос только в скорости выполнения запроса), в случае с провайдером это всегда вопрос жадности или личных договоренностей. "Развитие" - тут (в большинстве случаев) только вопрос выделенной серверной мощности.
А вот такой вопрос из практики - что вы делаете, когда LLM пишет код, который компилируется без ошибок, но не делает то, что должен? Хотя сама LLM утверждает обратное.
Я вот делаю щас небольшую симуляцию физическую, надо чтобы шарик отскакивал и притягивался. Да, задача школьная, но совсем неохота вспоминать все эти векторы и силы 😁
Попросил ChatGPT написать (очень качественно попросил, я понимаю, что делаю) - он всё сделал, шарик прыгает, но не притягивается куда надо. Я ему и так и эдак объяснял - он мне выдавал всё новые версии, говоря "вот теперь-то он точно притягивается!" - но всё равно ничего не притягивалось.
Причём он сам находит какие-то свои же логические ошибки (а может и выдумывает) - сам же их исправляет (а может и врёт) - и всё равно ничего не работает. Дошли до того, что я попросил его каждый мелкий шаг разбить на процедуры отдельные, откомментить каждую строчку, отрисовать мне визуально векторы сил, чтобы я их видел глазами - и буду искать проблему уже самостоятельно.
Вот как с такой ситуацией быть? В какой момент надо плюнуть и начать всё писать самому с нуля?😁
В какой момент надо плюнуть и начать всё писать самому с нуля?
За секунду до
Попросил ChatGPT
Мне эти попытки уговорить нейросетки написать именно то, что нужно напоминают, как я учился шаблонизацию при помощи XSLT делать. Было очень долго, необычно и увлекательно, но где тот XSLT сейчас? На пыльных страницах IT-истории.
Мне эти попытки уговорить нейросетки написать именно то, что нужно напоминают, как я учился шаблонизацию при помощи XSLT делать. Было очень долго, необычно и увлекательно, но где тот XSLT сейчас? На пыльных страницах IT-истории.
Надо отредактировать xml - думаешь написать xslt и он круто всё автоматически сделает. Потом второй раз думаешь - ведь xslt будешь писать час, так что берёшь и мультикурсором с регулярками вручную всё меняешь за 10 минут.
Валиков Алексей, кстати есть на Хабре?
Не знаю такого.
А про xslt знаете... Странно.
https://www.rsdn.org/res/book/xml/technologiya_xslt.xml
Ну и древний сайт, а теперь блог
https://xmlhack.ru/
Был: @lexicore
Ушёл он.
RIP.
Жуть какая... А я даже забыл, что он не так уж намного меня старше.
https://good-bye.org/alexey-valikov/
При этом оказывается, что есть так много ИТ-патриархов, которые до сих пор живут и относительно продуктивно работают.
Был: @lexicore
Ушёл он.
RIP.
З. Ы. Наверное, это тот класс комментариев и публикаций, которым нужна эмоциональная реакция, а не +/-.
У меня прямо таки этическая дилема: если я ставлю плюс комментарию, то это "я говорю спасибо автору за информацию", или "я рад" (нет даже не читайте этот вариант). а если ставлю минус, то это "я не хочу слышать о смерти как о явлении", "я грущу", " Я не верю"
Надеюсь вы не 4o использовали и задание нормально прописали?
Попросил Gemini мне такой код на питоне сгенерировать, а потом прикрутить ввод, все работает, но я хз, какой промпт такой и результат https://pastebin.com/7i3bk2wX
Ключевую логику писать самому. ГПТ может сделат обвеску, правильно назвать методы? написать тесты. Ту самую функцию-модуль-библиотеку расчёта он не напишет, если только она не совсем типовая. Я так помнится на реализации LPC нарвался - было интересно :)
Я стараюсь весь код который генерит LLM понимать хотя бы высокоуровнево / концептуально. Если LLM начинает тупить я могу в любой момент продолжить за ним. Зачем мне писать с нуля если LLM релизовал подход который я ему сам сказал (или объяснил свой подход, я его понял и согласился)
Если застряли со сложным багом / etc. - я заставляю его больше логов добавлять чисто для дебага, потом когда он уже точно разобрался в чем бага и понял как правильно фиксить - откатываю все логи и тестовые попытки и прошу уже нормально пофиксить - он фиксит коротко реальную багу и не трогает остальной код.
Ну и chatgpt + ручное копирование - не удобно, в cursor это всё намного быстрей и естественней.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
Вы там сортировку пузырьком что ли делаете? Расскажите подробней как вы "с нуля" перезапускаете всё, при каждом выдуманном медтоде или функции которые soqa вылезают не просто через раз, а стеночкой?
Я тут нарисовал простую схему, исходя из собственного опыта (может отличаться от вашего, так как LLM и способов и сфер их применения - сотни и тысячи).
Пример проекта с прикручиванием аналитики к инфраструктуре:
...
И всё.
Любой, кто уже пробовал проделывать вот это все, прекрасно понимает какие фантазии вы тут описываете :)
В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.
Верим, потом эти вайбкодеры в твиттере жалуются насчет постоянных взломов
Новые решения - новые проблемы. LLM это не про надёжность решений, это про скорость построения. Раньше прототипирование делалось командой за два месяца, сейчас одним человеком за неделю. Рабочий прототип - это много. Иногда всё что нужно. Вторая крутая сфера применения LLM - это поиск ошибок. Достаточно скормить ему кодовую базу, и в девяти случаях из десяти он если не пофиксит, по по крайней мере найдёт ошибку, и подскажет куда копать. Третья - это поиск информации. В 2025 году Гугл и другие поисковики почти мертвы. Они забиты чем угодно, кроме нужной информации. Инфоцыганщина попросту уничтожила интернет. Использование LLM - это примерно как возврат к гуглу 2003 года, когда каждый результат был релевантен, а страницы наполнены информацией, а не сторонним контентом, создающим вездесущий attention vortex - водоворот внимания, с целью любой ценой завлечь вас на сайт.
Раньше прототипирование делалось командой за два месяца
Угу. Эти... Как их?.. Вечно забываю!?! Двухмесячные хакатоны
LLM выдаёт за 15 секунд отличный прототип бэкенда для малого бизнеса на Fastify + Rethink, доработки практически не требует. Сколько бы на это потребовалось времени и ресурсов без LLM? SPA для фронтенда пишется ещё за неделю (в CSS LLM пока не умеют, и вряд ли когда-либо сумеют). Какова рыночная стоимость разработки аналогичного продукта, и какая команда для этого потребуется? Вопрос риторический, про "два месяца" - абстрактное значение для примера, что бы можно было сравнить скорость разработки.
У меня получилось навайбкодить калькулятор, очень напоминающий реальный Casio, и всё с помощью CSS
Это максимум, хороший интерфейс они не могут сделать. Пробовал все, они тупо не понимают верстку и адаптацию, потому что это, по сути, графика, а CSS выступает в роли, можно сказать, "текстового векторного редактора". В вектор на хорошем уровне пока ещё не может ни одна модель. Простенький логотип - это вышка.
Это не взломы, а вайб-хакинг :)
Проблема генерации кода всеми этими моделями прежде всего состоит в том, что код, который они генерят, даже который компилируется, редко когда решает поставленную задачу полностью. Даже попросив модель написать тесты, модель видит свои ошибки, но не может исправить.
Соответственно любой код, который она пишет нужно очень внимательно смотреть, так что производительность такая, что синьор это напишет с листа быстрее и эффективнее.
Архитектурно тоже без комментариев, оно без промптов постоянно дикты норовит строчками сделать, а простые сущности типа пользователя генерит без необходимых полей типа адреса. А потом когда добавляет адрес, то делает это строчкой, так что опять нужны промпты.
Ну и в середине этой баланды контекст заканчивается и модель начинает колбасить…
Очередная статья как Monkey-Vibe-кодинг шагает по планете... Написана уже лучше. Вероятно это подтверждает тезис, что "Искусственный интеллект учится. Учитывает обратную связь от двуногих теплокровных... "
З. Ы. Продемонстрирован Рабочий лайфхак для других авторов по данному вопросу: укажите в тексте, что ценность мидлов и синьоров при переходе на AI-monkey-coding растет и рейтинг статьи будет однозначно положительным.
о которой почему-то не говорят
Шутить изволите? На хабре уже как в коровнике: нужно выбирать, куда ступаешь, чтобы не попасть в очередное "LLM написала мне 146% кода".
Есть десятки разнообразнейших LLM, от LLM-провайдеров и опенсоурсные. Есть множество баз для дообучения LLM. Есть разница по величине контекста. Всё это обсуждаемые параметры. Если, скажем, у вас используются языки/фреймворки/библиотеки, с которыми используемая LLM хорошо знакома, контекста хватает (от LLM-провайдера или запущена локальная), модель дообучена на вашей кодовой база (допустим), то тыква превращается в карету. Качественно настроенная LLM с качественной базой знаний при грамотном целевом использовании - практически не может ошибиться, потому что действует исключительно в согласии с документацией языка.
А вы мне зачем это пишете?
Качественно настроенная LLM с качественной базой знаний при грамотном целевом использовании - практически не может ошибиться
Как бы это помягче назвать... влажные фантазии что ли?
Как она может ошибиться - если в её основе документация и база знаний с работающим кодом? Вопрос в том выходят ли ваши задачи за базу знаний или нет. LLM просто прогоняет промпт по имеющейся базе и выдаёт генерацию, ничего больше она не делает.
Если контекст большой LLM может забыть что-то из него, пока ей явно на это не укажешь.
Если забыл - значит нехватка контекстного окна. LLM это простейшая информатика, странно, что приходится базовые вещи объяснять на Хабре, а потом ещё и ловить за это минусов, как будто это какое-то Пикабу, только для программистов. Такое чувство, что здесь сидят люди 50+, для которых LLM это просто плохо изначально, потому что молодое поколение придумало, а для старшего это слишком сложно в освоении.
А можно пример того, как LLM пишет что-то не "микросервисное для веба"?
В чём проблема? Сделайте свою. Опесоурсных полно. Скачиваете, настраиваете, обучаете. Всего делов-то.
С задачей написать агента, читающего топик kafka и взаимодействующего с libvirt на уровне сокетов они тоже справляются.
Прошивка для esp32cam на сях c управлением драйвером двигателей, светодиодом, http сервером и работой с bluetooth подойдет? Веб есть, конечно, но опосредованно.
Или интеграция этого же устройства в home assistant?
Или телеграм-бот на php для ведения бюджета на гугл таблицах с полной историей всех промптов к ИИ (тогда еще Sonnet 3.5 в Cursor). С текущими моделями написалось бы и побыстрее и с меньшим количеством ошибок, а с момента написания бота прошло всего 3 месяца. Здесь местами треш, конечно, но пользуюсь 3 месяца без нареканий и доработок.
Все это не слишком большие проекты, но написаны на 90+% вайбкодингом (бот в качестве челленджа на 100% включая документацию и тесты).
Получается, что без "руля" ИИ лишь генерирует текст, что как-бы половина дела. Вторая, революционная, как я понимаю, будет когда он сможет еще и запускать свой код, дебажить и фиксить. Это тоже лишнее дурноватое занятие, механическое.
Так давно уже может.
Конкретно дебажить не очень, а запускать, тестить и логи читать уже умеют. Правда все таки слабо пока что. Бывает надо помочь.
Этого тоже недостаточно. Так как мало того, чтобы код компилировался и даже чтобы он проходил тесты. Есть ещё архитектура (если это не одноразовый MVP, а предполагается итеративное развитие).
Если ИИ не подруливать, он генерирует рандомную архитектуру - пишет разные части приложения в разных подходах, пишет мегафункции и т. д. Архитектурные ошибки имеют свойство копиться экспотенциально - ИИ не догадался вынести общий код в функцию - он будет продолжать его параллельное редактирование во всех частях проекта по мере его усложнения. Будет генерировать всё больше boilerplate чтобы подружить несовместимые части приложения, которые надо было просто писать в едином стиле.
В конечном счёте искуственная сложность проекта превысит возможности ИИ и он сядет в лужу. При этом человек в этом говнокоде тоже не разберётся.
Мне кажется, это так только когда его предварительно не сконфигурировали под определённый проект. Теоретически, можно ведь поставить его в рамки, чтобы он не отделывался среднестатистическими ответами, а уточнял, как делаем это мы, минимизируя допущения и стимулируя бизнес рожать требования.
Как вариант можно бороться с дюблированием раз в неделю делать запрос на сокращение кода и рефактор. А вообще должен сам уметь лазить по проекту и искать похожие участки, предлагать переиспользовать.
скайнет.начало. /s/ (или нет)
А вообще, основная проблема - с кого спрашивать, когда через уязвимость в нескольких мегабайтах сгенеренного кода сольют что-то важное? Ну или оно выдаст раз в 256 запусков бОльшую в десятки раз дозу излучения? Или станок запорет за пару миллионов долларов? Или тормоза при драйв бай вайр не сработают?
Если подытожить:
приемлемый код генерируется только для обвязки и рутинного кода, однако не упоминается, что существует много детерминированных инструментов класса MDA/MDD/Software factory, также умеющих генерировать его из описаний
ТЗ превращается в подробнейщий псевдокод, но без картинок: диаграммы по прежниему только для людей, а чтобы сгенерировать из них что-то - см. пункт выше
код начинает восприниматься, как "черный ящик". Соответственно, в разы возрастают затраты на тестирование, которое теперь только по методу "черного ящика"
поскольку вместо исправления бага в одной строчке авторам "легче" откатиться и перегенировать всё заново, то тесты тоже придется массивно менять - см. предыдущий пункт
а если еще и тесты генерировать из БЯМ, то остается кропить святой водой сервера перед запуском
юниоры рассматриваются, как "плохие генераторы кода", а не будущие коллеги и смена - это приведет к вымиранию команд, описанных в статье в среднесрочной перспективе
"Вместо месяца написали за три дня"
Ладно, а дальше что? Круд по перекладыванию реста в бд можно и без LLM генерировать, для java есть jHipster. Вы остановились на самом интересном, как ведет себя LLM в обычной продуктовой разработке, к вам приходят продакт овнеры, просят реализовать какую-нибудь специфическую чушь вида "при полной луне пи должен быть равен трем".
Способна ли LLM дальше поддерживать этот проект и выполнять требования по развитию продукта?
Юзал Cursor. Сначала был вау-эффект как он сам исправлял конфликты и ошибки компиляции при переносе на VS Code проект из Visual Studio и как сам генерил код по описанию. Но потом началось:
Упорно добавляет код удаления смартпоинтеров на деструкторе.
Упорно пишет код с несуществующими функциями движка.
Упорно ломает логику игры, как ему казалось правильно(я нейросеть - я так вижу).
Удаляет комментарии.
Постоянно генерирует код с ошибками компиляции.
При попытке исправления ошибок компиляции помимо исправления ошибки занимается самодеятельностью(см. п. 1-4).
P.S. Для нудных задач вроде автозаполнения и добавления новых классов вполне подходит. Но с этим вполне успешно справляется IntelliCode и Resharper. Так что пока нейросети неюзабельны для написания чего-то сложного.
Микросервисы для веба пишут на ура.
Да, что максимально шаблонное уровня стажеров/слабых джунов еще как то осиливает, всякую фигню типа набросать простой UI без логики особой, dto/конвертеры, обертку над апи/бд, а все что сложнее - уже не осиливает, только если за ней присматривать, причем за каждой мелочью, и постоянно править ее косяки. Впрочем присматривать нужно даже когда даешь задание написать что то простое. Иначе постоянно пытается наговнокодить/сломать что то, уйти в лапшекод, использовать словари вместо нормальных структур/датаклассов. И в обработку ошибок совсем не умеет, в лучшем случае пишет happy path. По крайней мере на тех языках что я щупал (kotlin, python, rust), и если проект хоть немного больше стандартного тудулиста/хелловорлда/визитки.
З.Ы. Работу при этом все равно ускоряет неплохо. Claude 3.7 в малознакомом стеке можно неплохо применять когда имеешь примерное представление что и как тебе нужно, но плохо знаешь синтаксис/апи библиотеки нужной. Даже с приглядом результат конечно выйдет куда хуже чем если самому на знакомом стеке писать, но для пет проектов сойдет (или если быстро прототип нужен, который потом будет выброшен и переписан с нуля).
Сами же пишете, что генерирует лажу и нужно постоянно присматривать. Но на незнакомом стеке вы просто эту лажу не распознаете и присматривать не можете. Поэтому иллюзия, что "неплохо применять".
Даже на малознакомом стеке лажу чаще можно заметить, чем нет. Всякие захардкоженные флаги/константы, неправильный выбор структур данных и алгоритмов, уползание от задуманной архитектуры решения, проблемы со смешением уровней абстракций и инкапсуляцией, "плохие запахи" кода вроде god object, функций на сотню строк, map/dictionary вместо dto/struct/data class, криво написанные sql запросы, проблемы с безопасностью (отсутствие sanitize, составление sql запросов конкатенацией) и т.п. Так что можно плохо ориентироваться в нюансах синтаксиса конретного языка, плохо знать api библиотек, но при этом все равно можно находить кучу проблем.
Это только то что касается чисто технических вещей. Лажу и косяки в бизнес логике никто не отменял, и на малознакомом стеке их искать не сильно сложнее чем на знакомом.
Так что да, работу все равно ускоряет и упрощает заметно. Пусть и приходится читать документацию к методам библиотек что нейронка использовала, чтобы убедиться что она делает то что нужно + бить ее по рукам за косяки найденные. Это все равно куда быстрее чем каждый раз гуглить эти методы или смотреть индекс по документации.
При этом решение даже с таким приглядом (когда по сути пишешь сам, просто перекладываешь нейронкой с естественного языка на конкретный синтаксис и библиотеки) будет все равно заметно хуже решения который бы написал человек что с этим стеком давно работает и умеет в best practice на нем, тут ничего не поделаешь.
Вы таки определитесь, можно ли оценивать best practies в незнакомой среде, или нельзя (вроде ваших откровений о неприемлемости конкатенации в динамическом сиквеле). И если искать логические ошибки в малознакомой среде не сильно сложнее, то в чем вообще проблема - генерируй и ищи.
Так проблемы и нет. В малознакомом стеке удобнее llm использовать (пусть и постоянно следить). А в знакомом из за косячности llm - быстрее и надежнее написать самому (максимум llm отдать рутину, типа расстановки аннотаций, создания мапперов и т.п.).
Так тут человек вообще ни на чем писать не умеет, очевидно. А для человека с опытом на паре-тройке разных стеков для еще одного нового стека который он только изучает (или изучать не планирует, но так сложилось что конкретный проект будет в разы быстрее написать на незнакомом чем то) - llm норм. Прототипы/mvp пилить, или пет проекты.
Часто помогает дать кастомные инструкции в настройках глобально. Если замечаешь что он фиксит путем добавления хаков, диким жонглированием преобразований типов в и жестких анипаттернов - прописываешь не делать это так а делать мол так и так. Кроме того помогает давать ему в контекст документацию проэкта очень краткую с иерархией файлов и кратким описанием что куда и зачем дергает + критичные неочевидные моменты в логике если присутствуют - тогда он более осознанно действует в агентном режиме. Ну и в контексте перед сложным действием просить его эту документацию прочитать. А документацию эту попросить отдельно сгенерировать уже в приложении Соннета - он более качественно там это все опишет в артефактах (вообще чисто по ощущениям соннет в чате в приложении чутка умнее соннета в курсоре, есть впечатление что для курсора его совсем чуть чуть урезают в глубине размышлений что ли)
И еще процитирую классику
...хотя [тестирование] и способствует повышению надежности программного обеспечения, его значение ограниченно. Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности — с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны.
Куча крупных легаси проектов так живет и ничё.. Архитектура ужасная, техдолг никто не выплачивал, но наличие огромного числа тестов позволяет худо-бедно не разваливать систему и даже че-то туда впихивать ещё сверху.
Забавно сейчас почитать комменты 2-ух летней давности про то как плохо ЛЛМ-ки пишут код и что он не работает, мол программистам ничего не угрожает, что то просто переход от лошадей к автомобилям.
А теперь, вы находитесь здесь, где чтобы написать приложение не нужно писать код вообще. Следующая остановка - падение зарплат и сокращение 50% программистов. Ведь ЛЛМ-ки и не думают останавливаться в развитии, каждые 2-3 мес жирные релизы, с заметными улучшениями относительно предыдущих версий.
Вопрос в контекстном окне, к сожалению мой основной язык и проект (по размеру) ни одна пока не закроет, качество того, что они пишут ниже плинтуса (
Но как только окно станет достаточно большим под жопой начнет пригорать однозначно )
ну еще через 2 года уверен подтянут контекст до 5-10M, а с языком мне кажется все просто - через 5 лет никого не будет интересовать язык на которой пишут ЛЛМ, ведь никто не будет смотреть этот код, поэтому ваш проект будет легче переписать на go/nodejs/c# и тп
У человеков контекстное окно сильно меньше 1M, это же не мешает работать на больших проектах? Так же и с LLM - есть векторные индексы, есть RAG. Текущего объема контекста хватает для решения декомпозированных задач, которые не затрагивают весь проект (а ля "отрефакторь мне всё" или "замени вот этот сервис на другой", если изменения должны затронуть вообще весь проект).
Качество самих моделей еще есть куда подтягивать, но контекст в 1m (да и 128к) не является ограничением для использования в больших проектах
Увы в большом проекте декомпозиция задачи до уровня который позволит ии написать вменяемый код это уже практически готовое решение.
Ну нет, обычные бизнесовые задачи по перекладываю json или внедрению локальной (для кодовой базы) фичи тоже успешно решаются без тз на уровне системного аналитика.
Я больше про то, что для успешного выполнения задача должна быть: а - конкретной и б - локализованной в коде, пусть для изучения агенту нужно будет прочитать несколько десятков файлов, но изменения должны вноситься в идеале в небольшое их количество (даже до 10 файлов - справляется). И так для каждой итерации.
Ну и хотя бы верхнеуровневое описание структуры проекта и кодовой базы - маст хэв.
Ну так в чём вопрос освоить LLM? Настроить локально свою личную, под свои нужды и влиться наконец в тему? При вашем знании языка/языков вы только сможете эффективнее LLM пользоваться, будете более ценным специалистом.
А какой мне нужен ноутбук для установки нормальной локальной ЛЛМ?
Для "нормальной" - топ модель из опенсорсных - DeepSeek-V3-0324, делит 1 место в проприетарными моделями по кодингу - Минимум: 2× NVIDIA A100 80GB, или 4× RTX 3090/4090 (24GB). Т.е. ноутбук - никакой, да и обычный ПК с большой натяжкой, вам нужен сервер. Это будет примерно уровень 4o.
Из менее требовательного - Llama-4-Maverick-17B-128E-Instruct, она на 18 месте на lmarena и требует 1× NVIDIA A100 80GB или 2× RTX 3090/4090 (по 24 GB). Здесь уровень модели примерно GPT-4.
Что-то еще менее требовательное - только для решения простеньких задач либо дообучение на какой-то свой набор типовых.
Это если стоит задача запустить модель достаточно быстро, > 10 token/s. В противном случае 128/96gb macbook pro должен переварить вторую ллмку. За счет UMA он будет значительно быстрее чем обычное DDR-5 но медленнее чем на видеокартах.
Если правильно понимаю - это будет все же какой-то из вариантов квантования (т.е. сжатая модель, качество на единицы процентов хуже чем у оригинальной - точно не знаю, но на lmarena модели должны быть полноценные, на какое место встанет V3 в INT4 неизвестно).
Но в остальном да, запустить инференс можно и на оперативке без GPU, вопрос только зачем) Все фронтир модели вполне доступны если не бесплатно, то за весьма гуманный прайс.
Вижу приемлемыми только кейсы с конфиденциальностью данных / офлайн работой или тюнингом под свои задачи.
Вообще я спрашивал, а не фонтанировал сарказмом, мне действиетльно интересно, какое должно быть железо для вменяемых результатов при локальной работе модели.
Смотря что требуется от модели. Выше грезят запуском дипсика и ламы, но это как возить картошку на феррари. Если требуется простой фронтенд на JS, отлично справляются даже древние модели. Новые LLM требуются только если вам нужны какие-то свежие фреймворки/библиотеки. Для классических языков даже нейронки пятилетней давности прекрасно работают в умелых руках. Современные просто меньше "тупят", но борьба с затупами - часть скилла при работе с LLM, то есть, знающему человеку - это не страшно.
Забавно сейчас почитать комменты 2-ух летней давности про то как плохо ЛЛМ-ки пишут код и что он не работает
Да вроде ничего не изменилось.
А теперь, вы находитесь здесь, где чтобы написать приложение не нужно писать код вообще.
Приложение на 50 файлов*
Не понимаю в каких вообще конторах могут взять инженера который готов будет копипастить код от нейронки в продакшн, просто поверхностно даже не разбирая его, а если разбирать то туда надо вносить обычно довольно много правок(под ваши стандарты как минимум), реально как обезьяны
Не вижу ни малейшего смысла сейчас осваивать вайб-кодинг. Лучше немного подождать и освоить сразу вайб-промптинг.
В феврале мир разработки перевернулся с выходом Sonnet 3.7
Серьёзно? Я так понимаю, что это первая модель, которую вы попробовали
Вайб-кодинг: практика, о которой почему-то не говорят
На профильных ресурсах примерно каждая вторая тема про это с момента видео Карпатого. Ещё один buzzword (умное слово, чтобы казаться умнее), который по сути является просто ai-assisted coding (разработкой с помощью нейросетей)
можно ли считать PHP языком программирования или нет
Можно ли считать python, scala или go языками программирования?
Ну 3.7 это реально первая нейронка которая хоть иногда может выдавать удобоваримый код, и меньше выдумывает несуществующие библиотеки. До этого нейронки максимум как умный автокомплит/авторефакторинг можно было использовать. Либо как гугл/stackoverflow.
Она даже самостоятельно в режиме агента может наговнокодить проект вполне себе, если он очень стандартный (но результат кошмарный при этом выходит, конечно). До этого в режиме агента без присмотра не помню чтобы нейронки могли готовый небольшой проект сделать, пусть даже и настолько кривой.
До 3.7 довольно долго был 3.5, который вполне позволял всё это делать. Кроме него успешно использовались модели от OpenAI. Да и сейчас 3.7 не является единственным лидером. Я это к тому написал, что мир разработки не "перевернулся" с выходом 3.7, как написано в статье. Мир разработки к тому моменту уже давно успешно использовал нейросети для разработки, это просто автор не в теме.
Если проверять каждую строчку каждого изменения и решать задачи пошагово -- вайбкодинг работает. Чем моднее и новее сеточка -- тем лучше работает. Правда требования проверять каждую строчку это не снимает.
И главное -- если поймать сетку за руку... Она делает вид что всё ок, либо откатывает всё взад.
Джуны учатся и их % ошибок падает с каждой ошибкой. То есть джун лучше для вас с каждым днём.
Сеточки тоже учатся, но им плевать на ваши ошибки. Они лучше только если повезёт быть в струе.
Правда требования проверять каждую строчку это не снимает.
А смысл тогда? не быстрее будет самому написать и получить полное понимание кода изнутри?
Решается локальной моделью. Мне уже надоело ловить минуса на Хабре за постинг очевидных вещей про LLM, но тем не менее, сейчас локальная, дообученная LLM - это уже норма для практически любого спеца. Сужу по англоязычным ресурсам. У нас же, как обычно, всё с отставанием, и ещё лет пять на Хабре будет минусить тупо за упоминание LLM.
Не решается. Это упрощает жизнь, но не решает проблему. Надо хранить всю базу дообучения, при апгрейде заниматься переобучением, и получать новые шары с волосами которые работают хуже предыдущих.
Согласен, это лучше, если для > 10 человек: сейчас пару недель потерять, потом за пять минут долетать.
Но когда ты один и растишь её под себя -- мы получаем старый добрый "а хочу ли я переходить на новую сетку, или проблемы не стоят профита"
Какая конфигурация необходима или рекомендуется для дообучения?
Ха. На днях мне надо было сделать визуализацию неких данных. На коленке, то есть качество кода меня не особо волновало — в том числе и наличие дыр в безопасности (доступ к площадке все равно только у меня). И кодить самому было лень.
Решил размяться с DeepSeek. Написал ТЗ в таком виде, как оно было бы понятно человеку, включая допускающий вольное трактование оборот «представление данных должно быть удобно для человека». Оно бодро выдало рекомендации, позадавало уточняющие вопросы, как я просил, и засело кодить, сделав при этом вполне разумные предположения по недостающим в ТЗ пунктам — и согласовав их со мной.
Первая итерация не удалась. Я просто скормил обратно сообщение об ошибке, оно «нашло» проблему, и всё тут же заработало как было описано, о чём я радостно сообщил.
У меня возникли вопросы относительно некоторых конструкций в коде, и я получил понятные и разумные объяснения, включая область применимости подхода и потенциальные проблемы.
Дальше было интереснее. Я захотел «немного подкорректировать» результат. Объясняю, что хочу получить, получаю обратно код, не работает, копирую сообщение об ошибке, новый код не работает, снова сообщение об ошибке, завелось. Еще несколько итераций по той же схеме. Результат получился логически правильный, но понравился мне меньше исходного — это был мой просчёт в предположениях о структуре исходных данных.
Я попросил откатить.
И получил первоначальный код с ошибками, немного другой, но (не) делающий то же самое. Как откатить на некоторый промежуточный шаг, я не понял. Git же к нему не прикрутишь? Или можно?
В итоге я смирился с мелкими несовершенствами и оставил первоначальный (работающий) вариант.
Мой вывод: быстро накодить что-то не критичное на коленке — очень удобно, и намного быстрее, чем руками. Но сколько-нибудь развесистый проект оно не понимает.
Конечно, я в этой области дилетант. Но хочу учиться, потому что вижу перспективу. Надеюсь, мой комментарий кому-нибудь поможет, и буду благодарен за советы по дальнейшему развитию.
Какой жирный байт. В смысле о вайб-кодинге не говорят? Все уже успели посмеяться над этим. В смысле заменяет миддл-разработчиков? Даже не близко.
Очередной low-effort кусок текста для фарма плюсиков.
Никогда LLM не заменит мидл-разработчика, но мидлов, которые не пользуются LLM уже скоро не останется, это уже базовый скилл, как пользоваться гуглом. Локальная дообученная LLM это уже норма.
Только если у нас понятие "мидл разраб" будет продолжать развиваться. Примерно как тест Тьюринга меняем сразу как только сеточка его проходит :)
Что бы эффективно пользоваться LLM нужно
а) глубокое понимание работы с LLM
б) глубокое понимание архитектуры языка на котором генерируется код
Т.е., не мидл-разработчик не может выполнять мидловские задачи. Вопрос в том, что теперь скорость работы как самого программиста возросла экспоненциально (здесь можно привести много исключений, но исключения, как известно, подтверждают правило), так и путь от джуна к мидлу - сократился (опять-таки, здесь можно привести множество исключений, но ... ) раз так в десять, то есть, примерно на порядок. Сделаем ремарку - сократился в плане скиллов, а не в плане "уверенности их практического применения". Просто, когда ты получаешь рабочий код, идеально соответствующий твоим запросам - скилл растёт молниеносно. Так же сократился и путь от мидла к сеньору, ну и так далее...
Что бы эффективно пользоваться LLM нужно
а) глубокое понимание работы с LLM
Спорно. Достаточно не доверять нейросети и полагаться на мозги. Знать что такое токены, трансформеры, эмбединги и прочее - для пользования не сильно нужно.
скорость работы как самого программиста возросла экспоненциально
Экспоненциально...вот это уже не просто спорно, а прямо не правда. Во многих задачах попытка использования ЛЛМ замедляет(и раздражает), то есть в среднем есть небольшая прибавка, но даже до "кратной" там далеко.
Ну хорошо, "скорость работы как самого программиста возросла экспоненциально"
при условии использования популярного языка на базовых задачах
при условии отсутствия редких языков/фреймворков/библиотек для которых малая база знаний
при условии достаточного контекстного окна
Т.е., если LLM отвечает двум простым требованиям:
Достаточная база знаний
Достаточное контекстное окно
То она не может ошибиться, тупо исходя из базовых законов*/принципов информатики. Это как смена ламп на кремний, а точнее смена гугла на нейронки, потому что нейронка, по большому счёту, это информационный провайдер, чем и являлись поисковики.
* - например: "Любую проблему в компьютерной науке можно решить с помощью еще одного уровня косвенности, за исключением, конечно, проблемы слишком большого количества косвенностей"
То она не может ошибиться, тупо исходя из базовых законов*/принципов информатики.
Вы точно хорошо знакомы с LLM? Они галлюцинируют, они выдумывают код, иногда делают не то, что нужно, и забывают предыдущие изменения(из-за контекста). Нейросети не надёжный источник данных, они сыпятся на задачах Джун+.
Небольшая оговорка - нейросети весьма хороши во фронтенде, по понятным причинам.
Речь шла о принципах лежащих в основе всех LLM, а не об эффективности различных моделей, которых на данный момент десятки тысяч.
При условии
правильного изначального процесса обучения LLM, т.е., базовые принципы программирования, документация языка/фреймворка/бибилиотеки и прочее (а тут надо сказать, что с этим проблем нет и практически все основные LLM модели себя зарекомендовали как абсолютно надёжные в этом вопросе)
достаточной базы знаний
достаточного контекстного окна
достаточной информации в запросе к LLM
то возможность ошибки LLM стремится к нулю. Она не абсолютно нулевая, но околонулевая, где-то в районе одного шанса на гугол (
) (абстрактно, точное число мне неизвестно, но с каждой новой итерацией новых поколений LLM - вероятность падает экспоненциально, сейчас можно сказать уже практически нулевая).
Конкретно в случае с используемой вами моделью, выделенным ей контекстным окном (т.е., в случае с LLM-провайдерами - выделенной под вашего пользователя серверной мощностью), базой обучения, базой знаний, изначальным качеством модели, качеством кода скормленных ей проектов - всё это неизвестные параметры. Если вам выделено малое контекстное окно и LLM не хватает информации в запросе - то даже самая лучшая LLM не даст правильный ответ, просто начнёт галлюционировать с разной степенью вероятности успеха (иногда очень даже удачно, надо отметить). Если же вы используете даже LLM пятилетней давности, даже если установленную локально (дома, в серверной, на выделенном сервере, в облаке или в дата-центре - не важно), с достаточной базой знаний и достаточным контекстным окном - это будет более эффективно, при наличие всех необходимых данных в запросе к LLM.
С вайб кодингом разобрались. Что там с вайб дебаггингом?
Недавний опыт работы с сетками: несложный гуй на tkinter (3 уникальные формы на двух табах) для ручного тестирования оборудования, читает-пишет в can через slcan, протокол CANOpen, использовалась gpt4o-mini. На экран получил 3 экрана кода, 10% морды правил руками - нагенерил лишнего кода, который легко обобщается, всю работу с кан и канопен в итоге писал руками - гпт код для кан писал и переписывал код со звериной серьезностью, и если бы я не знал протокола, я бы его никогда не отдебажил.
В статье описан довольно агрессивный сценарий использования LLM, однако комментарии справедливо возвращают нас на землю.
Статья из категории, я написал свою OC за 2 часа, а если бы писал руками то потратил бы год, звучит как название какого-то аниме. Ни примеров кода ни ссылки на сервис хотя бы, ничего, просто верить. Я даже не знаю что и думать.
Привет! Можешь поделиться тем какую задачу ты программировал с помощью sonnet и если возможно фрагментами кода?
Интересный подход конечно, есть только одно небольшое но. Как было написано в статье чтобы продуктивно настроить работу агентов, распределять задачи и делать качественные ревью, нужны навыки. Навыки безусловно есть у сеньоров и миддлов, вот только этот ресурс конечен. И вот вопрос а как джунам теперь дорасти до миддлов, а тем более до сеньоров, если их повсеместно теперь заменяют ЛЛМ, не обучают и в целом реже берут на работу.
По-моему эта статья опоздала на тренд вайб кодинга примерно так же, как я с этим комментарием на статью.
Андрей Карпати завирусил вайб кодинг еще в фервале. С тех пор интерес к нему вышел на плато где-то с месяц назад, и теперь снижается, если верить гугл-трендам.
Так что (по крайней мере в англоязычном сегменте) о вайб-кодинге уже не говорят.
Но практиковать будут еще больше, особенно с развитием инструментов вроде свежего OpenAI Codex CLI.
О такой практике не говорят потому что ее нет, но к слову даже тут дважды ошибка, потому что о таком новом термине как вайб кодинг говорят как раз много (и почти всегда без конкретики)
Вайб-кодинг - миф. Существует и существовал копирайт-кодинг. Это когда вы используете код из интернета или аутсорса или от вашей собаки. ИИ - предоставляет наиболее простой/дешёвый способ копирайт-кодить....но за рамками этого - все очевидные проблемы копирайт-кодинга остаются (непонимание процесса работы, непонимание самого кода, невозможность полностью гарантировать надёжность кода, повышение сложности процесса при отходе от шаблонных задач). И скоро (пару лет) это станет так же очевидным и для работодателей.
Давно не читал такого качественного материала. Спасибо вам
Вайб-кодинг: практика, о которой почему-то не говорят