Очень понравилась статья про элитный вайбкодинг. Выражаю восхищение автору за решение вопроса со сложным клиентом.
Но один тезис, который виден как у автора, так и в комментариях, хочется затронуть отдельно.
Тезис звучит так - LLM не нужны, это только хайп, пользы от них нет. Так ли это?
Хочу рассказать коротко о личном опыте и конкретных кейсах из работы и хобби, как я прошел полный круг - от скептика, до энтузиаста, и затем снова до скептика.
Мой главный тезис в том, что для каждой задачи - свой инструмент. И LLM с обвесами - инструмент настолько мощный для целого круга задач, что он просто на порядок бьет по эффективности старые подходы, примерно как управление инфрой в эру DevOps против ручной настройки пары сотни железных серверов, или как современная IDE против написания кода в голом редакторе.
Скептицизм
Три года назад один коллега предложил попробовать ChatGPT, который тогда набирал хайп. Я попробовал на конкретной задаче - изменить запрос к BigQuery для вычисления медианы одного из выражений. Решения, которые система выдавала, были или слишком сложные и неэффективные, или неработающие. То, что я нагуглил на stackoverflow и сделал после изучения документации, работало эффективнее и было проще. Сделав вывод, что это хайп, забросил на полгода.
Спустя полгода, когда делал сложный проект, срочно понадобилось написать небольшую утилиту для парсинга API параллельно по д��угой задаче. И при этом общаться с внешней командой. На вход был только curl запрос. Времени погружаться в контекст и экспериментировать не было. Тогда ChatGPT добавил режим с редактированием кода. Не особо погружаясь, я решил задачу-влет параллельно, делая ревью кода и не теряя контекст основного проекта. Это было необычно, и я стал более открыт, что из этих LLM может получиться толк.
Развитие - Cursor, MCP, RAG, модели, perplexity, боль роста
Тут даже сложно сказать, но постепенно я стал видеть, как более эффективно решаю старые задачи с новыми инструментами. Делаю больше, лучше, и даже то, что никогда не любил. Ниже я приведу несколько конкретных кейсов, объединенных в группы
Поиск
Самое большое изменение - это Perplexity + ChatGPT против Гугла. В гугле нельзя было сделать follow-up (кроме как через site:some-great-forum.com и ряд других подходов). В Гугле нужно было руками пробираться через левые статьи, руками смотреть и разбирать ветки форумов. В Гугле нужно было, если ты нашел какой-то пример кода, адаптировать его. Если ты исследовал серьезную тему, то полчаса-час-два могло уйти на десятки вкладок и эксперименты по красноглазию.
Теперь на большую часть вопросов можно получить быстрый ответ и уточнить его. Можно получить в виде сниппета кода. Погрузиться в новую технологию, взять типовые команды и проверить быстро по документации - можно погрузиться за полчаса, а не за полдня или неделю.
Реверс-инжиниринг
Примерно через год после ChatGPT мне нужно было за один день понять, как работает примерно сотня классов. Документации не было, это критически важный участок системы. В прошлой жизни без документации и разработчиков на такие задачи уходили недели. С Курсором и указанием входных точек, откуда смотреть, а также в каком формате и что изучать (взаимосвязи, бизнес-логика), я за полдня погрузился в систему и увидел все ключевые точки, а также проблемы.
Поиск в документации
Самое сильное изменение - поиск по синонимам и смыслу. Не помните точную фразу? Нужно саммари 10 первых результатов из поиска Confluence? LLM делает это возможным. Кстати, есть даже решения (включая open-source он-прем), которые индексируют вашу документацию и делают поиск по ней очень эффективным. И просто рабочим.
Документация
С MCP для Confluence для в одном GCP проекте для документирования облачных функций, которые стали плодиться как пирожки, эта проблема была решена. Раньше было не добиться от команды документации, а сейчас она генерится быстро. Да, нужно выверять и проверять, но гораздо проще работать по живому тексту, чем с нуля.
Упрощение рефакторинга
Сколько в прошлом было случаев, когда нужно было в чужом (или своем старом) коде отрефакторить проект. И либо писать сложную тулзу (использовать существующие), которая делает замены зависимостей и обновление кода, причем дольше, чем просто самому руками везде обновить. Либо просто отложить. Сейчас можно сделать анализ зависимостей, спланировать небольшой, средний, большой рефакторинг, и по частям его осуществить.
Тесты, всякие и разные
Как и документация, тесты многие не любят писать, если это не обязательно. Стоит ли говорить, что набросать базовое покрытие тестами р��зных уровней можно очень быстро, равно как и поддерживать их актуальными. Да, нужно смотреть, да, нужно дорабатывать и додумывать и дописывать. Но значимая часть базовой и даже средней сложности юз кейсов может закрываться LLM.
Кодревью
Авторевью внешими инструментами в Github - это мастхэв. Анализ кода, подсвет ошибок и проблем, диаграмма последовательностей - и все в каждый pull request. Экономия сотен часов тимлидов в год. Это не заменяет тимлидов, но можно фокусироваться на ключевых и сложных проблемах, и не тратить время на указание мелочей или очевидных моментов.
Нелюбимые технологии
Я всегда был больше бекендером, особенно с тех времен, как были хаки для IE, а потом JS фреймворки менялись так часто, что даже появилась шутка - придумай слово и вбей в Гугл, и найдешь такой JS фреймворк. jQuery, ExtJS, mootools, потом смена идеологии (пример SPA, VDOM и тд), и с нами Angular, React, Vue, и тд.
Туда же - верстка. Переносить в таблицы (а потом дивы) макеты из PSD (потом Фигмы) и под десяток браузеров + устройств тюнить с помощью магии HTML+CSS - не мое.
Думаю, у каждого есть какое-то слабое место, которое человек может сделать (как и я могу отдебажить баг на фронте - иногда даже поймать race condition, поднять реакт проект или верстку пофиксить), но просто не любит. Или не готов потратить X часов, чтобы стать экспертом.
Однако, как у каждого разработчика, всегда были и есть идеи. Но порог вхождения до уровня мастерства высок, равно как и отсутствие времени+желания. Теперь же с помощью LLM можно легко и прототипировать тот же фронт (и давать агенту получать обратную связь), и быстро чинить проблемы, и ускорять погружение в разы. Для того, чтобы стать экспертом, усилия приложить придется, но двигаться можно гораздо быстрее - от выжимок лучших практик и опоры на лучшие проекты в данной технологии, до конкретных реализаций
Новые технологии и рисерч/эксперименты
Я не фанат Typescript, больше люблю Golang/Python. Но для общего развития, в одном из прототипов в этом году под ключ с нуля собрал и три раза отрефакторил приложение для сбора данных с двух поставщиков и дедупликации (с medallion слоями). Докеризация, ПГ база, UI/UX, API, документация, пайплайн, тесты. Да, исходный промпт у меня был очень большой, и архитектуру я продумал заранее (на листках), равно как и схему БД. И сначала заставил одну из последних моделей спланировать все, взвесить совместно (ответив на уточнения, подсветив ошибки и риски), а затем пошагово реализовать - добиваясь результата в виде прохождения тестов, сборки в докере. Это буквально работа в роли solution архитектора на первом этапе, а затем такие рисерчи - когда ты получаешь реальные данные поставщика, тестируешь его API , и итерируешь систему на базе полученной информации.
Аналогичные итерации вместо трех дней в прошлом занимали несколько недель и это был труд целой команды программистов. Не говоря про декомпозицию задачи, отписывание всем, затем кодревью, тестирование, деплой и проверку.
А уже если ты добавляешь в эксперименты новый элемент - например, Эластик, потому что подходит для Use Case - то еще неделя-две-три уходит на настройку нового добра, отладку, чтение книг и статей, форумов с best practices. Сегодня же LLM при наличии Skills / rules + правильного контекста и инструментов (например, MCP для Гугл документации - вышел на днях - чтобы агент имел самую актуальную доку) львиная часть этой работы автоматизируется, так что ты можешь сосредоточиться на главном. На достижение результата, на trade-offs, на архитектуре системы, на учете как оно будет жить в продакшене и как использоваться и сколько стоить, и так далее.
А как же ПРОД?
Вставлю отдельный абзац. Разберу несколько случаев
Первый случае - у меня перестала с сервера идти синхронизация данных в Gcloud. С другого сервера с тем же service account работает, а с этого нет. Буквально за десяток минут я смог понять проблему - отвал был на получении токена, и на сервере сбился сервис синхронизации времени. Обычно на поиск такой штуки уходил час-два-три (особенно когда в запаре и никаких изменений , две идентичные среды).
Второй случай - команда другого проекта сильно улучшила джоб получения данных с кучи API, добавила всяких quality gates, и тд. Я когда-то тыкал этот джоб, но их версию видел впервые. В силу многий ограничений, нужно было быстро взять из их проекта и пересадить джоб к нам в проект. LLM позволила сделать мне это за пару часов под ключ, руками же вычленение кода из чужого проекта это легко денек-другой, с переписками - а что это делает, или отладкой.
Третий случай - быстрый дебаг. После обновления облачной функции GCP python3.9 до 3.11 сломалась запись в логи результатов работы с внешним API в одном поле. Буквально на второй итерации сразу был найден тонкий момент, который я упустил на ревью, и фикс был готов.
Еще один пример - я знал в целом, как получать анализы расходов в облаке. Но мне нужно было нарезать их по секциях - запросы BigQuery по источникам (самые дорогие и тяжелые + самые частые которые в сумме дают расход), классифицировать запросы (паттерны выделить у самых частых, но дающих в сумме ощутимый расход); а также другие сервисы по SKU и прочему. Я набросал анализатор, пообщавшись с LLM об алгоритмах и подходах сначала, которые подойдут. LLM подружила это с нужными эндпоинтами, а я получил инструмент срезов и группировки данных, который я до появления агента анализа в костах у Гугла даже думал как продукт сделать (а-ля не понимаешь, куда и как идут деньги и что надо оптимизировать ? Штука проанализирует).
Ну и да, я в 3 раза (речь о сотнях долларов) сократил расходы в месяц , добавив партиций и поправив запросы (чтобы партиции использовались, условно в where clause фильтр по дате записи уменьшает скан с десятка Гб до мб) на базе того анализа в одном из GCP проектов. Это уже только сам, ибо там было очевидно, low hanging fruit.
Другие сферы для разработчика - от изучения рынка до планирования поездок, перевод книг
Тут даже не знаю. Прикрутив MCP, запустив несколько локальных агентов, потыкав нейтан , я получил возможность делать вещи, которые раньше занимали недели и до большинства не доходили руки. От подбора по матрице параметров нужных мест, используя какой-нибудь Places API, сочетания музеи, театры и рестораны с достопримечательностью. До опроса десятков разных источников данных и анализа, вместо сведения цифр в эксель (или загрузки в DWH + попытки приладить какой-нибудь BI для визуализации и срезов, когда ты не дата сатанист). Бери и делай, стоит только захотеть.
Знакомый попросил помочь перевести книгу, и буквально за пару поисков был найден гитхаб репо, где книга разбивается на чанки, переводится в MD, и воткнутый ключ OpenAI со средней моделькой переводит книгу.
Обработка текста непростая, когда сверстали таблицу, что она не копируется нормально (привет Хабру)? Простой скрипт, и вот уже за пару минут все прекрасно решено.
Прислали длинный текст и нет времени читать? Саммари легко и быстро.
Список сфер, где ИИ полезна и повышает эффективность, раздвигает границы, просто бесконечен.
ИИ как продукт
Попробовал сделать достаточно типовые задачи, вроде помощника по подбору билетов, или агента по анализу потенциальных ниш на рынке , исходя из общедоступных АПИ и датасетов и конкурентов. Результаты пока не блещут, но очень интересный опыт.
Боль роста
Несколько раз по пути мне попадались люди, которые прямо говорили - если я не могу сделать что-то с помощью LLM, то я просто не умею. После десятка лет опыта слышать это было тяжело, но было необходимо (как в старых фильмах сначала талантливого ученика заставляют убираться, чтобы самомнение сбить, и только потом он готов впитывать знания).
И действительно, нужно было учиться пользоваться инструментами. Сначала - промпты, простой прием "попроси LLM сгенерить промпт для тебя" сделал огромный рывок в эффетивности. Затем - Cursor rules. Затем - понимание контекстного окна, и когда ты сначала говоришь агенту планировать, а потом уже делать, и задаешь контекст, используешь MD как память и внешние штуки типа openmemory, бьешь задачу на шаги, выступая в роли тимлида , если угодно. Потом - выбор более дорогих моделей, закупка тулз. И постепенно - свой локальных репозиторий mcp proxy, свои агенты, свои rules. Все это делает тебя более эффективным, способным делать новое и интересное.
И да, по пути бывали и тупящие модели (привет Соннету), и галлюцинации, и когда контекст упущен, и много чего еще. Все это решается путем адаптации к инструменту и пониманию, как лучше его использовать в данном конкретном случае.
Скептицизм 2.0 и AI first
В итоге, я для примерно половины задач активно применяю всякие ИИ инструменты. Курсор может работать 10-15-20 минут. И требовать корректировки.
Еще ждет освоение цепочек агентов на серьезном уровне - все вокруг хвалят.
И каждую задачу, которую я вижу, я пытаюсь посмотреть - можно ли ее решить частично с помощью ИИ (для поиска информации, анализа, идей, критики).
Но при этом во мне постоянно живет кодревьюер. Все требует проверки. И результат, и получаемый продукт, и идеи. Утверждения - фактчекинга, написанный код - прохождения тестов (которые надо проверить, чтобы там не было подгонки под результат, и были учтены все моменты). С моделью Opus 4.6 кстати, стало все сильно лучше. До этого Gemini 2.5 Pro рулил.
Как я могу эффективно и быстро проверять, что делает ИИ, и не говорить ,что это маразм? И делать то, что мои коллеги делают часами или днями?
Легко, коллеги. Это как красноглазие. Как опытный админ жопой чует, когда проблема в железе, а когда в софте, а когда кривые руки чьи-то накатили конфиг левый, или что сетевые правила виноваты, апстрим, или и правда Меркурий в ретрограде, так и опытный разработчик понимает, и когда использовать ИИ, когда - не использовать. И как быть при этом с ним на "ты".
Возвращаясь к исходному тезису - IDE сделала нашу жизнь лучше и приятнее, а волосы гладкими и шелковистыми. LLM дают нам огромный рычаг и возможности, а все обвесы к ним, а также способы организации этого дела в агентные системы и прочие конвееры - очень интересное будущее. В конечном итоге, как говорят в ML, garbage in - garbage out. И если ваш опыт с LLM не достигает хайпа, возможно, как той басне про 10 типов людей и бинарную систему счисления - что вы или правы, или просто не освоили этот скилл.
В конце-концов, хайп хайпом, но инструмент революционный. Особенно, если у вас солидная база и практический опыт, и вам нужны руки и автоматизация.
Поделитесь в комментариях личным опытом, пожалуйста. Большинство на Хабре видит пользу и толк на практике (в работе, в хобби, в обычной жизни) от LLM, MCP, агентов и прочего, или нет? Если убрать хайп и инфоцыганство, смогли ли вы поставить этот инструмент себе на службу?
