Комментарии 53
Всем кодерам советую сначала изучить основы языка, а позже как вы уже всё хорошо знаете использовать ИИ, а то вы в край обленитесь + не будете понимать, что в коде есть и как решить конкретный баг и что как конкретно работает.
Согласен. На реальных бизнес проектах с его легаси и порой зубодробительными алгоритмами ни один ИИ на сегодня не справится. В чём-то простом справляется отлично, чуть более сложное/комплексное уже не вытягивает.
что мешает использовать ИИ для обучения?
Да ничо не мешает. Обычно от него эти вайбы хотят готовое решение. Как репетитор ИИ - почти идеален.
Нет. Даже как репетитор нейросети полный отстой. Потому что они не учат ничему, а выдают готовое типовое решение. А типовое решение - это вообще неконкурентноспособная позиция на рынке. Как итог - после обучения нейросетей ты мало того что будешь надеяться на кого то, так еще и будешь выдавать шаблонные решения по задачам. А раз так - то зачем выбирать тебя, если можно найти студентика который сделает то же самое, но дешевле?
Обучение - само по себе более сложный процесс, автоматизировать его на данный момент с помощью нейросетей нельзя. Да и в дальнейшем думаю тоже нельзя, но там уже психология сработает
Ну а как составитель планов по самообучению? Вроде неплохо
Проблема нейросетей, как мне видится, в том что они используют выборки максимального вхождения. Т.е. то что часто встречается - то они и рекомендуют. Во всяком случае по своему предмету я вижу именно это. Вот смотрите. Сейчас задал вопрос в таком виде (двум нейросетям - ClaudeAI и ChatGPT).
" В каком порядке ты порекомендуешь изучать шахматные фигуры детям 5-7 лет. принимай во внимание возраст и то что детям предмет интересен. Но они ничего не знают про шахматы. Как легче всего им изучать шахматы. Просто опиши порядок фигур, не нужно объяснять почему "
Ответ ClaudeAI -
Пешка
Ладья
Слон
Конь
Ферзь
Король
Ответ ChatGPT -
Пешка
Ладья
Конь
Слон
Ферзь
Король
Ничего так что пешка САМАЯ сложная для понимания фигура? Но они ставят ее на первое место. А теперь попробуйте ответить - почему пешкана первом месте? Да потому что ТАК ПРИНЯТО в шахматах - изучать с самой дешевой фигуры. Но не самой простой. В то же время практически ВСЕ современные методики изучают в другом порядке
Ладья
Слон
Ферзь
Конь
Пешка
Король
с некоторыми вариациями в конце. Видно разницу? (если в шахматы хоть чуть-чуть умеете играть естественно).
Но на основании этого вопроса можно сделать простой вывод - для обучения нейросети хрен подходят. Потому что ВАЖНО откуда они получили информацию. А мы просто не знаем этого. Хотя по тому что я вижу по шахматам - это накачана куча инфы, не более.
Но вернемся к нашему вопросу - прикиньте КАКОЙ он вам составит план для обучения если важна весовая характеристика вопроса, а не ее значимость в современном мире? И это я еще молчу про оригинальность любого вопроса. Нейросети - это рутина и ширпотреб. Если готовы на это - то почему нет? Я тоже делаю с их помощью платформу сейчас. Но я понимаю вопрос и тему, и правлю очень-очень много того что мне Клауд накидывает. Но любой студент будет делать лишь бы сделать, а в итоге получится лажа и тупой специалист.
Поэтому я противник использования нейросетей в образовании. Сначала надо получить знания и умения самостоятельно, а уже потом их использовать.
P.S. И это я еще обошел вопрос привыкания к ним, это сложная психологическая тема. И справится с привыканием к тому что нейросетки делают - молодому ученику сложно
Ну хз. Далеко не самая умная модель от китайцев (qwen) на тот же запрос:
1. Ладья
2. Слон
3. Ферзь
4. Король
5. Конь
6. Пешка
Это уже логинчнее. Потому что пешка самая сложная по факту, но у Короля больше правил (если все посчитать). Такая схема может существовать.
Но тут наверное стоит учесть что у них может быть в Китае такие учебники, и тогда инфа будет в приоритете. Судя по тому что ЧМ у женщин китаянка, и китаец был чемпионом - то почему нет?
Но в любом случае все упирается в источник информации. Это как раз по этому запросу видно очень и очень хорошо
Ни в коем случае нельзя использовать нейросети для обучения. Потому что это будет тапанье кнопок и привыкание к выбору готового решения, а не разработка своего. Как итог - те кто учится или будет учиться на базе нейросетей будут неконкурентноспособны в реальности.
Ну несколько лет подождать и ИИ уже на изи будет писать код за пользователя. Скорее бы 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-компоненты.
Я уже много лет использую текстовые 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 рабочее приложение. Но в чём подвох?