Очень понравилась статья про элитный вайбкодинг. Выражаю восхищение автору за решение вопроса со сложным клиентом.
Но один тезис, который виден как у автора, так и в комментариях, хочется затронуть отдельно.
Тезис звучит так – 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 мне нужно было за один день понять, как работает примерно сотня классов. Документации не было, это критически важный участок системы. В прошлой жизни без документации и разработчиков на такие задачи уходили недели. С Курсором и указанием входных точек, откуда смотреть, а также в каком формате и что изучать (взаимосвязи, бизнес-логика), я за полдня погрузился в систему и увидел все ключевые точки, а также проблемы.
Документация
С MCP для Confluence для в одном проекте для документирования облачных функций, которые стали плодиться как пирожки, эта проблема была решена. Раньше было не добиться от команды документации, а сейчас она генерится быстро. Да, нужно выверять и проверять, но гораздо проще работать по живому тексту, чем с нуля.
Упрощение рефакторинга
Сколько в прошлом было случаев, когда нужно было в чужом (или своем старом) коде отрефакторить проект. И либо писать сложную тулзу (использовать существующие), которая делает замены зависимостей и обновление кода, причем дольше, чем просто самому руками везде обновить. Либо просто отложить. Сейчас можно сделать анализ зависимостей, спланировать небольшой, средний, большой рефакторинг, и по частям его осуществить.
Тесты, всякие и разные
Как и документация, тесты многие не любят писать, если это не обязательно. Стоит ли говорить, что набросать базовое покрытие тестами разных уровней можно очень быстро, равно как и поддерживать их актуальными. Да, нужно смотреть, да, нужно дорабатывать и додумывать и дописывать. Но значимая часть базовой и даже средней сложности юз кейсов может закрываться 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, на архитектуре системы, на учете как оно будет жить в продакшене и как использоваться и сколько стоить, и так далее.
Другие сферы для разработчика – от изучения рынка до планирования поездок, перевод книг
Тут даже не знаю. Прикрутив MCP, запустив несколько локальных агентов, потыкав нейтан , я получил возможность делать вещи, которые раньше занимали недели и до большинства не доходили руки. От подбора по матрице параметров нужных мест, используя какой-нибудь Places API, сочетания музеи, театры и рестораны с достопримечательностью. До опроса десятков разных источников данных и анализа, вместо сведения цифр в эксель (или загрузки в DWH + попытки приладить какой-нибудь BI для визуализации и срезов, когда ты не дата сатанист). Бери и делай, стоит только захотеть.
Знакомый попросил помочь перевести книгу, и буквально за пару поисков был найден гитхаб репо, где книга разбивается на чанки, переводится в MD, и воткнутый ключ OpenAI со средней моделькой переводит книгу.
Обработка текста непростая, когда сверстали таблицу, что она не копируется нормально (привет Хабру)? Простой скрипт, и вот уже за пару минут все прекрасно решено.
Прислали длинный текст и нет времени читать? Саммари легко и быстро.
Список сфер, где ИИ полезна и повышает эффективность, раздвигает границы, просто бесконечен.
ИИ как продукт
Попробовал сделать достаточно типовые задачи, вроде помощника по подбору билетов, или агента по анализу потенциальных ниш на рынке , исходя из общедоступных АПИ и датасетов и конкурентов. Результаты пока не блещут, но очень интересный опыт.
Боль роста
Несколько раз по пути мне попадались люди, которые прямо говорили – если я не могу сделать что-то с помощью LLM, то я просто не умею. После десятка лет опыта слышать это было тяжело, но было необходимо (как в старых фильмах сначала талантливого ученика заставляют убираться, чтобы самомнение сбить, и только потом он готов впитывать знания).
И действительно, нужно было учиться пользоваться инструментами. Сначала – промпты, простой прием “попроси LLM сгенерить промпт для тебя” сделал огромный рывок в эффетивности. Затем – Cursor rules. Затем – понимание контекстного окна, и когда ты сначала говоришь агенту планировать, а потом уже делать, и задаешь контекст, выступая в роли тимлида , если угодно. Потом – выбор более дорогих моделей, закупка тулз. И постепенно – свой локальных репозиторий 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 типов людей и бинарную систему счисления – что вы или правы, или просто не освоили этот скилл.
В конце-концов, хайп хайпом, но инструмент революционный.
Всем желаю органичного вплетения в новую реальность.
Автор: Cord
