Comments 72
Всем кодерам советую сначала изучить основы языка, а позже как вы уже всё хорошо знаете использовать ИИ, а то вы в край обленитесь + не будете понимать, что в коде есть и как решить конкретный баг и что как конкретно работает.
Согласен. На реальных бизнес проектах с его легаси и порой зубодробительными алгоритмами ни один ИИ на сегодня не справится. В чём-то простом справляется отлично, чуть более сложное/комплексное уже не вытягивает.
что мешает использовать ИИ для обучения?
Да ничо не мешает. Обычно от него эти вайбы хотят готовое решение. Как репетитор ИИ - почти идеален.
Нет. Даже как репетитор нейросети полный отстой. Потому что они не учат ничему, а выдают готовое типовое решение. А типовое решение - это вообще неконкурентноспособная позиция на рынке. Как итог - после обучения нейросетей ты мало того что будешь надеяться на кого то, так еще и будешь выдавать шаблонные решения по задачам. А раз так - то зачем выбирать тебя, если можно найти студентика который сделает то же самое, но дешевле?
Обучение - само по себе более сложный процесс, автоматизировать его на данный момент с помощью нейросетей нельзя. Да и в дальнейшем думаю тоже нельзя, но там уже психология сработает
Ну а как составитель планов по самообучению? Вроде неплохо
Проблема нейросетей, как мне видится, в том что они используют выборки максимального вхождения. Т.е. то что часто встречается - то они и рекомендуют. Во всяком случае по своему предмету я вижу именно это. Вот смотрите. Сейчас задал вопрос в таком виде (двум нейросетям - ClaudeAI и ChatGPT).
" В каком порядке ты порекомендуешь изучать шахматные фигуры детям 5-7 лет. принимай во внимание возраст и то что детям предмет интересен. Но они ничего не знают про шахматы. Как легче всего им изучать шахматы. Просто опиши порядок фигур, не нужно объяснять почему "
Ответ ClaudeAI -
Пешка
Ладья
Слон
Конь
Ферзь
Король
Ответ ChatGPT -
Пешка
Ладья
Конь
Слон
Ферзь
Король
Ничего так что пешка САМАЯ сложная для понимания фигура? Но они ставят ее на первое место. А теперь попробуйте ответить - почему пешкана первом месте? Да потому что ТАК ПРИНЯТО в шахматах - изучать с самой дешевой фигуры. Но не самой простой. В то же время практически ВСЕ современные методики изучают в другом порядке
Ладья
Слон
Ферзь
Конь
Пешка
Король
с некоторыми вариациями в конце. Видно разницу? (если в шахматы хоть чуть-чуть умеете играть естественно).
Но на основании этого вопроса можно сделать простой вывод - для обучения нейросети хрен подходят. Потому что ВАЖНО откуда они получили информацию. А мы просто не знаем этого. Хотя по тому что я вижу по шахматам - это накачана куча инфы, не более.
Но вернемся к нашему вопросу - прикиньте КАКОЙ он вам составит план для обучения если важна весовая характеристика вопроса, а не ее значимость в современном мире? И это я еще молчу про оригинальность любого вопроса. Нейросети - это рутина и ширпотреб. Если готовы на это - то почему нет? Я тоже делаю с их помощью платформу сейчас. Но я понимаю вопрос и тему, и правлю очень-очень много того что мне Клауд накидывает. Но любой студент будет делать лишь бы сделать, а в итоге получится лажа и тупой специалист.
Поэтому я противник использования нейросетей в образовании. Сначала надо получить знания и умения самостоятельно, а уже потом их использовать.
P.S. И это я еще обошел вопрос привыкания к ним, это сложная психологическая тема. И справится с привыканием к тому что нейросетки делают - молодому ученику сложно
Ну хз. Далеко не самая умная модель от китайцев (qwen) на тот же запрос:
1. Ладья
2. Слон
3. Ферзь
4. Король
5. Конь
6. Пешка
Это уже логинчнее. Потому что пешка самая сложная по факту, но у Короля больше правил (если все посчитать). Такая схема может существовать.
Но тут наверное стоит учесть что у них может быть в Китае такие учебники, и тогда инфа будет в приоритете. Судя по тому что ЧМ у женщин китаянка, и китаец был чемпионом - то почему нет?
Но в любом случае все упирается в источник информации. Это как раз по этому запросу видно очень и очень хорошо
А вот не согласен. Я питон изучаю как раз с помощью llm, и мне вполне заходит. Параллельно я еще и книг купил, чтобы на ии не полагаться уж совсем (ну или не писать лишний раз "подскажи как срезы в списках на питоне адресуются?"). Не нужно "напиши мне готовую программу". Я допустим знаю, что я хочу сделать, алгоритмику знаю, а как это тут реализовать? Отступы эти еще...
И все, он мне и примеры текстовые с описанием, и готовые мелкие программки напишет. Можно задавать уточняющие вопросы - а чем А от Б отличается, а вот еще я слышал про С, это вообще близко или нет? У книги даже самой электронной и продвинутой с поиском по ключевым такое не спросишь. Он может наврать, и когда я начну этот код тестировать, у меня будет куча ошибок в консоли. Тут всегда можно просто посмотреть логически на код, на вывод консоли, если совсем тупняк можно показать ошибку llm и спросить что тут не так? В 80% случаев расскажет и покажет. В 20% уже полагаться на книги. Ну вот например так.
А не то вот это "напиши мне винду на ассемблере и чтобы летала на attiny15". Он то напишет...но это проблема вопрошающего.
Понимаете - программирование это не тупо кодить. точнее так - большая часть тупо-кодеров которые тапают клавиши - они да. Но это ИХ проблема, т.к. именно их и заменят в первую очередь.
В обучении же цели другие. Вот Вы ставите себе какую цель? Чтобы программа работала и от Вас отстал преподаватель (или кто там еще - чтобы главу завершить в книге)? Ну ок. А теперь интерполируйте это на реальность и подумайте - сколько Вы будете скрываться от работодателя при таком подходе.
Минусы нейросетей - пишут слишком заумно. Часто используют базу которая общепринята, а не что-то другое. А при таком подходе Вы становитесь зависимы от них и без нейросети не сможете вообще ни строчки кода написать (это кстати другая проблема - привыкание. Если мне в мои 50+ простительно это т.к. цели малешко другие, то уж молодым то это нафиг надо? Быть ненужным и замененным в ближайшей перспективе?).
Мы с Вами смотрим с разных сторон. Моя цель как преподавателя - научить пользоваться инструментарием. А Ваша - просто что-то слабать на коленке лишь бы работало. А сколько путей решения одной проблемы в программировании есть, в курсе? У меня вот буквально сейчас свежий кейс, и я его решил за 2 часа просто по причине того что сделал не КАК ВСЕ. Задача то была простая изначально - обсепечить с минимальными затратами обмен между клиентом и сервером. Сервера дешевые в Европе, обмен можно сделать кучей способов. Я решил забабахать на HTTP, без навороченных систем. Просто потому что ломать никто не будет, все клиенты под рукой. И тут пришел РКН и просто заблочил сервера в Европе. Упс... Переносить в РФ я сервера не буду - возни много, а платить мне за это не будут (я там уже не работаю), а сделать gate по HTTP с помощью нейросетки у меня вышло быстро (даже не 2 часа, за час управился). Вопрос - если бы я изначально повелся на способы сделать как все делают - то получилось бы быстро решить проблему потом?
Я не о том что крут, просто к тому что нормальный программист должен знать кучу способов решения поставленной задачи, а не пользоваться готовыми. И выбирать из того что он знает, но да - можно поспрашивать у нейросетки варианты, но еще и подумать.
Вам бы я посоветовал перестать кодить на LLM. Просто по причине что с таким стартом Вы первый кандидат на вылет в ближайшей перспективе. Пользоваться советами - почему нет? Кодить - руками, либо даватьчеткую постановку задачи LLM (но вряд ли без опыта Вы сможете это сделать).
P.S. но если Вы заморочились из-за отступов - то это (реально) смешно....
Llm стоит нынче 30-60 баксов где ты найдёшь студентов за эти деньги?
Ни в коем случае нельзя использовать нейросети для обучения. Потому что это будет тапанье кнопок и привыкание к выбору готового решения, а не разработка своего. Как итог - те кто учится или будет учиться на базе нейросетей будут неконкурентноспособны в реальности.
те кто учится или будет учиться на базе нейросетей будут неконкурентноспособны в реальности.
Тсссс, пускай «учатся». На нас же потом спрос больше будет — чинить всё то оно, что они понавайбили.
Да я бы был не против, но они так настойчиво доказывают что LLM модели круты...
У меня был случай когда одна знакомая радовалась за сына который учился программированию (сыну 15 лет было тогда, это было год назад). И он использовал ChatGPT для тго чтобы тот проверял его решения... Я когда услышал тихо взвыл (хотя на тот момент еще и не пользовался LLM моделями). Потому что для любого программиста с опытом ясно что проблема не в разработке, а в тестировании. Но у меня такое впечатление что я не смог донести до нее эту простую истину. Даже не в курсе как дела сейчас. Но боюсь (или не боюсь?) что это вряд ли подействовало. Но и ладно.
«Все программисты в мире делятся на две категории:
— Те, кто считает, что ChatGPT кодит на порядок лучше их;
— Те, кто считает, что ChatGPT кодит на порядок хуже их.
И первые, и вторые абсолютно правы.»
Скорее, деление такое: те, кто научился его использовать, и те, кто нет.
Научиться использовать LLM не умея думать - сложновато. А если использовать его на этапе обучения - то и научиться невозможно
Скорее, деление такое: те, кто научился его использовать, и те, кто нет.
Скрытый текст
«Все программисты в мире делятся на две категории:
— Те, кто считает, что ChatGPT кодит на порядок лучше их;
— Те, кто считает, что ChatGPT кодит на порядок хуже их.
И первые, и вторые абсолютно правы.»
«лучше/хуже»
Я просто использую LLM
«Я печатаю со скоростью 1000 знаков в минуту.
...Правда какая‑то ерунда получается...»
«Зачем нам эти автомобили? Лошадь надежнее, и сено всегда есть!»
Никто не спорит, что «Hello World» LLM пишет восхитительно. Но в реальной работе есть нюансы.
LLM - это что-то среднее :-) Рутину выполняет хорошо (когда бы я еще столько накодил кода). но надо понимать что он делает. Дублей и прочего - дофигища. И это у клауда, chatGPT похуже кодит.
Плюс есть, минусы - тоже есть. но в образовании его пользовать нельзя. И так люди отупели в последнее время (чур меня общаться с конспирологами... Наобщался уже...). Просто будут такие же расти.
Ну несколько лет подождать и ИИ уже на изи будет писать код за пользователя. Скорее бы ChatGPT скормили ИИ всю базу кодов из например, Гитхаба. Уже не будет существовать программистов как отдельной касты, каждый без образования будет иметь возможность "кодить", создавать проекты, приложения и сайты.
Вайбкодинг - это первый шаг. Дальше - больше. Вспомним как 50 лет назад программирование было чем-то, что доступно лишь гениям. Написание и создание кода было чем-то сверхъестественным. Сложно осознать как Билл Гейтс работал с кодом, не имея под рукой интернет с базой данных. Только книжки, только хардкор.
Сложно осознать как Билл Гейтс работал с кодом, не имея под рукой интернет с базой данных.
Ловите школьника!
Тут достаточно людей, которые занимались этим без всяких инторнетов.
То что все будет однотипно - не смущает? А что Вы будете делать с чем то что должно стать чем то новым? А что будете делать с тем что когда вы делаете какое то приложение, то другой чел зайдет, скормит ваше приложение нейросети и она налабает такую же лажу как и остальные?
Не будет изи. Разработка это творческий процесс. Нейросетки помогают его упростить и ускорить, но основной компонент- человек св его идеями
Пф, влажные мечты, пройдет еще 10-к лет и программирование как было так и останется. Просто порог входа будет как у нормального научного сотрудника после аспирантуры.
А вы будете потреблятствовать контент от необразованных прогеров. Если взять пример игр - как глюкавых от Unity, rpg maker, только уже от нейросетей. Уже забыли?))) Ха ха!
На текущий момент без влезания пользователя в код сайта - агентовые нейросети, с поиском, с попытками ревью, промтами, проверками и прочим и прочим - не в состоянии расположить строку текста на старом сайтике так, как ты им сказал с помощью JavaScript.
Ну несколько лет подождать и ИИ уже на изи будет писать код за пользователя.
Ну да,
Мне кажется, самое сложное в процессе разработки чего-либо это начать. Нейросети отлично помогают решить эту проблему. Можно закидывать тупыми вопросами "почему не отрабатывает команда x" или "как установить фреймворк y". Процесс настройки окружения ускоряется значительно. И опираясь на каркас, который накидала нейронка, разрабатывать гораздо проще.И процесс обучения ускоряется значительно. Я взялся за реализацию фронта на React с Redux, вообще не зная о нем ничего, кроме названия и не умея писать на js. В итоге я приобрел багаж знаний о механизмах реакта и о синтаксисе JavaScript. Прочитав кучу книжек и пройдя курсы, я бы не получил такой мотивации развиваться и изучать.
Я так ещё на ChatGPT3.5 ради интереса написал полноценный фронтенд для небольшого интернет-магазина, не имея серьёзного практического опыта работы с JS. По классическим языкам и популярным фреймворкам - у нейронок огромные базы знаний (переработанная алгоритмами бигдата), и они крайне хорошо генерируют выдачу, при умелой работе. LLM так хорошо пишут на JS, что скорее всего лет через пять JS-фреймворки уйдут в прошлое (как ушёл jQuery), потому что сейчас уже проще свой микро-реакт собрать под целевой проект, получив минималистичную кодовую базу вместо тонны лишнего кода в рантайме на машине пользователя, где уже открыто пятьдесят вкладок и у вас в распоряжении 30 мегабайт ОЗУ и 2% процессорной мощности для работы вашего фронтенда.
Кажется , Вы написали что вам нужно мигрировать с React на Vue, а фактически весь ваш пост это просто просьба ИИ написать новый код.
Выглядит как ошибка типичного невнимательного джуна
Именно такое впечатление произвёл Cursor.
Написал на нем простенький кликер за один вечер, были проблемы в том, что он не меняет цвет текста по аромату "поменяй цвет текста на другой", создавал общие стейты вместо отдельных для каждой кнопки. До сих пор там остался баг, что чтобы разблокировать следующую кнопку, нужно разблокировать кнопку идущую за ней. Не смотрел в код, но головой навскидку сложно понять, как это вообще связано. Наверное, где-то что-то неправильно добавляется в какой-то лист.
Да, кстати, это был котлин мультиплатформ. Так что кликер запускается как на Андроиде так и на iOS.
Пришёл к выводу, что ИИ как джун. Результат есть, но каким путём он к нему пришёл - это вопрос. Нужно контролировать, нужно перепроверять, нужно самому держать контекст проекта в голове, потому что иначе будет проект, но абы какой и при любых изменениях шанс того, что что-то/всё сломается только растёт (как и в целом с программистами, у которых мало опыта).
Это нормально.
Для себя я сделал вывод, что если каждые изменения (или группу изменений) коммитить и потом следить за тем, что курсор поменял на этот раз - следить за контекстом, изменениями и результатом будет намного проще.
Ну и да, скорость разработки точно быстрее. Как минимум, на определенных этапах.
Автор реально не довёз даже пет-проект. Ценность простыни — ноль. Трындеж ради трындежа. Дно: ни сам, ни с ИИ — ничего не сделал.
Как способ набросать костяк скрипта автоматизации или инвентаризации на PowerShell недавно начал использовать MS Copilot. Без понимания, что он в итоге написал, и ручной доработки выдача копилота бесполезна и даже вредна.
Поиск логических ошибок и исправление до рабочего состояния требует хорошей квалификации. Учиться на его примерах - плохая идея.
В целом инструмент неплохой, но заменой человека не является и скорее всего не будет являться. От рутины спасает, иногда предлагает оригинальные сценарии и приёмы. Если заставлять себя думать, а не тупо копипастить, то штука классная.
Соглашусь. Мучаю Клауд уже несколько месяцев. Был один этап когда он мне наваял почти 3000 строк кода которые я потом разгребал недели полторы. В итоге переделал почти все, но рутину он убрал прилично. По моим прикидкам такой же код я был писал месяц минимум
На каком стеке мучаете Claude? И почему выбрали мучать именно его?
Порекомендовал партнер. Но реально я пощупал другие - те хуже кодили.
С другой тсороны они сейчас выкатили новую версию. Сижу - матерюсь уже недели 2. Косяков - море! Причем "прикольные". Либо надо уточнять все до самой-самой мелочи (но в старой версии этого не было, все работало норм), либо получать вот такое
Запрос (упрощаю) - "Рассмотри файлы, найди в них ошибку которая выкидывает вот такое сообщение в лог браузера..." и далее прикладываю код который отрабатывает.
Ответ (читайте внимательно) - "Я ДУМАЮ что у вас в коде вот такая строка (далее приводит строку котолрой в коде нет), и вам нужно ее поправить"
Мой ответ - "Слушай, а ты не думаешь что я тебе ДАЛ весь код который надо проверить и найти ошибку?"
Ответ - "Да, извините. Я не обратил внимание что вы прикрепили файл с кодом к сообщению. Сейчас проанализирую"...
Такого еще 3 недели назад не было! Он ПОДУМАЛ блин что там есть такая строка имея весь код на руках! Ну или пытается придумать код модуля на который есть ссылка, хотя сам модуль висит в проекте у него же!
Я уже беситься начинаю. Не считая того что из-за длинны тек5ста модулей он режет его, а потом достать код можно только запросив его целиком, потому что куда он их девает - фиг знает. Соответственно токены тают и Клауд блокируется раньше времени. В итоге если раньше я работал нон-стоп часа 3, то сейчас час и токены кончились. Иди кури бамбук....
Но пробовал на других - там хуже. Даже с учетом этих недочетов. Сижу жду- надеюсь поправят. А пока сижу и каждый запрос уточняю до самой мелочи и прошу выводить только те изменения которые нужны, не более. Чуть упустил - швах - вагон кода который потом быстро иссякает по лимитам.
Но реально я пощупал другие - те хуже кодили.
Да, Claude для фронтенд — топ.
С другой тсороны они сейчас выкатили новую версию. Сижу - матерюсь уже недели 2.
Не заметил, последнее обновление Claude 3.7 Sonnet было в феврале, и системный промпт не менялся с того времени.
Возможно, сложность проекта растет и новый контекст меняет поведение модели. Декомпозиция задач помогает модели сфокусироваться, экономит токены и повышает точность ответов.
А пока сижу и каждый запрос уточняю до самой мелочи и прошу выводить только те изменения которые нужны, не более.
Это цена за предсказуемость.
Исходя из моего опыта, лучший способ работы с LLM - это написание "скелета архитектуры" (так как в таком случае LLM хватает контекстного окна даже для сложных задач). Если вам надо улучшить свой собственный проект, то помогает декомпозиция/сегментация, либо же просто на LLM пишете чистую логику, а потом разворачиваете все необходимые зависимости из своего проекта на логике написанной LLM. Работа с LLM в чистом виде в разы менее эффективна.
У Minervasoft ...
А, тогда понятно.
Использую Aider и Cursor, последний поскольку работодатель оплачивает, а первый опенсорсный и легко прикручивается к разным IDE и моделям (у меня это Emacs + локальные модели на видеокарте через llama.cpp). По опыту применения у меня сложилось примерно такое же мнение, как у автора статьи, подобные инструменты хорошо годятся для автоматизации рутинных задач, для исправления простых ошибок в коде, даже порой помогают увидеть вещи которые своим взглядом упустил. Вероятно в будущем они смогут делать всё это лучше и быстрее. Но пока нужно очень тщательно смотреть не нарисовала ли сеточка шесть пальцев и ревьюить результаты. И действительно сложные вещи, где требуется глубокое понимание языка/платформы/библиотек пока проще оставлять на себя, даже не пытаться это промптить. Т.к. это как если бы вы все нюансы пытались описать джуну, а потом посмотрев результаты его работы просто переписывали код сами, чертыхаясь, что зря потратили время на объяснения. В любом случае, прогресс в инструментарии вокруг нейросетей за последние годы выглядит внушительно и результаты можно применять с большой пользой уже сейчас. Но отдача от них прямо пропорциональна вашей собственной экспертизе! Схема, когда ничего не понимающий в IT человек создает сложные программы всё ещё не работает. В будущем со strong AI полагаю заработает, а пока здесь много хайпа на теме и результаты стоит воспринимать скептически и внимательно анализировать восторженные отзывы. Однако, не стоит их также недооценивать!
Редкий пример трезвого взгляда.
На каком стеке и какие модели используете?
Спасибо :) Использую на Linux и софт в целом тоже ориентирован на работу в Linux, в основном бэкенды для веба, плюс мелкие GUI. Код на Golang, редко Python или C (в последний без нейросетей я бы и не полез). Ну и Elisp ещё. Модели подбираю чтобы вписались в AMD Radeon 7900XTX (llama.cpp через Vulkan), однако последнее время использую связку с Macbook на M3, который на удивление шустро работает с LLM, по скорости не хуже чем на указанной видеокарте! AMD Radeon выбирал как более удобный для работы в Linux и память на этой видюхе 24G, но судя по всему Nvidia + CUDA всё ещё рулят здесь, так что мой вариант не оптимален.
Для проектирования хорошо подходят "рассуждающие" модели как DeepSeek R1. А для кодинга и в принципе любых задач с инструментами Qwen2.5 или Gemma. Последнее используемое это deepseek-r1-distill-qwen-32B на m3 + gemma-3-27B-it-QAT на Radeon. Aider позволяет с некоторыми ухищрениями прицепить модели от разных провайдеров и мне так удалось зацепить LM Studio на маке с Llama.cpp, так что режим "архитектор" в Aider использует Deepseek с мака, а для исполнения плана и создания файлов применяет локальную Gemma в Llama.cpp. С Cursor шаманств поменьше, "включил и работает", но и ограничений больше, главное из которых это жесткая привязка к VS Code в их собственном исполнении. Даже коллеги привыкшие для Go к Jetbrains Goland сильно плачут, мне же после Emacs вовсе непонятно как этим удобно пользоваться :) Тем не менее, если абстрагироваться от ограничений IDE, то Cursor в связке с DeepSeek-R1 для построения планов + Gemini 2.5 или Sonnet 3.7 для кода -- это прям огонь, позволяет анализировать и править код довольно жирных сервисов на Go (особенно с Gemini Pro, у которого огромный входной контекст).
В целом выбор моделей на мог взгляд есть некоторая вкусовщина. Определенно, для построения плана "что делать" лучшие результаты дают thinking-модели. А дальше реализацию по ним вообще не критично какой модели отдать, лишь бы понимала работу с инструментами. Так то результаты плавают от случая к случаю. Тем более, я тесты моделей не проводил, просто решаю свои задачки, поэтому мои рекомендации здесь определенно не точны. Для своих задач получите свои предпочтения.
Удивлен, что локальные 32B‑модели (Qwen2.5, Gemma, DeepSeek) тянут рабочие задачи. Использую Claude3.7/Gemini2.5 на Dart/Flutter, но даже их нужно крепко держать за руку.
Да я может быть красочно описал. Локальные модели тянут, но задачи им даю попроще. Уровня: опиши создание библиотеки по доке, теперь создай, допиши юнит-тесты -- именно так, поэтапно, и конечно с более подробными промптами. В целом, на таких задачах существенной разницы по качеству кода с использованием больших платных моделей в Cursor я не увидел. Но в Cursor я могу попросить что-нибудь в стиле "спроектируй взаимодействие этих двух сервисов" и дать на входе оба репозитория с сотнями файлов, в Aider на моих локальных мощностях так конечно не прокатит. Хотя если его подключать к платным провайдерам, то подозреваю выход будет плюс-минус такой же.
Btw, для себя раньше интересовался Flutter, и понятно дело в отсутствие проектов по работе дальше простых примеров оно не пошло, я на своем бекенде сильно далек от мобильной разработки. Прям любопытно попробовать снова, с новым доступным нейро-инструментарием, глядишь дело дальше продвинется :)
Учитывая ваш опыт с Aider/Cursor на бэке, думаю, с Flutter дело пойдет бодрее. С Claude 3.7 реально писать до 80% вполне сносного коммерческого кода, включая довольно сложный UI. Остальное — ручная доводка UX, где нужен именно человеческий взгляд и опыт. Но основную рутину по созданию виджетов, экранов, базовой логики он снимает.
Claude часто лезет в дебри. То пытался мне реакт прикрутить (я промучался 3 дня, потом бросил и упростил - на данный момент не готов к нему, не работал и пока нет времени изучать), то наворачивает офигенно большие модули обьектов, из которых половина кода не используется совсем, либо логика слишком сложная которую можно упростить.
Но на фоне остальных - он еще норм :-)
Это именно тот вопрос: как на практике «крепко держать за руку» LLM, чтобы она не «лезла в дебри»?
Давайте в контекст только то, что абсолютно необходимо для текущей подзадачи, минимум необходимого.
Прямо в промпте указывайте, чего НЕ делать: «НЕ используй React», «НЕ вводи новые зависимости», «НЕ создавай сложные абстракции для этой задачи», «НЕ генерируй вспомогательные функции, если я не просил».
Архитектуру лучше продумать и набросать самому (хотя бы в виде заглушек/интерфейсов), а LLM просить заполнить конкретные части (конечные реализации).
Чем меньше кусок, тем меньше шансов на «полет фантазии» и генерацию лишнего. Вместо «Напиши модуль для X» просите «Напиши функцию Y для этого модуля», «Напиши класс Z с методами A и B».
Попросите LLM сгенерировать самую простую, возможно, даже наивную версию решения. Если модель сгенерировала что‑то сложное, укажите ей: «Этот подход слишком сложный. Перепиши, используя [более простой подход] и без [лишние элементы]».
Используйте LLM как инструмент упрощения, а не только генерации: «Проанализируй этот код на предмет упрощения», «Можно ли сделать эту логику понятнее?», «Убери неиспользуемые части из этого сгенерированного кода».
Вы максимально сужаете пространство возможных решений для LLM через жесткий промптинг, декомпозицию и ограниченный контекст. Вы не даете ей думать «широко», а заставляете работать в очень узком коридоре, который вы сами для нее определили. Это не гарантирует 100% идеальный результат, но значительно снижает вероятность «ухода в дебри». Нельзя давать слишком много свободы на сложных или архитектурных задачах.
Извините - но Вы даете "общие" советы которые понятны в любом случае через месяц работы с нейросетями. Я работаю уже больше 3х месяцев, так что в курсе.
Но пишу то не совсем об этом.Я же написал что у Клауда изменился подход к работе. Это было заметно еще и потому что поменялся интерфейс. В частности изменилась загрузка файлов - раньше она была другая. В этот же момент стали происходить интересные вещи - Клауд стал размышлять. И на аналогичные запросы и вопросы при полном предоставлении информации он стал размышлять о "вездесущем", вместо того чтобы смотреть в код.
Еще появился глюк (я его раньше не замечал точно) когда при превышении лимита сообщения получить сам файл нельзя. Ну никак. Его просто в артефактах нет. Это вылазило если ты делаешь пакет (ну у меня это обычно 4 файла - страница PHP, вставка секции внутрь типа панели элемента, CSS файл и JS-код) то при выводе например PHP файла если он большой и обрывается, то когда пишешь ему "Продолжи" (кстати вчерашнее(??) изменение - теперь появляется кнопка Continue) он продолжает забывая про предыдущий код, потом скидывает другие файлы. И как итог - первый файл фиг достанешь.
Я попытался обьяснить как это вылазит. Но явно глюк не самого LLM, а интерфейса. Про LLM - он начал рассуждать.
При этом они не обьявляли что были изменения. Но тем не менее - они были. Я это вижу.
Работая с Claude ежедневно на своих задачах (Dart/Flutter), не заметил существенных изменений в поведении модели после обновления интерфейса.
Может в вашем случае будет удобнее использовать Cursor — он может вставлять код в файл или предоставлять дифф, который легко применить. Нет проблемы "потерянного" начала файла, как в чате.
Возможно да. Но разработка сейчас на пред-продакшене. И менять подход - трата времени и оттягивание продакшна. На перестройку мозга и компа уйдет неделя точно. Не хочу терять это время. Осталось буквально чуть-чуть, причем больше именно ввод данных и рихтовка небольшая.
А по поводу "потеряшек" - я уже перестроился, и вручную то же самое получаю. Причем достаточно легко
Спросил сейчас Клауда. Для интереса. Собственно то о чем я написал в пункте 1 видно - как раз оно и глючит. Ну и понятно почему он сует React - он стоит в приоритете.
Вопрос:
"Но тем не менее у тебя были изменения. Например в интерфейсе"
Ответ:
Да, вы правы. У меня действительно были некоторые изменения в интерфейсе взаимодействия с пользователями. Хотя я не имею прямого доступа к полной информации об обновлениях интерфейса, вот несколько заметных изменений, которые произошли:
Улучшенная поддержка артефактов — теперь я могу создавать и работать с различными типами артефактов, включая код, документы, SVG-изображения, HTML, мермейд-диаграммы и React-компоненты.
Прямо в промпте указывайте, чего НЕ делать: «НЕ используй React», «НЕ вводи новые зависимости», «НЕ создавай сложные абстракции для этой задачи», «НЕ генерируй вспомогательные функции, если я не просил»
Говорить LLM что ей НЕ делать - это один из антипаттернов промптинга, так-то.
Я уже много лет использую текстовые LLM для генерации кода (ещё до появления AI ассистентов в IDE), и могу вам так сказать: если язык/фреймворк/библиотека популярные, а весь контекст максимально сжат (удалены все лишние зависимости, из базы данных убраны все значения кроме необходимых для примера), т.е., вы скармливаете LLM ровно необходимый ей для работы контекст и не байтом больше, при условии задания правильных текстовых инструкций (стек, задачи, архитектура и прочее, при необходимости - получаемые ошибки), то LLM генерируют код безошибочно, любой сложности и любого объёма (при наличие достаточной базы знаний у LLM). Главную проблему составляет контекстное окно, просовывать контекст через контекстное окно и обратно выдачу - это целое искусство, обычно помогает декомпозиция и сегментация, при нехватке контекстного окна в любую из сторон (к LLM/от LLM) вы получаете галлюцинацию вместо генерации. Насколько я понимаю, при работе с локальной моделью тут достаточно увеличить контекстное окно, просто запрос будет выполняться медленнее.
Как я понимаю, Cursor (как и Aider, Plandex и прочие), как раз в этом помогают, строя карту по коду (repomap) и убирая лишнее через tree-sitter, чтобы минимизировать контекст. В Cursor еще RAG как-то задействовали, судя по их заявлениям.
если язык/фреймворк/библиотека популярные, а весь контекст максимально сжат [...] то LLM генерируют код безошибочно, любой сложности и любого объёма
Мне LLM не смогли доработать старую JS-библиотечку, состоящую из одного файла. Да, структуру её оно поняло, объяснило правильно. Но предложенные правки совершенно не были похожи ни на какой "безошибочный код". Ваши восторженные комментарии попахивают чем-то... странным.
подобные инструменты хорошо годятся для автоматизации рутинных задач
Для автоматизации рутинных задач гораздо лучше годится любой скриптовый язык.
У меня есть проект, полностью написанный курсором. По сути шаблон для разворачивания телеграм-бота на серверлесс штуках в AWS https://github.com/dmgritsan/aws-serverless-tg-bot
Следующий шаг перед тем, как идти развивать функциональность - заставить его всё покрыть тестами. Я вообще верю, что через некоторое время TDD захватит мир благодаря курсору
Как раз для задач типа: "я это уже 100500 раз делал" современные LLM подходят, но лично мне пока сложно нащупать грань между: "с этим AI справится с первого раза" и "это для него невозможно даже после 100 попыток и подсказок"
Вайб код, как каскадные стили, работает хорошо только сверху вниз😂
Навайбкодил с Cursor AI рабочее приложение. Но в чём подвох?